Как потерять три часа истории мониторинга из-за одной циферки в конфиге

Знаете, что самое обидное в IT? Когда все вроде бы сделано правильно, но в критический момент система подводит. И оказывается, что проблема была в одной настройке, о которой просто забыли.

Что случилось

Делали клиенту страницу статуса сервиса — чтобы всегда видеть, работает ли все как надо. Поставили мониторинг на две отдельные машины (ноды), настроили так, чтобы они обновлялись по очереди. Казалось бы, запас надежности есть.

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

В чем была ошибка?

Представьте: у вас два сейфа для хранения важных документов. Вы думаете: "Отлично, есть резервирование!" Но все документы лежат только в одном сейфе. Второй — просто пустой, на всякий случай.

Именно это и произошло. Машин для мониторинга — две. А сам сервис, который собирает данные, запущен только на одной из них. Причем в одном экземпляре.

Когда система начала обновление этой ноды, она просто вышвырнула сервис и начала запускать новую версию. А запуск занял три часа. Почему так долго — отдельная история, но суть не в этом.

Что делают неправильно?

Можно было настроить систему так, чтобы она не давала отключить последнюю копию сервиса. Это называется PodDisruptionBudget — такая защита от дурака.

Но у нас его вообще не было. Поэтому система просто взяла и выключила единственный экземпляр.

А если бы мы его настроили неправильно — выставили минимум в 1 работающую копию при общем лимите в 1 копию — было бы еще хуже. Система не может запустить новую копию (лимит 1, а одна уже работает) и не может удалить старую (PDB требует минимум 1). Получается тупик, и обновление кластера просто зависнет навсегда.

Как правильно?

Всё просто: если сервис критичный — запускайте минимум две копии. Даже если по нагрузке хватает одной. Это и есть настоящая отказоустойчивость.

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

Мораль

Владельцы бизнеса часто думают: "Ну у меня же две машины, все должно работать надежно!" А на деле оказывается, что само приложение запущено в одном экземпляре, и никакие две машины не спасут.

Вот и получается: деньги потрачены на "надежность", а в критический момент — три часа пробела в мониторинге. А если бы это был не мониторинг, а основной сервис?

А у вас в проде сколько реплик у критичных сервисов? Один — это не отказоустойчивость, это надежда.

"В чём разница между арендовать сервер в интернете и сделать облачное приложение?"

Представь: ты можешь взять грузовик в долгосрочную аренду — он твой, пока платишь, но ты сам его заправляешь, чинишь, планируешь маршруты, нанимаешь водителя.
Сломался в дороге? Твоя проблема. Нужно везти больше груза? Арендуй второй грузовик, сам разбирайся как распределить товары между ними.

А можешь подключиться к логистической платформе: указал пункт А и Б, объём груза — система сама подобрала нужное количество машин, распределила маршруты, подключила резервный транспорт на случай поломки.
Вырос объём поставок? Платформа автоматически добавит грузовики. Один сломался? Другой уже подъехал, ты даже не заметил.

АРЕНДОВАТЬ СЕРВЕР (VPS, Dedicated) — это взять "грузовик". Ты получаешь машину с фиксированными ресурсами: 4 ядра CPU, 16 GB RAM, IP-адрес. Запускаешь всё сам — сервис, nginx, базу данных, настройки безопасности. Если нагрузка выросла в 10 раз, ты вручную поднимаешь второй сервер, настраиваешь балансировщик, синхронизируешь данные. Упал сервер ночью? Пока ты не вмешаешься, приложение недоступно.

ОБЛАЧНОЕ ПРИЛОЖЕНИЕ — это когда ты используешь управляемые сервисы провайдера (AWS ECS, Lambda, RDS, ALB).
Твой код запускается в контейнерах, которые автоматически масштабируются под нагрузку — от 1 до 100 или 1000 инстансов за минуты. База данных реплицируется, бэкапы создаются. Балансировщик распределяет трафик и отсекает упавшие инстансы. Ты строишь архитектуру, а платформа обеспечивает высокую доступность и отказоустойчивость.

Разница не в том, ГДЕ крутится код, а в том, КТО отвечает за масштабирование, надёжность и доступность.

Реальный кейс: компания просит "запустить Django API в AWS".
Я делаю ECS + ALB + автоскейлинг + Multi-AZ.
Выясняется — им нужен просто один EC2 с HTTP на порту 8000 для разработки. Это не облачное приложение, это арендованный сервер в AWS. Переплата в 5 раз по сравнению с VPS в Hetzner за €5, а преимуществ облака — ноль.

Задайте мне вопрос по теме — и я вам отвечу

Привет! Я тот человек, который следит, чтобы ваша облачная ИТ-инфраструктура работала, а не пожирала деньги.

Некоторое время назад я работал с одной компанией. Они предложили мне 25 евро в час вместо 35, мотивируя это тем, что "клиенты платят им меньше". Без фиксированной оплаты. То есть, есть задачи — я работаю, нет задач — сижу без оплаты. При этом на бюрократию уходило столько времени, что я фактически работал почти бесплатно.

И тогда я понял: я не хочу конкурировать по цене с джунами на минималке. Я не хочу ждать, пока кто-то вспомнит дать мне задачу. Я хочу решать настоящие проблемы бизнеса — чтобы после моей работы клиент зарабатывал больше и надёжнее.

