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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уменьшение избыточных ВМ

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

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

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

Цифры округлены.

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

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

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

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

Что дальше

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

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

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