Prometheus бесплатный. Пока не посчитаешь.

Смотришь на кластер - и начинаешь считать: а это что за поды?

prometheus-0           3387 MB
prometheus-1           3028 MB
thanos-store-0          439 MB
thanos-store-1          899 MB
thanos-query            486 MB
thanos-query            139 MB
thanos-compact          300 MB
thanos-bucket            13 MB
grafana                 334 MB
kube-state-metrics       40 MB
prometheus-operator      21 MB
prometheus-adapter       24 MB
blackbox-exporter        16 MB
node-exporter ×8         ~10 MB каждый

Это только мониторинг. ~9.5 GB RAM, 20+ подов.

---

kube-prometheus-stack разворачивает всё это одной командой. Дефолты почти разумные - надо только включить хранилище и выставить лимиты под свой кластер. По умолчанию ни того ни другого нет.

На трёхнодовом кластере стек мониторинга легко занимает 20-30% ресурсов кластера. Это до того как начал мониторить само приложение. На больших проектах мы обычно выделяем отдельный nodepool под мониторинг - минимум две ноды. Чтобы мониторинг не аффектил рабочую нагрузку. И чтобы рабочая нагрузка не влияла на мониторинг.

Это уже не просто ещё несколько подов. Это отдельные машины которые работают круглосуточно.

---

Главный пожиратель - Prometheus. И RAM и диск зависят от трёх вещей: сколько метрик, как часто скрейпишь, сколько хранишь.

Грубая математика: 100 000 метрик × 30 дней retention × скрейп каждые 15 секунд ≈ 25-40 GB. Это небольшой кластер. Нагруженный - 500K метрик → 200-300 GB. И это только Prometheus.

---

Стоимость обслуживания считают реже чем стоимость ресурсов.

Обновление стека - раз в квартал разумно, breaking changes бывают (да и при minor версии тоже, хоть и не должен). Ревизия алертов - старые rules устаревают вместе с приложениями, алерт на сервис которого уже нет это просто шум. Grafana дашборды - кто-то должен их поддерживать. Обычно никто. Потом "а почему тут данные не показываются" - а сервис переименовали три месяца назад.

Реалистично: 2-4 часа в месяц если всё здорово. Плюс время на инциденты.

---

Prometheus бесплатный.
За Datadog ты не платишь - ты же его не покупал.

Берут временем людей, ресурсами кластера и вниманием которое надо поддерживать чтобы это работало.

Ты знаешь сколько это стоит тебе?

Это мистер Коди. Он приходит к тем кто лжет и заставляет их исправиться.

Слышит по радио: "все говорят о том-то". Лезет за ручкой. "Мы с тобой говорим об этом? Нет. Значит лгут. Надо навестить."

Трасса 60. Было смешно. Запомнилось.

Листаю линкедин.
"Все используют kubernetes..."
"Все уже используют AI..."
"Все/Никто блабла..."

"Все" - это такой эвфемизм "я не знаю, но хочу набросить на вентилятор и словить хайп".
Кто эти все? Они с вами сейчас в одной комнате?

В коде переменная без значения не компилируется. В тексте - пожалуйста, написал, опубликовал и ждешь лайки.

Рука тянется к кнопке "перестать отслеживать". Не потому что я хочу что-то продемонстрировать, и пусть он жалеет что я его не читаю.
Нет.
Просто я понимаю что ничего полезного для меня он не скажет.

«Ну и заодно дай доступ к CloudSQL.»
Нашёл базу на $342 в месяц. В dev.

Разработчик попросил настроить CI/CD в GKE. Ну и «заодно». Добрался до CloudSQL - он уже создал инстанс вручную. К счастью, доступ у него только к dev.
250 ГБ - в 25 раз больше нужного. Enterprise Plus - инстанс $342/мес вместо $32 для dev. Публичный IP. В регионе, отличном от кластера - межрегиональный трафик платный, и задержки на каждый запрос.

Дал по рукам. Сделал нормально. (Это включая объяснение как пользоваться bastion host для доступа к CloudSQL без публичной сети.)

---
В течение следующих двух месяцев периодически: "а надо ещё вот это задеплоить". Новый пайп, отдельные права в GCP, допресурсы. Постоянно возникали дополнительные требования.