Теперь я делаю по-другому. Провожу аудит, показываю что не так, объясняю что можно сделать лучше — и почему это важно для вашего бизнеса. Не просто "этот сервер быстрее", а "в этом случае вырастет стабильность приложения, улучшится SLA, и в итоге будет дешевле". Я говорю на языке денег и результата, а не только технологий.

Я верю: ИТ-инфраструктура нужна не сама по себе. Она нужна, чтобы бизнес работал без сбоев и приносил прибыль. А облако — это не волшебная кнопка "сделать всё лучше". Это инструмент, который нужно правильно настроить.

Чем я могу вам помочь:
— Аудит инфраструктуры: найду узкие места, покажу где переплачиваете, что мешает расти
— Консультации: регулярный ревьюер для команды, кто-то с большим опытом, кому можно задать вопрос
— Реализация: помогу воплотить проект после консультации

Если у вас есть ощущение "что-то работает не так" или "платим много, а толку мало" — напишите в ЛС. Обсудим вашу ситуацию по-человечески, конкретно, подробно.

Я редко делюсь своими фейлами. Но за 15 лет в IT-инфраструктуре я понял: самые дорогие и ценные уроки — из собственных ошибок. Хотя, гораздо выгоднее всё-таки учиться на чужих. Вот одна из моих.

Это было в самом начале моей карьеры. Мне дали задачу: удалить несколько строк из таблицы базы данных. На проде. Прямо в консоли. Почему сразу на проде? Сейчас уже не помню. Помню только, что я только-только разобрался, как вообще запускать команды, на примере SELECT.

Я должен был написать:

DELETE FROM users WHERE is_active = false;

Я написал:

DELETE FROM users;

Секунда. Консоль показала: "Удалено столько-то строк". Я офигел. Сделал SELECT - 0 результатов. Таблица пустая.

Секунд 10 я сидел и думал: "Как это исправить?". И понял — лично я ничего не могу. Тем более быстро. Мыслей типа "меня уволят" не было. Была только одна: исправить всё как можно быстрее.

Я пошёл к сеньёру, который мне поручил это. Рассказал что случилось.

Он был спокоен. Реально не парился. Быстро проверил, что бэкап был сделан сегодня и успешно завершился. Сказал: "А, ну щас поправим. База не особо активная на изменения, бэкап свежий, всё норм".

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

---

Что я понял тогда?

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

Во-вторых, ручные изменения на проде — это зло. Особенно если их поручают джуну без присмотра и контроля. Особенно если не отработали это на тестовом окружении.

С тех пор я пишу скрипты. Перепроверяю их на тестовых средах. Использую dry-run, если это в принципе возможно. Стремлюсь к максимальной автоматизации. Применяю атомарные операции — если что-то в цепочке команд упало, откатываются все изменения.

Теперь я слежу, чтобы доступ в прод был только у тех, кому реально надо, а все изменения проходили ревью. Я показываю джунам, как работать на тестовых средах, отрабатываем процессы вместе. А на прод руками всё равно не лезем, если можно иначе.

---

Если ты сейчас в похожей ситуации — знай:

Ошибки случаются. Даже у тех, кто делает это 10 лет. Разница в том, есть ли у тебя система, которая позволяет откатить последствия быстро и без паники.

Бэкапы, тестовые окружения, автоматизация, ревью — это не перфекционизм. Это страховка.

А ещё — если ты джун и накосячил: иди сразу к тому, кто может помочь. Не сиди в панике. Чем быстрее скажешь — тем быстрее исправите.

И да, нормальные сеньёры не уволят тебя за такое. Потому что когда делегируешь — ты должен быть готов, что человек ошибётся. Его обучение, в том числе на косяках — это цена за то, что он будет делать работу вместо тебя.

Платите за каждый Load Balancer в GCP? Есть способ урезать счёт

Представьте: у вас 10 микросервисов в GKE. Для каждого поднят свой Application Load Balancer. Это значит 10 внешних IP-адресов. Казалось бы, мелочь — но когда сервисов становится 20, 30... счёт за IP начинает бросаться в глаза.

В чём суть проблемы?

GCP берёт деньги за внешние статические IP ($0.01/час = ~$7/месяц за каждый). Когда у вас 10 IP - это $72/месяц. Запустили ещё 10 сервисов — уже $144. Плюс управление: отслеживать DNS-записи для каждого IP, следить за сертификатами, дебажить routing. Это не космос, но больно.

Что делают неправильно?

Классическая ошибка — "один сервис = один Load Balancer". Так проще на старте, но дальше это превращается в зоопарк из IP-адресов и конфигов. Второй миф: "SSL-сертификаты дорогие, надо экономить". В GCP managed-сертификаты для HTTPS бесплатны (первые 100 штук). Проблема не в сертификатах, а в IP.

Как правильно?

Можно использовать один Application Load Balancer как прокси (аналог Nginx). Несколько доменов (service1.example.com, service2.example.com) висят на одном внешнем IP. Load Balancer по host header понимает, куда отправить запрос, и автоматом управляет SSL-сертификатами для всех доменов.

В GCP ALB оплата идёт за routing rules (~$0.025/час за правило = ~$18/мес), а не за количество балансеров. Если у вас 20 сервисов на одном LB - вы платите за один IP (~$7/мес) + 20 правил (~$360/мес) = ~$367/мес.

