Как мы тратили $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 плейбуки сломались. Молча.

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

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

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

"Доступно обновление системы" - знакомое сообщение? Вспомните такое окошко.
Нажал. Подождал. Готово.

В ит инфраструктуре так не работает.

---

Да, девопсы не любят обновления. Но обновлять надо - уязвимости, новые фичи, прекращение поддержки. Ладно, мы ленивые черти, мы это автоматизируем.

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

А если мы обновляем наши, инфраструктурные тулзы? Версию k8s, prometheus, grafana, логи и тд. Тут всё сложнее. То, что для разработчиков дев-среда - для нас всё равно прод. Используется. Да, не настолько критично как реальный прод, но всё же.

---

Давайте возьмём кубер для примера - там зацепим и всё остальное.

Итак, как мы обновляем kubernetes кластер:

1. Смотрим changelog
2. Проверяем список deprecated и удалённых фич
3. Проверяем кластер: какие из них у нас используются
4. Находим старые чарты, манифесты, которые на них полагаются - обновляем
5. Ищем свежую версию чарта, сравниваем: параметры, шаблоны, values, дефолтные значения, переименования
6. Обновляем values.yaml
7. helm upgrade --atomic (и --reuse-values, по ситуации)
8. Смотрим: всё установилось, запустилось, ничего не упало

Если новой версии нет, или это самописный чарт - обновляешь сам. Форкаешь, правишь шаблон, или используешь Kustomize.

А обновление самого кластера - получается, в следующий раз. Всё как в жизни.

---

Итого: мы ещё даже до самого кластера не добрались. Только чарты обновили. И уже голова пухнет.

И всё это - в голове у одного человека. Максимум что вы узнаете на созвоне - "обновляю чарты, до кластера пока не добрался, почти половина готова".

Пока он не ушёл в отпуск. Или не уволился.

Bus-factor, помним.

---

Сколько helm-чартов у вас в кластере? И когда последний раз обновляли все?

Ладно. "В следующий раз" наступил.

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

---

В случае managed - EKS, GKE, AKS - там действительно есть кнопка. С нюансами: надо следить за версиями аддонов, нод-групп, и не прыгать через минорные версии. Но в целом - терпимо.

В случае self-hosted - обновляем сами. В kubeadm нет кнопки "обновить кластер". Есть последовательность, которую нельзя перепутать:

1. Бэкап (он должен быть регулярным, но особенно - перед обновлением)
2. kubectl drain <node> - выгоняем поды с ноды
3. apt-mark unhold kubelet kubeadm kubectl
4. apt install kubelet=1.32.0-1.1 kubeadm=1.32.0-1.1 kubectl=1.32.0-1.1 - версию указываем явно
5. kubeadm upgrade apply - на мастере, потом kubeadm upgrade node на воркерах
6. Правим если что-то не так
7. kubectl uncordon <node>, проверка
8. Повторяем для каждой следующей ноды

Одна нода за раз. Не все сразу.

---

В случае kubespray, talos и подобных - обновляем через ту же систему. Но сверяем версии зависимостей: kubespray тоже не всегда успевает за upstream k8s.

После обновления: проверить поды, метрики, алерты.
Потом повторить всё то же самое на проде - с учётом косяков, найденных в деве.

---

Прошло две недели. Очередной созвон.
"Обновляю ноды, осталась последняя треть."

Это не прокрастинация. Это реально столько занимает.

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

У него куча заметок, списков, чтобы не забыть и не перепутать ничего. К сожалению, это его личные заметки, а не документация. Документацию он сделает потом, если успеет после обновления и до следующей "срочной" задачи. Хорошо бы хоть список траблшутинга был читаемым.

Если не написать документацию сразу - через месяц разобраться в заметках можно только воспроизведя весь процесс заново. При следующем обновлении он сможет быстрее фиксить проблемы. Но не избежать их.

Для менеджера это значит: новая фича - подождёт. Срочный фикс - зависит от серьёзности. Онбординг нового разработчика - не лучшее время. Обновление кластера блокирует не одну задачу - оно блокирует весь ритм команды на недели.

Bus-factor здесь не абстрактный. Это конкретно: уйдёт - и вместе с ним уйдут те заметки, список граблей с прошлого обновления, понимание "почему мы делаем вот так, а не иначе". Следующий человек начнёт сначала. С теми же граблями.

---

У вас есть runbook по обновлению кластера? Или это "спросить Васю"?
Подписывайся. Пока Вася ещё здесь.

P.S. Это было обновление самого кластера. Но есть ещё один уровень - базовая ОС под ним. Об этом в очередной следующий раз.

Потратил два часа делая всё правильно.
Terraform. CodeBuild. IAM роли. VPC endpoints.
Я ошибался.

---

У нас есть AWS China аккаунт. Приложение для китайских пользователей.

