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

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

Допустим, у нас была тысяча пользователей, а после рекламы стало 5 тысяч. Потом РКН заблокировал нашего главного конкурента, его аудитория перешла к нам – и вот у нас уже 15 тысяч юзеров, о которых неделю назад мы даже не помышляли. Облако, конечно, вместит всех. Знай только плати. Но точности прогнозирования это не добавляет.

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

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

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

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

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

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

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

К тому моменту, когда счета до дойдут до разработчиков, пройдет уже немало времени. А какая связь между тем, что они делали, скажем, полмесяца назад, и цифрами в таблице?

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

Более 50% компаний используют несколько облачных провайдеров одновременно. Даже если все они находятся в одной юрисдикции и принимают оплату в одной валюте, вы почти наверняка столкнетесь с разными подходами к тарификации, уникальными формами учета и дисконтными условиями. Какие уж тут прогнозы? Тут бы дебет с кредитом свести.

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

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

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

Кроме того, у каждого провайдера свои названия для сервисов, свои способы группировки ресурсов, свои форматы отчетов. Создать универсальный инструмент для анализа расходов в мультиоблачной среде задача нетривиальная.

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

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

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

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

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

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

В результате инициативы по управлению расходами часто начинают буксовать еще на старте.

Всего одна инфраструктура – а тормозит развитие всего бизнеса.

У стартапов в этом плане все еще хуже. Когда вместо запланированных 200 тысяч в месяц приходит счет на полмиллиона, это плохо. Очень плохо. А кому захочется объяснять и без того немногочисленным инвесторам, что деньги улетели на забытые тестовые серверы?

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

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

Чем больше расходы на облако, тем меньше у руководства желания им заниматься. Возможно, сразу от него не откажутся, но будьте уверены, что вскоре начнут появляться новые ограничения, микроменеджмент и никому ненужные многоуровневые согласования. А что? Жечь деньги попусту не захочет ни один руководитель, если он не враг своей компании.

А дальше – пошло-поехало. Релизы срываются, новые функции откладываются, репутация падает, конкуренты радостно подбирают недовольных пользователей и хантят сотрудников.

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

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

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

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

Как управлять тем, что ты никогда не видел? Логично, что никак. Поэтому странно требовать от сотрудников какого-то результата, если они не имеют возможности наблюдать свои затраты в реальном времени.

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

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

Терминология и аббревиатуры – это, конечно, хорошо и правильно. Но только для тех, кто шарит. А если начать затирать руководству про RAM и CPU, вас почти наверняка не поймут. Поэтому всем важно говорить на понятном друг другу языке. В этом и состоит unit-экономика.

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

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