Нюанс: реализация завязана на специфику GCP (NEG, backend targets). Без Terraform-модуля управлять вручную - дорого по времени. Зато когда настроено — работает как часы.

Реальный пример:
- Было: 20 сервисов = 20 IP + 20 LB = ~$500-600/мес
- Стало: 1 IP + 20 routing rules = ~$367/мес

Экономия заметна, особенно если сервисов много. Если у вас 2-3 сервиса - возможно, не стоит заморачиваться. Если 20+ - точно стоит посчитать.

---

А у вас как организован Load Balancing? Сколько сервисов, сколько IP? Может, пора пересмотреть архитектуру?
Пишите - разберем ваш случай.

Альтернатива GCP ALB: Nginx-Ingress в кластере

В прошлом посте рассказывал, как использовать один Application Load Balancer вместо десятка отдельных. Но есть ещё вариант, о котором не упомянул - Nginx-Ingress + Cert-Manager внутри GKE.

Как это работает?

Поднимаете в кластере Nginx-Ingress контроллер с Cert-Manager и один Network Load Balancer перед ним. Все сервисы направляются через Nginx, который управляет роутингом и автоматически получает SSL-сертификаты через Let's Encrypt.

Во что обойдётся?

- Network LB: ~$25/мес (IP + forwarding rule)
- Compute внутри GKE: ~$15-30/мес (Nginx-Ingress требует ~0.5-1 vCPU + 512MB-1GB RAM)
- Cert-Manager: практически бесплатно
- Время DevOps: ~4-6 часов на настройку + 1-2 часа/мес на поддержку = ~$50-200/мес (зависит от ставки)

Итого: ~$90-255/мес для 20 сервисов

Против managed ALB (~$367/мес) это дешевле. Главный плюс - универсальность. Не привязан к конкретному облаку, легко мигрировать в другой Kubernetes. Минус — нужна экспертиза в настройке ingress-контроллеров и интеграции в существующий workflow.

Что выбрать?

Managed ALB - если хотите managed-решение без головной боли. Nginx - если есть DevOps-команда и планируете мультиоблачность.

---

Какой подход используете вы? Managed-решения или self-hosted? Пишите

Я каждый день нахожу что-то новое. Или разновидность старого косяка

Сейчас я DevOps/Cloud архитектор, и когда делюсь опытом, одна из первых тем - "никогда не используйте :latest в production". Эта история рассказывает мой случай "почему".

Немного контекста

Работали мы в Azure Kubernetes, команда логгинг/мониторинг. Собирали кастомный OpenSearch, пайплайн билдил образ, вешал версию и переставлял тэг :latest.

После каждого билда мы руками меняли версию в Helm чарте для деплоя. И вот сидим с коллегой, смотрим на очередной перезапуск StatefulSet и думаем:
"А зачем? Давай просто :latest используем? Мы же все равно сразу деплоим?"

Поменяли. PullPolicy был Always, вроде норм.

В чем косяк

Хватило на два деплоя в dev. Потом вылезли нюансы:
- Откатить версию просто так нельзя
- Протестировать образ отдельно перед деплоем нельзя - он сразу катится
- И главное: dev для разработчиков был dev, а для нас - вполне себе прод. Логи-то им все равно нужны)))

Быстро пофиксили, вернули версии. Рабочий момент.

Свежий пример

Месяц назад помогал команде с падением MongoDB в dev:

image: mongo  # без тэга, а значит используется latest

Ноду убрали на maintenance, под переехал и образ перекачался. А 16 дней назад вышла Mongo v8, тэг :latest переехал на нее. Под поднялся с новой версией, а в storage лежала база от старой - несовместимая. Dev не работал несколько часов.

Разработчики были удивлены - они ж в docker compose работают локально, так что для них это просто "хм, интересно, не знали что так бывает".

---

С тех пор (первого случая) я всегда использую явные версии в манифестах. :latest только в локальной разработке, и то не всегда.

Когда хочу подушнить, или объясняю нюансы, то упоминаю что: тэг :latest - это не "последняя стабильная", это "что там сейчас под этим тэгом лежит". Погуглите ":latest problems" - тонны историй "10 способов выстрелить себе в ногу".

Расскажете свою историю с :latest?

Почему ArgoCD, а не просто kubectl apply из Jenkins

Ваш CI/CD врёт вам.

"Deployment successful" не значит что в продакшене работает то, что вы задеплоили.

Увидел пост про ArgoCD. Автор объяснял с точки зрения безопасности - не надо раздавать kubeconfig, все через Git.

Правильно. Но я хочу обратить внимание на то, что ломается в три часа ночи.

Вопрос который задают: "Зачем ArgoCD? У нас Jenkins (Github Actions, GitlabCI, CircleCI, etc.) деплоит, работает же?"

Работает. А потом ты просыпаешься в три часа ночи и фиксишь срочно.

Представьте:

Push-based - это как работать над курсовой.
"Вот тебе курсовая_работа_v3_final_fix_last_checked.doc".
Правишь, проверяешь, правишь, но хочешь сохранить старый вариант, делаешь копию с другим именем. Потом решаешь что нужно иначе, берешь старую, создаешу другую новую. Потом снова правки. Через неделю у вас 5 версий файла, никто не помнит какая последняя, и в итоге сдаёте не ту.

Pull-based - это Google Doc с версионированием. Один файл, вся история сохранена. Внес правки - открыл историю, посмотрел что было раньше, откатился если нужно. Всегда понятно что актуально.

