На одном из недавних FinOps X саммитов Джрордж Паркер и Уилл Форрестер из Salesforce представили примечательный, на мой взгляд, кейс построения FinOps-модели, что называется «на вырост». 

Salesforce является одним из мировых лидеров рынка CRM-систем и предлагает облачные решения, основанные на модели SaaS.

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

Проблема: рост затрат и сложность контроля эффективности

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

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

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

Решение: концепция и механика показателя COIN 

Формула и логика

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

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

• Общая стоимость — это фактические расходы на облачные ресурсы за тот же период.

• Срез — атрибут или атрибуты, по которым производится группировка (например, сервисы, владельцы, действия).

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

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

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

Ссылка на страницу, где показатель оформлен как KPI для FinOps-практики. 

Интерпретация и визуализация

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

Для быстрой визуальной оценки используется простая и эффективная система грейдинга Красный — Желтый — Зеленый, которая мгновенно сигнализирует о состоянии дел:

• ? Зеленый (Соответствует ожиданиям):  85-100. Команды в этой зоне эффективно управляют своими ресурсами.

• ? Желтый (Требует улучшения): 60-84. Существуют возможности для оптимизации, на которые стоит обратить внимание.

• ? Красный (Требует срочного внимания): 0-59. Области с высоким потенциалом экономии, требующие немедленных действий.

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

Геймификация и мотивация

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

Техническая реализация: как устроен подсчет показателя COIN 

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

Три ключевых источника данных

1. Данные о совокупных затратах (Total Cost). Это самый простой для получения компонент. Информация извлекается напрямую из биллинговых данных облачных провайдеров и служит знаменателем в формуле COIN Score.

2. Данные для возможностей экономии (Savings Opportunity). Этот компонент требует сбора информации из разнообразных источников: телеметрии и мониторинга (например, утилизация ресурсов),

3. Метаданные и организационная структура. Это самый важный источник данных. Компания использует внутренний «реестр сервисов», который позволяет сопоставить любой уровень иерархии инженерной команды с конкретными сервисами и затратами: от вице-президент по разработке до линейных менеджеров.

Кто и как создает рекомендации по экономии

Моделирование рекомендаций по возможностям экономии — это наиболее важный и творческий аспект поддержания актуальности СOIN. Именно на этом этапе абстрактное понятие «неэффективности» превращается в конкретные, измеримые и действенные метрики. 

Финопс команда выявила 8 направлений рекомендаций. Ниже основные из них:

О чем стоит задумываться, когда вы создаете новую рекомендацию: 

• потенциальная выгода;

• затраты на то, чтобы обратить назад предлагаемое изменение, на случай, если что-то пойдет не так;

• затраты усилий на реализацию предлагаемого изменения (не для всех команд усилия могут иметь одинаковую сложность);

• приемлемость рекомендации с технической точки зрения.

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

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

Разбор примеров с формулами

Вот несколько конкретных примеров, как Salesforce рассчитывает потенциальную экономию.

Пример 1. Апгрейд блочных хранилищ

Описание: Облачный провайдер предлагает экономию до 20% при обновлении хранилищ с поколения Gen 2 на Gen 3. Это простая и понятная возможность.

Формула: Сумма рекомендации = Стоимость хранилища Gen 2 * 20%

Пример 2. Процент использования CPU

Описание: Это самая значимая возможность для экономии в Salesforce, и подход к ее расчету постоянно эволюционировал. Изначально целевым показателем была утилизация P95 на уровне 35% (хотя бы раз в день выходить в пик на такой показатель). Однако этот подход создавал проблемы для архитектур высокой доступности (HA), где резервные узлы намеренно простаивают. В итоге методологию пересмотрели: теперь дополнительно анализируется P99 и отслеживаются только активные узлы, чтобы не «штрафовать» отказоустойчивые системы.

Формула: Сумма рекомендации = Стоимость Compute * (1 - (Пиковая утилизация / Целевая утилизация))

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

Пример 3. Неэффективная сетевая маршрутизация

Описание: Анализ IP-потоков выявил, что трафик, предназначенный для внутренних IP-адресов, иногда направлялся через внешний интернет-шлюз. Перенаправление этого трафика на внутренний маршрут не только повышает безопасность, но и позволяет сэкономить до 75% на стоимости трафика.

Формула: Сумма рекомендации = Стоимость внешнего трафика (% трафика, который мог быть внутренним) 75%

Внедрение и уроки: от прототипа до масштабирования

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

Пересекающиеся возможности. Ключевая сложность — двойной учет экономии, ведь нельзя сэкономить одну и ту же копейку дважды. Например, на один и тот же инстанс могут быть нацелены рекомендации по right-sizing и по переходу на новое поколение платформы. Решение Salesforce — внедрение четкой приоритизации: сначала выполняется right-sizing, а затем остальные рекомендации.

Процесс работы с исключениями. Вскоре стало ясно, что не все рекомендации применимы ко всем командам. 

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

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

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

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

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

Команда Salesforce сделала доступными следующие данные:

• итоговый показатель COIN,

• общие затраты,

• общий размер возможностей экономии,

• разбивка экономии по каждой рекомендации,

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

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

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

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

Получение поддержки руководства. Финопс команда назвала это критическим фактором успеха. Как действовали:

• создание быстрых прототипов для наглядной демонстрации ценности,

• проведение роуд-шоу для топ-менеджеров разработки,

• разработка простых и понятных презентаций и FAQ-документов,

• формулирование ценности на языке менеджеров, делая акцент на том, что им это даст — например, используя аргумент: «Вы сможете обосновать  увеличение бюджета в следующем году».

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

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

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

Планы на будущее

Команда Salesforce не останавливается на достигнутом и планирует дальнейшее развитие системы.

• Расширение покрытия. Добавление новых рекомендаций по оптимизации, охват новых бизнес-юнитов и интеграция с новыми облачными провайдерами.

• Совершенствование методологий. Улучшение точности расчетов, особенно для утилизации CPU в архитектурах высокой доступности (HA), с переходом на анализ P99 вместо P95.

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

• Применение AI. Разработка внутренних инструментов с использованием AI для помощи командам в оптимизации их COIN Score, а также исследование возможностей экономии, связанных с растущими AI-нагрузками.

Ключевые выводы для FinOps-специалистов

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

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

2. Прозрачность порождает доверие. Не скрывайте «магию» расчетов. Предоставьте инженерам полный доступ к данным и формулам. Когда они смогут самостоятельно проверить и понять, как формируется их оценка, они начнут доверять метрике и использовать ее для реальных улучшений.

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

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

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