LB для HTTP2/gRPC, но без TLS на поде. Потом внезапно один сервис оказался WebSocket - "а чего он не работает?" Таймаут. Надо нужный ставить, а не дефолтные 30 секунд.

Потом один из сервисов убрали из GKE - "мы перенесли его в Cloud Function". Ну ок. Как будет готово - допилим IaC.

---
Вечером в пятницу разработчик объявил: "Я думаю, мы готовы деплоить в прод. Не прям срочно, но хотелось бы как можно скорее."

И привёл список из 8 пунктов.

Я настраивал 7. Один удалили. Должно быть 6. Это сильно.

Выясняется.

Тот "удалённый" сервис - это "CloudRun Function". Так Cloud Run или Function? Как деплоили? Тот же репо или отдельный?

8-й пункт - PubSub топик. Тоже создан руками.

---
Звучит как жалоба на дебилов? Ну есть маленько.

Но есть важный нюанс. Без DevOps этот же разработчик смог бы запустить всё это в прод - и оно бы работало. Некоторое время. Вполне реально.

Вот только вопрос цены. Размер инстансов? Больше чем нужно, или ещё хуже - меньше чем нужно. База в другом регионе - трафик между регионами платный, задержки на каждый запрос. Кривые права - один SA с максимальными правами на всё. Отсутствующая автоматизация и резервирование. Публичный доступ ко всему.

Молодцы, сделали так чтобы работало. Теперь давайте проверим и сделаем так чтобы работало надёжно и за разумные деньги.

Что вы почувствуете, когда ваш сайт с историей за 5 лет будет полностью удален одним неловким движением?
Я не могу вас сказать, я не был на той стороне.
Но я могу поделиться что я почувствовал когда сделал это.

Я удалил сайт с хранилищем и базой на 110 гигабайт. Это не особо много, но это вся история бизнеса за 5 лет.
Вы можете сказать - "плохо что даунтайм, наверное целый день/ночь восстанавливал?"
Нет.
Я удалил его полностью, без возможности восстановления.
Потому что там не было никаких бэкапов. Никаких. Ни настроек, ни контента. Ничего.
Сайт буквально жил на носу несущейся ракеты, и я просто был тем самым камешком что сбил его просто коснувшись.

Там не было никаких бэкапов, ни регулярных автоматических, ни ручных, и даже я перед нажатием кнопки delete не сделал бэкап.
Причина? Я удалял не прод, я удалял дев. Но из-за похожих имен я удалил очень нужный, работающий сайт.
Да, это было единое окружение для дев и прод.

Итак, что вы чувствуете? Представьте эту ситуацию:
Ваш успешный сайт/сервис/приложение работало-работало, а потом бац! и ваш сотрудник случайно его удаляет.
Давайте, не стесняйтесь, прочувствуйте это.
5 лет SEO. Позиции в Google которые копились годами - это не восстанавливается за день, это месяцы работы поисковика.
Контент написанный вручную. Аккаунты пользователей. История заказов, обращений, всего что там было.
Все что нажито непосильным трудом, длинными ежедневными часами разработки, написания, редактирования, все пропало.
Совсем пропало. Абсолютно. Исчезло.


ЗЫ:

Здесь должна быть история как мы успешно все восстановили, LessonLearned и прочий буллшит.
Но ее не будет.
Потому что здесь нечего восстанавливать. Да, картинки наверное остались. Может быть осталось что-то еще. Где-то.
Но это не восстановление из бэкапа, даже супердолгое.
Это пересоздание, кем-то как-то... Это может стоить вам бизнеса.

матрица эйзенхауэра, рис, wtf и другие матерные слова в работе инженера

"Как вы расставляете приоритеты между задачами - например, вот фронтендеры хотят срочно сейчас, и бэкендеры тоже хотят срочно сейчас, но другое?"
Я вот задумался...
Как-то не возникало раньше настолько конфликтующих задач, когда час времени влияет. Обычно хватало "сегодня сделаю", и так получалось что что-то я делал в первую очередь (попроще, понятнее, просто быстрее), а что-то во вторую, но в рамках одного дня это не существенно. Если же задача больше чем на один день - то тем более не критично.

