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

FinOps помогает ИТ-директору не только обосновать необходимость инвестиций через бизнес-результаты, но и, что особенно важно на начальных этапах, объяснить текущий объем расходов. Если завтра CEO спросит: «Почему мы платим столько за облако?» — вы хотя бы сможете показать, куда уходят деньги и за что именно платит компания. На низком уровне зрелости FinOps речь идет не об окупаемости, а о базовой прозрачности и возможности не выглядеть некомпетентным перед финансовым директором (CFO). FinOps — это ваш новый must have, если вы хотите выйти из режима «платим непонятно за что» и взять расходы под контроль.

В статье собрала ключевые тезисы из практики управления FinOps для ИТ-руководителей. При подготовке статьи опиралась на свой опыт в ITSM, материалы по FinOps фреймворк, исследования Gartner и McKinsey, выступления экспертов на конференциях.

FinOps и ITIL Financial Management — взаимодополняющие практики, которые вместе помогают управлять расходами на ИТ и получать максимальный результат от инвестиций в технологии. Gartner рекомендует объединять практики FinOps и ITFM, чтобы получить полную прозрачность затрат на ИТ-ландшафт. Ключевые различия  — в охвате (ITFM  — все ИТ, FinOps  — облако), частоте анализа (ITFM  — ретроспективно, FinOps  — в реальном времени) и ролях (ITFM  — CIO и финансы, FinOps  — инженеры, облачные практики, бизнес). 

На рисунке исследование Gartner по распределению затрат на ИТ по категориям, где видно растущий спрос на облачные сервисы, что подтверждает тенденцию роста затрат на облака.

Скачать исследование Gartner: ITFM, FinOps или оба?

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

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

Ключевые вопросы CIO/CTO об управлении облачными расходами:

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

1. «Какой P&L у каждого сервиса? Приносит ли доход сервис? Доход покрывает расходы?»
   Зачем: Этот вопрос помогает выявить «топ-пожирателей» бюджета (например, забытые тестовые среды, избыточные мощности), понять какие сервисы и процессы зарабатывают деньги и подготовить аргументы для диалога с бизнесом.

2. «Сколько мы можем сэкономить уже сейчас без ущерба для работы сервисов?»
   Зачем: Ответ покажет, какие ресурсы можно уменьшить (rightsizing), удалить или перевести на дешевые тарифы. Например, 20% экономии за счет автоматического удаления «зомби»-серверов.

3. «Как облачные расходы связаны с бизнес-результатами (например, стоимость инфраструктуры на один заказ)?»
   Зачем: Чтобы перестать быть «черным ящиком» и стать полноценным бизнес-партнером. Этот вопрос смещает фокус с абстрактной экономии на управление ценностью. Если стоимость обработки заказа снижается на 15% - это прямая ценность для компании, а не абстрактная экономия. Когда вы знаете какую долю затраты на инфраструктуру занимают в себестоимости одного заказа, вы можете напрямую влиять на рентабельность бизнеса.

Для FinOps специалиста есть дополнительные вопросы, которые помогут оценить уровень зрелости процесса:

1. Сколько будем платить через месяц, полгода, год?

2. Почему расходы на инфраструктуру растут быстрее, чем бизнес?

3. Как устроена структура наших облачных расходов — что составляет основную долю?

4. Кто реально отвечает за эти затраты и кто владелец каждого сервиса?

5. Какой процент расходов мы можем точно атрибутировать по сервисам?

6. Какой у нас оптимизационный потенциал (сколько можно сэкономить при правильном сайзинге)?

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

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

Содержание

Теория FinOps
Что говорит McKinsey о FinOps и на что обратить внимание ИТ-директорам
Как внедрить FinOps: опыт СберМаркета
Почему CFO и ИТ-директор всегда говорят о разном, когда обсуждают облачные расходы
Вы не одни: проблема облачных расходов — массовая
Облако глазами CTO и CFO: почему это действительно выгодно бизнесу
Проблемы при использовании облачной инфраструктуры, которые требуют внедрения FinOps
Пример организации FinOps практики в СберМаркет
Метрики FinOps
Кто нужен для внедрения FinOps и сколько это стоит
Как можно дальше развивать FinOps
Что почитать и посмотреть про FinOps
Для ИТ-руководителей: Организация зрелого FinOps процесса в облаках

