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

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

Цифры говорят сами за себя: почти 40% компаний регулярно выходят за рамки своих облачных бюджетов, расходуя до трети всех денег, выделенных на облако, впустую. Получается замкнутый круг: 

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

Почему экономия облачных расходов — это не про запреты

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

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

Да, все это может звучать как красивые слова, но понимание затрат реально помогает выбирать решения, которые будут оптимальны как с точки зрения архитектуры, так и с точки зрения бюджета. Если мы сразу видим, что PostgreSQL справляется с задачей за 15 тысяч рублей в месяц, а MongoDB – за 45 тысяч, то поневоле задумаешься, на чем остановиться. Само собой, MongoDB может быть безальтернативным выбором для проекта, но чаще всего выясняется, что реляционная база данных решает задачу не в три раза лучше, чтобы платить за нее в три раза больше.

5 FinOps-методов заставить команды думать о деньгах

1. Мониторинг облачных трат в реальном времени

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

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

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

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

2. Геймификация FinOps: соревнования за экономию бюджета

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

Устраивать в офисе веселые старты не надо (как бы на них тогда попали удаленщики?). Достаточно просто создать внутренние рейтинги команд с реальными поощрениями и давать бонусы за разного рода достижения:

• За высокий процент аллокации затрат в бюджете

• За низкий процент отклонения от запланированных расходов

• За наибольшее количество найденных и устраненных зомби-ресурсов

• За лучшую оптимизацию без потери производительности

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

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

3. Cost-метрики в CI/CD: контроль затрат на этапе разработки

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

Проверка стоимости перед деплоем делается через инструменты вроде Terraform Cost Estimation. Эта штука цепляется к системам CI/CD и автоматически добавляет в Pull Request комментарии с расчетом того, сколько будут стоить планируемые изменения инфраструктуры.

Переоценить пользу от такого подхода реально сложно. По итогу дорогие ошибки будут отсекаться еще до их появления в боевой среде. Разработчик (если он не враг вашей компании, конечно) сразу увидит в своем PR, что новая база увеличит месячные расходы, скажем, на 30 тысяч, и сможет либо подобрать альтернативу, либо как минимум предупредить команду заранее.

Но ограничиваться только CI/CD не стоит. Будет полезно делать предварительные расчеты стоимости инфраструктуры на архитектурном уровне еще до начала разработки. Это может быть отдельный этап на архитектурном комитете или внутренняя проверка.

Берем предполагаемый стек (например, Kubernetes-кластер + managed-база + очередь сообщений) и через калькуляторы облачных провайдеров или open source-инструменты вроде Infracost прикидываем месячный счет. Уже на этом шаге часто выясняется, что выбранная комбинация ест больше бюджета, чем нужно для пилота, и лучше сразу подобрать более экономичный вариант.

Так формируется двухуровневая система:

1. стратегический расчёт общей стоимости будущей инфраструктуры до старта

2. тактический контроль изменений в каждом pull request. В итоге компания получает не только защиту от дорогих ошибок «на лету», но и от изначально избыточных архитектурных решений.

4. Обучение команд FinOps через разбор реальных кейсов

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

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

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

5. Делегирование бюджета: как дать командам финансовую ответственность

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

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

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

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

FinOps-платформы для мониторинга облачных расходов

Готовые FinOps-решения против самописных систем

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

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

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

Не хочется платить за готовые решения? Можно изобрести велосипед, воспользовавшись через Prometheus и Grafana. Благо API у российских провайдеров — Яндекса, VK, Selectel — более-менее нормальные, поэтому метрики затрат вытащить будет не так уж и сложно. Хотя повозиться придется. 

Автоматизация очистки неиспользуемых облачных ресурсов

Но контролировать расходы ручками – это путь заведомо тупиковый. Особенно если у вас больше десятка сервисов и команда постоянно что-то деплоит. Поэтому надо автоматизировать.

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

• Виртуальные машины, которые запустили для теста и забыли;

• Диски без хозяина;

• Снапшоты баз данных, которые создавали для бэкапов, а потом не почистили;

• Балансировщики, которые ни на что не указывают.

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

С алертами история похожая. Настроили лимиты – и ждете. Если траты начнут расти быстрее обычного, вы получите уведомление. Звучит просто, но на практике половина команд узнает о перерасходах только из месячного счета. А там уже поздно что-то менять. Лучше получить пинок в Slack (или вы уже перешли на MAX?), когда еще можно среагировать, чем разбираться постфактум, почему на одинарный эффект приходится двойной бюджет.

Барьеры внедрения FinOps и способы их преодоления

Когда вы начнете внедрять FinOps-практики, то почти наверняка столкнетесь с сопротивлением. Это нормально. Главное знать, как – простите за эту фразу – отрабатывать возражения.

"Нам некогда"

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

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

"Это не наша зона ответственности"

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

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

Чек-лист для внедрения FinOps

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

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

2. Привязать экономию к зарплате. Добавить показатели оптимизации расходов в KPI разработчиков и тимлидов. Когда от этого зависит премия, интерес к облачным тратам появляется очень быстро.

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

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