-—
В командах с тимлидом это его головная боль. Но работая соло с несколькими командами одновременно - приходилось развивать и навыки планирования.
В-основном это выглядит как интуиция - "это быстро, сделаю", "тут надо копаться, но команде не горит, отложу и спокойно изучу", "это срочно, бросаю все и жечь напалмом".
На самом деле - тут все логично, и даже есть умные слова для определения методик.
Я их не знал, мне хватало нормального описания в книге "Тайм-менеджмент для системного администратора" Томаса Лимончелли, чем, собственно, и руководствовался все 16+ лет.

Но согласитесь, это не тот идеальный ответ, который предполагается в разговоре, где надо показать отглаженный воротничок.
Пошел изучать.

Матрица Эйзенхауэра - это тот крестик с половинами "срочно/не срочно" и "сложно/не сложно", или как-то так. Это первичный фильтр. Прод горит? Чини сейчас. Остальное - сортировка.
RICE - для планирования. (Reach × Impact × Confidence) / Effort. Дает число. Ну а потом сортируешь по величине, да и все.
WSJF - для выбора "что делать прямо сейчас". Учитывает стоимость задержки - что мы теряем каждый день пока не решили. CI/CD падает каждый третий деплой? Каждый день теряются часы инженеров. QA ждет окружение? Пока не ждет - у него есть другие задачи. Отрубился автомат в распредщитке в офисе - оооо, почти все сотрудники бездельничают, а часы капают.

-—
Вот я узнал, даже записал. В другой раз всплыл аналогичный вопрос - единственные термины что вспомнил - "матрица эйзенхауэра" и "планнинг покер".
Ну что поделать, в работе их называть мне обычно не надо)))) Хватало делать все вовремя в нужном порядке.

Если же вам надо регулярно приводить аргументы почему надо делать что-то в первую очередь - то держите конспект, и сделайте из него шпаргалку при подготовке к разговору. medium

Вы дали ИИ больше прав чем новичку в его первый день?
И чему вы удивляетесь?

Я использую ИИ (claude code), реально полезная штука. Планирую, обсуждаю архитектуру, прошу написать код, проверяю.
И никогда не позволяю "сделай что-нибудь, вот тебе права на всё".

Я собирался засечь сколько времени мне понадобится чтобы задеплоить кластер k8s с нуля в Hetzner.
ИИ сделал мне план, обсудили шаги, сгенерировал последовательный howto. Прекрасно.
Конечно, я не перепроверял каждую команду в плане. Я нормальный.

Выбрал день чтобы заняться, планировал потратить минут 30, но погрузился на два часа.
В процессе выполнения нашел ошибки, поправил, продолжил. Выглядит как реальная ежедневная работа.

Косяки были не только из-за ИИ. Конечно, всякие несуществующие параметры были. Но также повлияло несовершенство hcloud утилиты.
Например, маршруты балансировщика нагрузки: при пропущенном параметре консольная утилита создала без ошибок, успешно. Только оно не работало.

В результате, кубер кластер я создал за два часа, примерно. Делаешь по плану, что-то не так - фиксишь, продолжаешь.
Во второй прогон я поднял его за 40 минут.


Когда я читаю всякие новости "блабла сломалось из-за того что ai получил слишком широкие права; аи обошел запрет и получил права и удалил кластер;"...
Мне дико странно такое видеть.

Vercel взломали в апреле 2026 из-за нажатия "Разрешить все".

Я воспринимаю ИИ-помощников как джунов. Он пишет код, не всегда оптимальный, но очень быстро. Я планирую, правлю архитектуру, с его помощью и вместе мы получаем результат быстрее.
Но пустить его в прод, сказать "эй, сиди здесь, обрабатывай запросы, вот тебе рут-доступ" - вы ебанулись?

Казалось бы все эти истории про скайнет должны были всех научить - логическим продолжением защиты человечества является уничтожение человечества.

Вот прямо сейчас возьмите и проверьте как ваши сотрудники могут сломать вашу систему.

K8s 1.26->1.33. 4 часа нажатия кнопки "обновить" в Oracle Cloud.

Там нодпул жесткий, оказывается, а не динамический.То есть, при создании нодпула вручную указываешь AZ где создавать, отдельно для каждой ноды!!!!! и так же руками указываешь сеть.
Вот где я с благодарнростью вспомнил ноды gke, которые автоматически динамически обновляются сами, незаметно.