Теория FinOps

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

Загрузить оригинал постера FinOps-Framework-Poster-2025.pdf

Ключевые стадии FinOps:

• Inform (Информирование):
  Организация получает прозрачность расходов, настраивает детальное распределение затрат по командам, продуктам и окружениям, внедряет мониторинг и аналитику. На этом этапе формируется база для прогнозирования, бюджетирования и принятия решений.

• Optimize (Оптимизация):
  Анализируются данные о потреблении, выявляются аномалии, используются инструменты rightsizing, внедряются скидочные механизмы и автоматизация для устранения неэффективностей. Здесь принимаются меры по снижению затрат без ущерба для качества и скорости.

• Operate (Эксплуатация):
  Внедряются процессы постоянного улучшения, автоматизация оптимизации и контроля, строится культура финансовой ответственности и регулярного взаимодействия между ИТ, финансами и бизнесом. Организация отслеживает метрики, совершенствует политики и обеспечивает соответствие целям бизнеса.

Модель зрелости FinOps строится по принципу Crawl–Walk–Run (Ползти–Идти–Бежать):

• Crawl: базовая видимость и учет расходов, простая отчетность, реактивное управление.

• Walk: регулярная оптимизация, автоматизация части процессов, внедрение политик и практик.

• Run: автоматизация, прогнозирование, интеграция с бизнес-метриками, принятие решений в реальном времени, постоянное совершенствование.

С фреймворком можно ознакомиться на официальном сайте FinOps Framework Overview

Что говорит McKinsey о FinOps и на что обратить внимание ИТ-директорам

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

1. Не откладывайте FinOps на потом
Многие компании начинают задумываться о FinOps только тогда, когда облачные счета становятся слишком большими (более 100 млн $ в год). 

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

2. Вовлекайте бизнес-лидеров с самого начала

Частая ошибка — рассматривать FinOps как чисто ИТ-практику. Если финансовые директора, владельцы продуктов и другие бизнес-руководители не понимают, как облачные расходы влияют на их показатели, ценность облака для бизнеса остается туманной. Важно не просто информировать бизнес о затратах, а вместе анализировать, как облако влияет на себестоимость, скорость вывода новых продуктов (T2M), маржинальность и конкурентоспособность. Регулярно обсуждайте эти вопросы с CFO и владельцами продуктов, чтобы облачные расходы стали понятной частью бизнес-метрик.

3. Фокусируйтесь на стратегии
McKinsey приводит статистику: 80% времени FinOps-команды уходит на операционные задачи — ручное тегирование, сверку счетов, управление контрактами. На стратегию, аналитику и поиск точек роста остается лишь 20%. Такой перекос мешает увидеть реальную отдачу от облака. Автоматизируйте рутинные процессы с помощью специализированных инструментов, чтобы команда могла сосредоточиться на главном — анализе юнит-экономики, прогнозировании расходов и поиске новых возможностей для бизнеса.

4. Развивайте команду, чтобы она говорила на языке бизнеса
Только 15% компаний действительно понимают (или думают, что понимают), как облачные расходы связаны с бизнес-результатами. Причина — нехватка навыков работы с данными, прогнозирования и коммуникации между ИТ и финансами. 

Многие ИТ-лидеры ошибочно полагают, что для FinOps достаточно собрать пару облачных архитекторов и дать им доступ к биллингу. Однако, как показывает практика, сильная техническая экспертиза — это необходимое, но недостаточное условие.

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

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

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

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

Источник:  The FinOps way: How to avoid the pitfalls to realizing cloud’s value 

Как внедрить FinOps: опыт СберМаркета

