Хотите лайфхак, как выбесить финдира? Забудьте про задержки в релизах, падения продакшена и критические баги. Все это мелочи. Если хотите по-настоящему вывести его из себя, возьмите за правило никогда не отключать на выходные тестовые инстансы, разверните staging-среду на том же железе, что и продакшен, и настройте автобэкапы сразу в 2-3 региона. А когда получите счет за облако на 800 тысяч вместо 300, надменно спросите – “А при чем тут я?”. Звучит как вольный пересказ “Вредных советов” Г. Остера, согласен. Да и мы с вами не в третьем классе, а значит, вредительско-инфантильный подход к работе просто не допустим. Поэтому в команде надо с самого начала развивать культуру разумного потребления облачных ресурсов, чтобы и код писать с удовольствием, и финансистов до нервного срыва не доводить.

Экономия на корпоративном облаке

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

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

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

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

Откуда взялся FinOps: сравнение западного и российского подхода

Оптимизация – она, как говорится, и в Африке оптимизация. Но вот FinOps почему-то в разных странах развивают по-разному.

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

"Я начала свой путь как бизнес-аналитик. И потом интерес к аналитике облачных сервисов возник персонально, мне было интересно это изучать," — рассказывает Ксения Кроха, эксперт с 8-летним опытом работы в FinOps, работающая на Западе.

У нас все с точностью до наоборот: FinOps обычно вырастает из DevOps, потому что финансисты в железе чаще всего почти не разбираются. 

То есть в России превалирует схема "от железа к деньгам": DevOps’ы, которые работают с инфраструктурой, первыми замечают неэффективное использование ресурсов и начинают считать, во что это обходится компании. 

Еще одно отличие – формирование команд. На Западе предпочитают формировать специальные отделы для претворения политик FinOps в жизнь, а в России это чаще всего не отдельная должность, а совмещение.

Культурные различия тоже заметны. У нас сотрудники до сих пор боятся какого-то контроля. А в Европе к этому относятся очень положительно, даже аналитика вплоть до owner’а дает очень хорошую прозрачность.

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

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

Пять способов заставить команды считать деньги

Мониторинг затрат

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

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

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

Только на этом можно экономить по 20-30%. Не верите? Все так и есть: увидели проблему в реальном времени – тут же ее решили. А если нет слепого перерасхода  – есть экономия. Вот вам и простые истины.

Геймификация в FinOps

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

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

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

Калькулятор стоимости разработки

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

В этом помогает встраивание cost-метрик в процесс разработки. Этой цели могут служить как Terraform Cost Estimation или Infracost, так и собственные решения, которые умеют автоматически анализировать изменения в инфраструктурном коде и добавлять в Pull Request оценку финансовых последствий.

Когда разработчик создает PR с изменениями в конфигурации с разбивкой по стоимости, он сразу увидит, что добавление, скажем, managed-сервиса увеличит расходы на 28 тысяч рублей, масштабирование кластера – на 16 тысяч, а CDN – на 7. Таким образом, с одной стороны, достигается наглядность, а с другой, появляется возможность выбирать, что важнее. 

В результате:

• Дорогие архитектурные решения отсекаются еще до деплоя, когда их легко поменять.

• На этапе ревью кода появляется дополнительный критерий оценки, такой как финансовая эффективность.

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

Обучение FinOps на живых кейсах

Обучаться на сухих презентациях про принципы FinOps – дело неблагодарное и малоэффективное. Скажите спасибо, если люди вообще высидят и досмотрят слайды до конца. А то ведь и уйти могут. То ли дело живые истории из практики. Дайте людям конкретный пример. Возьмите неудачный алгоритм обработки данных, который обходился компании в десятки тысяч рублей, а потом покажите, как вы (или не вы) его оптимизировали, снизив расходы в несколько раз. 

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

Но, когда люди понимают, что каждый гигабайт исходящего трафика стоит 5-10 рублей, будьте покойны, они и сами начнут искать способы оптимизации. Может, стоит включить сжатие для API-ответов? Или кэшировать статические ресурсы на CDN? Или пересмотреть архитект��ру, чтобы уменьшить объем межсервисного взаимодействия? Главное – дайте им свободу выбора, чтобы вас не свели с ума своими согласованиями.

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

Что собственные бюджеты команд дают для FinOps

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

• Во-первых, так мы учим команды отвечать за свои затраты. Нет, не головой, конечно. Зачем вам “ходоки к Ленину” с целой пачкой написанных “по собственному”? 

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

"Ключевая идея FinOps — чтобы команды отвечали за свои расходы," — отмечает Ксения Кроха.

Только не наказывайте людей за превышение. На самом деле это и не нужно. На первом этапе нам будет достаточно просто видеть showback-отчеты: сколько потрачено относительно плана, какие сервисы съедают больше всего денег, где есть возможности оптимизации. 

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

Инструменты оптимизации: бесплатная FinOps-платформа

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

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

Просто воспользуйтесь FinOps Radar. Это бесплатный инструмент, который анализирует ваши биллинговые данные и выдает рекомендации, какие действия следует предпринять, чтобы сэкономить.

Что умеет FinOps Radar:

• Обнаружение аномалий

• Поиск зомби-ресурсов

• Автоалерты

Пусть вас не пугает его самостоятельность. Сервис работает в режиме read-only. В этом и преимущество, и недостаток FinOps Radar. Преимущество – потому что он не положит ваш продакшен, если вдруг что-то пойдет не так. А недостаток – потому что это ограничивает возможности автоматизации рутины, и все действия вы должны подтверждать вручную. 

Как подключить FinOps Radar

Процесс занимает около получаса. Но ничего сложного тут нет:

1. Настроить экспорт детализации биллинга в Object Storage (создать бакет и папку, включить поресурсную детализацию).

2. Создать сервисный аккаунт с минимальными правами, сгенерировать ключи доступа и назначить роли auditor, monitoring.viewer и billing.accounts.viewer.

Зарегистрироваться на cp.finopsradar.ru, указать параметры бакета и ключи.

Более подробная инструкция по настройке дана в отдельной статье – обязательно почитайте, если интересно. Там расписаны не только шаги, но и преимущества и особенности работы FinOps Radar.

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

Как победить непринятие FinOps у сотрудников

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

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

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

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

"Не все будут принимать практики FinOps с распростертыми объятиями. Особенно это касается DevOps’ов и разработчиков. Они почему-то считают, что их заставляют быть ответственными за ресурсы, но на самом деле никто не несет ответственность за ресурсы компании. Каждый несет ответственность за качество выполнения своей работы," — объясняет разницу в восприятии Ксения Кроха, эксперт в области FinOps.

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

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

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

Если вы дотерпели до этого момента, вручаем вам медаль юного падавана FinOps-практик. И хотя вам еще предстоит внедрить их у себя в компании, первый этап начат. Теперь главное – следовать правилам, которые приведут вас к успеху:

1. Добиться прозрачности затрат. Интегрируйте данные о расходах в системы мониторинга, которыми пользуются ваши разработчики, или подключайте специализированный сервис типа FinOps Radar.

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

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

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

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

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

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

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