И вот я руками в веб-консоли нажимаю кнопку "обновить", три раза, с паузами.
Создаю новый нод пул со второй попытки, отключаю старые ноды по одной (даунтайм подов до 14 минут! что у них там с сетью?).
Снова жму "обновить" три раза... Создаю новый нодпул, отключаю старые ноды...
Жму "обновить" два раза и решаю на этом остановиться - ибо уже дофига на это потратил, и слава яйцам версия 1.34 будет актуальна до октября 2026.

Всё началось с диска D.

Помните? Игры на D, документы на D. Диск C - под систему, раз в полгода форматируем.
Один мой коллега пошёл дальше: настроил винду один раз, снял образ, и после форматирования накатывал именно его. Не переустанавливал - восстанавливал.

Прошло двадцать лет. Мы называем это "контейнерами".
Та же идея: данные отдельно, исполняемые файлы отдельно. Только теперь сама ОС стала "исполняемыми файлами". Запустил новый образ - всё работает.

И вот вопрос: зачем тогда делать do-release-upgrade на нодах кубер кластера?

Вывел ноду из ротации. Накатил новый образ. Вернул в кластер.
Это не обновление - это замена. Намного чище.

Не процесс - результат.

Я не смог объяснить что я делаю.
Я пытался простыми словами объяснить чем я занимаюсь как айтишник.

Вот эти все облака, девопс культура, сервера...

Человек взрослый, современный, пользуется телефоном, компьютером, сайтами и приложениями.
Никак.

Это было обескураживающе.

Помогите - как объяснить "пятилетнему" что такое "сервер", и что такое "облако"?
Просто, без зауми и лекций на месяц для определения терминологии.

Помните историю как я грохнул продакшен сайт без возможности восстановления? https://www.linkedin.com/posts/anton-yushkov_devops-backup-incident-activity-7458476375423963136-ri1W

Две недели прошло.
Его сейчас создают заново, и я особо помочь не могу.
Зато я могу настроить бэкап для оставшихся в живых.

Всего-то небольшой конфиг, скрипт для копирования бд и файлов на сетевое хранилище, и настройки для регулярного запуска в кластере.
Меньше одного рабочего дня на создание, еще день на отладку и проверку.

Один день обычной работы против недель на восстановление и неизвестное количество усилий.

У вас есть бэкапы? Точно?

Меня попросили рассказать про самые запомнившиеся проекты.
Ну там, стандартная фигня - звёздная история, что было самым интересным, блабла.

Это как с вакансиями - сначала пара больших абзацев про крутую команду и как мы меняем мир, потом key requirements.
Я читаю только requirements.

Короче, клиент: стартап, что-то для школ в США.
У них был рабочий проект, клиенты, нормально всё.
Правильный стартап - сделали чтобы работало, получили клиентов, на заработанное допиливают чтобы работало надёжно.

Что я знаю про проект? Полностью серверлесс - лямбды, S3, Aurora. Cognito, apigw - ну там тоже всё это есть.
Смотришь архитектуру, уточняешь детали, оптимизируешь, пишешь terraform/terragrunt, новый аккаунт, CI/CD, мониторинг. Стандартно.
Сделали, остались на поддержке - под новые фичи допилить, и всё такое.

Чем они занимаются? Честно - не знаю. Я как-то пропустил представление, или не вслушивался, или просто забыл.
Нам абсолютно насрать в чём заключается их уникальная идея. Нас спрашивали про лямбды.

Справились два девопса на полдня за пару месяцев.

Звёздная история? Её нет.
Просто обычная работа.

Есть клиенты у которых деньги есть. Есть клиенты у которых денег нет. И есть третий тип.

Вообще, насколько я заметил, владельцы успешного бизнеса не особо парятся насчет больших расходов - сальдо положительное, значит ок.
Могут нанять финопс, если бюджет позволяет, но там другие приколы, финопсы в больших конторах не дадут соврать. Там легаси и бюрократия еще круче чем в техдолге могут быть.

Владельцы загибающегося бизнеса... Наверное, у них нет денег на это, и они режут косты как попало, скорее всего не там где надо.

