Nixys – системный IT-интегратор, который помогает бизнесу ускорять разработку и снижать риски за счёт внедрения передовых практик DevOps, DevSecOps и MLOps. Наша команда проектирует и разворачивает отказоустойчивые автоматизированные инфраструктуры на базе Kubernetes, автоматизирует процессы CI/CD и решает задачи, которые обеспечивают стабильную работу вашего проекта.
В этой статье Team-lead инфраструктурного отдела, DevOps-инженер Nixys Пётр Рукин совместно с экспертами комьюнити Практики FinOps поделился практическим подходом к внедрению FinOps-культуры: как начать экономить, как распределять ответственность и плавно перейти от showback к chargeback..
Закон Мура, который обещал нам удвоение мощности каждые два года, оказался не вечным. Прямо сейчас мы наблюдаем за тем, как покорение производителями процессоров каждого следующего нанометра стоит все дороже, а прироста дает все меньше. Из-за этого почти половина операционных расходов дата-центров уходит на оплату электроэнергии. И это притом, что земля тоже не дешевеет, а площади под строительство новых ЦОД выкупаются везде и в любом состоянии. А масштабироваться в таких условиях, сами понимаете, весьма и весьма проблематично. Но бизнесу-то это не объяснишь. Значит, надо экономить. И, по возможности, там, где это делать проще всего.
Эпоха бездумного масштабирования ресурсов подходит к концу
Раньше нехватка инфраструктуры решалась просто. Все просто брали и добавляли ещё серверов, разворачивали новые кластеры, заказывали побольше ресурсов в облаке. Железо дешевело, мощности росли, и никто особо не считал. Сейчас всё иначе. Увеличение ресурсов — это не ответ на рост бизнеса, а дорогостоящая операция, которую нужно как-то обосновывать. Будущее за гетерогенными архитектурами, циклическим использованием ресурсов и глубокой оптимизацией на всех уровнях — от железа и алгоритмов до культуры внутри компании. И без FinOps тут никак.
Помните, как появился DevOps? Разработчики жаловались, что админы тормозят деплои, админы жаловались, что разработчики пишут код, который невозможно поддерживать, а бизнес не понимал, почему всё так долго и дорого. DevOps научил всех работать вместе. Поначалу это нововведение пугало, но прошли годы, и вот это уже не просто мода, а базовый минимум. Так вот FinOps – это то же самое, только для ситуаций, когда железо дорожает, а расходы нужно как-то привязывать к результату.
Какие цели мы хотим достичь?
Важно понять: DevOps – это не только про деплои, а FinOps не только про аудит ресурсов или оптимизацию затрат на инфраструктуру. Речь идет о методологии управления затратами на инфраструктуру, которая объединяет IT и бизнес для повышения ценности от технологических инвестиций за счет прозрачности, оптимизации и совместной ответственности. Основная цель внедрения этой культуры — сделать расходы на инфраструктуру предсказуемыми, управляемыми и соответствующими бизнес-целям. По данным FinOps Foundation, организации, внедряющие FinOps, в среднем снижают облачные расходы на 20-30% при одновременном повышении прозрачности и вовлеченности всех участников.
Внедряя FinOps, мы хотим быть уверены, что наши мощности используются оптимально, а ресурсы ДЦ потребляют ровно столько финансов, сколько необходимо IT командам для достижения их бизнес целей. Собрать данные, распределить затраты и найти аномали�� – это еще не культура. Настоящая культура FinOps начинается только тогда, когда сотрудник может уверенно сказать: “Сам решууу”.
Присоединяйтесь к нашему сообществу Практики FinOps в Telegram. У нас вы встретите настоящих единомышленников и профессионалов своего дела.
Зачем вообще нужен FinOps, если есть финансисты
В профессиональном сообществе живёт стереотип, что FinOps — это вотчина финансистов. Ну а чья же ещё? Разработчик пишет код, DevOps разворачивает инфраструктуру, SRE мониторит приложения, архитектор проектирует системы. А траты — дело бухгалтерии, у них там свои таблички и отчёты. На Западе этим действительно часто занимаются бизнес-аналитики с дашбордами в BI-системах. Но FinOps вырос из DevOps, а не из финотдела. Если DevOps учит команды эффективно распоряжаться временем и совместно отвечать за стабильность, то FinOps добавляет к этому разумное потребление денег.
И вот тут начинается интересное. Внедрять FinOps должна не бухгалтерия — она просто не понимает, почему Kubernetes-кластер стоит столько, сколько стоит, и что с этим делать. Внедрять должна техническая команда. И чаще всего именно DevOps-инженеры становятся катализаторами изменений.
Почему именно DevOps
DevOps-инженер, в отличие от остальных участников, находится в суперпозиции. Он видит инфраструктуру целиком, отвечает за её работу, и имеет доверие всех сторон: разработчики могут получить представление о том, как их приложения будут работать на боевой инфраструктуре. А финансисты получают объяснения, почему инфраструктура стоит именно столько и как можно оптимизировать затраты на ее поддержку.
В российской практике влияние этих факторов ощущается особенно остро. Компании массово уходят в гибридные схемы, строят собственные платформы, смешивают сервисы между облаками и on-prem. Как следствие, чеки растут, а инфраструктуры становятся все менее предсказуемыми.
Что мы хотим получить от FinOps
Как практикующие инженеры и интеграторы, мы особенно заинтересованы в способе перевода «осознанности расходов» в реальные экономические стимулы – от showback к корректному chargeback. В кризис руководство платит за решения с быстрым ROI, и здесь инфраструктура играет роль инструмента выживания – если управлять ею правильно.
Сооснователь Nixys поделился кейсом из нашей практики: веб-студия с более чем 50 проектами получила по результатам аудита неприятный сюрприз – 15 виртуальных машин с утилизацией <10%, избыточные CPU/RAM и неоптимальные S3-полиси. Итоговая переплата – ≈ 82,5 тыс. руб./мес (~990 тыс. руб./год). Пакет оперативных мер снизил расходы в краткие сроки: мы перевели статичные ВМ в instance-groups с автоскейлингом, мигрировали БД на managed PostgreSQL, перенесли архивы в cold storage и настроили мониторинг с рекомендациями по rightsizing. Результат – предсказуемый бюджет и ощутимая экономия уже в первые месяцы.
По данным FinOps Foundation, организации, внедрившие FinOps, в среднем снижают обл��чные расходы на 20-30% при одновременном повышении прозрачности и вовлеченности команд. Но тут важно понимать, что сокращение бюджета – это не самоцель как таковая. Цель — сделать расходы предсказуемыми, управляемыми и привязанными к бизнес-результатам.
FinOps — это методология управления затратами на инфраструктуру, которая объединяет IT и бизнес через прозрачность, оптимизацию и совместную ответственность. Мы хотим быть уверены, что мощности используются оптимально, а ресурсы ДЦ потребляют ровно столько денег, сколько нужно командам для достижения их целей. Не больше, не меньше.
Но собрать данные, распределить затраты, найти аномалии — это механика, а не культура. А настоящая культура FinOps начинается тогда, когда инженер может уверенно сказать: "Я сам решу, сколько мне нужно ресурсов, и сам отвечаю за результат".
Шесть этапов внедрения FinOps-культуры
Весь процесс можно разбить на шесть последовательных этапов. Уточнение “последовательных” тут очень важно, потому что каждый следующий опирается на предыдущий, так что перескакивать не стоит, да вряд ли выйдет.
Этап 1. Подготовка — показываем, что проблема есть
Первый этап — самый простой и самый важный. Нужно показать руководству и командам, что проблема реально существует, и она стоит денег. Много денег.
Настроить мониторинг. В 2026 году инфраструктура без мониторинга — как машина без лобового стекла. Вроде катится, но куда и с какой скоростью — непонятно. Без observability FinOps не взлетит вообще. По стандарту для этого используется стек из Prometheus + Grafana. На нём можно построить отказоустойчивую систему мониторинга, логирования и алертинга, которая и станет фундаментом для всех дальнейших шагов.
Провести аудит расходов. DevOps-команда берёт Ansible (или что там у вас) и прогоняет аудит всех ресурсов инфраструктуры. Можно, конечно, сделать это вручную, но это долго, нудно и чревато ошибками. Поэтому наш выбор – это автоматизированные скрипты. Главное помнить: это не разовая акция, а регулярный процесс. Раз в квартал минимум.
Найти очевидные проблемы. Неиспользуемые виртуалки, забытые dev-окружения, дублирующиеся сервисы, ресурсы без тегов — всё это вылезет при первом же аудите. И вылезет много. Знай только – фиксируй это добро и вноси в черную тетрадку. Фигурально выражаясь, конечно.
Сформировать отчёт. Лучше всего делать это сразу в BI-системе вроде SuperSet или Yandex DataLens, а не в Excel-таблице. BI даёт историческую аналитику, тренды, прогнозы — словом, всё то, что делает отчёт отчётом, а не просто набором цифр.
Предоставить отчёт всем заинтересованным и компетентным. То есть руководству, командам, финансистам. Тут важно донести одну мысль: ресурсы — это не бесплатные игрушки, а деньги. Деньги, которые могли пойти на премии, обучение, новые проекты, да хотя бы корпоративы. А каждый забытый сервер всего этого вас лишает.
Создать межфункциональную команду FinOps. Назначить главу направления и ответственных от каждого департамента: DevOps, разработка, финансы. Если этого не сделать, FinOps превратится в очередную бюрократическую инициативу, которая благополучно загнётся через месяц-другой.
Этап 2. Установление основ — строим фундамент
Второй этап — это фундамент. Здесь закладываются процессы, без которых дальше двигаться бессмысленно.
Настроить централизованную observability расходов. На старте подойдёт облачный биллинг: AWS Cost Explorer, GCP Billing, Yandex Cloud Billing. Потом можно перейти на сторонние платформы вроде CloudHealth или OpenCost и интегрировать их в свою BI-систему. Главное — чтобы данные о затратах собирались автоматически и в одном месте.
Определить зоны ответственности. Кто за что платит? Это нужно прописать чётко и однозначно. Подход зависит от структуры компании: кто-то делит по юнитам, кто-то по тенантам, кто-то по направлениям разработки. Универсального решения нет, делайте как хотите. Просто без распределения ответственности далеко вы не уедете.
Внедрить политику тегирования ресурсов. Это вторая несущая стена фундамента. Без тегов вы не поймёте, кто за что платит, какие ресурсы можно резать, а какие критичны для бизнеса.
Задокументировать всё. Модель ответственности, политика тегирования, регламенты — всё должно быть прописано, утверждено и доступно для ознакомления. Иначе через месяц начнутся споры: "А мы так не договаривались".
Как выстроить систему тегирования
Теги — это пары ключ-значение, которые вешаются на ресурсы как стикеры. Они помогают понять, кто владелец, для чего используется ресурс, насколько он критичен и когда его можно удалить.
Вот как это выглядит в Terraform для AWS:
resource "aws_instance" "example" {
ami = data.aws_ami.ubuntu.id
instance_type = "t3.micro"
tags = {
Name = "App-01"
Team= "Backend"
}
}
Прежде чем лепить теги на всё подряд, нужно ответить на несколько базовых вопросов:
К какому проекту относится ресурс? Без привязки к проекту распределить затраты невозможно. Виртуалка может жить в VDC с названием production-cluster-01, но реально работать на проект mobile-app-redesign. Теги решают эту проблему.
К какому дата-центру относится? В мультитенантных и гибридных архитектурах часть ресурсов проекта может быть в облаке, часть в локальном ДЦ. Например, dev в облаке, а prod on-prem. Тег datacenter позволяет отследить, где что живёт.
Какая команда использует ресурс? Это критично для тестовых контуров, где к ресурсам относятся легкомысленно. В нашей практике был случай: после аудита нашли VM с 64 CPU и 128 RAM, которая 1,5 года простаивала в тестовом контуре. Сейчас такая машина в Yandex Cloud стоит 82 956 рублей в месяц. Разработчик забыл удалить сервер после тестирования базы — и компания год с лишним платила за воздух. Посчитайте убытки сами.
Кто должен платить? Это не всегда очевидно. База данных PostgreSQL может обслуживать три команды одновременно: backend-разработку, аналитику и дата-инженеров. Кто платит? Все поровну? Пропорционально нагрузке? Пропорциональное распределение требует метрик из логов или APM-систем, что усложняет процесс. Проще выделить одного владельца через тег owner: payments_team, а правила распределения общих ресурсов описать отдельно.
Насколько ресурс критичен? От этого зависит, можно ли его оптимизировать радикально. Тестовые ресурсы можно перевести на прерываемые VM с 20% гарантированной доли vCPU — они в три раза дешевле. С production такое не прокатит, но для dev и test — идеальное решение.
Сравним на практике. Виртуальная машина 4 CPU / 16 RAM в стандартной комплектации Yandex Cloud стоит 8 359,51 рубля:
Поставим на ту же модель всего два флага (20% гарантированной доли vCPU + прерываемость), и стоимость падает в три раза:
Ощутимо, правда? Для прода не подходит, но для тестовых контуров — самое то.
На какой срок нужен ресурс? Временные ресурсы — частая история. Например, нужно сравнять тестовый и продовый контуры для нагрузочного тестирования. После тестов серверы больше не нужны. Тег expires_at: 31-12-2025 даёт право на автоматическое удаление, если дата прошла, а тег не обновили. Автоматизация удаления временных ресурсов экономит до 15-20% облачного бюджета.
Примерная политика тегирования
Теги можно разбить на три категории.
Управление затратами:
department — какой отдел платит (finance, marketing, engineering)
project — конкретный проект (crm_migration, mobile_app_v2)
customer — если работаете с несколькими клиентами (client_alfa, client_beta)
cost_center — центр затрат по финмодели (cc_1001, cc_2045)
Жизненный цикл ресурса:
environment — окружение (dev, test, staging, prod)
application — приложение или сервис (web_frontend, api_backend)
owner — кто отвечает (ivan.petrov)
team — команда владельца (devops_team)
schedule — график работы (24x7, business_hours, weekend_off)
Критичность и безопасность:
criticality — критичность для бизнеса (critical, high, medium, low)
compliance — требования соответствия (gdpr, pci_dss, hipaa)
На старте ограничьтесь базовыми тегами. Оптимальный набор: team, project, environment, owner, schedule, criticality. Шести тегов достаточно, чтобы распределить 80-90% затрат и автоматизировать базовые процессы. Будет больше — и никто не станет их проставлять правильно.
И ещё важный момент: стандарты написания. Только латиница, только строчные буквы, только подчёркивания вместо пробелов. Кириллица в тегах — это кракозябры в экспортированных CSV. Environment: prod, environment: production и environment: PROD — это три разных значения для системы, хотя все подразумевают одно и то же. Без единых стандартов отчёты превращаются в мусор.
Этап 3. Метрики — считаем эффективность, а не просто деньги
Теги есть, затраты по командам распределены. Команда видит, что потратила 150 тысяч за месяц. И что дальше? Много это или мало? Абсолютные цифры вроде Total Cloud Spend ничего не говорят. Нужны unit-метрики, которые привязывают затраты к реальному выходу.
Idle Resource Ratio (IRR) — доля неиспользуемых ресурсов. CPU < 5%, RAM < 25% в течение 7 дней — это idle-ресурс, за который платим впустую.
IRR = (Количество неактивных ресурсов / Общее количество ресурсов) × 100%
Cost Allocation Accuracy (CAA) — процент правильно распределённых затрат по тегам. Если половина ресурсов без тегов, распределение затрат не работает.
CAA = (Затраты с корректными тегами / Общие затраты) × 100%
Return on Investment (ROI) — финансовая отдача от инфраструктурных инвестиций.
ROI = (Чистая прибыль от сервисов на инфраструктуре / Общие инфраструктурные затраты) × 100%
Cost Efficiency Index (CEI) — соотношение бизнес-ценности к затратам.
CEI = Доход от внедрения фичи / Затраты на её разработку
SLA-метрики — уровень доступности и качества сервиса.
Availability (%) = (1 − Время недоступности / Общее время периода) × 100%
Success Rate (%) = (Количество успешных запросов / Общее количество запросов) × 100%
Эти метрики позволяют понять, эффективно ли тратятся деньги. Можно тратить миллион в месяц — и будет нормально, если обслуживаешь 10 миллионов пользователей с высоким SLA. А можно тратить 100 тысяч — и это будет слишком много для 1000 пользователей с availability 95%.
Важный момент: никогда не ставьте метрики стоимости без метрик качества. Иначе команда начнёт экономить в ущерб работе сервиса. Правильная связка выглядит так:
Cost per user < 10 рублей И Availability > 99.9% И P95 latency < 200 мс
Все три условия должны выполняться одновременно. Нельзя снизить cost per user до 8 рублей, если availability упал до 99.5%. Это плохая оптимизация. Получается, что вы просто сэкономили за счёт качества.
Этап 4. Культура ответственности — showback vs chargeback
На четвёртом этапе решаем главный вопрос: как именно показывать командам их затраты? Есть два варианта.
Showback — мягкая осознанность
Команды видят свои затраты, но платят из общего IT-бюджета. Инженеры видят, сколько потратили и на что конкретно, но формальных последствий нет.
Showback работает в трёх случаях:
Высокая зрелость команд. Инженеры понимают стоимость инфраструктуры, знают, как оптимизировать, и у них есть время это делать. Обычно это платформенные команды в зрелых tech-компаниях. Им достаточно просто увидеть цифры — и они сами разберутся.
Переходный период. Компания только начинает FinOps. Команды впервые видят реальные затраты — и этого достаточно для первого эффекта. Осознание работает, но временно.
Малый масштаб. Небольшие компании, где все друг друга знают. Работает социальное давление: если мобильная команда тратит в три раза больше бэкенда, это становится темой обсуждений. Репутация важнее формальных механизмов.
Но showback не работает, когда:
Команды хотят, но не могут. Видят проблему, понимают, что надо оптимизировать, но физически не успевают. База жрёт половину бюджета, все это видят, но у всех дедлайны. Showback превращается в хронический отчёт о проблемах без решений.
Команды могут, но не хотят. Нет мотивации. Одна команда тратит 350 тысяч, три другие по 50. Логично оптимизировать первую? Но в showback нет механизма давления. Команда может годами ничего не менять, потому что "у нас своя специфика".
Chargeback — когда нужны реальные деньги
Каждая команда получает счёт за свои ресурсы и платит из своего бюджета. Сэкономил 30 тысяч на инфраструктуре — можешь потратить на что-то полезное или оставить в бюджете. Потратил больше — объясняйся и согласовывай перерасход.
Это меняет всё. Оптимизация из "хорошей практики" превращается в прямую выгоду. Каждое архитектурное решение начинает включать финансовое измерение.
Простой пример: managed MySQL в Yandex Cloud стоит 47 381 рубль в месяц:
Self-hosted на виртуальной машине — 15 221 рубль:
Но для self-hosted нужно время на поднятие MySQL, настройку базы, бэкапирование и поддержку. Стоит ли это делать? В showback выбор очевиден — managed проще и быстрее. В chargeback появляется дилемма: стоит ли потратить время, чтобы сэкономить деньги?
Но chargeback создаёт свои проблемы:
Войны за общие ресурсы. Кто платит за Kubernetes-кластер, которым пользуются пять команд? За CI/CD? За мониторинг? Без чётких правил распределения shared costs начнутся споры.
Субоптимизация. Команда экономит на себе, но создаёт расходы компании. Отказались от managed-базы, сэкономили 60 тысяч в месяц. Теперь нужен DBA на 300 тысяч зарплаты. Команда сэкономила, компания потеряла.
Манипуляции. Chargeback работает по тегам. Появляется соблазн забыть поставить тег, повесить на другую команду или перенести в shared. Без контроля система ломается.
Психология. Chargeback создаёт ощущение недоверия. Раньше все были одной командой, теперь каждый за себя. Снижается кооперация, люди думают не как решить проблему вместе, а как минимизировать свои затраты.
Chargeback имеет смысл только при выполнении всех условий:
Аллокация покрывает 90-95% затрат
Есть единый каталог тегов
Есть процедура апелляции
Задокументированы правила распределения shared costs
Есть ответственный за платформу
Финансы готовы выставлять внутренние счета
Если хоть одно условие не выполнено — оставайтесь на showback. Доведите процессы до ума, а потом милости просим.
Гибридная модель: chargeback + showback
Многие компании используют гибридную схему: продуктовые команды на chargeback, внутренние на showback. Платформенные команды, которые поддерживают общую инфраструктуру, сидят на showback, а их затраты входят в стоимость платформы и делятся между всеми продуктовыми командами через chargeback.
Главное — чётко документировать, кто на какой модели и почему. Иначе будут вопросы: "А почему мы платим, а они нет?"
Определить зоны ответственности. FinOps, как и любая инвестиция, должен окупаться. Нельзя экономить в ущерб работе сервиса. Для этого нужно понимать период возврата инвестиций и оценивать его через ROI.
Есть три основных показателя, которые формируют треугольник ответственности:
DevOps — отвечают за предоставление мощностей, соблюдение SLA и отслеживание динамики расходов
Бизнес-блок — за формирование CEI-оценки и требований к окупаемости продуктов
Разработка — за формулирование целей и определение необходимого количества ресурсов, тем самым определяя ROI
Инфраструктура должна способствовать достижению целей, а не препятствовать им. Все команды работают ради развития продукта компании. Помните об этом.
Этап 5. Автоматизация FinOps-процессов
Пятый этап — встроить FinOps в DevOps-цикл так, чтобы оно работало само.
Встроить тегирование в IaC. Теги должны выставляться автоматически через Terraform, а не вручную. При каждом деплое теги проверяются и применяются в соответствии с кодом в репозитории. Ручное тегирование — это путь к хаосу и ошибкам.
Оценить динамические окружения. Временные среды для feature-веток, pull request'ов, релизных кандидатов. Они создаются автоматически, живут только пока нужны, и автоматически удаляются после завершения задачи. Это экономит до 30% бюджета на dev/test-окружениях.
Интегрировать стоимость в CI/CD. Дашборды в Grafana, OpenCost для Kubernetes — данные о затратах должны быть видны в том же месте, где метрики производительности и надёжности.
Настроить алертинг на простаивающие ресурсы. Prometheus + AlertManager умеют отслеживать метрики утилизации CPU, памяти, количества запросов в базу. Если ресурс простаивает неделю — должен прийти алерт.
Настроить автоматическую отправку отчётов. Раз в две недели команды должны получать отчёт по своим затратам. Автоматически, без напоминаний.
Построить ETL-систему для аналитики.
В зрелых организациях это выглядит так:
Данные из облачных API, систем виртуализации, OpenCost собираются через Airflow
Складываются в единую базу (например, ClickHouse) в формате OBT
Отображаются в BI-системе (Apache Superset), доступной всем командам
Раз в две недели DAG в Airflow собирает аналитику и рассылает отчёты
Этап 6. Закрепление культуры
Шестой этап — превратить FinOps из проекта в часть корпоративной культуры.
Финально задокументировать всё. Правила распределения финансов, зоны ответственности команд, политику тегирования, процедуру апелляции. Всё должно быть записано, утверждено и доступно. Новые сотрудники должны знакомиться с этим при онбординге.
Интегрировать FinOps в OKR, KPI и грейдовую сетку. Если затраты на инфраструктуру не влияют на оценку работы команды, то FinOps — это просто очередная бюрократия. Метрики вроде Cost per User, Idle Resource Ratio, ROI должны стать частью оценки эффективности наравне с SLA и производительностью.
Внедрить культуру внутренних митапов. Команда FinOps делится способами оптимизации, инженеры рассказывают свои кейсы по сокращению расходов. Лучшие практики должны распространяться горизонтально, а не спускаться сверху.
Настроить процедуру апелляции. Иногда команды выходят за бюджет обоснованно. DevOps-инженер ночью поднял количество ресурсов из-за наплыва трафика и сохранил доступность площадки — он действовал в рамках своей ответственности по SLA. Применять к нему санкции бессмысленно. Процедура апелляции должна быть прозрачной и быстрой, иначе люди перестанут рисковать даже ради спасения сервиса.
На этом этапе мы сделали основные шаги по внедрению FinOps внутри компании. Однако, здесь необходимо вернуться Showback и Chargeback. Потому как FinOps – это культура, в разные моменты компании необходимы разные решения.
План внедрения: от showback к chargeback за год
Согласно FinOps Foundation, 78% зрелых организаций используют showback, а 42% — chargeback. Выбор зависит от зрелости команд, структуры компании и готовности финансового блока. Вот примерный план на 12 месяцев.
Месяц 1-2: Подготовка (Этапы 1-2)
Аудит расходов, настройка мониторинга, первые отчёты. Цель — показать, что проблема есть и она дорого стоит. Важно получить обратную связь: понятны ли отчёты, правильно ли распределены затраты, есть ли вопросы. На основе фидбека корректируем аллокацию и уточняем правила тегирования.
Месяц 3-5: Showback для всех команд (Этапы 3-4)
Повышаем осведомлённость команд о расходах, обучаем интерпретировать данные. Цель — довести покрытие showback до 90-95% и запустить первые инициативы по оптимизации. На этом этапе работает осознанность, а не принуждение.
Месяц 6-9: Пилотный chargeback (Этап 5)
Выбираем одну-две команды, которые понимают ценность FinOps, и начинаем выставлять им счета. Параллельно отвечаем на вопросы:
Как обрабатывать общие сервисы (CI/CD, мониторинг)?
Как реагировать на перерасход?
Как внедрить перерасход в финансовую модель?
На основе фидбека пилотных команд оптимизируем модель chargeback.
Месяц 10-12: Chargeback для всех продуктовых команд (Этап 6)
Переводим остальные команды волнами, по 2-3 в месяц. Так остаётся время на реакцию, ответы на вопросы и корректировку процессов. Внутренние команды можно оставить на showback — получится гибридная модель.
Для некоторых команд, например стартапов, Chargeback абсолютно не подходит, так как у них отсутствует техническая основа и устоявшиеся процессы. В тоже время для больших компаний возможно гораздо более быстрое внедрение Chargeback, чем мы описали выше, без долгого переходного этапа в виде Showback.
Зачастую хорошо себя показывает гибридный подход: часть команд, например продуктовые – на Chargeback, а внутренние – на Showback. Это позволяет создать мотивацию там, где она нужна больше всего, не перегружая процессы для небольших внутренних команд. Главное четко документировать, кто на какой модели и почему. Иначе будут вопросы: а почему мы платим, а они нет?
Заключение
Исследования показывают, что компании, успешно внедрившие FinOps, снижают облачные расходы на 20-30% за первый год, а через два года экономия доходит до 40%. Но это не про сокращение бюджета ради сокращения. Это про эффективность: платить только за то, что реально нужно, и привязывать каждый потраченный рубль к бизнес-результату.
FinOps — это ответ на вызовы эпохи, когда закон Мура замедлился, железо перестало дешеветь, а энергия стала основной статьёй расходов дата-центров. Эпоха бездумного масштабирования закончилась. Теперь нужно считать каждый сервер и оправдывать каждый киловатт.
История Sears — хороший пример того, что бывает с компаниями, которые не адаптируются к новым реалиям. В 1980-х это был крупнейший ритейлер в США с 2705 магазинами. Они не восприняли онлайн-торговлю всерьёз — культура компании была сосредоточена на физических магазинах и локальном маркетинге. Сегодня открыто пять магазинов. Если компания не меняет культуру под вызовы времени — она отстаёт от индустрии.
Начните с showback, чтобы команды научились видеть затраты. Переходите к chargeback, когда они будут готовы управлять ими самостоятельно. Главное — помнить, что FinOps — это не набор отчётов, а культура осознанного потребления ресурсов на всех уровнях организации. Культура, которая начинается тогда, когда инженер может уверенно сказать: «Я сам решу».