Два ECS сервиса. 0.25 CPU. Минимум памяти. Приложение + MongoDB.
Вокруг: ALB, Service Discovery, ECR, VPC, EFS, пара VPC endpoints.
Итого ~1800 юаней в месяц. Всё работает.

Образ собирается на CircleCI, пушится в AWS CN ECR.

---

Потом пуш стал падать по таймауту - 10 минут.

Образ - всего 120 МБ. Проблема не в размере.
Проблема в том, что AWS China за Великим китайским файрволом.
Скорость внешнего канала непредсказуема. CircleCI в США толкает образ в cn-northwest-1 - лотерея по времени.

---

Думаю: переехать на CodeBuild. Логика железная.

CircleCI заливает только исходники - 5 МБ. Триггерит CodeBuild внутри CN.
CodeBuild сам собирает образ и пушит в ECR. Внешний канал - только для кода, не для 120 МБ образа.

---

Понедельник, 16:00. Два часа до конца рабочего дня.

Начал делать. Увлёкся.

Дополнительный модуль Terraform. Параметры в Terragrunt. IAM роли - там всегда отдельная история: разделение прав в AWS замороченное, не зря его везде упоминают отдельно.

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

Пришло время деплоить. Я всегда в этот момент делаю паузу - отвлечься, ещё раз просмотреть, иногда проговорить вслух. Помогает поймать то, что не замечаешь в процессе.

Поймал.

ECR VPC endpoints. Их два.

Я уже думал об этом когда впервые запускал ECS. Казалось странным: ECS без ECR не работает - почему я должен платить за два дополнительных эндпойнта? Ладно, тогда принял как данность.

Но сейчас я их добавил зачем?

---

Потом посчитал.

Каждый VPC endpoint - $0.01 в час за зону. Две зоны - $14 в месяц с эндпойнта. Два эндпойнта - $29 в месяц суммарно.
Образ собирается раз в полгода.

$348 в год. За два билда.

Убрал оба - работает и без них.

---

Ладно. Но потом думаю дальше.

Я потратил 2 инженерных часа. Это не бесплатно.
CircleCI раннер с увеличенным таймаутом - сколько он стоит за запуск раз в полгода?

Посчитал: копейки.

Итог: просто увеличил таймаут до 20 минут. Закрыл тикет.

---

Это не история про лень.

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

Новый сервис. Новые права. Новые endpoints. Новые деньги. Каждый шаг логичен. Сумма - нет.

---

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

Именно это я проверяю на аудитах - не отдельные сервисы, а сумму решений.

→ itaudit.yushkov.org

Я критиковал helm-чарты bitnami за сложность. Потом сам написал такое же.

---

Было у клиента: laravel-приложение, mongodb рядом, postgres managed. Просто задеплоить. Написал chart с нуля - 30 строк. Минималка, работает.

Потом понадобились env переменные. Дописал.
Решил сразу добавить - секреты, PVC монтирование.
Потом отдельно - affinity правила. Дописал.
Решил переиспользовать для другого приложения - нашёл хардкод имени в трёх местах. Дописал хелперы. Аннотации. Метки.

Штук десять итераций примерно.

Открыл chart. Посмотрел на номер строки.

220 строк.

Не 500. Но уже не 30.

---

Вот так вот.

Bitnami чарты написаны для любого приложения в любом кластере с любыми требованиями. Из-за этого 500 строк.

Я писал под конкретный проект - и всё равно пришёл к 220, потому что реальность всегда сложнее чем кажется в начале.

Разница одна: у них всё предусмотрено заранее. У меня - по мере появления.

---

- Нужно быстро и стандартно → bitnami
- Нужен контроль над деталями → пишешь свой, это несложно.

Лично я предпочитаю идти вторым путём - мне часто нужны перламутровые пуговицы.

Универсальность стоит сложности.
Просто не всегда твоей.

Компания платит $5 000 в месяц за DataDog.

И $2 000 в месяц за CloudWatch.

Одновременно. Вся инфра - только AWS.

Я спросил: зачем оба?

- Мы привыкли.

Пять лет назад подключили DataDog - для универсальности. Или потому что планировали расширение, которое так и не случилось. Всех устраивало.

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

$7 000 в месяц на мониторинг. По привычке.

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

Им нужен Kubernetes. Это не мнение - я проверил.

Микросервисы, несколько команд, разные циклы деплоя.

Кластер есть - kubernetes нет. Использовали как сервер-помойку с кучей сайтов.

- Нагрузка без requests/limits.
- Namespace projectname-dev соседствует с website-www - то есть с продом.
- Три ноды, без автоскейлинга и мониторинга.
- StorageClass только RWO - общий диск без affinity не работает, с affinity теряется смысл.
- Деплой сырых манифестов через kubectl apply, образы с тегом latest.

И вот я пришёл. Создал Helm chart для нового сервиса с requests/limits - как положено.
Новый под завис Pending.

Кластер overprovisioned.

Вопрос не "нужен ли вам Kubernetes".

Вопрос - готовы ли вы к нему.