На конференции «DevOpsConf 2025» Илья Кочнев, руководитель управления эксплуатации и ИТ-инфраструктуры в Сбермаркет поделился практическим опытом внедрения FinOps для управления расходами в одной из самых облачных компаний страны. Сделано это было столь ювелирно и детально, что вам достаточно посмотреть его выступление и вы закроете большинство вопросов связанных с темой. В самой статье разложила по полочкам доклад Ильи, для тех кто спешит и не может найти час на просмотр видео. 

Второй источник, который расширил картину работы практики FinOps в СберМаркете стал — Антон Егорушков, благодаря его выступлению на TAGES DevOps MeetUp 2023. 

Ссылки все на все источники — в конце статьи. 

Почему CFO и ИТ-директор всегда говорят о разном, когда обсуждают облачные расходы

В работе с облаками у ИТ-директора и финансового директора (CFO) часто возникает недопонимание. Даже если вопросы звучат одинаково, на самом деле их смысл для бизнеса — разный. Посмотрите на топ-вопросы CFO и то, что на самом деле хочет знать финансовый директор (см. картинку):

Разница — не в формулировках, а в ожиданиях:

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

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

Вы не одни: проблема облачных расходов — массовая

Например, отчет Flexera «State of the Cloud 2023» прямо говорит: затраты на ресурсы — проблема №1 в облаке для большинства компаний. 

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

Облако глазами CTO и CFO: почему это действительно выгодно бизнесу

Когда речь заходит о переходе в облако, CTO и CFO зачастую смотрят на одни и те же вещи под разным углом, но оба видят стратегические преимущества. Вот как это выглядит на практике:

С точки зрения CTO, облако предоставляет ключевые технологические преимущества. Во-первых, можно разворачивать любые сервисы и инфраструктуру тогда, когда это нужно бизнесу, без долгих согласований и ожидания закупок. Это напрямую сокращает Time-to-Market: новые продукты и сервисы выходят на рынок гораздо быстрее, что критично для конкурентоспособности компании — и именно это ценит CFO. 

Во-вторых, модель «pay as you go» позволяет сначала использовать ресурсы, а платить потом, что избавляет от необходимости закупать мощности впрок и дает гибкость масштабирования под реальные задачи. Для бизнеса это означает отсутствие замороженных средств и возможность быстро реагировать на изменения спроса.

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

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

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

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

Рассмотрим основные проблемы, которые возникают после начала эксплуатации облачной инфраструктуры.

Более высокая стоимость за единицу ресурса

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

Сложность биллинга и консолидации данных

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

Встроенные инструменты учета затрат на облачную инфраструктуру не работают

Встроенные инструменты учета затрат на облачную инфраструктуру — это одна из самых больших ловушек для ИТ-директора, который хочет реально управлять бюджетом и отвечать на вопросы CFO. Стандартные средства облачных провайдеров работают только для небольших, изолированных проектов, но полностью проваливаются на масштабе современной компании с микросервисной архитектурой и мультиклаудом.

Каталоги, аккаунты, проекты — кажется, что если разнести сервисы по разным папкам и владельцам, можно получить прозрачную картину расходов. Но на практике 90% затрат оказываются в одном «production»-каталоге.

«Черные ящики» и коммунальные ресурсы

В микросервисной архитектуре и Kubernetes сервисы плотно упакованы друг с другом. Общие ресурсы (кластеры, базы данных, очереди) становятся «черными ящиками», где сложно понять, кто и сколько потребляет. Без специальных инструментов (Kubecost и аналоги) расходы сложно точно атрибутировать. Без «разрезания» общих ресурсов, аттрибуция будет недостоверной и нерепрезентативной. Будет у вас здоровенный и дорогой кусок инфраструктуры без аттрибуции, как будто вообще не начинали этим заниматься. Это нужно делать обязательно.

Облака ничего не знают о вас

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

Облака меняют подход к планированию мощностей

В традиционной ИТ-инфраструктуре планирование емкости (capacity planning) строилось на годовых бюджетах и экспертных оценках: раз в год собирались заявки от бизнес-подразделений, закупались серверы и оборудование «с запасом» — и можно было относительно спокойно жить до следующего бюджетного цикла. В облаке этот подход перестает работать: ресурсы берутся по мере необходимости, новые сервисы запускаются буквально за часы, а расходы становятся динамичными и непредсказуемыми

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

