Как отучить разработчиков тратить облачный бюджет как в последний раз

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

Стандартная реакция финдира на раздувшийся счет за облако чаще всего проста как пять копеек:

Разработчикам это, конечно, не нравится, и они тут же встают в позу. Дескать, как же так? У нас дедлайны, а тут вы со своими копейками.

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

Ведь если разработчику, который использует MongoDB, просто потому что с ней удобнее работать, никто не объяснил, что она обходится втрое дороже PostgreSQ, иначе и быть не может. Так вот FinOps как раз и нужен, чтобы всю эту информацию сделать доступной, а недопонимание между сотрудниками – устранить.

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

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

Многие российские платформы предлагают готовые решения мониторинга. Например, Клаудмастер подмечает странности в потреблении ресурсов и предупреждает, если что-то идет не так. Вроде мелочь, но своевременное выявление аномалий позволяет сократить облачные траты на 20-30%, фактически ничем не жертвуя. Главное – настроить уведомления так, чтобы они прилетали до того, как деньги закончились, а не после.

Еще можно встроить расчет стоимости прямо в процесс разработки. Terraform Cost Estimation может автоматически комментировать каждый pull request, показывая, во что обойдутся планируемые изменения. Так разработчик сразу будет знать, что добавить новую базу обойдется компании в дополнительные 30 тысяч к месячному счету. И тут уже придется выбирать: либо искать альтернативу подешевле, либо хотя бы предупредить команду заранее.

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

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

Но о деньгах надо думать еще до того, как начнется разработка. Правильнее всего будет прикинуть, во сколько обойдется выбранный стек еще на архитектурном этапе. Берем, например, Kubernetes-кластер, managed-базу и очередь сообщений, прогоняем через калькулятор облачного провайдера или Infracost. Так мы получим месячный счет и сможем сразу понять, тянем мы пилот или нет.

В результате контроль работает на двух уровнях:

Так мы снижаем риск как глобальных просчетов, так и мелких перерасходов в процессе разработки.

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

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

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

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

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

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

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

Хочешь заставить команду экономить? Дай ей… нет, не рыбу, а собственный бюджет и скажи: вот ваши деньги, тратьте их как считаете нужным. Звучит страшно. Но когда люди понимают, что перерасход придется как-то объяснять руководству или компенсировать экономией на других проектах, отношение к тратам меняется.

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

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

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

А ведь всего-то и нужно, что простенький скрипт, который раз в неделю проверяет неиспользуемые ресурсы и шлет уведомления. У российских провайдеров – Яндекс.Облако, VK Cloud, Selectel – API достаточно адекватные, чтобы вытащить нужные метрики без особых мучений.

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

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

Вопрос только в том, как их искать:

Когда вы начнете внедрять FinOps-практики, то почти наверняка столкнетесь с неприятием со стороны команды. На самом деле это неважно. Важно то, как с этим работать.

Чаще всего отказ погружаться в FinOps сопровождает довод о нехватке времени. Якобы разработчики и DevOps-инженеры и так работают на пределе, поэтому дополнительные задачи им уже “не лезут”. Решается это довольно легко. Просто покажите им, что, потратив один час на автоматическое отключение тестовых окружений, они будут экономить компании десятки тысяч каждый месяц и сами получат больше свободного времени.

Второе популярное возражение звучит примерно так: "А причем тут мы вообще?" Технари часто думают, что финансы – это забота бухгалтерии, а им нужно просто писать код. Логика понятная, но в контексте FinOps в корне неправильная.

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

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

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

Эта статья написана в интересах русскоязычного комьюнити “Практики FinOps”.