Многие российские компании, отказались от железной инфраструктуры и, перейдя в облако, столкнулись с неожиданным парадоксом. Финансовое планирование, которое должно было стать проще, на деле усложнилось настолько, что потеряло всякий смысл. Ситуации, когда стартап закладывал в месячный бюджет 500 тысяч рублей на облачные расходы, а по итогу получал счет на 1.2 миллиона, стали обычным делом. И это не единичные случаи. Исследование Flexera за 2023 год показывает, что с перерасходом сталкиваются примерно 45% всех организаций. А, по данным Wasabi, и вовсе 60%. Конечно, так быть не должно. 

Подписывайтесь на наше FinOps-комьюнити в Telegram. Обещаем не спамить. Там только настоящая польза, рабочие кейсы и общение с единомышленниками.

Откуда берется непредсказуемость

Нагрузки живут своей жизнью

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

Сегодня количество пользователей одно. А завтра мы провели маркетинговую акцию и привлекли в 10 раз больше посетителей всего за несколько часов. Послезавтра Роскомнадзор заблокировал какой-нибудь сервис, и вот мы отмечаем еще 2- или 3-кратный прирост. 

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

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

Тарификация как черный ящик

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

• Процессорное время

• Память

• Дисковые операции

• Сетевой трафик

• API-вызовы

• Служебные запросы

А поскольку все это тарифицируется отдельно и по разным алгоритмам, просчитать все заранее становится практически нереально.

Чтобы сократить зависимость от переменной составляющей, многие компании переходят на резервированные инстансы. Но и тут есть свои нюансы. Во-первых, это требует более точного прогнозирования будущих нагрузок. А, во-вторых, ошибка в ту или иную сторону все равно приведет к переплате: либо за неиспользованные резервы, либо за дорогие on-demand ресурсы, запущенные сверх плана.

А ведь еще есть скрытые статьи расходов. Они редко попадают в планы, но при этом составляют существенную долю в итоговом счете:

• Исходящий трафик между регионами

• Вызовы к внешним API

• Служебные запросы систем мониторинга

• Резервное копирование данных 

По факту их еще больше. Многие провайдеры – в том числе и российские – используют сложные схемы тарификации трафика, которые учитывают не только объем, но и направление передачи данных, время суток, тип контента. В результате к ожидаемому счету легко добавляется еще 30, а то и 40%.

Человеческие ошибки множатся на автоматизацию

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

• Забытые инстансы для тестирования;

• Кластеры Kubernetes с включенным автоскейлингом;

• Неудаленные базы данных;

• Дублирующие системы бэкапов.

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

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

Мультиоблачность как источник хаоса

А если платформ несколько? По данным Deloitte, 73% организаций используют гибридные облака, а 53% работают с несколькими провайдерами сразу, и у каждого собственная модель тарификации, своя форма учета и тем более скидочные программы.

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

Цена непредсказуемости

Финансовые риски растут как снежный ком

Результат всех этих сложностей более чем предсказуем – превышение облачного бюджета, которое в свою очередь влечет за собой целый каскад финансовых проблем. Это и перебрасывание средств, заложенных на другие проекты, на покрытие неожиданных расходов, и недовольство инвесторов, которые начинают задавать вопросы о финансовой грамотности, и требование дополнительных гарантий внутрикомандной дисциплины, и задержки проектов. 

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

Операционный хаос между отделами

Неконтролируемые облачные расходы – это история не только про деньги. Это еще и про распри между техническими и финансовыми командами. Очевидно, что разработчики хотят расширять ресурсы для новых возможностей продукта, а цель финансистов – урезать расходы любой ценой. Иногда стороны находят компромиссы, но в итоге получается “ни вашим, ни нашим”.

Такие решения напрямую тормозят разработку:

• Пропадает возможность быстро тестировать гипотезы;

• Появляется ограничение на A/B-тесты;

• Экспериментировать с новыми технологиями оказываются под запретом.

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

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

Репутационные потери 

А дальше – как снежный ком. Регулярные перерасходы закономерно ведут к тому, что высшее руководство перестает доверять облаку как таковому. Иначе просто и быть не может. Срывы релизов из-за бюджетного голода вызывают недовольство клиентов, партнеров, инвесторов. IT-команда попадает под подозрение в некомпетентности, а каждая крупная трата начинает требовать многоуровневых согласований. 

Как говорится, не проще ли взять и отменить все, что так портит всем жизнь? Может быть, и проще. Но это при условии, что вы ищете именно простоту, а не эффективность. Для всех остальных путь только один – менять тактику прогнозирования.

Методы борьбы с неопределенностью

Исторические данные плюс машинное обучение

Как ни странно, но это вполне реально даже в условиях множества переменных. Основой для для построения прогнозов будущих трат станет анализ прошлых расходов. Для этого современные облачные BI-сервисы предлагают предсказательные модели, работающие на ретроспективных данных. Такие фичи давно есть не только у AWS, Azure и Google, но и у отечественных платформ. 

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

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

Сценарное планирование как подстраховка

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

• В оптимистичный сценарий закладываем значительный рост трафика из-за успешных маркетинговых акций или вирусного распространения продукта.

• Базовый сценарий предполагает стабильное развитие без резких скачков.

• Пессимистичный учитывает возможные проблемы: технические сбои, снижение активности пользователей, необходимость экстренной оптимизации.

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

Финансовая дисциплина через unit-экономику

Третий метод напрямую связан с изменениями в корпоративной культуре. Перевод облачных метрик в бизнес-термины помогает связать технические решения с финансовыми результатами. Когда себестоимость одного посещения сайта или стоимость обработки одного API-запроса становятся понятными показателями, принимать решения становится гораздо проще.

Жесткие лимиты и процедуры согласования тоже дисциплинируют команды. AWS Budgets, Яндекс.Облако, VK Cloud позволяют задавать месячные квоты на проект и требовать дополнительных согласований для превышения лимитов. Такой порядок позволяет исключить большинство случайных перерасходов и заставляет разработчиков заранее планировать ресурсоемкие операции.

Система showback/chargeback распределяет облачные расходы между подразделениями, делая каждую команду ответственной за свои траты. А когда стоимость инфраструктуры напрямую влияет на бюджет отдела, мотивацию родишь поневоле, хочешь ты этого или не хочешь.

Специализированные инструменты контроля

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

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

Первые шаги к контролю

Все это звучит сложно, но FinOps – это про последовательность. А значит, начинать можно с самых простых шагов:

• Аудит текущих трат позволит выяснить, куда уходят основные деньги, и найти очевидный мусор.

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

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

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