В чём реальная разница:

Jenkins задеплоил. kubectl apply отработал с exit code 0. Билд зелёный. Красота.

Но:
- Кто-то руками поправил deployment в кластере? Jenkins не узнает.
- HPA изменил количество реплик? Jenkins не видит.
- Другой пайплайн перезаписал конфиг? Jenkins пофиг.
- Манифест в Git устарел? Jenkins применил что есть.

kubectl apply - fire and forget. Выстрелил и забыл.

ArgoCD живёт в кластере. Каждые 3 минуты сверяет: "То что в Git = то что в кластере?"
Нет? Фиксит.

Но главное не это.

Главное - кто контролирует ваш production?

Jenkins, GitHub Actions, GitLab CI - это внешние инструменты. Управляются кем-то еще. Их правила, их цены, их breaking changes.

Помните Google URL Shortener? Bitnami образы MongoDB? GitHub Actions меняли расценки?

Когда CI/CD интегрирован в ваш workflow напрямую - вы зависите от него как от критической инфраструктуры. Но не контролируете.

ArgoCD - это часть вашего кластера. Под вашим контролем. Как библиотека в коде, а не внешний сервис.

Мой опыт:

Я видел и использовал оба подхода в production.

Push-based ломается тихо. Всё зелёное, а продакшн лежит. Потому что то что задеплоили != то что реально работает.

Pull-based ломается громко, сразу. Drift detection показывает расхождение. Git log - полный аудит. Rollback = git revert.

Да, ArgoCD - это ещё один компонент. Порог вхождения, настройка, поддержка.

Но для Kubernetes в production - это может критически повысить надежность.

Не всегда, иногда это оверкилл, или ваше приложение не настолько зависит от git - тогда push-based норм.

---

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

Написал большую статью про то, как я нахожу деньги в облаках 😄

Два реальных аудита, $50k сэкономленных долларов.

Обычная история: компания платит, все работает, никто не жалуется. А потом смотришь — 26 забытых IP-адресов, 300 неактивных пользователей с паролями десятилетней давности, серверы на 15% загрузке.

В статье — как это находить, как считать окупаемость аудита, и чеклист что проверять самостоятельно.

Если интересно — вот ссылка:
[Medium]

Буду рад обратной связи 🙂

В 2018-м Google закрыл goo.gl. Я не потерял ни одной ссылки — просто не использовал его.

Помню, как в 2009-м коллеги говорили: "Зачем свой сервис? Google сделал бесплатный shortener — надёжно, быстро, навсегда".

Логика казалась железной. Google - не какой-то стартап на коленке. Инфраструктура мирового уровня, команда инженеров, репутация. Зачем тратить время на свой велосипед?

В апреле 2018-го сервис закрыли. Не потому что Google злые - просто бизнес-решение. Поддержка стоит денег, монетизации нет, приоритеты сменились.

Что я наблюдал после:

Компании судорожно искали ссылки в документации, маркетинговых материалах, email-рассылках за годы. QR-коды на печатной продукции стали вести в пустоту. Часть просто смирилась с битыми ссылками.

Самое забавное - большинство мигрировало на Bitly. То есть на другой бесплатный публичный сервис.

Это повторяется постоянно:

Parse от Facebook, Google Reader, Docker Hub rate limits, Heroku free tier, некоторые Bitnami образы. Список можно продолжать.

Бесплатный сервис живёт ровно до тех пор, пока компании выгодно его держать. Это не цинизм - это бизнес.

Где граница?

Для MVP, для proof of concept, для быстрого старта - бесплатные сервисы идеальны. Тестируете идею 3 месяца? Отлично, используйте что угодно.

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

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

После 15 лет в инфраструктуре я знаю:

Бесплатное - для экспериментов.

Критическое - под контролем.

Между ними - осознанный риск.

Вы наверняка это знаете. Но, возможно, где-то в вашей инфраструктуре до сих пор есть зависимость, которая завтра может исчезнуть.

Думайте своей головой. Даже если это я говорю.

---

А какие примеры можете привести вы?

Утро пятницы. Кофе. Деплою рутинный апдейт.

kubectl get pods

ImagePullBackOff.

Что…

---

Bitnami переехали с образами MongoDB за ночь.

Старое место: docker.io/bitnami/mongodb
Новое место: docker.io/bitnamilegacy/mongodb

Мой Helm chart: "Эй, Bitnami, где монга?"
Bitnami: "Переехали. Смотри в другом репо."
Мой chart: "Мне никто не сказал."

Ноль предупреждений. Ноль редиректов. Просто исчезли.

---

Самое прекрасное?

Случилось у ТЫСЯЧ команд одновременно.
Кто-то обнаружил при рутинном перезапуске.
Другие — во время настоящего аутеджа.

GitHub затопило воплями "ПОЧЕМУ ВСЁ СЛОМАЛОСЬ"

Ответ Bitnami: "А, да, мы анонсировали. Разве не видели?"

(Они не видели.)

---

Повторюсь:

Бесплатные сервисы меняют правила.
Вы не можете засудить Docker Hub.
Вы не можете требовать SLA по аптайму.
Вы просто... адаптируетесь.

Разумный ход: Зеркалить критичные образы в СВОЙ реджистри.
Ваш AWS ECR. Ваш GCP Artifact Registry. ВАШ контроль.

