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

Вместе с Виталием Глушаковым мы решили разобрать, как это работает (или не работает, пусть будет сюрприз) на практике. Виталий имеет большой опыт управления и FinOps-трансформации отделов разработки и уже опубликовал свою часть на LinkedIn — «FinOps: 5 шагов к зрелости». Обязательно почитайте, там много интересного. А мы, со своей стороны, дополняем каждый тезис практическим контекстом, потому что между тем, как должно быть и как оно бывает на самом деле, иногда помещается целая пропасть.

Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram.

1. Почему урезание бюджетов и заморозка R&D не снижают расходы на инфраструктуру

Когда счета за облако и инфраструктуру начинают пухнуть, компании реагируют ровно так, как привыкли: ужесточают закупки, режут ФОТ, замораживают R&D, задумываются о замене внешних сервисов собственными. На бумаге всё логично. Но на практике это ведет к ряду неприятных последствий:

• жёсткий контроль закупок тормозит разработку;

• урезание зарплат провоцирует отток лучших людей;

• заморозка R&D убивает конкурентные преимущества;

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

Короче, лечим головную боль топором. Не надо так.

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

А все почему? Во-первых, потому что не хватает общей управленческой логики, которая связала бы архитектуру, ресурсы, стоимость и ответственность. Причём не потому, что инструментов нет (их-то как раз полно), а потому что нет воли или компетенции, чтобы это собрать воедино. 

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

2. Чем управление затратами отличается от простого урезания расходов

Тут, казалось бы, всё просто: компании хотят сократить расходы. И это логично. Кто ж не хочет? Вот только прямое урезание затрат не делает инфраструктуру эффективной, потому что стоимость не исчезает сама по себе, если просто давить на команды или ограничивать закупки.

По данным Harness, 52% инженерных руководителей признают, что разрыв между FinOps и разработкой напрямую приводит к перерасходу. А 55% разработчиков говорят, что решения о резервировании ресурсов принимаются, по сути, наугад. То есть больше половины команд, если уж совсем напрямик, тыкают пальцем в небо, когда выбирают, что зарезервировать.

Просто у них нет данных, чтобы решать иначе. Собственно, поэтому эффект от FinOps и не сводится к тому, чтобы на счету стало больше денег.

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

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

3. Почему децентрализация бюджетов не работает без культуры ответственности

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

Но (всегда есть какое-то «но») сама по себе передача бюджета еще ничего не даст. Чтобы все заработало, у каждого объекта инфраструктуры должен быть владелец. Если у ресурса нет владельца — за ним никто не следит. Без тегирования и аллокации невозможно даже понять, кто за что платит. А тегирование, между прочим, штука скучная. Настолько скучная, что её хочется пропустить. Но без неё всё остальное просто рассыпется.

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

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

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

Люди ведь тоже не дураки: им чисто психологически хочется видеть не только рамки, но и какой все это дает профит. 

4. Зачем нужен FinOps-специалист, если у него нет полномочий

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

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

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

По данным State of FinOps 2026, управление затратами на AI стало навыком номер один при найме FinOps-специалистов (58% респондентов). Эта роль, по сути, перестаёт быть отчётной и становится управленческой. Ну, разумеется, при условии, что компания готова дать этому человеку полномочия, а не просто должность.

5. С чего начать юнит-экономику в ИТ, если есть только дашборд

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

Юнитом, по сути, может быть что угодно: продукт, сервис, филиал, команда, конкретный человек, да вообще любая единица, по которой имеет смысл считать деньги. По данным State of FinOps 2026, юнит-экономика поднялась на пять позиций в списке приоритетов. И это правильно: без юнит-метрик принимать управленческие решения – как рулить с закрытыми глазами. Можно, конечно. Но только до первого оврага.

А вот когда модель выстроена, тогда уже можно осмысленно распределять затраты. Не на уровне «кто больше потратил» (это вообще ни о чём), а на уровне экономики конкретного юнита. Сколько стоит этот продукт? Окупается ли он? Стоит ли туда вкладываться дальше? Без модели эти вопросы просто некому задать. Вернее задать их вам никто не запретит, просто ответа не получите.

6. Как распределять затраты на shared-сервисы между командами

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

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

• Хостим сами. Команда поднимает инструмент на собственном железе и сама за него отвечает. С CI/CD-раннерами или мониторингом так делают постоянно. Удобно? Да. Но попробуйте так же поступить с дата-платформой и быстро поймёте, что не всё масштабируется таким способом.

• Внутренний продукт-сервис. Это когда shared-ресурс превращается во внутренний продукт с биллингом по запросам или пропускной способности. Разворачивать свой Clickhouse в каждой команде — решение так себе. Проще сделать его общим продуктом, который тарифицирует потребление. Деньги перетекают между подразделениями внутри компании, зато все видят, сколько стоит их кусок пирога. Тут главное не перемудрить: если сам биллинг обходится дороже, чем экономия от него, то зачем он вообще нужен?

• Квотирование. Самый простой вариант. Зарезервировали 100 мбит из гигабитного канала — и платите за них, укладывайтесь как хотите. Вышли за пределы — эскалация. Не идеально, но как первый шаг работает.

Но вот что важно, и тут, пожалуйста, не пропускайте: даже на зрелой стадии системам нельзя давать право автоматически резать инфраструктуру. Максимум — сформировать тикет и предложить действие. Потому что алгоритмы не учитывают весь контекст. Нельзя просто взять и ограничить канал, надеясь, что ничего не сломается. Сломается.