Вспомним также про «человеческие» минусы, возникающие на стороне компании пользователя облака.

Основные проблемы:

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

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

• Забыли остановить ненужное. После завершения проектов, тестов и экспериментов ресурсы продолжают работать, хотя уже не нужны. Такие «зомби»-инстансы и базы данных незаметно увеличивают расходы.

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

• «Фирма платит». Классическая проблема корпоративной среды. Сотрудники не чувствуют личной ответственности за расходы, ведь платит компания. Нет мотивации экономить, т.к. «не мое».

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

Пример организации FinOps практики в СберМаркет

Стратегия распределения затрат

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

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

• Теговая (лейбловая) модель
  Каждый облачный ресурс, сервис или сущность обязательно маркируется тегами/лейблами, которые указывают на владельца, тип сервиса, проект и другие параметры. Это дает высокую детализацию и достоверность распределения затрат — можно точно посчитать, сколько стоил каждый сервис или команда. Минус — сложно реализовать на 100% покрытие, требует автоматизации и дисциплины, а также не решает проблему «черных ящиков» (общих ресурсов).

Команда СберМаркета использует обе модели одновременно:

• На верхнем уровне затраты делятся по аккаунтам и каталогам (иерархия).

• Внутри — все сущности тегируются, что позволяет детализировать расходы до уровня сервисов и владельцев.

• Для «черных ящиков» (например, Kubernetes-кластеры) дополнительно внедряются лейблы и специализированные инструменты (Kubecost и аналоги), чтобы «просветлять» коммунальные ресурсы и правильно атрибутировать затраты.

Плюсы такого подхода:

• Можно покрыть практически все расходы, включая сложные и общие ресурсы.

• Достигается баланс между простотой управления и глубиной аналитики.

• Позволяет строить сквозную аналитику для BI-дашбордов, финансов и владельцев сервисов.

Минус:

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

Сервисный каталог и CMDB

Чтобы соединить мир финансов и ИТ, команда СберМаркета выбрала понятие «сервис» как ключевую точку соприкосновения между инфраструктурой и финансами. С точки зрения финансистов, все строится вокруг центров затрат и бизнес-владельцев, а облако оперирует сущностями вроде кластеров, виртуальных машин и баз данных. Эксплуатация же видит сервис как бизнес-единицу, за которой стоит конкретный владелец и набор облачных ресурсов.

Каждый бизнес-сервис описан в сервисном каталоге. Каталог хранится в CMDB (например, Jira Insight), что позволяет автоматически связывать каждую облачную сущность с конкретным сервисом и владельцем. Эти данные становятся «источником правды». 

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

1. Сервисный каталог как обязательное условие управляемости. Вы не можете управлять тем, о чем не знаете. В условиях сложной микросервисной архитектуры сервисный каталог — это не опция, а абсолютный must-have. Он создает единый реестр всех ИТ-активов, без которого любые попытки анализа и оптимизации обречены на провал.

2. Жесткая интеграция с процессами. Чтобы каталог не разошелся с реальностью, он должен быть встроен в процессы. Самый эффективный подход — сделать его использование обязательным. Например, по принципу «нет сервиса в CMDB — нет деплоя». Когда без актуальной записи в каталоге невозможно выкатить изменения в прод, команды сами заинтересованы в поддержании данных в порядке.

3. Двусторонняя синхронизация и поиск аномалий. Необходимо наладить не только обновление CMDB из процессов, но и «обратную сверку» — регулярный аудит реальной инфраструктуры с данными каталога. Нужен автоматизированный процесс, который будет выявлять аномалии: например, находить ресурсы, которые существуют в облаке, но не описаны в CMDB. Это помогает находить «бесхозные» или забытые активы и поддерживать каталог в стопроцентной актуальности.

Инфраструктура как код и обязательное тегирование

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

Консолидация биллинга и детализация расходов

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