Стоит $5/месяц. Спасает ваши выходные.

---

Доверять обещаниям вендоров? Конечно.
Но когда их нарушение стоит денег ВАМ, а им ничего...

Может, держать запасной план?

Было у вас "блин, а куда делся образ?" ?

P.S. На прошлой неделе писал про goo.gl - та же история

Я заметил проблем на $17,000 в год.

Клиент: "А можно без аудита? Вы же уже знаете что не так."

---

Поддерживал их инфраструктуру, заметил очевидные проблемы:

- Старый тариф (в 2 раза дороже текущего)
- Забытая тестовая нода, работает впустую
- Загрузка 30-40%, платят за 100%
- Нет автоскейлинга

Потенциальная экономия: ~$1,400/месяц

---

Предложил полноценный аудит:
40 часов - глубокий анализ, план миграции
8 часов - безопасное внедрение

Ответ: "Вы и так знаете что не так. Просто сделайте."

Перевод: "Пропустите аудит. Работайте за 1/5 цены."

---

Что они упустили:

Заметить проблему = 20 лет опыта
Починить безопасно = детальный анализ

Старая инженерная шутка:
$1 - ударить молотком
$9,999 - знать куда ударить

"Вы увидели за 5 минут" = да, потому что 20 лет учился куда смотреть.

---

Почему нужен аудит:

Какие нагрузки можно перенести без риска?
Правильный размер под реальное использование
Последовательность миграции без даунтайма
План отката когда что-то сломается

"Просто сделайте" = рулетка с продакшеном.

---

Отказались. До сих пор платят лишние $1,400/месяц.

Опыт выглядит легко.
Поэтому люди думают что он бесплатный.

Но знания - это и есть работа.

Коллега случайно увидел пароль от LDAP админа.
В git-репозитории.
Переменная называлась PASSWORD.

---

Мы все знаем, что так нельзя.
Но продолжаем.

---

Проблема

Мы храним креды в коде. Вся индустрия. В репозиториях. В конфигах. В переменных с говорящими названиями типа PASSWORD. И продолжаем пушить это в main, хотя все знаем, что это плохо.

Почему?

Потому что "здесь так принято".
Потому что быстрее.
Потому что автоматизация секретов кажется оверхедом, когда дедлайн через два дня.
Потому что "у нас же приватный репозиторий".
Потому что коллега, который полгода назад боролся с такими косяками, сам кладёт cn=admin с паролем в конфиг - и сдаётся.

Это не лень. Это усталость от борьбы с культурой, где "и так сойдёт".

Я?

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

Переношу креды в секреты CI/CD, в хранилища вроде Vault, в переменные окружения.
Каждый раз. Даже когда кажется, что "это же только для теста".

Что может помочь?

Автоматизация + последствия. Инструмент, который не даст закоммитить секрет. В некоторых организациях идут дальше: добавляют автоматическое оповещение отдела ИБ и руководства при каждом срабатывании. А там уже своя политика - где-то просто разговор, где-то влияет на премию. Когда есть реальные последствия - культура меняется быстрее.

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

И?

Ты не обязан продолжать врать себе, что "приватный репозиторий - это безопасно". Что "потом переделаем". Что "у нас же не взломают".

Коллега сегодня узнал пароль от админа LDAP случайно. Завтра - неслучайно узнает кто-то другой.

Запустил один и тот же API на AWS и GCP.

AWS: $33/месяц
GCP: $16/месяц

Код не менял. Архитектура не менялась.
Разница: в 2 раза.

---

Если выбираете serverless платформу и думаете «возьму Lambda, это же стандарт» - подождите считать бюджет.

Протестировали один и тот же API на Node.js в AWS и GCP:

- 15 млн запросов в месяц
- Среднее время выполнения: 200 мс
- Память: 512 МБ
- Без VPC, прямые HTTP-адреса

Результат

AWS Lambda: $33.63/мес

- Requests: $2.80
- Compute: $23.33
- CW Logs: $7.50

GCP Cloud Functions gen2: $15.95/мес

- Requests: $5.20
- Compute: $3.25
- CW Logs: $7.50

Разница: в 2.1 раза

Почему GCP дешевле

Цена за ГБ-секунду: $0.0000025 против $0.0000166667 у AWS - в 6.7 раза ниже.

Плюс больший бесплатный лимит (2 млн запросов против 1 млн), щедрые ограничения (60 минут выполнения против 15, память 32 ГБ против 10 ГБ).

Где AWS окупается

Экосистема. EventBridge, Step Functions, DynamoDB Streams - встроенные связки экономят время разработки.

GCP требует больше связующего кода через Pub/Sub. То, что в AWS делается встроенным триггером, в GCP - отдельный сервис.

Реальный вывод

Большинство переплачивают не из-за провайдера, а из-за архитектуры:

- Память 512 МБ там, где хватит 256 МБ - переплата в 2 раза
- 1000 отдельных вызовов вместо батчей - переплата в 1000 раз
- Логи без политики хранения - +$50 в месяц через полгода
- Раздутые зависимости - холодный старт +2 секунды
- Синхронные вызовы вместо асинхронных - двойные вызовы при повторе

Аудит инфраструктуры находит 30-40% экономии без смены провайдера. Выбор между AWS и GCP даёт максимум 2 раза сферически в вакууме, правильная архитектура - в 3-5 раз.