"БД в рид-онли, ничего не работает."

Без уточнения. Какой проект, какое приложение - не написали.
У клиента их четыре и десять.

Нашёл нужный.

Диск - 100%. Реплика - read-only:on. Смотрю размеры таблиц:

exception_logs  |  33 ГБ
failed_jobs     |  15 ГБ
jobs            |  22 ГБ

Нахрена писать логи в ту же базу что и данные?

Ладно. Смотрю что в этих логах:

cURL error 6: Could not resolve host: teams-webhook-url

В helm values кто-то добавил:

TEAMS_WEBHOOK_URL: "teams-webhook-url"

Буквально строку "teams-webhook-url". Идея - пусть берёт значение из переменной Bitbucket Pipelines. Вот только в пайплайне забыли его установить через --set.

И понеслось:

exception → пишет лог в БД → пытается отправить в Teams → хост не резолвится → exception → пишет лог → пытается отправить → ...

Пока не забило диск.

Попробовал почистить таблицы - не вышло.
База managed в OVH: пользователей создаёшь через веб-интерфейс, суперпользователя назначить нельзя - OVH не даёт.
А без суперпользователя писать в read-only базу невозможно.

Остался один вариант. Сбросил базу. Восстановил из бэкапа.

Итог: система оповещений об ошибках положила базу данных.

Бэкап был. Повезло.

Если вы узнали что прод упал - от клиента -
у вас не прод. У вас MVP.

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

На интервью DevOps-инженера спрашивают: "как вы действуете при звонке 'прод упал'?"
Хороший ответ: "такого звонка не должно быть".

Не потому что DevOps такой крутой.
А потому что система должна знать о проблеме раньше клиента. Всегда.

Как выглядит нормально:

СТО утром получает сообщение:
"Ночью упало X. Даунтайм 5 минут. Причина такая. Пофиксили так. Постмортем к вечеру."

Не звонок от клиента. Отчёт от команды.

Если у вас иначе - вопрос не к DevOps.
Вопрос к вам: как так получилось, что клиент узнал раньше?

"Прод упал" - это не задача. Это начало разговора.
DevOps знает какой прод упал - или ждёт пока объяснят?

Листал ленту LinkedIn. Увидел пост про "многие девопсы не знают" - и там вопрос: "прод упал, что сделаешь первым делом?"

Ответил в комментарии: "спрошу какой именно прод".

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

Ребят, а с чего вы взяли что это в AWS?

У одного моего клиента инфраструктура: AWS, GCP, Alibaba и AWS-CN.
Чем мне помогут логи AWS?

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

Итак, прод упал.
Что я сделаю первым?
Я спрошу: что конкретно упало, что видит клиент, как давно?

Потом - документация, ранбуки. Потом логи и метрики.

Не после того как посмотрю логи. До.

Кто не спрашивает - тот тушит соседний дом вслепую.

S3 выглядит дёшево. Пока не посмотришь в счёт.

Коллега рассказал: предложили им сделать бэкап данных в Yandex Cloud. 600ТБ.
Посчитали egress из S3.
Разговор закончился.

---

У меня была похожая история, но поменьше.

~60ТБ в S3, три аккаунта, около 50 бакетов. Приложение крутится в GKE.
Данные идут из S3 в приложение - платим S3 egress на каждом запросе.
Попросили посмотреть: может дешевле держать в GCP Buckets, раз уж инфра там?

Посчитал только хранение: S3 $1,422/мес, GCS $1,237/мес. Разница $185.
Egress при переезде $5,530 разово. Окупаемость ~30 месяцев.

Посчитал трафик: $101/мес egress S3→GKE - внутри GCP бесплатно.

Итого: экономия $286/мес. Окупаемость ~19 месяцев.

---

Но вот что интересно.

Трафик показывает: из 60ТБ за год выкачивается дай бог треть.
Остальное - мёртвый груз.

Что реально делать:

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

Переписать приложение: при получении файла из S3 - сохранять копию в GCS. Самые используемые файлы переедут сами, постепенно, без разового egress на $5,500.
Да, это время разработчика - которого всегда не хватает и которое можно потратить на фичи или закрытие уязвимостей.

---

Никто этого не делает. Потому что больно, долго, не горит.

А Amazon тебя не торопит.
Просто регулярно выставляет счёт.

Как сломать свой HA мониторинг одним дашбордом?

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

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

---

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

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

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

Thanos storage пух. Незаметно.

---

При чём здесь дашборд?

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

И этот дашборд для графиков дёргал метрики. Все метрики приложения. Все серии данных. Они короткие, но их очень много.

И тут не помогал никакой HA - при выполнении запроса promql thanos-query выжирал память как не в себя и убивался по resource limit. Каждая реплика, по очереди.

(А до этого убивал ноды, специально выделенные под мониторинг - изначально лимиты не были прописаны. Вот такой HA.)

---

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

Дашборд который должен был показывать что всё работает - ронял мониторинг при открытии.