— Мы берём ресурсы с запасом. Так надёжнее.
— А какой у вас сейчас CPU utilization в проде?
— Ну... где-то 12%. Но в пике бывает больше.
— Хорошо. А в staging?
— Там вообще 3%. Но там нельзя трогать — там всегда так было.
— Почему нельзя?
— Ну, так исторически сложилось…
Это, кстати, не выдуманный диалог. Это разговор, который автору доводилось слышать не один десяток раз и не в одной компании, и он не про DevOps-культуру и не про лень. Он про то, что человек, который заказывает ресурс, не видит его цену — и не несёт за неё ответственности. Иными словами, пока не выстроен Inform, оптимизировать нечего: нет данных, нет аллокации, нет понимания, кто за что платит. Но если вы читаете эту статью — значит, первый этап уже позади.
Inform уже позади — что меняется на Optimize
В предыдущем материале мы разобрали фазу Inform: как собирать и нормализовать данные о затратах, выстраивать аллокацию по командам и проектам, строить дашборды и ловить аномалии раньше, чем они успевают превратиться в сюрприз на экране биллинга. Логика была простая: без видимости оптимизация — это банальная угадайка. Оптимизируете 2% расходов, пока 60% бюджета молча уходит в базы данных, которые никто не проверял с прошлого года.
Теперь видимость есть: данные собираются, аллокация работает, понятно, кто тратит и сколько. Следующий шаг — превратить это знание в устойчивую экономию. Это и есть фаза Optimize.
Почему оптимизация срывается ещё до начала
Но сказать проще, чем сделать. Потому что стоит кому-то в компании только произнести слово «оптимизация», как в команде начинается одно из двух: люди либо боятся тронуть лишнее и потом разгребать инцидент в пятницу вечером, либо по полгода согласовывают каждый чих, позволяя счетам за это время улететь на луну. И то, и другое — следствие одного: оптимизация без данных — это угадывание с последствиями, а угадывание на инфраструктуре обходится дорого.
Фаза Optimize строится на четырёх компетенциях, и ни одна из них не предполагает решений на интуиции.
Компетенция 1: выявление неэффективности. Остановленная ВМ со слившимися дисками и зарезервированным публичным IP — это не экзотика. Это обычная картина в компании через 6 месяцев после того, как инженер, который всё это создавал, ушёл. Снапшоты на всякий случай, неиспользуемые балансировщики под сервис, который скоро вернём, dev-окружения, работающие ночью и в выходные, — всё это ест бюджет молча и методично. По данным Kubernetes Cost Benchmark Report за 2025 год, средняя загрузка CPU в кластерах составляет 10%, а памяти – 23%. Не 40, не 60, а всего-навсего 10. То есть на каждые 10 рублей, потраченных на managed Kubernetes, реально используется ресурс примерно на один рубль. С обычными ВМ ситуация, как правило, не сильно лучше — просто там реже смотрят.
Компетенция 2: техническая оптимизация конфигураций. Райтсайзинг — это не про то, чтобы поставить инстанс поменьше, а про то, чтобы подобрать его под конкретный профиль нагрузки: с упором на вычисления или на память, SSD или HDD для разных классов данных, managed-сервис вместо зоопарка ВМ. Да, managed стоит дороже самосбора, но инженер в Москве все равно стоит дороже.
Компетенция 3: скорость цикла «обнаружил – исправил». Time-to-Optimize — это время от момента обнаружения аномалии до её устранения: типовая должна закрываться за 2–3 дня, крупная инициатива — в пределах спринта. Если TTO измеряется неделями, это плохо. Деньги-то утекают. Допустим, нашли зомби-диск на 2 ТБ, но от обнаружения до фактического удаления прошло 10 дней — это 10 × (стоимость хранения), которые ушли в никуда. А будь у вас отлаженный процесс с ответственными, дедлайнами, уведомлениями и прозрачностью, все было бы ок.
Компетенция 4: unit-экономика. Рост счёта на 20% сам по себе мало о чём говорит, если нет контекста нагрузки. Если нагрузка выросла на 25%, то +20% к счёту — хороший результат. Если нагрузка стабильна — тогда вопрос, откуда эти 20%. Unit-экономика переводит разговор в правильную плоскость: cost per user, cost per order, cost per 1 000 API-запросов. Цель фазы Optimize — чтобы unit-cost не рос линейно при росте нагрузки: если каждый новый пользователь стоит столько же, сколько первый, значит, где-то в архитектуре есть проблема масштабируемости, которая пока прячется за общей цифрой счёта.
Больше про FinOps и облачные затраты — в нашем Telegram-канале. Там разбираем реальные кейсы, а не пересказываем документацию провайдеров.
Три сценария оптимизации — и почему важен порядок
Когда компетенции выстроены, встает вопрос, с чего начинать. Задачи по снижению затрат почти всегда укладываются в один из трёх сценариев:
работа с ценой
работа с конфигурациями
работа с архитектурой
Все три сценария оптимизации – верные, но у них разная сложность, разная скорость результата и разный порог входа. Начинать с архитектуры, пропустив конфигурации, — это как переезжать в новую квартиру, не выкинув строительный мусор: квартира будет новая, но хлам-то останется.
Поэтому работаем.
Сценарий 1: работа с ценой. Резервы, коммиты, споты, переговоры с провайдером — всё это реальные инструменты с реальной экономией. Но у каждого есть условие, без которого он работает против вас. Да, резервы дают 30–40% скидки по сравнению с он-демандом. Но это как сравнивать опт и розницу. Потому что работает тот самый “опт”, только если вы уверены в базовой нагрузке на горизонте 1–3 лет. Купили резерв под нагрузку, которая упала через квартал — деньги заморожены. Купили резерв под ресурс, который нужно было сначала уменьшить вдвое — сэкономили 30% от суммы, которую не нужно было тратить.
Споты дешевле на 60–80% — и это реальная экономия. Но только если нагрузка её выдержит. Батчи, CI/CD-агенты, ML-обучение, тестовые среды — да. А вот стейтфул-сервис, который не умеет переживать отъём ресурса — наверное, нет. Потому что это скрытый риск инцидента с понятной ценой в виде нескольких часов разбора полётов и объяснений с бизнесом. Переговоры с провайдером по коммитам — отдельная история: для объёмов от нескольких миллионов рублей в месяц провайдеры идут на персональные условия, и если не спросите — сами не предложат.
Только к работе с ценой стоит переходить лишь после того, как разобрались с конфигурациями. Иначе просто зафиксируете неэффективность на год вперёд по выгодной цене – и все.
Сценарий 2: работа с конфигурациями. Самый доступный и быстрый из трёх. Он не требует архитектурных решений. Нужны только данные и дисциплина.
Зомби-ресурсы — первый кандидат на удаление. Статус STOPPED не означает, что ресурс ничего не стоит: зарезервированные диски, публичные IP, снапшоты — всё продолжает тарифицироваться. В компании с несколькими сотнями ресурсов найдётся 15–25%, которые можно удалить без каких-либо последствий для бизнеса. Просто никто не смотрел.
Далее — смотрим недогруженные инстансы. CPU < 10–15% и память < 20–30% в течение 14 дней — это не запас, это неправильный размер. Смотреть нужно на 95-й перцентиль, а не на пиковый всплеск: если нагрузка прыгнула один раз за неделю на 5 минут, это не повод держать вдвое больший ресурс постоянно. И тут либо уменьшаем, либо разбираемся, зачем этот сервис вообще существует.
Dev и стейджинг-окружения, работающие 24/7, — третий кейс, и один из самых простых для исправления. Если команда работает с 9 до 19, зачем dev-кластеру работать ночью и в выходные? Выключение по расписанию на непроде экономит порядка 40% расходов на них без изменений в архитектуре или коде. А это буквально несколько строк в кроне.
Завышенные resource requests в Kubernetes — четвёртый, и часто самый недооценённый пример. Открываете kubectl top pods и видите: cpu: 0.05 при request cpu: 2.0. Кто-то выставил лимиты на вырост, ушёл из компании, а overhead остался. Помножьте это на 50 сервисов — и получите несколько сотен тысяч рублей в месяц на воздух. И результат тут приходит быстро: часто в течение первых 2–4 недель после того, как выстроен нормальный мониторинг утилизации.
Сценарий 3: работа с архитектурой. Самый сложный и долгий. Он может дать крутой результат, а может — полтора года боли и те же цифры в счёте. Сюда попадают решения, где вопрос-то уже не про конфигурации, а про саму платформу или провайдера.
Смена провайдера — инструмент, который часто переоценивают по потенциальной экономии и недооценивают по стоимости миграции. Перенос между провайдерами занимает месяцы инженерного времени: считайте TCO честно — стоимость миграции, переобучение команды, возможный даунтайм, изменение SLA, вендор-специфичные зависимости, которые накопились за годы. Иногда вместо экономии получаете полтора года боли и примерно то же число в счёте.
Выход в онпрем — классический запрос, когда в компанию приходит новый финансовый директор. Два года оптимизировали публичное облако, а теперь — а не выгоднее ли просто купить железо? Честный ответ – все зависит от профиля нагрузки:
Если нагрузка стабильная и не меняется 3–5 лет — онпрем может выиграть.
Переменная нагрузка, быстрый рост, неопределённость по продукту — публичное облако остаётся гибче.
Только не забывайте про скрытые статьи расходов: электричество, охлаждение, физическая безопасность, инженеры, которые всё это обслуживают. Если речь про строительство собственного ЦОДа с нуля, 1 МВт мощности обойдётся в многие миллионы рублей в зависимости от класса объекта, а 5 МВт — уже миллиарды с учётом серверов, СХД и систем охлаждения.
Коло и выделенные серверы в коммерческих ЦОДах выйдут заметно дешевле, но и там аренда, электричество и обслуживание никуда не денутся — просто порог входа будет другим. Нет, это не аргумент против онпрема. Это аргумент за честный расчёт, в котором учтены все варианты, а не только самый дорогой.
Смена платформы — кубер вместо виртуалок, менеджд вместо зоопарка, серверлесс для подходящей нагрузки — это тоже архитектурная оптимизация. Она будет менее драматичной, чем смена провайдера, но, несмотря на это, может оказаться даже более результативной. Главное – порядок: сначала разберитесь с конфигурациями на текущей платформе, а потом уже думайте о смене.
Какие бывают дашборды и зачем они нужны
Если на фазе Inform дашборды строились для прозрачности, то на фазе Optimize они становятся инструментом принятия решений, когда каждый должен отвечать, что именно можно оптимизировать прямо сейчас, и желательно с именем владельца ресурса.
Дашборд «Охота на зомби-ресурсы». Его цель — определять кандидатов на удаление с первого взгляда, не требуя ручного аудита раз в квартал. Что смотрим:
ВМ в статусе STOPPED: возраст, объём дисков, наличие публичного IP
не присоединенные диски: размер, время последней операции, проект
снапшоты старше N дней без тега-исключения
Задача — заменить ежемесячный ручной обход. Делается это просто. Открываем — видим список — передаем владельцам — получаем подтверждение или объяснение — удаляем. Весь цикл занимает 2–3 дня.
Дашборд «Стоимость и утилизация compute». Он уже связывает цену инстанса с фактическим потреблением CPU и RAM за последние 7–14 дней. Внутри него:
стоимость по инстансам с отображением средней загрузки
список инстансов с утилизацией ниже порога (CPU < 15%, RAM < 30%)
группировка по каталогам и проектам — чтобы сразу видеть ответственного
Этот дашборд убирает любое недопонимание из разговора про right-sizing: вот инстанс, вот утилизация, вот сколько сэкономим при downsize. А когда есть конкретика – сопротивления нет.
Дашборд «Storage: цена за гигабайт ценности». Это, по сути, переводчик абстрактных категорий типа “терабайты данных” во вполне конкретные и понятные любому технарю рубли.
Что смотрим:
активные тома
снапшоты — с выделением старых и неиспользуемых
архивное и холодное хранилище, Object Storage
Дашборд делает видимой цену привычки ничего не удалять, причем сразу в рублях за гигабайт каждый месяц. Для команд с бизнес-метриками можно добавить unit-cost: cost per 1 000 лог-строк или cost per 1 000 объектов.
Дашборд unit-экономики. Он включает в себя три метрики, которые переводят инфраструктуру в деньги бизнеса:
cost per active user
cost per order
cost per 1 000 API-запросов
Плюс графики изменения unit-cost при росте нагрузки и после внедрения оптимизаций. Этот дашборд больше всего нужен продуктовой и финансовой командам, но именно инженеры должны уметь объяснить, какие изменения в инфраструктуре дали тот или иной эффект. Без этой связи FinOps остаётся внутри IT-периметра и не влияет на бизнес-решения. А значит, и бюджет на него рано или поздно срежут.
CLI и специализированные инструменты
Теория понятна — посмотрим на конкретные команды. Неприсоединенные диски в Yandex Cloud — прямой кандидат на удаление или архивирование:
yc compute disk list \
--folder-id <FOLDER_ID> \
--format json | jq '
.[]
| select(.instance_ids == null or (.instance_ids | length == 0))
| {name, id, size, type, zone_id, created_at}'
На выходе получаете список дисков без привязанных ВМ с датой создания. Всё, что старше 30 дней и не помечено тегом-исключением — кандидат на разговор с владельцем. Владелец определяется из тегов owner или team. Если тегов нет — значит, фаза Inform не до конца пройдена, и это отдельная задача.
Поиск остановленных ВМ строится по общему паттерну: получить список ВМ в каталоге (yc compute instance list --folder-id <FOLDER_ID> --format json), отфильтровать по статусу STOPPED, по каждой ВМ получить связанные диски и IP-адреса и свести всё в таблицу — инстанс, статус, диски, IP, последняя активность, владелец, потенциальная экономия при удалении. Важный нюанс, который часто упускают: «остановленная» ВМ — это не «бесплатная» ВМ. Диски тарифицируются вне зависимости от того, запущен инстанс или нет, публичный IP в зарезервированном статусе тоже стоит денег, и суммарно за несколько месяцев набегает сумма, которую неприятно увидеть в отчёте.
Для анализа billing-данных по зомби-ресурсам через Yandex Query поверх Object Storage с экспортом биллинга общий паттерн SQL-запроса выглядит так:
SELECT
resource_id,
resource_name,
SUM(cost) AS total_cost,
COUNT(DISTINCT usage_date) AS active_days
FROM billing-export/detail
WHERE usage_date >= DATE_TRUNC('month', CURRENT_DATE())
AND service_id = 'compute'
AND labels['status'] = 'stopped'
GROUP BY resource_id, resource_name
ORDER BY total_cost DESC
Данные биллинга можно дополнять метаданными из API. Тогда получаете полную картину: сколько конкретный зомби-ресурс стоит в деньгах за текущий месяц, а не просто знаете, что он есть.
Про специализированные инструменты. Писать свои скрипты — нормально. Поддерживать их через полгода, когда API провайдера обновился, а автор скрипта давно в другой компании, — это особый тип извращения.
Поэтому лучше использовать специальный инструментарий, который возьмет всю рутину на себя. Одно из таких решений – FinOps Radar. Он подключается к Yandex Cloud в режиме read-only, автоматически собирает данные по ресурсам и выдаёт конкретные аномалии с оценкой потенциальной экономии — по сути, это готовый пайплайн «обнаружил – показал – жди решения владельца» без необходимости писать и поддерживать собственный инструментарий.
Его ценность даже не столько в экономии времени, сколько в эффективности. От подключения до первых находок проходят минуты, и если нужно доказать бизнесу ценность FinOps-подхода, лучше конкретных цифр экономии пока что ничего не придумали.
Как понять, что фаза Optimize работает
Все сделали, но не поняли, правильно ли? Вот три индикатора, которые свидетельствуют о том, что Optimize работает как надо:
≥20–30% идентифицируемого потерь устранено и не возвращается. Ключевое слово — «не возвращается». Удалить зомби-ресурсы один раз и через квартал обнаружить их снова — это не Optimize, это ручная уборка. Должен быть процесс: регулярный мониторинг, уведомления, ответственные, дедлайны.
Time-to-Optimize ≤ 2–3 дней для типовой аномалии. Нашли проблему — она закрыта в течение рабочей недели. Для крупных инициатив — в пределах спринта. Если аномалии живут неделями, это накопленный технический долг, который принимает форму денег.
Unit-cost стабилен или снижается при росте нагрузки. То есть должно быть не просто «счёт вырос на 20%», а «cost per user снизился на 8% при росте аудитории на 30%». Только тогда становится ясно, что архитектура масштабируется правильно и оптимизации дают устойчивый эффект.
А когда все три индикатора выполняются — можно думать о переходе к фазе Operate, где задача уже не найти неэффективность вручную, а автоматизировать процессы так, чтобы она не накапливалась.
Главное тут – понять, что Optimize — это не разовая акция. Зомби-ресурсы будут появляться снова, потому что инфраструктура живёт: команды меняются, фичи запускаются и закрываются, нагрузка сдвигается. Unit-cost реагирует на каждое архитектурное решение, а конфигурации, которые были правильными год назад, через год могут оказаться избыточными. Задача этой фазы — не оптимизировать один раз и забыть, а сделать так, чтобы неэффективность обнаруживалась хотя бы за дни, а не за кварталы.
В следующей статье мы разберём фазу Operate. Расскажем, как перейти от ручных проверок к автоматизированному контролю затрат и внедрить культуру FinOps в ежедневные процессы инженерных команд.