Сделал CI/CD. Docker правильный, билды быстрые. Prod упал через 2 дня.

Как-то делал для команды CI/CD workflow. Стандартная история: взял их образец, подрихтовал - правильные Docker-слои, минимализм, билд заранее, а не при старте контейнера.

Сделал. Задеплоилось и в dev, и в prod. Работает. Красота.

Через 2 дня звонок: "В проде всё сломалось."

Полез разбираться. Нашёл быстро: в package.json стояла зависимость с тегом :dev. Для продакшена.

То есть кто-то поставил dev-версию сторонней библиотеки в прод. В этой версии что-то изменилось - либо баг, либо breaking changes. Прод лежит.

Я сделал pipeline правильным для себя. Но забыл про команду.

Я построил всё как надо. Со своей стороны. Но забыл про главное: люди не идеальны.
Кто-то поставит :dev в прод.
Кто-то забудет зафиксировать версию.
Кто-то вообще не знает, что так нельзя.

Знаете, как "нельзя коммитить пароли в git"? Точно так же: нельзя использовать dev-версии библиотек в проде. Но правило знать мало - нужна система, которая не даст нарушить его случайно.

Раньше я строил "правильные" CI/CD со своей стороны. Pipeline работает? ✅ Моя работа закончена.

Теперь - надёжные. С автоматическими проверками не только моего кода, но и типичных косяков команды:

- Линтеры для версий зависимостей
- Проверки конфигов перед деплоем
- Автотесты на "что не должно попасть в прод"

Не потому что не доверяю людям.

А потому что хорошая система не полагается на то, что все всегда помнят правила.

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

Linux даёт мне rm -rf / - и это правильно, мне нужна эта свобода.

Но команде разработки я даю систему, где :dev в prod просто не пройдёт первичную проверку.

---

Делаю аудит IT-инфраструктуры.

Нахожу не только "что сломано", но и "что сломается при следующей случайной ошибке человека".

Потому что prod не должен падать из-за :dev в package.json.

Знаете, как положить весь проект из-за... нехватки соединений с базой?

Не трафика. Не памяти. Просто коннекты к БД закончились.

---

Как это работает: приложение общается с базой через соединения — как телефонные линии. У облачных баз есть лимит (Oracle Cloud: 300, CloudSQL: зависит от тарифа). Каждый запрос может занять одно. Звучит безобидно, пока не перестаёт.

---

История #1:

Делали Cloudways Autonomos (WordPress-хостинг с автоскейлингом). Использовали CloudSQL. Первое нагрузочное тестирование — видим: лимит коннектов всё ближе и ближе.

Хорошо, что поймали по метрикам, а не когда всё рухнуло в проде.

Фикс: CloudSQL Proxy + connection pooling.

---

История #2 (свежая):

У клиента Oracle Cloud DB. Лимит: 300 коннектов.

Месяцами работало нормально. Потом в понедельник утром: мёртв. Никаких ошибок. Никаких предупреждений. Просто перестал отвечать.

Смотрю метрики: 333 активных соединения. В планке.

Пробую перезагрузить инстанс БД — зависает.

Саппорт час вручную реанимировал. Вернулись к жизни: 4 коннекта. Четыре. Из трёхсот.

---

Почему так?

- "Мы маленькие, у нас такого не будет" (размер не важен — важно, как приложение работает с БД)
- SaaS-база = бесконечный ресурс (спойлер: нет)
- Нет мониторинга на БД, потому что "это же managed"
- Нет connection pooling в приложении

---

Как лучше:

- Connection pooling (PgBouncer, ProxySQL, облачные прокси)
- Правильные таймауты в приложении
- Мониторинг + алерты на количество коннектов (даже на SaaS)
- Кэш-слой, чтобы разгрузить БД

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

---

А у вас какие были "ой всё" моменты с базами?

Делитесь в комментах — будем учиться на чужих граблях, а не только на своих 👇

Команда из 8 человек. 12 почти одинаковых файлов. Каждое изменение копируется вручную.

Рано или поздно кто-то забудет. Конечно, это случилось.

---
Копипастили манифесты Kubernetes между dev/staging/prod. Изменили количество реплик в dev. Обновили staging. Забыли про prod.

Прод упал.

---
Проблема: ручная копипаста не масштабируется. Человеческая ошибка неизбежна.

Решение: автоматизация. Но есть три разных инструмента, и выбор не очевиден.

Коротко:
- Ручное копирование = рано или поздно сломается
- Helm = мощно, но сложно для простых задач
- Kustomize = просто, но не для всего подходит
- Гибрид = что используют опытные команды

Результат после перехода: ошибки деплоя -80%, время развёртывания вдвое быстрее.

---
⚙️ Технические детали:

Чистые манифесты = копипаста YAML на окружение. Просто вначале, кошмар в масштабе. Каждое изменение умножается на количество окружений.

Helm = пакетный менеджер (как npm для K8s). Есть базовый values.yaml, потом переопределяешь под окружение:
helm install app -f base-values.yaml -f dev-values.yaml --set image.tag=v1.2.3

Мощные шаблоны. Отлично для готовых приложений с кучей настроек.

Kustomize = система слоёв. Базовые манифесты + патчи на окружение. Никаких шаблонов - чистые YAML-оверлеи. Что видишь, то деплоишь.

