База FinOps: Почему счет за облако каждый месяц растет и что с этим делать

Модель pay-as-you-go, которую предлагают в облаке, всегда была палкой о двух концах. С одной стороны, история вроде честнее некуда: платишь ровно за то, что заказал. Как в ресторане. Но, с другой, именно она практике нередко приводит к такому перерасходу, что поневоле начинаешь задумываться, а нужно ли нам вообще это облако?

На самом деле чудес не бывает, и я намеренно перевел pay-as-you-go как “платишь за то, что заказал”. Внимание: заказал, а не потребил. Потому что в этом и заключается первая проблема – нет, не облаков, – а тех, кто их использует. Компании регулярно выходят за рамки бюджетов, потому что платят за ресурсы, которыми де-факто не пользуются. Тут и забытые тестовые стенды, и старые проекты, которые продолжают генерировать счета, и простаивающие виртуальные машины с запасом по мощности, и чего только не. В результате до 30% облачного бюджета просто улетает впустую. А у некоторых и того больше. 

Плюс – усложнение архитектуры как таковой. Если раньше одно приложение работало на одном сервере, то теперь они состоят из десятков разных микросервисов, и каждому нужна своя база, свой кэш, своя очередь. А ведь еще есть тестовое окружение, staging, CI/CD и много других английских слов. И за все надо платить. Да, по отдельности вроде копейки. Но когда таких сервисов 100 или 200, сумма выходит приличная. Добавим сюда накладные расходы и получим еще минимум 15-25% к счету. А хотелось бы эти деньги оставить у себя в кармане. О том, как это сделать, сегодня и поговорим.

Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram.

Российский облачный рынок: масштаб проблемы

Российский облачный рынок – явление очень быстрорастущее. Если в 2024 году его совокупный объем составлял 392 миллиарда рублей, то в 2025 прыгнул уже до 416. В условиях экономической турбулентности, которая нас сейчас сопровождает, это вполне нормальный такой рост. Средняя компания тратит 6.7 миллионов рублей на облако в год, или примерно треть от всего IT-бюджета. 

А когда траты измеряются сотнями миллиардов по стране и миллионами для каждой отдельной компании, контролировать, куда именно уходят деньги, становится задачей совсем уж нетривиальной. Тем более что компании обычно используют не одно облако, а несколько сразу. И у каждого провайдера свой интерфейс, свои метрики, свой способ считать расходы. Поэтому, когда финансовый отдел смотрит на все это, он чаще всего не понимает, как вообще сравнивать между собой эти цифры. 

Из-за этого, по статистике, 84% IT-директоров называют контроль затрат главной проблемой облака. Если еще пару лет назад на первом месте была безопасность, потом тестирование, то теперь это именно деньги. Потому что дыр, куда они утекают, становится все больше и больше.

Перестраховка убивает: как теряем 30% на простое CPU

Первая болевая точка — это просто неэффективно выделенные ресурсы. Допустим, разработчику надо поднять новый сервис или протестировать нагрузку. Поэтому он берет и запускает инстанс с четырьмя ядрами CPU. Почему четырьмя? Ну, а вдруг двух не хватит. Правда, даже если на практике хватает и одного, а три просто висят без дела, никого это особенно не волнует. Вот только заплатить-то по итогу придется за весь заказанный ресурс, даже если пользы он не принес.

С памятью, кстати, все то же самое. Когда не ясно, сколько брать – 4 или 8 ГБ – почему-то всегда берут с запасом. Причем с большим. В результате приложение потребляет максимум 2-3 ГБ, а остальное просто пустует. Как говорится, лучше вылить, чем не хватит. Вот и выливают. 

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

Естественно, любой разработчик или SRE будет настаивать, что надежность важнее и что экономия на ресурсах – смерти подобна. Любой шатдаун – и проблем не оберешься, скажет он. И будет прав.

Потому что живется в таких условиях, действительно, куда спокойнее. Но обходится это спокойствие слишком дорого.

Посчитайте сами:

• Инстанс с 4 ядрами и 16 ГБ памяти в Яндекс.Облаке стоит около 15-20 тысяч рублей в месяц.

• Если таких инстансов 50, и половина мощностей простаивает, потери составят в районе 300-400 тысяч рублей в месяц только за compute.

• Плюсуем диски, сетевой трафик, резервные копии — и получаем сумму под полмиллиона рублей, которые платятся ни за что.

Однако неэффективно выделенные ресурсы – это только часть проблемы. Есть еще целый класс расходов, о которых большинство вообще не задумывается. А именно забытые ресурсы.