Владельцы же бизнеса "так себе", вроде и не загибается но и успешным успехом не назвать. Наверное, самый некомфортный тип клиентов.
Хотят вот этого всего забесплатно.
Я писал пост о них. Почти год думали, вроде решились.
Неделю им делал, красиво расписал, все подсвечено...
"если со своей стороны подтвердите что вот этот кластер не нужен (а я проверил - на него трафика нет, доменов нет, данных нет), то разом срежем половину ваших затрат. Ну и остальное вот тут, тут и тут - почти половину от оставшейся половины"
"На данный момент этот твой аудит для нас - чистый расход, никакой пользы. Это должно было быть сделано в рамках имеющегося контракта devops support."

Ну блин.

Ты потерял $35,000. Хочешь знать где?

Для тех кто регулярно платит за AWS и не уверен что понимает за что именно.

Ни один клиент не ушёл без находки. На скрине $1000/m только за extended support старых версий БД. И это не самый крупный случай.

Карта минного поля - разовый снимок инфраструктуры, чтобы сразу видеть где утекают деньги.

- Без погружения в биллинг, тарифы и учёт трафика
- Без страха выключить нужное и уронить прод
- Ты рассказываешь - я показываю что и где. Чётко, без жаргона

Посмотри как это выглядит → https://itaudit.yushkov.org/reports/demo/

Вообще, у меня есть аналогичный скрипт для k8s [https://www.linkedin.com/posts/anton-yushkov_aws-finops-cloudcosts-activity-7470511751902580736-XueG] - показывает что сомнительно что можно улучшить.
Слава kubernetes за формализованные правила и рекомендации.
Когда не надо изобретать свой собственный вариант HA, или подстраиваться к конкретной реализации софта - это удобно.

Так вот, про скрипт - лично для меня, того кто этот кластер поддерживает и обслуживает, этот дашборд кажется не очень-то и полезным.
Но вдруг кому-то интересно что можно собрать по-быстрому из k8s кластера и подсветить?

Без долгоиграющих настроек, просто разовый слепок.
https://itaudit.yushkov.org/reports/demo/k8s.html

Мне нравятся метрики.
Но я не люблю алерты.

Весь этот стек - prometheus (или victoriametrics) + grafana + alertmanager + loki, а если нужен нормальное хранение - thanos (storage, compactor, query...). Поднять несложно - а потом ныряешь в ад обслуживания.

Свои дашборды для своих метрик, свои фильтры для логов.
Бывало что приходилось внедрять всё это, включая дашборды для приложения - когда разработчик не добавил ни метрик, ни трейсов.

Сделал свою статус-страницу на обычных метриках: healthcheck подов и вычисляемые правила. Горжусь до сих пор.
Конечно, не конкурент betterstack uptime monitor (бесплатный, кастомный домен, брендинг, несколько проверок).
Но это было моё. Я сделал, оно работало в проде и было надёжным.

Да, метрики люблю - алерты в 3 ночи нет (привет, стандартный тезис от ИИ).
Автоматизация - вот ключ. Ради этого и придумали вычислительные машины.

Зачем ставить алерт, если можно сразу задать действие? Порог, правила, действие.
Автоскейлинг, рестарт, восстановление, банхаммер, принятие решений...

И всё это без ИИ. Если можешь описать правила словами - можешь автоматизировать скриптом в килобайты памяти.


PS: иногда в моменте выгоднее выключить сервис, чем масштабировать до небес)

Знаешь кого-то, кому нужно построить IT инфраструктуру для приложения с нуля?

Сегодня разговаривал с другом - говорили про управление талантами. Неожиданно, да?

Есть создатели и есть те, кто поддерживает. Некоторые компании реально умеют с этим работать: пересаживают людей на подходящие места.
Создатели создают. Поддерживающие поддерживают. И не надо их смешивать.

Я всегда был в поддержке. Это просто: есть документация, есть правила, следуй им, повторяй. Легкий старт - просто обслуживай ПК, сети, серверы, облака.

Создавать новое всегда было для меня сложно.
Не сделать - а решиться попробовать.
Но я всегда немного завидовал тем, кто создаёт. Что-то настоящее.

Идей было полно, проработанных до мелочей.
Самая глубоко проработанная - пятистраничный дизайн рюкзака для художника на пленэре. Из джинсы, вроде мягкого кейса для всех инструментов - кистей, красок, мольберта. (да, я тогда учился в художественной школе)

Ок, считаю что нашел вариант. Инфраструктура.
Надо построить ит-инфраструктуру с нуля для чего-то реального?
Я могу помочь.