Частые косяки:
- Чистые манифесты в проде (копипаста неизбежно разъедется)
- Helm для всего (боль с шаблонами для простых правок)
- Kustomize для чужого софта (300-строчные патчи = ад)

Когда что использовать:
Чистые манифесты: только PoC, одно окружение. В проде - нет.
Helm: сторонний софт, стабильные сложные приложения, lifecycle management.
Kustomize: свои микросервисы на разных окружениях, простые патчи (реплики, лимиты, домены), GitOps без дебага шаблонов.

Гибрид: Helm для зависимостей, Kustomize для своих приложений. ArgoCD поддерживает оба нативно не просто так.

Реальный пример с аудита: переход на Helm (инфра) + Kustomize (приложения). Ошибки деплоя -80%, пайплайн вдвое быстрее.

---
У вас как? Только Helm, только Kustomize или микс? Или что-то ещё?

Твой VPN работает. Сертификат протух 3 месяца назад. A ты не в курсе…

Коллега написал мне сегодня:
"У нас тихо протух CA сертификат на VPN серверах."

Тихо - потому что мониторинга не было.
Валиден был 10 лет. Никто не проверял.
Конечно, никто не заметил.

---

Вот где это больно: сертификаты на 10 лет ставят именно потому, что "не хочется думать об этом часто". Логика понятна. Но результат - ты забываешь о нём полностью.

И когда он протухает - VPN падает. Тихо. Без предупреждений. Просто перестаёт работать.

Хорошо если в рабочее время. Хорошо если кто-то заметил быстро.

---

Сделай прямо сейчас:

Проверь срок действия своих CA-сертификатов:

openssl x509 -in /path/to/ca.crt -noout -dates

Если до истечения меньше года - добавь алерт в мониторинг.
Если мониторинга нет - это и есть проблема.

---

Не для всех очевидный момент: алертить надо не на "сертификат протух", а на "до истечения осталось 90/60/30 дней". К моменту протухания уже поздно планировать - ты уже тушишь пожар.

Prometheus, Zabbix, Datadog, даже простой cron со скриптом - не важно что. Важно что это есть.

---

Всё что "работает само" и настроено больше года назад - кандидат на проверку. Сертификаты. Бэкапы. Ротация логов. Cron-джобы.

"Работает" ≠ "работает правильно" ≠ "будет работать завтра".

---

Делаю аудит IT-инфраструктуры.
Нахожу то, что протухло - до инцидента.

Запустили мы как-то видео-стриминг для нового проекта.

Инфраструктура на AWS. Выбрали App Runner.

Видео обрывалось на 2-й минуте. Причина: лимит, который нельзя обойти.

---
Вся инфраструктура компании на AWS. EC2, RDS, S3 - стандартный стек.

Новая задача: стриминг видео по запросу. Записи вебинаров, демо продукта.

Выбрали App Runner:

- Логично: уже на AWS, не плодить провайдеров
- Быстро: деплой за 10 минут
- Просто: managed, автоскейлинг из коробки

Первые недели - отлично. Короткие ролики по 60-90 секунд работали без проблем.

Потом добавили длинные видео. Записи вебинаров на 10-15 минут. И тут началось.

---
Проблема?

App Runner рубит любое соединение на 120 секунде.

Жёстко. Без предупреждения. Без настройки. Нельзя изменить даже за деньги.

Это в документации, но кто её читает, когда уже деплоишь третий сервис на той же платформе?

Результат:

- Видео обрывалось на середине
- Демо клиентам приходилось разбивать на куски
- Записи вебинаров показать полностью - невозможно

Костыли типа "нарезать видео на 90-секундные чанки" работают, но это хак, не решение.

---
Техническое ограничение = бизнес-ограничение.

- Фича, которую анонсировали клиенту → не работает
- Демо продукта → нельзя показать полностью
- Миграция на другое решение → неделя работы команды

Один параметр в документации стоил недели времени и объяснений, почему "то, что работало на тесте" не работает в проде.

---
Альтернативы внутри AWS

Lambda (Function URL): 15 минут timeout. Но холодные старты убивают первые секунды стрима.

ECS Fargate: Без лимитов. Но настройка сложнее (IAM, load balancers, scaling policies, networking).

App Runner - это про скорость разработки. ECS - про гибкость. Для 120+ секунд придётся выбрать ECS или искать обходы.

---

А что у GCP?

Cloud Run: timeout до 60 минут.

Та же модель (контейнер → URL → автоскейлинг), но лимит в 30 раз выше.

Стриминг работает из коробки. Цена сопоставима с App Runner.

Проблема здесь: это другой облачный провайдер.

- Биллинг отдельно
- Мониторинг отдельно
- IAM/права отдельно
- Команда учится новой платформе

Для одного сервиса это может быть дороже, чем костыли на AWS. Но если таких задач несколько - Cloud Run начинает окупаться.

---
Преимущества App Runner

Простые REST API, задачи <30 секунд. Если у вас уже AWS и нужно быстро задеплоить контейнер - App Runner идеален.

Но если в roadmap:

- Видео-стриминг
- Генерация отчётов >2 минут
- WebSocket/SSE
- Long-polling

Проверьте лимиты до того, как писать код.

---
Выводы (lesson learned)))
"Мы уже на AWS" - не всегда аргумент для выбора сервиса.

Иногда конкретная задача требует конкретных возможностей. App Runner, Cloud Run, Lambda, ECS - у каждого свои потолки.

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

