Статья о том, почему «снизить расходы на облако» и «управлять расходами на облако» — это принципиально разные задачи, и что с этим делать команде системного администрирования.
Всем привет! Меня зовут Андрей Лапкин. Около года назад я перешёл на роль архитектора ИТ‑инфраструктуры в подразделении Эксплуатации музыкального сервиса Звук — и практически сразу мы запустили программу управления облачными расходами.
Облачная инфраструктура стримингового сервиса — это сотни виртуальных машин, десятки кластеров 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% экономии за полгода:
Сформулировали цели и принципы прежде, чем перешли к действиям.
Ввели обязательные теги на все ресурсы и выстроили дашборды на их основе.
Прошлись по всем классам ресурсов и удалили то, что точно не нужно.
Внедрили lifecycle‑политики, которые предотвращают бесконтрольный рост.
Встроили FinOps‑задачи в обычный рабочий процесс через Jira.
Каждый наш шаг требует и технической работы, и организационных изменений — и второе, как показывает опыт, всегда труднее.
Главное, что даёт FinOps — управляемость. Каждый потраченный рубль становится результатом осознанного решения, а не побочным эффектом чьего‑то спринта неделю назад.
Если у вас есть опыт внедрения FinOps в российских облаках (Cloud.ru, Selectel, VK Cloud, Яндекс.Облако) — буду рад обменяться практиками в комментариях или моём Telegram‑канале.
