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

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% времени команды. Это точно того стоит?

Как мы тратили $2000 в год на Grafana, потому что PM привык к ней

Стартап. Всё работает, клиенты есть. Пришли к нам: сделайте правильно - IaC, автоматизация, секурность.
Сделали: Terraform, GitHub Actions, красиво.

Дошли до метрик. Стандартные Lambda-метрики в CloudWatch, ничего особенного. Начали делать CW dashboards.

На созвоне: "Нам надо Grafana. Я привык работать с Grafana, там удобно."

Это сказал PM.

Ну... ок. Если так надо.

Собрали стек на ECS: Victoria Metrics, VMAlert, Loki, Grafana, Blackbox, Yet Another CloudWatch Exporter. 3 EFS, 2 S3, ECR, Lambda для CloudTrail → Loki, GitHub Actions для сборки образов (потому что ECS не умеет ConfigMaps - каждое изменение конфига = пересборка образа, да). Service discovery, SSM, дашборды.

Месяц работы. Но красиво получилось.

Потом PM ушёл из проекта.

Через полгода на ревью стоимости: "А что это за $2000 в год?"

Только инфраструктура, без учёта работы.

Откатили на CloudWatch. Статус-страницу заменили бесплатным внешним сервисом.

---

Провал? Не совсем.

За эти полгода с нормальными дашбордами они нашли узкие места, оптимизировали Lambda, и сэкономили на compute явно больше $2k. Быстрее лямбда - дешевле лямбда.

Но то же самое можно было сделать на CloudWatch dashboards.

---

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

Перед следующим архитектурным решением спросите:
→ Кому это реально нужно, и будет ли этот человек здесь через год?
→ Какова полная стоимость владения?
→ Есть ли более простой путь к тому же результату?

Если не уверены - это именно то, для чего существует аудит инфраструктуры.

Полная история с разбором стоимости: https://medium.com/@anton_yushkov/2-000-year-grafana-tax-a-real-story-about-observability-costs-on-aws-7ee1e267b69f

Помогаю командам находить скрытые расходы, архитектурные долги и системы которые пережили свою цель.

#AWS #DevOps #Grafana #CloudWatch #Стартапы #Инфраструктура

# Вредные советы: Почему не нужно писать документацию к IT-системам

В лучших традициях Григория Остера

---
Код сам себя объясняет
Переменная tmp_var_2 - временная переменная номер два. Функция doStuff() делает штуки. Что непонятного?
Через год вы забудете, что "XX" - VIP из Швейцарии, "YY" - проблемные дебиторы. Зато какой азарт отлаживать баг в 5 утра субботы!

---
Будьте незаменимым
Держите всё в голове. Только вы знаете, как работает критическая система.
"Как это работает?" - "Сложно, лучше я сам".
Пусть звонят в 11 вечера пятницы: "Система упала".
Заболеете на неделю - отличная демонстрация ценности.

---
Экономьте время
2 часа на документацию или на фичу? Фича!
Новый DevOps три дня разбирается и роняет прод раз в месяц - мелочи. Зато больше фич в резюме!

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

---
У вас отличная память
Когда упадёт база: "Сначала остановить сервис А, потом Б, или наоборот?" - отличная тренировка памяти под стрессом.
Потеряете данные - зато какая история!

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

---
Избегайте комментариев
Настоящий код не нуждается в объяснениях.
Следующий разработчик "улучшит" ваш код, убрав множитель 1.000001, всё сломается - отличный урок.
Вы восстановите, объясняя что коэффициент компенсирует баг в библиотеке 2.1.3.

---
Пароли в голове
Только вы знаете пароль от прода.
Уйдёте в отпуск - команда проведёт незабываемое время, взламывая собственные системы.
Нужна срочная смена из-за утечки, а вы только сели в такси после встречи - пусть админы учатся креативности. Вскрытие собственного сервера отлично развивает навыки.

---
Следуя этим советам, вы создадите IT-инфраструктуру, которая работает исключительно благодаря магии и вашему личному присутствию.
Особенно генеральный директор оценит звонки среди ночи: "Всё сломалось, а Петя в отпуске на Мальдивах без связи".

#DevOps #Документация #ITЮмор #ТехническийДолг

Инженер говорит: всё оптимизировано.
Счёт продолжает расти.

Никто не врёт. Просто никто не смотрел.

Именно поэтому появляются FinOps-инженеры. Иногда это правильно. Иногда - нет.

---

Коллега прошёл собеседование на позицию FinOps.

Первый час - перечисление инструментов. Как квалификационный экзамен на знание названий, не разговор о деньгах.

Потом началась вторая часть - уже про мышление. Про cost per request, про прогнозирование, про то как делить shared costs между командами. Вот это уже интереснее.

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

Ничего плохого. Просто это диагноз.

---

За 16 лет в DevOps у меня никогда не было коллеги с должностью "FinOps инженер". Но кто-то же должен был думать про деньги.

Помню созвон, где обсуждали PoC. По плану - запустить RDS за $600/месяц. Для PoC. С минимальной нагрузкой. Надолго.

Я спросил: "Ребят, нам точно нужен вот такой инстанс? Нагрузка маленькая, но работать будет долго - может возьмём подешевле?"

Команда засмеялась. Я засмеялся тоже - чтобы не выбиваться. Никто не ответил. Даже тимлид.

Запустили. Покрутили несколько месяцев, пока не закрыли PoC. Деньги ушли. Вопрос так и остался без ответа.

