Как мы срезали облачный счёт на 34%: что сработало, а что нет

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

У этого клиента — продуктовая компания, Яндекс Cloud, около 80 ресурсов в аккаунте — мы уложились в −34% от исходного счёта за первый месяц после обследования. Это попадает в нашу типовую вилку 20–40%, которую мы называем ещё до старта. Но дьявол в деталях: не всё сработало одинаково, и одна среда переехала болезненно.

Что показало обследование

Обследование заняло 3–5 рабочих дней — это стандартный срок для нашего аудита инфраструктуры. За это время мы смотрим два среза: что реально потребляется (метрики утилизации) и за что выставляется счёт (детализация биллинга).

Картина оказалась классической.

Зомби-ресурсы. Восемь дисков без привязанных ВМ, два балансировщика без бэкендов, четыре снапшота полугодовой давности. Всё это тихо оплачивалось. Аналогичную ситуацию мы описывали в сентябре прошлого года — зомби-ресурсы дают заметную долю счёта почти у всех, кто никогда не проводил ревизию. Здесь суммарно вышло около 8% ежемесячных расходов.

Staging живёт как prod. Три dev/staging-окружения работали круглосуточно, семь дней в неделю. Реально разработчики заходили туда в рабочее время по будням. Ночью и в выходные — тишина, но счётчик шёл.

Oversized инстансы. Несколько ВМ с загрузкой CPU 5–15% при пике. Классика после миграции: брали с запасом, потом забыли пересмотреть.

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

Что сделали и что дало реальный эффект

Чистка мёртвых ресурсов — быстро и без риска

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

Эффект: −8% счёта, мгновенно.

Ночное гашение тестовых сред

Настроили расписание остановки dev и staging-окружений: в 20:00 по будням и на всё время выходных ВМ останавливаются, в 8:00 поднимаются обратно. Конфигурация через Terraform, запуск через cron-задачи в облачном планировщике.

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

Эффект: −12% счёта (две из трёх тестовых сред × время простоя ~65% от суток).

Автоскейлинг кластера

Kubernetes Cluster Autoscaler настроили с минимумом 3 ноды и максимумом 12. Ночью кластер схлопывается до минимума, в дневной пик разворачивается под нагрузку. Это потребовало нескольких итераций настройки PodDisruptionBudget и проверки, что все деплойменты корректно переживают выселение пода.

Эффект: −7% счёта (ноды простаивали ~40% времени суток).

Spot-инстансы — где получилось и где нет

Spot-инстансы дали самую заметную экономию на единицу усилий: нагрузка на воркеры обработки данных — асинхронные задачи без состояния — переехала на Spot полностью. Экономия на этой группе составила около 60% стоимости воркеров.

Но Spot потребовал работы, которую нельзя недооценивать.

Честный trade-off: перед переводом нагрузки нужно было убедиться в её переносимости: задачи должны корректно прерываться по SIGTERM с сохранением прогресса, health-check должен давать кластеру время на graceful shutdown перед вытеснением пода. Для воркеров обработки это было реализовано — там изначально была идемпотентная логика с checkpoint-ами.

Но одна среда — легаси-сервис с накопленным состоянием в памяти и без graceful shutdown — «переехала» болезненно. После первого вытеснения Spot-ноды сервис потерял очередь задач, которая жила в памяти. Восстановление заняло несколько часов ручной работы. Этот сервис мы вернули на обычные инстансы и сделали его перевод на Spot отдельной задачей со сроком — требуется рефакторинг логики прерывания.

Spot не универсален. Нагрузку на него переносить только если она переносима: stateless, с идемпотентными операциями и проработанным завершением.

Суммарный эффект Spot: +7% к общей экономии (с учётом того, что часть нагрузки осталась на обычных инстансах).

Downsizing oversized ВМ

Инстансы с хронически низкой утилизацией уменьшили на один-два размера. Делалось аккуратно: смотрели метрики за 30 дней, выбирали момент для перезапуска, проверяли после изменения.

Эффект: −6% счёта.

Итог по статьям

Цифры округлены; реальный результат зависит от профиля нагрузки и того, что именно обнаружит обследование.

Что оказалось косметикой

Несколько вещей, которые казались перспективными, дали мало.

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

Чистка логов в Object Storage. Нашли несколько bucket-ов с логами без lifecycle policy — аналогичную ситуацию мы описывали при построении FinOps-пайплайна для нескольких провайдеров. Настроили удаление старых объектов. Экономия есть, но для этого клиента хранилище составляло малую долю общего счёта — эффект в пределах 1–2%.

Что дальше

−34% — это первый месяц после обследования. Дальше кривая выполаживается: зомби и очевидные oversized ресурсы убраны, оставшееся сложнее. Следующий рубеж — rightsizing на основе накопленных метрик утилизации, это требует нескольких недель наблюдений.

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

Если хотите понять, откуда берётся ваш облачный счёт — начните с обследования. Мы проводим его за 3–5 рабочих дней и даём конкретный список того, что можно срезать и на сколько. Подробнее об услуге — на странице DevOps-аутсорсинга; если нужен разовый аудит без постановки на поддержку — на странице аудита инфраструктуры.