Cloud Cost Control

«У нас всё в облаке, счёт — проблема финансового директора» — позиция инженерной команды, после которой через год компания платит за забытые кластеры в dev, разросшиеся пулы узлов и базы, взятые с тройным запасом. Cloud Cost Control — это инженерная практика, а не финансовый учёт: цикл FinOps (Inform → Optimize → Operate) опирается на observability, IaC и auto-scaling — инструменты, которые уже принадлежат SRE. По моим наблюдениям, чаще именно команда SRE становится точкой ответственности за облачные траты, потому что у платформенной команды есть нужные данные и нужный доступ.

Граница: Capacity Planning отвечает на «хватит ли»; этот лист — «во что обходится и можно ли дешевле, не теряя SLO».

Что должен уметь

Главный навык на уровне L4 — считать удельную стоимость: на запрос, на активного пользователя, на обработанный гигабайт. Я регулярно вижу команды, которые отчитываются абсолютными числами («в этом квартале потратили полмиллиона на вычисления»), но не могут ответить на вопрос «а на одного активного пользователя это сколько и куда движется тренд». Без удельных метрик не отличить здоровый рост, где стоимость пользователя стабильна, от неэффективности, где она растёт быстрее выручки. Это та точка, где счёт за инфраструктуру превращается из чёрного ящика в управляемую величину.

Читает свой счёт: из чего он состоит (вычисления, хранение, исходящий трафик, управляемые сервисы, поддержка), где посмотреть стоимость по сервисам, как сравнить с прошлым месяцем.
Знает базовые рычаги: подогнать размеры под нагрузку, гасить окружения вне рабочих часов, брать резервирование и планы экономии, использовать прерываемые машины.

Считает удельную стоимость своего сервиса (на запрос, на активного пользователя, на гигабайт) и сравнивает с прошлыми периодами.
Держит дисциплину тегов: каждый ресурс размечен по team / service / environment / cost-center, и отчёт по распределению трат действительно показывает, кто сколько тратит.

Проектирует архитектуру с оглядкой на счёт: классы хранения (горячий, тёплый, холодный), правила автомасштабирования с учётом не только нагрузки, но и цены, выбор между управляемым сервисом и своим с явным расчётом полной стоимости владения.
Заводит в команде ритуалы FinOps: ежемесячный разбор с обсуждением аномалий, бюджет на инфраструктуру как явный артефакт, автоматические алерты при отклонении больше чем на N процентов.

L6+

Связывает решения по деньгам с SLO и error budget: где можно деградировать ради экономии (второстепенный трафик), где нельзя (пути, на которых зарабатывают).
Выстраивает отношения с поставщиком: соотношение резервов и оплаты по факту, риск мультиоблака, переговоры о корпоративной скидке, оценка стоимости выхода.

Материалы

Книги

J. R. Storment, Mike Fuller — Cloud FinOps (O’Reilly, 2-е изд., 2023). Каноническое руководство от основателей FinOps Foundation. Если выбирать одну книгу — эту: рамка, словарь, разбор антипаттернов.
Forrest Brazeal — The Read Aloud Cloud (Wiley, 2020). Не про деньги напрямую, но даёт интуицию о том, как устроено облачное ценообразование, с неуютным уровнем детализации; полезно перед серьёзными переговорами с поставщиком.

Статьи и фреймворки

FinOps Foundation — FinOps Framework. Общий словарь и фазы цикла (Inform, Optimize, Operate). Это первое, с чем стоит сверяться в разговоре с финансами: снимает большую часть разночтений в терминах.
AWS Well-Architected — Cost Optimization Pillar. Несмотря на привязку к одному облаку в названии, принципы переносимы. По моим наблюдениям, на ревью архитектуры со стороны денег чаще ссылаются именно на этот документ.
The S3 Outage of February 28, 2017 — Cost as Reliability Constraint. Не про деньги напрямую, но показывает, как решения, принятые ради экономии, — вроде концентрации зависимостей в одном регионе — превращаются в риск для надёжности.
David Heinemeier Hansson — Why we’re leaving the cloud (2022) и We have left the cloud (2023). Публичный кейс — см. ниже.

Инструменты

Kubecost / OpenCost — разнесение стоимости кластера по пространствам имён, меткам и нагрузкам. По моим наблюдениям, стандарт де-факто там, где кластер общий для нескольких команд.
AWS Cost Explorer / GCP Cloud Billing / Azure Cost Management — родные средства самих облаков, обязательный минимум. Для нескольких окружений и сравнения месяц к месяцу на старте хватает.
Vantage / Cloudability / CloudHealth — сторонние платформы FinOps; их берут, когда нужен общий взгляд на несколько облаков и разнесение трат тоньше, чем дают родные консоли.
Spot.io / Karpenter — автоматизация работы на прерываемых мощностях. Karpenter — open-source и родной для k8s; для новых кластеров его чаще берут вместо Cluster Autoscaler.
Анти-инструмент: ручной разбор счёта раз в месяц, не связанный с алертами. Выглядит как практика, а реагирует с опозданием в месяц.

Best practices