Или другой момент: однажды посчитал стоимость одного и того же API на AWS и GCP при одинаковой нагрузке. Разница оказалась в 2 раза. Никто в команде этого не знал - потому что никто не считал.

https://blog.yushkov.org/ru/posts/ran-the-same-api-on-aws-and-gcp

Коллега - senior DevOps, FinOps не его специализация - открыл Cost Explorer, посмотрел на топ расходов. Самая большая строка: CloudTrail. Который стоит почти ничего. Оказалось, в части аккаунтов его настроили "с запасом" - логи писались в два региона. Трафик между регионами и генерировал расходы. Исправили по рекомендации самого AWS: один регион, синк в S3. Сэкономили $720k в год.

AWS об этом прямо говорит на своих экзаменах: "сделать можно по-всякому, но экономнее - вот так". Просто никто не запоминает советы, которые дают бесплатно.

---

Возвращаясь к FinOps.

Компания, которая искала FinOps специалиста, уже пробовала иначе: попросила кого-то из инженеров "следить за расходами". Тот находил задачи, добавлял в бэклог. Через несколько месяцев руководитель спросил: "Какие результаты?" Ответ: "Задачи в бэклоге."

Это не вина инженера. Это структурная проблема:
FinOps без полномочий = список рекомендаций, которые никто не приоритизирует.

---

Когда FinOps реально нужен?

Математика простая. FinOps инженер - это минимум ~$100k в год. Чтобы окупился - нужно находить и экономить сопоставимо.

Если ваши расходы на инфраструктуру меньше $300-500k в год - отдельная ставка, скорее всего, не окупится. Правильнее: инженеры с cost mindset плюс периодический аудит.

Но дело не только в деньгах. Важнее вопрос: есть ли у этого человека реальные полномочия что-то менять?

Потому что FinOps который "рекомендует" - это дорогой бэклог-менеджер.
FinOps который может сказать "выключаем" - это уже другая история.

---

Что делать, если вы не на том уровне трат?

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

Или нанять кого-то на разовый аудит - не отвлекая команду и не создавая постоянную ставку ради периодической задачи. В среднем первый аудит даёт 30% экономии, иногда больше - один из последних кейсов показал 50%. Без смены провайдера и без даунтайма. Для сравнения: Flexera говорит, что в среднем по рынку 42% облачных расходов тратится впустую.

---

"Работает" ≠ "работает за разумные деньги" ≠ "будет работать дёшево завтра".

---

А если честно - вы знаете, сколько тратите на каждый сервис прямо сейчас?

---

Делаю аудит IT-инфраструктуры. Нахожу не только что сломано, но и что тихо съедает бюджет.
Если в вашем AWS/GCP счёте есть строчки которые сложно объяснить - пишите, разберём.
https://itaudit.yushkov.org/

Сервис упал. Мониторинг молчал. Клиент написал первым.

Начал распутывать. Нашёл цепочку:

новый сертификат → s3 → lambda → tls_renew_server → gluu → sudo service

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

tls_renew_server - тот самый сервер, который выпускал сертификат в начале цепочки. Новый сертификат делал круг и возвращался туда откуда вышел. Через учётку человека, которого в компании уже два года как не было.

retired_colleague@tls_renew → retired_colleague@gluu → renew.sh

Он ушёл. Скрипты остались.

Починил. Поставил напоминание на 60 дней.

*Вроде работает.*

Через 60 дней сломалось снова. Через 120 - снова. Оказалось, несколько багов годами компенсировали друг друга. Я починил один - остальные перестали его прикрывать.

Полная история - по ссылке.
Блог Medium Pikabu

Однажды согласился на низкую ставку. Без ретейнера, почасово.

Любую их задачу закрывал за 10 минут. Большую — за 30. Получал копейки.
Энтузиазма — отрицательное количество. Но договор есть договор, я обещал.

В какой-то момент дошло: цена определяет отношение. В обе стороны.

Выработал систему.

Алгоритм работы с дешёвым клиентом:

1. Пришла задача → приписать 30 минут «на изучение деталей»
2. Включить таймер. Не торопясь посмотреть в чём дело
3. Сделать чай
4. Решить проблему
5. Тест. Комментарий в тикет. Ещё раз проверить. Отправить.
6. Остановить таймер

Работать стало заметно интереснее.

Качество то же. Результат тот же. Часов больше. Все довольны.

Новых таких клиентов беру только на ретейнер. Или не беру вообще.

Я ненавижу обновлять приложения на телефоне.

MS Authenticator - шрифт стал настолько крупным, что похож на бабушкофон. Было 12 строк, стало 8. Ну еперный театр - и раньше надо было крутить, а теперь ещё больше.

В приложении часов на OnePlus сменили циферблат - теперь 24-часовой формат. На аналоговом циферблате.

Команда, которая это выпустила, считает что улучшила продукт? Маркетологи, видимо, на голову насрали.

Откатиться? На телефоне - искать старый APK или восстанавливать из бэкапа. В инфраструктуре - ещё веселее.

Официальная документация утилиты от Grafana Labs. Опции указаны, версия совпадает - не работает. Собрал образ сам, из не-master ветки, из третьей подпапки.

Ubuntu 18.04 → 20.04: /usr/bin/python просто исчез. Все Ansible плейбуки сломались. Молча.

Это не лень. Это выученная боль.

"Работает" - не значит "будет работать после обновления".

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