Забытые «зомби»: Как 35% ресурсов жрут бюджет впустую

Как это обычно бывает, наверное, знают все. Разработчик поднимает тестовый стенд, работает с ним, а потом просто переключается на другую задачу. Естественно, к тому времени, про запущенный стенд уже никто не помнит, но он продолжает работать и генерировать счета. Изо дня в день. Из месяца в месяц. Из года в год. Скажете, драматизирую? Но так действительно бывает. Пока кто-то случайно не обнаружит ненужный инстанс в консоли и не спросит, что это вообще такое. А если не спросит, то он так и будет мотать счетчик.

Самое смешное, что виноватых в этой ситуации искать бессмысленно. Разработчик забыл выключить стенд? Так у него был дедлайн, релиз, три митинга подряд и вообще он болел. Тимлид не проконтролировал? А он и не знал, что кто-то что-то поднимал, потому что у команды есть права создавать ресурсы когда угодно. Финансовый отдел не заметил рост счета? Так они видят только одну итоговую цифру, а не разбивку по каждому инстансу. Админ не отследил? Ну, у него своих проблем по горло, плюс доступа к чужим проектам нет.

Вот и получается, что система устроена так, что запустить виртуалку легко, а чтобы выключить еще надо постараться про нее не забыть. И тут человеческий фактор показывает себя во всей красе.

Оттого и статистика получается неутешительная. По данным различных исследований, от 20 до 35% облачных ресурсов в компаниях вообще не используются. Они просто висят мертвым грузом и жрут бюджет. Кто-то называет их красивым словосочетанием zombie resources, кто-то — запутанным orphaned instances. Но суть остается одна: ресурс есть, а толку от него нет.

Что характерно, забывают не только виртуалки. Забывают диски, снапшоты, балансировщики, IP-адреса, базы данных. Особенно любят забывать тестовые копии продакшен-баз, которые весят столько же, сколько и оригинал, но нужны были ровно один раз три месяца назад.

Еще один популярный сценарий — это ресурсы, которые создал уволившийся сотрудник. Он ушел, а его инстансы остались. И теперь их вообще никто не знает. Потому что имена ресурсов у него были типа test-vm-42 или my-instance-new-2, и что там внутри, непонятно даже по названию.

Как с этим бороться? Тут нет волшебной таблетки, но есть несколько рабочих подходов:

• Первый — это автоудаление по таймеру. Создал ресурс? Отлично, через неделю он сам выключится, если ты не продлишь срок жизни явно.

• Второй — это теги с owner и expiration_date.

• Третий — регулярный аудит с вопросом в общий чат: кому нужна виртуалка vm-12345? Если за сутки никто не откликнулся — можно рубить.

Но главное — это культура. Пока в команде не станет нормой выключать за собой свет в облаке, забытые ресурсы никуда не денутся. Можно хоть какие системы внедрять, а все будет бестолку.

Счет опять больше. Мы же ничего не меняли

Но бесхозные ресурсы хотя бы можно понять. Ну, подумаешь, забыли. Главное, что все поправимо: нашли – выключили – сэкономили. А ведь есть ситуации, когда счета увеличиваются, а найти конкретную причину перерасхода не получается. Инфраструктура та же, команда ничего нового не разворачивала, нагрузка стабильная, а биллинг растет и растет. Процентов на 10-15 каждый раз.

Финансовый отдел, понятное дело, требует объяснений. Только чего тут объяснять-то? По метрикам все нормально. Всплесков нет, аномалий тоже. Дашборды зеленые, алерты никто не присылал. Продакшен жив-здоров. У нас все нормально. Просто дороже, чем три месяца назад, но кто бы знал, почему так.

Проблема в том, что рост расходов в облаке далеко не всегда связан с событиями, которые фиксируются и трактуются однозначно. Можно вообще ничего не менять в архитектуре, но затраты все равно будут расти, и причин тому сразу несколько.

Во-первых, логи. Если они пишутся себе потихоньку, то вместе с количеством запросов будут расти и объемы. А когда через полгода выясняется, что за хранение логов платишь столько же, сколько за саму инфраструктуру, становится как-то неловко.

Во-вторых, снапшоты. Настроили автоматическое создание бэкапов раз в день, и это правильно. А политику ретеншена прописали? То-то и оно. В результате снапшоты копятся месяцами, а стоимость стораджа медленно, но верно растет. Нет, конечно, один снапшот на 500 ГБ — это не страшно. Но когда их штук 100, а диски при этом еще и на SSD? В общем, вы поняли.