Спроектирую и реализую систему под твои бизнес-задачи: масштабируемую, отказоустойчивую, высокодоступную.
GCP, AWS или bare metal Kubernetes. SOC2, PCI-DSS - если нужно.

Я понимаю что это звучит как питч. Это и есть питч. Но предложение реальное.

Что получишь: хорошо спроектированную, экономичную, воспроизводимую инфраструктуру, которая будет расти вместе с бизнесом.

Два варианта:
1. Бесплатно. Абсолютно бесплатно, в мое свободное время. У меня будет достижение, у тебя - инфра.
2. За деньги. Гарантия что работа будет сделана как договорились.

Разницу понимаешь.

PS: знаю, что большинство моих контактов и подписчиков - коллеги: DevOps и инженеры. Много спасибо за репосты и не только.

Что ты выберешь и почему?
Есть два пути и оба правильные.

AWS NACL. Нужно закрыть один порт - и сделать это можно двумя способами:
1. Добавить правило "deny" с более высоким приоритетом, перед правилом "allow".
2. Разбить одно правило "allow" на два, исключив нужный порт из разрешённого диапазона.

У нас есть вот такие причины:
Если мешать "deny" и "allow" правила - внимание рассеивается. Надо держать в голове каждый диапазон: что разрешено, что запрещено, плюс порядок нумерации. Запутаться легко.

Другое дело, если у тебя только одно "deny all" в конце - последнее правило, которое применяется последним. Тогда все остальные правила - только "allow". Проверяешь проще: смотришь только на список портов, не думаешь про тип правила.

Звучит разумно, да? А теперь нюансы.

Пока портов немного - всё хорошо. Но когда их сотни с разными диапазонами - начинается веселье.
Например, блокируем RDP 3389 - вместо одного правила получаем два диапазона.
Все порты ниже 1024 тоже закрыты (кстати, помнишь почему?).
Потом блокируем 3306, 5432, 6379 и так далее.
Уже пять диапазонов. Каждый новый блокируемый порт меняет существующее правило и добавляет ещё одно.

Вот мы и пришли к сравнению двух подходов: "deny all" и "allow all" в конце.
При "deny all" - явно разрешаем нужные порты.
При "allow all" - явно запрещаем ненужные.

Почему не выбрать один подход для всего? Потому что ситуации разные.

В AWS Network Access Control List есть два списка правил - для ingress и для egress.

Для ingress обычно используют "deny all" - безопаснее.
Для egress - "allow all", потому что обычно хочется свободно ходить из своей сети в интернет, верно?

Но если нужен полный контроль трафика - разрешаем только конкретный список портов, нужных приложению. Тоже распространённая ситуация, просто чуть сложнее.

И тут приходим к ответам на запросы))))
Когда приложение отправляет запрос куда-то, оно должно получить ответ. А по протоколам TCP/IP ответ приходит на случайный порт где-то в диапазоне 40к. 😉

Но NACL - stateless штука! Он не помнит, что разрешил спросить секунду назад, и не пропустит ответ автоматически "потому что ты только что спросил". Это фича security group.
Для NACL нужно явно описать список портов, которые можно пропустить, в каждую сторону.
Вот почему у нас есть правило allow ingress для диапазона 1024-65535. С исключениями.

Небольшие нюансы Dockerfile

Сначала чуть-чуть базовой информации:
Каждая команда в докерфайле (RUN, COPY, ADD, etc) - это отдельный слой поверх предыдущего.
Слои неимзеняемые. То есть, сли вы во второй команде меняете те же файлы что изменялись в первой - вы получаете новый слой с измененной копией тех файлов.

В частности поэтому можно встретить команды вида

RUN apt update \
  && apt install bla-bla \
  && rm -rf /var/lib/apt/lists/* \
  && apt-get purge --auto-remove -y bla \
  && rm -rf /src/*.deb

Это сделано для того чтобы в одном слое добавить нужные файлы и сразу в нем же удалить ненужные.

Отсюда следует не совсем очевидное.
В наборе команд:

COPY ./ /app
RUN chown -R blabla /app

мы получаем *два* почти одинаковых слоя с файлами /app.
То есть, увеличение размера образа.
Большой размер образа увеличивает время старта приложения, и стоимость его хранения.