Ограничения нормально работают только через уведомления, внутренние бюджеты и эскалацию, но не через грубое техническое отключение. А то в один прекрасный момент автоматика отрежет что-нибудь важное, и экономия в 50 тысяч обернётся потерей на порядки больше. Ваш покорный слуга видел такое далеко не один раз. Вот вам крест. Хотя выстроить нормальный showback и chargeback – задача вполне посильная практически каждому.

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

Снизить расходы на инфраструктуру хотят все, тут и обсуждать нечего. Но когда начинают резать — режут не всегда то, что нужно. Почти половина ИТ-руководителей (данные VMware за 2025 год) считают, что более четверти облачных расходов их компании уходит впустую. Цифра, конечно, впечатляет. Вот только не всё, что стоит дорого, можно безболезненно урезать.

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

Поэтому начинать лучше не с самых дорогих позиций, а с сочетания двух параметров: объём затрат и критичность сервиса:

• Сервис некритичен — на нём безопаснее тестировать изменения. Пробуем, смотрим. Если ничего не сломалось, отлично, идём дальше.

• Сервис критичен — значит, ведем себя аккуратнее.

Потому что одно дело сэкономить 200 тысяч в месяц на райтсайзинге, а другое — уронить продакшен на час и потерять два миллиона. Надо ли объяснять, что второе перечёркивает первое?

8. Как выбор технологий влияет на стоимость владения инфраструктурой

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

Spotify, Zalando, Adyen и другие крупные компании давно используют TechRadar именно как инструмент, чтобы такого не допускать. Штука нехитрая, но полезная. Благодаря ей все технологии в компании раскидываются по четырём кольцам, и сразу видно, что можно брать в прод, а от чего лучше держаться подальше:

• Adopt — уверенно используем, экспертиза есть, можно ставить в прод без опасений.

• Trial — пробуем, выглядит перспективно, но пока ограничиваем одной командой или проектом.

• Assess — изучаем, потенциал есть, но знаний мало, нужен пилот.

• Hold — не используем для новых проектов, в перспективе выводим.

По сути, это способ не дать командам наступить на грабли, которые кто-то уже нашёл.

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

Короче, экономия без экспертизы — это не экономия, а… Ой, у нас же нельзя материться.

9. Как оценить, что выгоднее: купить готовое или пилить своё

Когда счета за облако и SaaS растут, неизменно возникает соблазн: а не заменить ли всё это своими решениями? Нет, идея в целом понятная: зачем платить внешнему провайдеру, если можно инвестировать в себя?

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

Именно поэтому, по данным IDC, к 2027 году крупнейшие компании столкнутся с недооценкой затрат на AI-инфраструктуру на 30%. Вы только вдумайтесь: почти треть трат будет не учтено. А все потому, что никто не захотел в нормальный анализ.

Хотя, справедливости ради, тут речь уже не просто про «купить или пилить своё». Тут надо понимать, куда вообще двигаться с инфраструктурой. Какой ресурс нужен? Какие задачи он закрывает? Где его лучше разместить? Что резервировать, а что нет? Может, именно в вашем случае оптимальным решением будет своё железо, а может быть ЦОД, или облако, или какой-то конкретный провайдер, а может вообще всё вместе. Зависит от ситуации.

И вот тут нельзя смотреть только на прайс. Технологии, ограничения, накопленные данные, то, как сервис будет эксплуатироваться — всё это бьёт по итоговой цифре не меньше, чем сам тариф провайдера. Поэтому сводить выбор к «онпрем дешевле» или «облако удобнее», скорее всего, не стоит. Без полной картины любая из этих позиций может оказаться убыточной. 

10. Какие косвенные затраты забывают учесть при расчёте ROI инфраструктуры

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

• До запуска — чтобы понять, есть ли вообще смысл.

• Перед разработкой — чтобы свериться с реальностью.

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

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

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

Около 21% нагрузок, по некоторым оценкам, уже прошли через обратную миграцию из облака. И что, все сэкономили? Да нет, конечно. Скорее наоборот. Сэкономили на серверах — потратили вдвое больше на людей, которые всё это переделывали. И в итоге вышло дороже, чем если бы вообще ничего не трогали. Вот вам и экономия. Мы, кстати, разбирали подробно, почему счета растут, даже когда инфраструктура вроде бы не меняется.

11. Как прогнозировать стоимость инфраструктурных решений на годы вперёд

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

Не «потратили X в прошлом квартале», а «если выберем архитектуру Y, через два года это будет стоить Z». Чувствуете разницу? Это уже не про биллинг. Это про то, как принимать архитектурные и инвестиционные решения на основе цифр, а не на глазок.

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

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

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

12. Есть ли универсальный подход к FinOps и с чего начать

После всего сказанного может показаться, что есть какой-то единственно правильный путь. Но вот вам спойлер: его нет. Компании решают задачи эффективности затрат кто во что горазд. Одни берут готовые инструменты. Другие пишут свои скрипты. Третьи строят аналитику прямо из биллинга. И это нормально — было бы странно, если бы все делали одинаково.

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

Одна компания начинает с тегирования ресурсов и дашборда в Grafana. Другая сразу внедряет chargeback на уровне бизнес-юнитов. Третья полгода бьётся с тем, чтобы просто получить нормальный доступ к биллингу. И это, между прочим, тоже результат. Все три на разных уровнях зрелости. И это ок.

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

Не потому что методология волшебная. А потому что она даёт рамку. Структурирует процесс. Конкретные решения под свою инфраструктуру всё равно придётся подбирать самим. Но хотя бы не с чистого листа. И не наступая на те же грабли, на которые уже наступили другие.