В-третьих, трафик. Между сервисами внутри одного региона он обычно бесплатный. А вот если микросервисы общаются между разными availability zones или, того хуже, между регионами, каждый гигабайт стоит денег. И когда архитектура разрастается, а сервисы общаются активно, исходящий трафик может съедать 10-20% бюджета. И никаких вам алертов. Почему? Да потому что технически так и должно быть.

В-четвертых, автоскейлинг без верхних границ. Обычное дело, когда настроили horizontal pod autoscaler в Kubernetes, указали минимум инстансов, но максимум не ограничили. Вроде логика в этом есть. Но, допустим, трафик увеличился процентов на 20 за счет органического роста аудитории, и HPA поднимает количество подов с 10 до 15. Опять же, по технике все правильно: продакшен не упал, latency в норме. Просто теперь за compute платишь на 50% больше, а заметить это можно только по счету в конце месяца.

Как же быть?

Решение только одно — регулярный мониторинг не только технических метрик, но и финансовых:

• Cost anomaly detection

• Бюджетные алерты

• Детализация трат по сервисам и командам

Это необходимо, чтобы видеть все расходы в моменте, а не ждать конца месяца и удивляться счету постфактум. А так, если логи начнут занимать слишком много места, трафик между регионами вырастет на 200% сразу или снапшотов станет больше, чем положено, вы тут же получите уведомление. 

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

Облако vs онпрем: как сравнить CAPEX и OPEX?

Когда со счетом в облаке более‑менее удается разобраться, следующей в повестку неизбежно попадает собственная инфраструктура. Если ситуацию в облаке хоть как‑то можно отследить по строчкам биллинга, по графикам и алертам, то вот собственный дата‑центр чаще всего живет своей жизнью. Во всяком случае, до тех пор, пока CFO не спросит, сколько стоит наша собственная инфраструктура. Вот та, что в дата-центре. Железо-то, конечно, свое, но оно ведь тоже деньги, правильно?

И тут начинается самое интересное. Потому что деньги на серверы потратили три года назад. Один раз. По CAPEX. А как теперь это считать — непонятно. По закупочной цене? По амортизации? По рыночной стоимости аналогичных ресурсов в облаке? И главное — зачем вообще это считать, если удаление виртуалки в онпреме не меняет счета?

Это в облаке все просто: включил инстанс – платишь, выключил – не платишь. А в онпреме все иначе: виртуалку-то ты выключишь, но железо от этого никуда не девается, а продолжает стоять в стойке, потреблять электричество и амортизироваться. Особенно амортизироваться. Поэтому экономия получается весьма условная. Да, ресурсы вроде бы освободили. Но сколько денег выгадали — вопрос философский.

Только зачем финансистам эта философия? Им нужны цифры. И желательно в том же формате, что и по облаку: сколько стоит CPU, сколько память, сколько диски. Только так можно сравнить и понять, что дешевле. А как перевести стоимость железа, купленного в 2022 году за 15 миллионов рублей, в ежемесячный эквивалент OPEX? Делить на 60 месяцев амортизации? Или на 36, потому что через три года все равно придется обновлять? А электричество, охлаждение, аренду стойко-места куда записывать? Сложно.

Плюс ко всему, в онпреме ресурсы обычно общие. Считай, как при коммунизме. Ладно, шутка. Просто там есть один большой кластер на всех, и посчитать, сколько конкретно стоит один под в Kubernetes, не так-то просто. 

Наверное, можно взять стоимость всего кластера и поделить на количество подов. Но что это даст? А может, лучше оценить реальное потребление CPU и памяти каждым сервисом? А если под использует 10% ядра, но при этом резервирует целое? В общем, что считать, непонятно.

В итоге получается, что в публичном облаке есть готовый биллинг с разбивкой до копейки, а в онпреме — набор допущений, которые можно интерпретировать как угодно. И сравнивать эти две модели напрямую почти невозможно, потому что природа затрат разная. В облаке платишь за потребление, в онпреме — за мощность, которая есть, независимо от того, используешь ты ее или нет.

Сколько жрет один сервис? Методы, которые не врут

После железа неизбежно всплывает вопрос про отдельные сервисы. Особенно в e-commerce или SaaS, где бизнес постоянно думает, развивать продукт или закрывать. И каждый раз все хотят понять, сколько конкретно этот сервис жрет инфраструктуры?