Сырые биллинговые данные из всех облаков автоматически парсятся и складываются в единую базу данных (Data Lake). Отдельно интегрируются данные из инструментов детализации (например, Kubecost для Kubernetes), чтобы «просветлять» коммунальные ресурсы (ЧЯ — черные ящики) и точно атрибутировать расходы по сервисам.

Для контроля затрат и оптимизации используемых ресурсов используются различные решения. 

Один из примеров — Cloud Advisor — это платформа, которая анализирует использование облачных ресурсов и автоматически выдает рекомендации по оптимизации расходов. Кроме вопросов инвентаризации и контроля расходов сервис также помогает обеспечению безопасности в публичном облаке (но это не вопрос этой статьи).

Пример отчета по сервисам в cloud advisor

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

Варианты представлений в Cloud Advisor

Пример аналитики с расчетами возможной экономии.

И показывает возможную экономию в разрезе каждого ресурса и рекомендации по ее достижению.

В том числе объединяя сущности более высокого порядка. Например, если виртуальные машины недостаточно нагружены, являются узлами Managed Kubernetes и входят в одну группу узлов, то Cloud Advisor выдаст один алерт на все виртуальные машины “Группа узлов недостаточно нагружена” вместо множества алертов на каждую виртуальную машину.

В том числе Cloud Advisor позволяет определять правила использования облаков и уведомлять о нарушении созданием заявки или письмом (сообщением в мессенджер).

Для управления расходами в Kubernetes-кластерах используются решения kubecost и opencost.

Обзор kubecost на Хабр – https://habr.com/ru/companies/flant/articles/466659/ 

Обзор opencost на Хабр – https://habr.com/ru/companies/selectel/articles/795659/ 

ML-модели для прогнозирования расходов

На основе исторических биллинговых данных и бизнес-показателей строятся ML-модели, которые прогнозируют расходы по каждому облаку и сервису с учетом сезонности, бизнес-планов и динамики компании. Такой подход позволяет уйти от экспертных оценок к data-driven планированию и минимизировать «сюрпризы» в бюджете.

BI-дашборды для прозрачности и управления

На основе единой базы строятся BI-дашборды для разных стейкхолдеров:

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

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

• ИТ-руководители контролируют покрытие тегами, утилизацию ресурсов и эффективность всей инфраструктуры.

Дашборд 1 предназначен для финансовых специалистов и ИТ-руководителей. Он строится на единой базе данных с историческими биллинговыми данными и позволяет:

• Видеть общие затраты по всем облакам — сколько тратится в целом и по каждому облаку отдельно.

• Делать drill-down до сервисов — можно провалиться внутрь каждого облака и посмотреть разбивку расходов по сервисам.

• Показывать прогноз потребления — дашборд отображает прогнозы на будущие периоды, построенные на ML-модели, что помогает финансистам и ИТ-подразделению планировать бюджет и контролировать отклонения.

• Контролировать потребление — позволяет отслеживать динамику расходов и сравнивать их с бизнес-планами.

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

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

• Делать drill-down по сервисам — можно посмотреть детализацию расходов по каждому сервису.

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

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

Метрики FinOps

Три ключевые метрики FinOps, которые помогают Сбермаркету управлять облачными расходами и принимать решения на основе данных:

% нераспределенных расходов

Что это: Доля затрат на инфраструктуру, которые не удалось «привязать» к конкретным сервисам, продуктам или владельцам.

Почему это важно: Чем выше этот процент, тем больше «черных ящиков» в вашей инфраструктуре и тем сложнее объяснить расходы бизнесу и финансам. Цель зрелого FinOps — максимально снизить долю нераспределенных расходов (идеал — 0%), чтобы каждый рубль был прозрачен и обоснован.

Оптимизационный потенциал всей инфраструктуры

Что это: Это сумма, которую компания могла бы сэкономить, если бы ресурсы использовались максимально эффективно. 

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

Стоимость инфраструктуры на 1 заказ

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

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

Эти метрики превращают FinOps из «отчетности ради отчетности» в реальный инструмент управления: позволяют видеть, где теряются деньги, где есть потенциал для экономии и как ИТ влияет на бизнес-результат. Чем прозрачнее и детальнее ваши метрики — тем сильнее ваша позиция перед финансами и бизнесом.