Главный публичный кейс — уход Basecamp и 37signals из облака (2022–2023). David Heinemeier Hansson опубликовал серию постов с конкретными числами: счёт AWS около 3,2 млн долларов в год, после переезда на своё железо экономия порядка 2 млн в год при тех же целях по надёжности. Кейс показателен не выбором между облаком и железом (для большинства команд правильный ответ — остаться в облаке), а уровнем прозрачности: они знали удельную стоимость по каждой команде до того, как принимать решение. Я регулярно вижу команды, которые рассуждают «облако дорогое» без такой диагностики, — это рассуждение, а не решение. Пока нет прозрачной удельной стоимости, любая «оптимизация» — догадка.

Дальше три вещи, с которых начинается управляемость. Все скучные.

Считать надо удельную стоимость, а не абсолютные траты. «Потратили полмиллиона» не значит ничего. А вот «0,0012 доллара на активного пользователя, рост на 8% при росте аудитории на 5%» — это уже величина, у которой есть тревожный порог и понятный владелец.

Дисциплина тегов — предусловие для любого разнесения трат. Без team, service, environment и cost-center отчёт показывает общий итог по аккаунту: обсуждать в команде нечего, взять на себя некому. Разметка, которую никто не проверяет, разъезжается за квартал. Минимум — теги, принудительно проставленные в IaC, плюс проверка на дрейф.

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

Про деньги думают на дизайне, а не после. Самые дорогие ошибки принимаются на стадии проектирования: выбор базы, стратегия регионов, схема исходящего трафика. Через два года «оптимизировать» их означает миграцию. Я регулярно вижу ADR без раздела про стоимость, после которых команда полгода воюет со счётом за хранение, предопределённым однажды на ревью схемы данных. Стоимость выносится на ревью архитектуры наравне с задержкой и доступностью. Так же буднично.

FinOps как ритуал, а не как реакция. Если про деньги вспоминают, когда счёт «вдруг» вырос, это уже поздно. Работают два механизма: ежемесячный разбор с фиксированной повесткой (потратили против прогноза, аномалии, что урезаем, что наращиваем) и автоматические алерты на аномалии. По моим наблюдениям, разница между здоровой и нездоровой практикой — именно в наличии ритуала. Инструменты вторичны.

Выкупленные резервы — не бесплатные деньги. Скидка за обязательство измеряется десятками процентов, но обязательство никуда не девается: недозагруженный резерв обходится дороже, чем оплата по факту. Базовое правило простое — резервом закрывают ровно ту нагрузку, что работает круглосуточно и предсказуемо, а всплески оставляют на оплату по факту или на прерываемые мощности. По моим наблюдениям, команды стартуют с покрытия примерно двух третей постоянной нагрузки и двигают эту долю вверх только тогда, когда прогнозу уже доверяют.

Инженерия и финансы говорят на разных языках, и переводчик здесь — SRE. Разговор с финансами в терминах ядер, памяти и IOPS не работает. Работает перевод в удельную стоимость и в результат для бизнеса: сколько стоит пользователь, какую долю выручки съедает инфраструктура. Это задача платформенной команды, а не финансистов: превратить счёт за инфраструктуру в форму, на которой бизнес умеет принимать решения.

Граница у практики есть. Пока счёт за облако меньше зарплаты одного инженера, вся эта машинерия не окупается: разметка, дашборды и ежемесячные разборы съедят больше, чем сэкономят, и честнее раз в квартал открыть консоль и погасить забытое. Не работает практика и там, где у команды нет власти над архитектурой: считать удельную стоимость, не имея возможности сменить тип базы или регион, — это отчётность, а не управление.

Связанные листья

Capacity Planning — на ресурс смотрят с двух сторон: «хватит ли» там и «сколько это стоит» здесь. Прогноз у них общий.
SLO Engineering — решения по деньгам ограничены целями надёжности. Где можно деградировать ради экономии, а где нельзя — определяет политика бюджета ошибок.
Architecture Decision Records — раздел про стоимость в ADR — место, где денежные последствия решения становятся явными.
Infrastructure as Code — дисциплина тегов и разнесение трат делаются кодом; изменение, которое двигает счёт, приезжает как PR.
Toil Tracking — ручной разбор счёта раз в месяц — это toil; целевая форма — дашборды и алерты.
Service Ownership — каталог сервиса содержит данные о деньгах: владелец, бюджет, текущие траты, тренд.
Stakeholder Management — перевод инженерных чисел на язык финансов — отдельный навык; разговор с финансовым директором требует удельной стоимости, а не метрик утилизации.
Cloud Providers — модель тарификации у поставщика — исходные данные для всего цикла FinOps; управляемый сервис против своего — центральный размен по деньгам.
Telemetry Economics — та же удельная стоимость, применённая к метрикам, логам и трейсам: приём данных, кардинальность, семплирование, сроки хранения и цена самого конвейера.

Открытые вопросы

Три листа-соседа пока не написаны. Cloud Exit Decisions (TBD) — расчёт полной стоимости владения для облака против своего железа и вопрос, когда переезд оправдан; кейсы Basecamp, Twitter, 37signals. Spot / Preemptible Workload Patterns (TBD) — какие нагрузки туда годятся, как обрабатывать прерывание, чем это отличается от автомасштабирования. Multi-Cloud Cost Strategy (TBD) — концентрация риска на одном поставщике против операционных накладных.

Отдельно висит Carbon-aware Computing: устойчивость как измерение, соседнее со стоимостью, — выбор локации датацентра и планирование нагрузки по времени суток под зелёную энергию.

Я не разобрался с тем, как считать вклад в выручку в командах, где один сервис обслуживает несколько источников дохода. Если у вас есть рабочий подход — расскажите через PR.