FinOps: как связать расходы на облако с продуктами, командами и бизнес-результатом

Облако обещает бизнесу гибкость: инфраструктуру можно получить за минуты, масштабировать под нагрузку и платить за фактическое потребление. Но у этой модели есть обратная сторона. Чем проще разработчику получить инфраструктуру, тем сложнее CIO ответить на простой вопрос CFO:

Проблема начинается не тогда, когда облако становится дорогим. Она начинается тогда, когда компания перестает понимать связь между расходами на инфраструктуру, продуктами, командами и бизнес-результатом. В своей практике я внедрял FinOps именно как систему управления затратами, а не как набор рекомендаций по отключению неиспользуемых серверов. В результате удалось снизить затраты на инфраструктуру на 17%, одновременно получив детализацию расходов по продуктам, компонентам и контурам.В этой статье расскажу, как построить такую систему и зачем она нужна CIO, CPO, CFO и руководителям продуктов.

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

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

Облако меняет эту экономику. Новый сервер появляется несколькими кликами. Новый Kubernetes-кластер — несколькими строками Infrastructure as Code. Увеличение CPU или RAM — изменением конфигурации. Новая база данных — одним запросом к API. Техническое решение превращается в финансовое обязательство мгновенно. И здесь возникает несколько проблем.

Сам факт, что за текущий месяц потрачено 1 млн рублей, мало что говорит. Нужно понимать:

То есть нужен не только план/факт, но и /прогноз.
Вопрос руководителя должен звучать не:

а:

Предположим, у компании есть десять цифровых продуктов. Общий счет за облако — 50 млн рублей в год. Но сколько из этих 50 млн стоит каждый продукт? Если ответить на этот вопрос невозможно, значит невозможно корректно посчитать и экономику продуктов. Мы можем знать выручку продукта, количество пользователей, количество транзакций, маржинальность. Но если стоимость ИТ-инфраструктуры известна только на уровне всей компании, полноценной юнит экономики нет.

Современный продукт может состоять из десятков или сотен компонентов:

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

Классическое представление о FinOps часто сводится к простой формуле:

Это слишком узкое понимание. В зрелой модели FinOps должен отвечать как минимум на пять вопросов:

1. Сколько мы тратим?
2. Кто тратит?
3. На что тратит?
4. Почему это столько стоит?
5. Какой бизнес-результат мы получаем за эти деньги?

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

Поэтому я рассматриваю FinOps не как отдельную техническую практику, а как систему управления экономикой ИТ.

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

Каждый инфраструктурный объект должен иметь соответствующие метки.

Например:

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

Cloud account → Product → Team

вместо:

Cloud account → «ИТ»

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

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

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

Базовая схема выглядит так:

Cloud Billing → Выгрузка в Excel → ручной анализ

Для полноценного анализа одного биллинга недостаточно. Ручной труд в XXI веке мовитон. Поэтому я построил контур данных следующим образом:

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

Но самое важное — рядом с биллингом должны появиться данные о фактическом потреблении ресурсов.

Например:

Теперь мы можем не просто знать:

Мы можем задать следующий вопрос:

Это уже совершенно другой уровень аналитики.

Самая важная часть подхода — соединить финансовые данные с техническими и продуктовыми. В DWH должны встретиться как минимум три группы источников.

Именно объединение этих данных создает ценность. Представим, что стоимость инфраструктуры продукта выросла на 20%. Сам по себе этот факт мало что говорит. Но если одновременно мы видим, что:

то возникает вполне конкретный вопрос:

Ответ может находиться уже не в лишних инфраструктурных компонентах, а в архитектуре или работе продуктовой команды.

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

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

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

Например, если общий сервис обслуживает три продукта, а на продукт А приходится 60% транзакций, на продукт B — 30%, на продукт C — 10%, стоимость сервиса можно распределить в соответствующей пропорции. Но здесь важен не столько конкретный алгоритм, сколько принцип:

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

Когда данные собраны, возникает следующий вопрос:

Я бы выделил четыре уровня аналитики: бюджет, продукты, детализация продукта, анализ инфраструктуры.

На верхнем уровне руководитель должен видеть:

Главный вопрос:

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

Следующий уровень — расходы по продуктам.
Например:

Продукт → DEV / STAGE / PROD / GeoPROD

Здесь сразу становятся заметны интересные вещи. Предположим, есть два примерно сопоставимых продукта. Один использует 100 условных единиц инфраструктурных ресурсов, другой — 300. Первый вопрос:

Это не означает автоматически, что второй продукт построен неправильно. У него может быть существенно большая нагрузка. Но если бизнес-нагрузка сопоставима, необходимо углубляться.Причиной может оказаться:

Здесь FinOps становится инструментом архитектурного контроля.

Это наиболее интересный уровень. Мы соединяем:

Пользователи → потребление → выручка → расходы → результат

Например:

Теперь стоимость инфраструктуры можно обсуждать не в терминах:

а:

Или:

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

Если выручка растет быстрее инфраструктурных расходов — экономика улучшается.

Если инфраструктурные расходы растут быстрее выручки — нужно искать причину.

Последний уровень — анализ самого ресурса. Для каждого элемента можно сопоставить:

Например:

Возникает простой вопрос:

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

26 CPU → 8 CPU → потенциальная экономия X ₽/месяц.

Теперь это не абстрактное:

Это конкретная задача:

Так формируется план работ по оптимизации инфраструктуры.

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

Представим обычную ошибку в IaC:

вместо:

Одна ошибка может создать сотню ресурсов.

Если ошибка обнаружена через несколько минут — это технический инцидент. Если через несколько часов — это технический инцидент с финансовыми последствиями. Если через несколько недель — это уже финансовый инцидент.Именно поэтому FinOps не должен находиться где-то отдельно от DevOps/SRE. Он должен встраиваться в инженерный процесс.
Например, через:

И здесь появляется важный принцип:

После внедрения такой системы меняется сам характер управления. До FinOps разговор выглядит примерно так:

После внедрения:

Это принципиально разные уровни управления.

Первый — реактивный.

Второй — Data Driven.

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

В зрелой ИТ-функции FinOps нельзя рассматривать изолированно.

Он соединяется с:

Получается замкнутый цикл:

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

Именно этот цикл превращает ИТ из центра затрат в управляемую бизнес-функцию.

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

Понять:

Определить:

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

Соединить стоимость с фактическим использованием:

Теперь появляется возможность анализировать эффективность.

Добавить:

И перейти от анализа cost к анализу unit economics.

Я бы двигался именно в такой последовательности:

Budget → Product → Unit Economics → Infrastructure

Сначала нужно научиться управлять общим бюджетом. Затем понять стоимость продуктов. После этого — связать стоимость с бизнес-результатом. И только затем глубоко оптимизировать отдельные инфраструктурные ресурсы.

У каждой значимой группы затрат должен быть владелец. Не должно существовать ситуации:

Нужно понимать:

Тогда возникает возможность не только анализировать затраты, но и управлять ими.

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

И главное — каждое решение должно иметь ожидаемый экономический эффект.

FinOps начинается с простого вопроса:

Зрелый FinOps должен привести компанию к совершенно другому вопросу:

Для этого необходимо уметь пройти по цепочке:

рубль → инфраструктура → микросервис → команда → продукт → пользователи → выручка.

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

Именно в этом я вижу главный смысл FinOps. Не в том, чтобы просто потратить на облако на 10% меньше. А в том, чтобы сделать экономику ИТ прозрачной, измеримой и управляемой.