Кто нужен для внедрения FinOps и сколько это стоит

Представьте, что вы покупаете дорогой пылесос-робот для уборки квартиры. Если у вас студия 20 м² — он окупится через год. Если дом 200 м² — за пару месяцев. Так и с FinOps: прежде чем внедрять сложные процессы, посчитайте, выгодно ли это именно вам.

Для внедрения FinOps в СберМаркете была собрана кросс-функциональная из команда из действующих сотрудников, которая включала аналитиков, project manager-а, CTO и infrastructure lead, финансистов (CFO и финансовых контроллеров), разработчика, инженера по инфраструктуре и платформе, ML-инженера и BI-специалиста. 

Такой состав позволил не только автоматизировать сбор и обработку данных, но и построить прозрачную аналитику, ML-прогнозы и дашборды для разных стейкхолдеров. За 8 месяцев команда вышла на процент покрытия нераспределенных расходов – 75%.

Стоимость команды внедрения FinOps была приведена в другом выступлении на конференции «Оптимизация цифровой инфраструктуры 2025», организованной CNews Conferences — Дмитрем Важениным, Директором по развитию Клаудмастер.

Стоимость ФОТ команды — 26 млн. руб. в год, что будет окупаться, если траты на облака более 174 млн. руб. 

По мнению Ильи Кочнева, этот подход скорее описывает зрелую стадию. Начинать можно и нужно раньше:

• Не создавайте отдельную команду на первом этапе. Это избыточно и дорого.

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

• Привлекайте ресурсы ad-hoc. По мере необходимости точечно подключайте к задачам аналитиков, финансистов или разработчиков, не выводя их из текущих команд.

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

Как можно дальше развивать FinOps

Дальнейшее развитие FinOps в СберМаркете будет строиться на трех ключевых метриках: максимальном увеличении процента распределенных расходов (сейчас покрытие 75%, цель — 100%), регулярной оценке и реализации оптимизационного потенциала всей инфраструктуры (выявление и устранение избыточных ресурсов, автоматизация rightsizing), а также постоянном снижении стоимости инфраструктуры на один заказ за счет прозрачной аналитики, автоматизации и тесной интеграции ИТ- и бизнес-метрик. 

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

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

Что почитать и посмотреть про FinOps

Выступление Ильи Кочнева «FinOps в облаках» на конференции «DevOpsConf 2025»

Выступление Антона Егорушкова на TAGES DevOps MeetUp 2023 – FinOps в облаках - YouTube — база про FinOps в облаках

Выступление Вячеслава Бессонова (Hilbert Team) с практическими примерами оптимизации расходов на облако «Как на практике оптимизировать расходы на облако с помощью FinOps - YouTube»

Hilbert Team. Полезные FinOps-ресурсы в одной Google Таблице

Также в материале используются материалы из презентации Дмитрия Важенина, Директора по развитию Клаудмастер.

Для ИТ-руководителей: Организация зрелого FinOps процесса в облаках

Практика FinOps сегодня становится неотъемлемой частью зрелого управления ИТ-расходами в облаках. Она помогает не только повысить прозрачность и управляемость затрат, но и выстроить прочную связь между ИТ-инвестициями и бизнес-результатами. Как показал опыт СберМаркета, внедрение FinOps — это не разовая акция, а путь постоянного развития: от первых шагов по учету расходов до построения автоматизированной аналитики, ML-прогнозов и глубокой интеграции с бизнес-метриками.

Для ИТ-руководитель должен понимать:

• FinOps — это не только про экономию, но и про культуру совместной ответственности, где ИТ, финансы и бизнес работают как единая команда.

• Без прозрачности и детализации расходов облако быстро превращается из драйвера эффективности в источник неожиданных затрат и рисков для бизнеса.

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

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

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

---

Материал бережно подготовлен:

Особая благодарность за помощь в подготовке статьи:

Илье Кочневу, Head of IT Ops Lamoda Tech

Антону Егорушкову, Head of DevOps Lamoda Tech, ТГ-канал: @owl_tech