FinOps: С чего начать?

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

Всем привет! Меня зовут Андрей Лапкин. Около года назад я перешёл на роль архитектора ИТ-инфраструктуры в подразделении Эксплуатации музыкального сервиса Звук — и практически сразу мы запустили программу управления облачными расходами.

Облачная инфраструктура стримингового сервиса — это сотни виртуальных машин, десятки кластеров Kubernetes, объектные хранилища, базы данных, балансировщики. Ресурсы создаются под задачи, но далеко не всегда удаляются после их завершения. С ростом инфраструктуры вопрос «сколько стоит конкретный сервис?» потребовал системного ответа”.

За полгода систематической работы мы снизили ежемесячные расходы на инфраструктуру примерно на 22%. Для контекста: до старта программы счёт органически рос на 1–2% в месяц. Расскажу, как мы к этому пришли: какую методологию взяли за основу, какие принципы заложили в фундамент и как выглядит дорожная карта. Фокус статьи — на стратегии, процессах и культуре, а не на готовых шаблонах развёртывания.

Что такое FinOps

FinOps (Financial Operations) — операционная модель управления облачными затратами, которая объединяет инженерные, финансовые и бизнес-команды для совместного принятия решений о потреблении инфраструктуры. Это не инструмент и не роль — это практика и культура.

Термин закреплён и развивается FinOps Foundation. Там же сформулированы три базовых принципа.

Совместная ответственность. Затраты на облако — ответственность не только финансового отдела. Каждый новый сервис, каждая нода в Kubernetes, каждый снапшот диска — это деньги, и решения о них принимают не только финансисты, но и инженеры.

Приоритет бизнес-ценности. Цель — не минимизировать расходы любой ценой, а обеспечить максимальную отдачу от каждого потраченного рубля. Иногда правильно потратить больше, если это ускоряет рост или снижает риски. Гнаться за минимальным счётом в ущерб надёжности — не FinOps, а просто недофинансирование.

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

Модель зрелости: Crawl → Walk → Run

FinOps Foundation описывает три уровня зрелости практики. Это нелинейная шкала: организация может находиться на разных уровнях в разных областях одновременно.

• Crawl — расходы видны в целом, но не атрибутированы по сервисам и командам. Теги частично отсутствуют. Оптимизация реактивная: нашли лишнее — удалили. FinOps живёт в голове одного-двух людей, не оформлен как процесс.

• Walk — теги покрывают большинство ресурсов, есть дашборды и регулярные ревью, lifecycle-политики автоматизированы. Создание нового ресурса проходит через согласованный процесс. Оптимизации плановые, но требуют ручного контроля.

• Run — showback и chargeback работают автоматически, аномалии детектируются без участия человека, команды самостоятельно управляют своими бюджетами. Резервирование, прогнозирование и policy-as-code — стандарт.

Стратегия прежде всего

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

Цели мы сформулировали так:

• Платить только за используемое. За каждым ресурсом стоит конкретный сервис или задача (обоснованность), он реально нагружен (утилизация) и привязан к команде через теги (атрибуция). Инстанс с 5% CPU «активен», но переплачен — поэтому одной активности мало, нужны все три свойства.

• Полная видимость затрат. Любой расход атрибутирован команде и сервису. Мы должны отвечать на вопрос «сколько стоит сервис X в месяц?» за минуты, а не за дни.

• Размер окружения = потребность. Prod — надёжно. Preprod и dev — экономно. Типичная ошибка: preprod настроен так же, как prod, с полной отказоустойчивостью и запасом мощностей. Это дорого и, как правило, не нужно.

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

Фундамент: три рабочих правила

На цели мы положили три рабочих правила, которые определяют всю дальнейшую работу. В отличие от трёх принципов FinOps Foundation, описанных выше, это уже не философия, а конкретные инженерные установки.

Видимость прежде всего

Нельзя оптимизировать то, что не размечено. Теги — основа любой аналитики затрат. Мы ввели обязательные метки на все ресурсы:

На практике внедрение тегов оказалось сложнее, чем кажется. Главная проблема — не технология, а данные. Без единого справочника команд и сервисов теги расходятся: одна команда называет сервис auth, другая — authentication, третья — authsvc. Аналитика по таким тегам непригодна, а ретроактивная маркировка — самая медленная и неблагодарная часть работы: автоматически сопоставить ресурс с сервисом сложно, нужен контекст.

Стек аналитики простой: данные о расходах берём из биллинга Cloud.ru, обогащаем атрибутами команд и сервисов через собственный экспорт и передаем в пайплайн, дашборды строим в Grafana. Чем чище теги — тем информативнее итоговая аналитика.

Сначала доказать, потом удалить

Перед удалением любого хранилища данных — верификация полноты данных в целевой системе. Это правило спасает от инцидентов. Звучит очевидно, но без формализации регулярно пропускается под давлением сроков или в уверенности, что «данные точно не нужны».

Конкретный пример: мы переходили с Elasticsearch на Loki для хранения логов. Прежде чем удалить старые кластеры, проверили — есть ли в Loki данные за нужный исторический период? Соответствуют ли объёмы? И только после подтверждения удаляли.

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

Lifecycle с первого дня

Каждый новый ресурс создаётся через задачу в Jira с обязательными полями, которые преобразуются в теги. Baseline-шаблоны задают минимальную конфигурацию по умолчанию: для preprod — single-инстанс вместо HA (High Availability), для dev — минимальный класс машины с правом на апгрейд по обоснованию.

Это не бюрократия — это защита от бесконтрольного роста. Без такого правила ресурсы создаются «быстро под задачу» и остаются работать годами.

Дорожная карта: четыре этапа

Мы разбили работу на четыре вехи — от быстрых побед до системного управления затратами. Каждый этап имеет собственный принцип и собственную сложность.

Этап 1 — Первичная очистка

Подход здесь простой: максимальный эффект при минимальном риске. Работали в два шага.

Шаг 1 — Инвентаризация с базовой разметкой. До удаления каждый ресурс-кандидат получал минимальный набор тегов: к какому сервису относится, кто создал. Без этого расследование перед каждым удалением превращалось в долгий ручной поиск. С базовыми тегами та же работа занимала в разы меньше времени и снижала риск случайно удалить что-то нужное.

Шаг 2 — Удаление и превентивные меры. Начали с того, что лежит на поверхности, — ресурсы, которые точно не нужны: осиротевшие балансировщики и диски без активных сервисов, дублирующие кластеры логирования, инстансы баз без соединений неделями, тестовые окружения без срока жизни, накопленные снапшоты, избыточные бэкапы dev-баз.

Параллельно с разовой очисткой заложили превентивные меры: автоматический lifecycle для объектного хранилища (переход между классами хранения и удаление по TTL, плюс отдельное правило на удаление незавершённых составных загрузок — типичный скрытый источник трат), rightsizing по фактическому потреблению, retention-политики на логи (dev — 7 дней, preprod — 30, prod — 90+ по compliance), пересмотр планов резервного копирования.

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

Этап 2 — Расчистка и маркировка

Главная задача этапа — выстроить единую маркировку как фундамент видимости. Если первый этап можно делать достаточно автономно, то здесь нужны согласования и общие справочники.

Главное на этом этапе — не качество разметки, а её масштаб. Согласованный справочник команд и сервисов из принципа «Видимость прежде всего» нужно применить ретроактивно к тысячам уже существующих ресурсов. Здесь не помогает ни автоматика, ни волевое решение тимлида — только методичный проход по инвентаризации. Это недели работы, а в некоторых случаях и месяцы.

Этап 3 — Уплотнение и миграция

Этап следует правилу «Сначала доказать, потом удалить»: ничего необратимого с хранилищами данных без проверки полноты данных в целевой системе. Конкретные задачи:

• Перевод preprod-кластеров RDS, Redis и Kafka с HA на single-инстансы. Предварительно убедились, что preprod не используется для нагрузочного тестирования с требованиями по доступности.

• Удаление старых файловых полок с логами — только после проверки полноты данных в Loki.

• Покрытие 100% бакетов правилом удаления незавершённых загрузок через baseline-конфигурацию в IaC (Terraform) — чтобы новые бакеты получали правило автоматически, без участия человека.

Этап 4 — Управление затратами

Этап 4 — текущая работа: часть направлений запущена, часть в проектировании. Это переход от «договорились» к «технически обязательно». Несколько направлений:

• K8s rightsizing. Анализ соответствия requests/limits фактическому потреблению. Занижено — кластер перегружен, OOM и throttling. Завышено — кластер расширяется больше, чем нужно. Здесь может пригодиться любое ПО, которое на основе VPA (Vertical Pod Autoscaler) будет выступать как источник рекомендаций, но решение о применении мер остаётся за командами.

• Governance. Policy-as-code на уровне IAM и Terraform: создать ресурс без обязательных тегов технически невозможно. Это переход от «просим соблюдать» к «нельзя нарушить».

Что дальше: зрелый FinOps

За четырьмя этапами — переход к Run.

Showback и Chargeback

Эти два термина описывают принципиально разные уровни финансовой ответственности команд, и переход между ними — организационный шаг, не технический.

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

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

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

Мы сейчас работаем над showback — закладываем техническую базу. Chargeback — следующий уровень.

Отключение preprod в нерабочее время

Простая идея с большим эффектом: preprod и staging не нужны ночью и в выходные, автоматическое выключение даёт 40–70% экономии этих окружений. Реализация требует решить вопросы graceful shutdown для stateful-сервисов, поведения CI/CD ночью и механизма исключений для команд, которым нужно поработать вечером. Это решаемые задачи, но требуют проектирования.

Уроки

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

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

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

Lifecycle-политики окупаются с первого дня. S3 lifecycle, retention, baseline-шаблоны в Terraform — лучшее соотношение усилий и результата: настроил один раз — экономит постоянно. В отличие от разовых чисток, эти меры работают, пока их кто-нибудь специально не выключит.

Самый сложный этап — не техника, а процессы. Написать Terraform-модуль с правилом lifecycle — час. Убедить команды размечать ресурсы, согласовать справочник сервисов, встроить FinOps-задачи в обычный спринт — недели. Технические изменения делаются быстро; культурные требуют времени и постоянного подкрепления.

FinOps — практика, а не выделенная команда. У нас есть небольшая рабочая группа, которая координирует процесс — формирует бэклог, приоритезирует, следит за результатами, — но сами задачи распределяются по всей команде эксплуатации. Это сознательный выбор: вынесенная команда быстро превращается во внешнего «контролёра», от которого защищаются, а не помогают.

Работа не заканчивается с закрытием бэклога. Инфраструктура меняется, появляются новые сервисы, растёт нагрузка — каждый новый сервис потенциально приносит новые неоптимальные ресурсы. Стратегия и дорожная карта помогают не терять фокус, но финишной черты у этого процесса нет.

Итог

Ключевые шаги, которые дали нам 22% экономии за полгода:

1. Сформулировали цели и принципы прежде, чем перешли к действиям.

2. Ввели обязательные теги на все ресурсы и выстроили дашборды на их основе.

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

4. Внедрили lifecycle-политики, которые предотвращают бесконтрольный рост.

5. Встроили FinOps-задачи в обычный рабочий процесс через Jira.

Каждый наш шаг требует и технической работы, и организационных изменений — и второе, как показывает опыт, всегда труднее.

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

Если у вас есть опыт внедрения FinOps в российских облаках (Cloud.ru, Selectel, VK Cloud, Яндекс.Облако) — буду рад обменяться практиками в комментариях или моём Telegram-канале https://t.me/lapkin_stream.