Облачные расходы: что становится видно только после миграции
Почему компании, перешедшие в облако, обнаруживают неожиданные счета - и как выстроить контроль затрат до того, как они станут проблемой.
Когда компания заканчивает миграцию в облако, первая реакция обычно положительная. Инфраструктура работает, старый дата-центр освобождён, команда вздыхает с облегчением. Через несколько месяцев приходит первый неожиданный счёт.
Это предсказуемый паттерн, а не случайность. Облачные расходы устроены принципиально иначе, чем расходы на собственное железо. Капитальные затраты превращаются в операционные, и контроль над ними требует другой дисциплины.
Я видел эту ситуацию достаточно часто, чтобы описать её закономерности.
Почему расходы растут незаметно
На собственном оборудовании бюджет IT выглядит как набор позиций: серверы, СХД, лицензии, поддержка. Каждая покупка - отдельное решение. В облаке каждый разработчик, каждая команда, каждый тестовый стенд могут запускать ресурсы в любой момент.
Типичные источники неожиданных расходов:
- тестовые окружения, которые забыли остановить;
- избыточное резервирование ресурсов "на всякий случай";
- передача данных между регионами и из облака - трафик, который часто не считают отдельно;
- хранение логов и снапшотов без политики удаления;
- неиспользуемые зарезервированные инстансы с предоплатой.
Каждая из этих статей по отдельности небольшая. Вместе они дают 30-60% сверх ожидаемого бюджета.
Чего не хватает большинству компаний после миграции
Техническая миграция и финансовый контроль - разные задачи, которые обычно решают в разное время. Команда, которая мигрировала инфраструктуру, думала о доступности и производительности, а не о тегировании ресурсов по бизнес-юнитам и центрам затрат.
В результате через полгода после миграции ситуация выглядит так:
- счёт есть, разбивки по продуктам или командам нет;
- за какие ресурсы платит какой отдел - непонятно;
- отключить что-то страшно, потому что неизвестно, кто пользуется;
- инженеры не видят стоимость своих архитектурных решений в реальном времени.
Это не проблема инструментов - все крупные облачные провайдеры предоставляют детальную аналитику расходов. Это проблема процесса и ответственности.
Что работает на практике
Финансовый контроль облачных расходов - это не разовая задача, а непрерывная дисциплина. Она включает несколько компонентов.
Тегирование ресурсов. Каждый облачный ресурс должен нести метаданные: команда, продукт, среда (prod/staging/dev). Без этого аналитика расходов бессмысленна. Тегирование нужно вводить как обязательное правило, а не надеяться что его будут делать по желанию.
Бюджеты и алерты. Для каждой команды или продукта устанавливается бюджет с уведомлениями при превышении порогов - например, 80% и 100% от месячного лимита. Это делает расходы видимыми для тех, кто их создаёт.
Регулярный FinOps-ревью. Раз в месяц кто-то смотрит на самые крупные статьи расходов и задаёт простой вопрос: это обосновано? Эту роль не обязательно отдавать финансовому отделу - достаточно назначить ответственного инженера или архитектора.
Политики автоматической остановки. Тестовые и staging-окружения не должны работать ночью и в выходные. Автоматическое расписание экономит 40-60% стоимости этих сред без каких-либо неудобств.
Три вопроса для самопроверки
Если вы уже в облаке или планируете переход, проверьте себя:
- Можете ли вы сейчас сказать, сколько тратит каждая команда или продукт - без ручной работы аналитика?
- Есть ли у вас бюджеты и алерты, которые сработают до конца расчётного периода, а не после?
- Знает ли инженерная команда стоимость своих решений на этапе проектирования, а не при получении счёта?
Если хотя бы на один вопрос ответ "нет" - стоит инвестировать несколько дней в базовую FinOps-дисциплину. Это дешевле, чем разбираться со следующим неожиданным счётом.