FinOps в отечественном облаке: как мы научились видеть, куда уходят деньги

Примерно год назад несколько наших клиентов перешли с on-premise и зарубежных облаков на отечественные - Selectel, VK Cloud, Yandex Cloud. Переход шёл под давлением: требования регулятора, изменения лицензионной политики, проблемы с оплатой зарубежных сервисов. В таких условиях вопрос «а сколько это всё стоит и почему» откладывается на потом. Потом наступило.

Как выглядела ситуация через год

Общая картина у всех трёх клиентов была похожей. Ресурсы есть, счета приходят, но откуда берётся конкретная сумма - непрозрачно. Проекты смешаны в одном аккаунте, теги не ведутся или ведутся непоследовательно, исторических данных нет - только текущий месяц в личном кабинете провайдера. Сравнить расходы апреля с расходами августа было нельзя, потому что в апреле никто не думал про апрель так далеко вперёд.

Отдельная история с тегами. В AWS или GCP культура тегирования ресурсов давно устоялась - есть best practices, есть инструменты принудительного тегирования через политики, есть billing-отчёты по тегам из коробки. В отечественных облаках эта часть заметно беднее. Не потому что провайдеры плохие - просто функциональность billing API и экспорта затрат у них моложе, и у части из них детализация по ресурсам до сих пор не такая гранулярная, как хотелось бы.

Что построили

Отправной точкой стала банальная вещь: нужно было вытащить данные о затратах в место, где с ними можно работать. У Selectel и VK Cloud есть API биллинга, у Yandex Cloud - экспорт в Object Storage. Написали несколько скриптов сбора, которые раз в сутки забирают детализацию затрат и кладут в ClickHouse. Там же живут метаданные ресурсов - что к какому проекту и окружению относится.

Схема вышла примерно такая:

Billing API провайдера
    |
    v
Сборщик (Python, cron)
    |
    v
ClickHouse (история затрат + метаданные ресурсов)
    |
    v
Grafana (дашборды, алерты на аномалии)

Ничего революционного. Но именно наличие истории в ClickHouse дало то, чего не было раньше: возможность смотреть тренды, сравнивать периоды, видеть аномальные всплески.

Параллельно навели порядок с тегами. Ввели обязательный минимум: project, environment (prod/staging/dev), team. Для ресурсов, созданных до этого момента, прошлись скриптом и проставили теги вручную там, где их не было. Это небыстро - у одного из клиентов около 200 ресурсов в аккаунте - но без этого агрегация по проектам не работает.

Observability-стек, который мы выстраивали для тех же клиентов, помог здесь неожиданным образом: когда уже есть Grafana с настроенными дашбордами и алертингом, добавить ещё один datasource (ClickHouse с billing-данными) - дело нескольких часов, не дней.

Что нашли после того, как стало видно

Классика жанра, которая обнаруживается у всех:

• Зомби-ресурсы. Диски без привязанных ВМ, snapshot-ы которым по полгода, балансировщики без бэкендов. У одного клиента нашли три виртуалки в stopped-состоянии - они не потребляли CPU, но диск оплачивался. Суммарно зомби-ресурсы давали заметную долю ежемесячного счёта - примерно десятую часть, иногда больше.

• Oversized инстансы. Типичная история при миграции: берут виртуалку побольше «чтобы точно хватило», потом забывают пересмотреть. Посмотрели утилизацию за три месяца - несколько инстансов с загрузкой CPU до 10% и памятью до 20%. Downsizing дал экономию без каких-либо компромиссов по производительности.

• Staging живёт как prod. Dev и staging-окружения, которые работают круглосуточно семь дней в неделю, хотя реально используются только в рабочее время. Для части из них настроили расписание остановки - в нерабочие часы просто выключаются. Не для всех это применимо (есть интеграционные тесты по ночам), но для чисто ручных окружений сработало.

• Непредсказуемый объём хранилища. Object storage растёт незаметно, если не смотреть на него специально. У двух клиентов нашли bucket-ы с логами, которые ротировались через terraform в S3, но lifecycle policy на удаление старых объектов не была настроена. Данные копились. Настроили lifecycle - через месяц хранилище сократилось значительно.

Что пока не работает хорошо

Честно о том, где мы ещё буксуем.

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

Детализация внутри сервисов провайдера. Биллинг Selectel говорит «Compute: X рублей», но не раскладывает это по конкретным ВМ в рамках API. Нужно сопоставлять с отдельным API ресурсов - это делается, но требует дополнительной логики и иногда даёт расхождения.

Культура внутри команд клиента. Инструмент есть, данные есть, но если разработчики не смотрят на дашборд перед тем, как поднять новое окружение - ничего не меняется. Это не технический вопрос. Внедрение ревью затрат в процесс (например, в еженедельный синк команды) - организационная задача, которая решается медленнее.

Где сейчас

Три клиента, managed-сопровождение, около года данных в ClickHouse. Ситуация изменилась: теперь мы можем ответить на вопрос «почему счёт вырос» не через неделю расследования, а за час. Это не сказать что высокая FinOps-зрелость - скорее выход из нулевого уровня на первый. Но разница ощутимая.

Отечественные провайдеры в части billing API заметно отстают от мирового уровня. Сертификационные и регуляторные требования давят на cloud-вендоров в одну сторону, финансовая прозрачность для клиентов - в другую. Пока второе явно проигрывает по приоритету. Приходится компенсировать инструментами вокруг, что добавляет работы, но не меняет базовую проблему.