Меня зовут Дмитрий Деев, я руководитель отдела IT-инфраструктуры в Ви.Tech - IT-дочке ВсеИнструменты.ру. В рамках нашего подкаста я поговорил с Ильей Кочневым, директором сопровождения информационных технологий в Lamoda Tech. Илья - более 20 лет в эксплуатации, начинал юникс-инженером, строил инфраструктуры в банках, нефтянке, e-commerce, открывал дата-центры в нескольких странах, мигрировал в облака, из облаков и между облаками.

Говорили про FinOps. Не про «культуру осознанного потребления» и не про «надо экономить», а про то, как это реально работает и когда вообще стоит этим заниматься.

«На эти деньги можно серверов вагон накупить»

Первое столкновение с темой у Ильи случилось еще когда слова «FinOps» в инфополе не существовало. Он пришел из мира корпоративного IT с собственными дата-центрами в компанию, где инфраструктура на 100% жила в облаке. Увидел счет и честно удивился:

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

Он пришел к CTO с этой идеей. Тот начал задавать вопросы. Компания работала на рынках Америки, Европы, Азии. «Ты умеешь дата-центр в Азии? В Европе? Где будешь в Америке - East Coast, West Coast? Хорошо, кто будет эксплуатировать по всему миру?»

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

А потом - финальный вопрос: «Давай представим, что завтра мы оптимизируем код сервиса и он начинает потреблять в два раза меньше ресурсов. Что с твоей экономикой случается?»

«Я понял, что эта экономика просто рушится до основания, как карточный домик. Жить в облаке и жить на железе - это прям совсем разные вещи, нельзя так в лоб считать.»

Это был зачаток FinOps - в форме расчета TCO. Просто тогда еще без названия.

Второй заход - уже без выбора

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

«Мы добираемся до статьи с расходами на облако, а там огромная сумма. "А за что мы платим?" Вот этот очень простой вопрос оказался ужасно сложным. Ужасно сложно оказалось на него дать ответ и объяснить, что эти расходы вообще дают для бизнеса.»

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

Что это вообще такое, если без определений

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

Есть и второй слой. С точки зрения бизнеса:

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

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

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

Есть у этого и личное измерение:

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

Всем ли это нужно и когда начинать

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

Стартап на стадии go-go - точно не время. Задача стартапа - быстро сделать продукт, быстро выпустить. FinOps здесь только отвлекает, а контролировать особенно нечего.

Когда продукт стабилизировался, инфраструктура растет, и облачные расходы всплывают на поверхность - вот тогда появляются рабочие вопросы: насколько затраты на услугу коррелируют с тем, что платит клиент? Почему инфраструктура растет быстрее бизнеса?

Плохой сценарий выглядит вот так:

«Прекрасный солнечный день, ничто не предвещало беды, но тут приходит финансовый директор и спрашивает, где деньги.»

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

Кто этим должен заниматься

В Lamoda нет ни одного выделенного FinOps-специалиста. Это распределенная роль: несколько руководителей, которым не все равно.

Стандартный состав рабочей группы: инженеры (только они знают, как устроена инфраструктура), финансы (только они знают про бюджеты и P&L), продукт и бизнес (только они понимают, насколько расходы соотносятся с ценностью). Если хотя бы одна из этих оптик выпадает - начинается перекос. Либо красивый отчет, которым никто не пользуется. Либо тупое давление «сделайте дешевле». Либо продукт, который растет, вообще не замечая стоимости инфраструктуры.

Почему сложно выделить людей специально - вот точная формулировка этой ловушки:

«Чтобы объяснить, какой бенефит принесут выделенные люди, тебе нужно начать заниматься FinOps и посчитать эту выгоду. Но чтобы посчитать выгоду, тебе нужен кто-то, кто за это сядет и сделает расчет.»

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

Как глубоко копать аллокацию

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

Нужен сервисный каталог. CMDB с привязкой сервисов к доменам и владельцам. Оцифрованная оргструктура. Культура тегирования. Infrastructure as Code и единые пайплайны - потому что ходить руками и тегировать все объекты вручную прикольно как разовая операция, но поддерживать это годами невозможно.

Рабочая рекомендация по глубине:

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

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

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

Черные ящики

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

«Такие ресурсы я называю черными ящиками. Единственное, что вы можете с ними сделать - посветить внутрь фонариком и посмотреть, что лежит там на самом деле.»

Для Kubernetes это относительно решаемо: есть KubeCost / OpenCost, который позволяет занырнуть вглубь и распределить затраты по кост-центрам. С observability, коммунальными базами и похожими историями - гораздо хуже. Готового инструментария почти нет, приходится делить расходы пропорционально утилизации CPU, RAM, I/O, хранилищу, числу запросов.

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

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

Оптимизация без давления

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

Прямое давление «срочно всё сократите» дает не экономию, а оборону. С пряниками тоже аккуратно: механику «сначала раздуть инфраструктуру, потом героически ее оптимизировать и получить бонус» несложно воспроизвести.

Рабочая модель - когда стоимость становится обычным инженерным параметром, таким же как latency или error rate. Когда есть автоскейлинг, наблюдаемость, нагрузочные тесты и привычка смотреть на непропорциональный рост потребления - разговор становится другим. Уже не «нас заставляют экономить», а «мы видим, что ресурсы растут быстрее полезной нагрузки, это осознанный выбор или нет».

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

Про лимиты

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

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

С чего начинать на практике

Без теории и слайдов старт обычно выглядит так:

Смотрим на самые дорогие статьи счета - конкретно, где лежат основные деньги.
Смотрим на динамику: что растет, с какой скоростью, как соотносится с сезонностью и бизнес-событиями.
Фиксируем минимальную рабочую аллокацию по cost centers - не идеальную, просто рабочую.
Вводим базовые теги хотя бы для новых ресурсов: owner, env, cost center. Усложнять - только если потом станет понятно, что реально нужно.

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

80/20 работает предсказуемо: большую часть эффекта дают относительно простые шаги. На отдельных кусках инфраструктуры так удавалось подрезать косты на 20-25 процентов - и это уже серьезные деньги, которые сами по себе объясняют, зачем все затевалось.

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

Про инструменты в России

На зарубежных рынках давно выросло семейство специализированных FinOps-инструментов под AWS, GCP, Azure. В российских облаках картина скромнее:

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

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

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

FinOps на практике: когда облачный счет перестает быть черным ящиком