На словах, как водится, ничего сложного. Открыл биллинг, посмотрел ресурсы сервиса, получил цифру. Но в реальности-то сервисы отдельно почти никогда не живут. Если Kubernetes-кластер, то один на десятки команд. Если база данных – то общая, минимум на три продукта. Очереди, кэши, балансировщики — все общее. И как тут считать, что кому принадлежит?

На самом деле есть несколько методов распределения затрат:

• Пропорционально CPU и памяти — учитывается нагрузка, но игнорируется storage и сеть.

• По количеству запросов или записей в базе — отражает активность, но не сложность операций.

• По фиксированному проценту от общей суммы — быстро, но основано на ощущениях, а не на данных.

Другое дело, что все они довольно спорные. Потому что бизнесу нужна не столько точность, сколько порядок цифр. Ему важно понимание, что каталог товаров обходится в 2 миллиона в год, а рекомендации — в 10. И что если выключить рекомендации, счет упадет не на 50%, как кажется, а на 7–8%. Но вот объяснить это на основе метрик без системы аллокации затрат практически невозможно. Поэтому дорогой сервис или дешевый, чаще всего определяют просто на глазок.

Гибрид: когда две системы счета не складываются

Облако и онпрем — это еще ладно, миры вроде миры, но по отдельности как бы понятные. А вот гибрид — история совсем другая. Тут-то и начинаются настоящие сложности. Часть нагрузки в паблике, часть в дата-центре, а иногда еще приватки замешаны. Поначалу все выглядит красиво: гибкость, независимость, экономия. Но на деле экономия быстро упирается в отсутствие общей картины.

Облако считает одна команда, онпрем — другая, причем часто даже не в этом же отделе. У каждого свой стек, свои отчеты, свои горизонты. В общем, разное абсолютно все. Публичка — помесячный биллинг, онпрем — циклы амортизации на годы. 

В результате появляется сразу несколько параллельных миров:

• Для облака — помесячный биллинг с детализацией до копейки и дашбордами в реальном времени.

• Для онпрема — годовые циклы CAPEX, планирование закупок и оценка через допущения.

• Для SaaS-сервисов — подписки с фиксированной ценой, которые живут отдельно.

То есть управление гибридом хоть и остается возможным, де-факто превращается в точечные костыли. Стоит ли сервис из облака выносить обратно в онпрем? Или старую монолитку перенести в публичку, потому что стойки закончились? Для таких решений нужно сравнивать стоимость CPU и гигабайта в двух мирах. А это опять допущения: электричество, охлаждение и куча других факторов вплоть до того, считать людей или нет.

Прогноз без угадайки: roadmap + метрики = реальность

До поры компании мирились с тем, что инфраструктура живет своей жизнью. Главное, что продакшен работает, а дебет с кредитом как нибудь сведем. Но в какой-то момент это инфраструктура составляет заметную часть затрат. Как следствие, согласовывать бюджеты становится все сложнее, а экстраполяция как способ прогнозирования не воспринимается вообще. Потому что все знают: по итогу получится как угодно, только не так, как считали.

Все дело в динамике облака. Нагрузка растет не по календарю, а по продукту: запустили новую фичу — подскочил трафик, вышли на новый рынок — подключайте дополнительные регионы, запустили внешний сервис — добавляйте к счету плату исходящий трафик. Плюс сезонность, кампании, распродажи… В общем, вы поняли.

В таких условиях более-менее реальный прогноз возможно сформулировать только на основе данных, которые редко лежат в одном месте:

• Маркетинговые планы — сколько новых клиентов приведут, какие кампании запланированы.

• Product roadmap — какие фичи выйдут, сколько новых сервисов появится, выход в регионы.

• Исторические метрики — как рос трафик при аналогичных событиях.

Иначе, если нет связки между бизнесом и инфраструктурой, планирование превращается в угадайку. Скажете, слишком пессимистично? А вот и нет. Это бытовая повседневность компаний с публичным, приватным и гибридным облаком.

Лимиты или культура? Что спасет бюджет на долгосрок?

И главный вопрос здесь не в том, как считать, а в том, как с этим жить? Это, если что, не риторический вопрос.

Если у вас есть опыт, подскажите, что будет лучше на долгосрок: жесткие лимиты с автоблокировкой инстансов или все-таки учить команды думать про деньги с первого terraform apply?

И почему управление инфраструктурными затратами до сих пор выглядит как набор разрозненных костылей, вне зависимости от типа облака? 

Как говорится, доколе?