Одна техническая деталь может стоить недели переделок. Или заставить посмотреть на другого провайдера.

---

P.S. Документацию читают либо до выбора платформы, либо после инцидента на проде. Второе - дороже.

# Новый проект. Вся инфраструктура на AWS.
Выбираем: ECS или EKS?
Команда: "Давайте K8s. Это же стандарт. Переносимость. Опыт в резюме."
Через 3 месяца считаем, во что это обошлось.

---
Вы понимаете, да?
Модно, молодежно, все вот это вот...
Инфра - AWS. Микросервисы, контейнеры!

Это нормально.

Варианта в целом два:
- ECS Fargate: AWS-специфичный, managed
- EKS: Kubernetes, "стандарт индустрии" (чувствуете сарказм, да?)

Народ выбирает EKS. Аргументы:

- "K8s знают все, найти людей проще"
- "Переносимость: завтра на GCP переедем за день"
- "Гибкость: любые варианты деплоя"

Звучит разумно? Поехали, давайте посчитаем.

---
Что же мы получим через 3 месяца разработки

EKS control plane: $73/месяц. Это фиксированно.

Минимум 3 ноды для стабильности control plane. Даже если нагрузка - один сервис на самом маленьком инстансе.

Что у нас теперь есть:

- Ingress: NGINX Ingress Controller или ALB Ingress. Настройка, обновления, мониторинг.
- Networking: VPC CNI, security groups, pod-to-pod routing.
- Monitoring: Prometheus + Grafana или покупать Datadog.
- Logging: Fluentd/Fluent Bit → CloudWatch/S3.
- RBAC: Service accounts, IAM roles for service accounts (IRSA), namespace isolation. В ECS - IAM task role, всё.
- DNS: CoreDNS, настройка, отладка.
- Обновления: Кластер*, ноды*, аддоны, CNI плагины. Каждый квартал.

Время инженера: ~20-30% уходит на поддержку кластера. Не на фичи, на инфраструктуру.

В ECS это было бы:

- Ingress: ALB, всё.
- Networking: Работает по умолчанию.
- Monitoring: CloudWatch из коробки.
- Logging: Один параметр в task definition.
- RBAC: IAM task role, всё.
- DNS: Route 53 и service discovery, работает.
- Обновления: AWS делает сам.

---
Про "переносимость"

"Завтра переедем на GCP" - красиво звучит. В реальности:

Managed K8s отличаются:

- EKS использует AWS Load Balancer Controller (CRD под AWS ALB/NLB)
- GKE использует Google Cloud Load Balancer (другие CRD)
- Bare metal - вообще свои Ingress

Если делать "чистый K8s" для переносимости:

- Не использовать managed Load Balancers → сложнее
- Не использовать IAM integration → ещё один слой авторизации
- Не использовать провайдерские storage classes → свой Persistent Volume provisioner

Это увеличивает сложность в 1.5-2 раза.

Вопросы:

- Вы реально планируете мигрировать? Когда?
- У вас есть критерии, при которых вы переедете?
- Окупится ли самоограничение или проще допилить, когда понадобится?

Большинство компаний никогда не переезжают. Vendor lock-in страшнее в теории, чем на практике.

---
Аналогия

Видел историю: начальник решил работать напрямую с фабриками в Китае, чтобы избежать наценки посредника (15%).

В итоге контейнер простоял в порту одну неделю из-за забытых таможенных документов. Штрафы стоили как два месяца поставок с посредником.

С EKS похоже:

Вы "избегаете" vendor lock-in, получаете "гибкость". Но платите временем инженеров, стабильностью, скоростью разработки.

Посредник (в данном случае AWS ECS) берёт "наценку", но решает проблемы за вас.

---
Преимущества ECS

ECS Fargate:

- Деплой за <10 минут (task definition → service → URL)
- Мониторинг из коробки (CloudWatch)
- Автоскейлинг настраивается за 5 минут
- Обновления - AWS делает сам
- Networking - работает по умолчанию

Стоимость: только за контейнеры. Нет control plane, нет "минимум 3 ноды".

Ограничения:

- Привязка к AWS
- Меньше гибкости (нет Helm, Operators, сложных patterns)
- Чистый compute - дороже за "единицу"

Но для очень многих проектов этого хватает.

---
Когда EKS оправдан

Честно? Не знаю.

Может быть:

- Высоконагруженный проект с десятками сервисов и сложными deployment patterns
- Команда уже знает K8s и не хочет переучиваться (серьезно? пять минут чтения-сравнения конфига?)
- Реальная мультиоблачность (не "может быть переедем", а уже работаете в нескольких облаках)

Но даже тогда вопрос: окупается ли сложность?

Для большинства проектов EKS - это overengineering. "Правильная" архитектура, которая стоит 30% времени команды.

---

Еще раз:

"K8s - это стандарт" - не аргумент для выбора.

ECS проще, дешевле и быстрее в разработке. EKS гибче, но дороже в обслуживании.

Проектирование архитектуры с учётом стоимости владения (не только счет от aws, но и время команды) избавляет от таких сюрпризов. Но большинство узнают о них через некоторое время после запуска.

Почти всегда "проще и чуть дороже" лучше, чем "правильно, но сложно".

---

P.S. "Гибкость" и "переносимость" звучат хорошо в презентациях. В реальности они стоят 20-30% времени команды. Это точно того стоит?