FinOps на практике. Серия 1: С чего реально начинается реальная экономия на облаке

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

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

Кстати, все это мы в свое время обсуждали (да и сейчас продолжаем) в канале Практики FinOps в Telegram. Там сидят те, кто проходил этот путь раньше, — иногда один вопрос в чате экономит неделю собственных экспериментов. Залетайте, если тоже на старте.

Почему FinOps не запустить в одиночку

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

А завязка у него типовая. В какой-то момент облачный счет раздулся настолько, что им внезапно заинтересовались наверху. И прилетела задача — даже не «запустить FinOps» как таковой, а сделать так, чтобы расходы на ИТ наконец-то стали управляемыми. FinOps — это уже название метода, до которого еще предстоит дойти; на старте есть только желание начальства взять косты под контроль и я, на которого это желание свалилось. Кто я в этой истории — тот самый человек, которому поручили разобраться, и который по ходу дела превращается в FinOps-специалиста. Дедлайн, ясное дело, вчера. Бюджет — как получится, но желательно нулевой.

Но где наша не пропадала. Поэтому первым делом я сделал ровно то, что в такой ситуации делает любой нормальный человек. Пошел читать. Что читать? Да все подряд: статьи, документацию FinOps Foundation, чужие кейсы, доклады с конференций. Туда же пошли и нейросети: я гонял ChatGPT и прочие модели как личных репетиторов — просил разжевать незнакомые термины, накидать список вопросов к финансам, объяснить на пальцах, чем одна стадия зрелости отличается от другой. Читал и расспрашивал все, что надо и не надо. Но таким макаром за пару недель довольно неплохо погрузился: вызубрил стадии зрелости — Crawl, Walk, Run, — разобрался, чем showback отличается от chargeback, а аллокация от нормализации.

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

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

И вот тут я сделал, пожалуй, единственную умную вещь за всю ту неделю. Не побежал выбирать платформу, не стал клепать дашборды на коленке и вообще не полез в инфраструктуру. Я просто пошел к финдиру с одним-единственным запросом: чтобы вся эта затея вообще взлетела, мне нужен живой человек со стороны финансов. Аналитик, экономист, неважно, — просто тот, кто сядет по мою сторону баррикад и поможет перевести инженерные косты на язык, который понимает бизнес.

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

Почему FinOps начинается не с софта

Тут полезен взгляд сверху. Хорошо ложится мысль из интервью Дмитрия Деева на Хабре (он руководит IT-инфраструктурой в Ви.Tech): FinOps стартует не с закупки инструмента, а с базовой гигиены планирования и с честного ответа на простейший вопрос — за что мы вообще платим. Вопрос вроде бы элементарный, а на практике именно об него все и спотыкаются. Пока ИТ-расходы не привязаны к продуктовым метрикам, защищать бюджет перед бизнесом нечем, кроме невнятного, что так, мол, надо по архитектуре. А это, прямо скажем, аргумент так себе.

Роли в FinOps: кто за что отвечает на старте

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

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

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

Владелец инфраструктуры — это ваш CTO, CIO или тимлид. На старте от него требуется две вещи. Первая — не кивать как болванчик на спущенную сверху команду экономить, а задать встречные вопросы. Типа экономить — это вообще относительно чего? Какой у нас бюджет? Что в итоге считается успехом, а что провалом? Вторая вещь — собрать все по технике: какие провайдеры, какой стек, какие инстансы крутятся и зачем, где у нас аккуратный managed, а где самосбор на честном слове. Потому что без этого мы даже масштаба бедствия не представляем — а значит, и исправлять что-либо пока не можем.

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

FinOps-специалист — это, собственно, я. И на старте я даже не столько считаю, сколько перевожу с одного языка на другой. Моя работа — свести процесс воедино, выровнять вокабуляр (про него чуть ниже, там вообще отдельная песня) и наладить нормальное общение между двумя командами, которые до этого пересекались хорошо если на новогоднем корпоративе. Звучит, может быть, несолидно: координатор, переводчик, мальчик на побегушках между финансами и инженерами. Но без этого никак. Данные-то есть у обеих сторон. Но что с них толку, если нет понимания друг друга?

Вопросы финансовому директору и CTO на старте FinOps

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

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

Что спросить у финансового директора

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

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

Что спросить у финансового директора

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

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

• Какова точная сумма затрат на инфраструктуру за последние три года — помесячно, а не общим котлом?

• Какова динамика: растут, падают, скачут? И с чем по времени совпадают скачки?

• Как расходы распределяются по подразделениям — хотя бы примерно, на уровне управленческого учета?

• Какие типы затрат вообще попадают в строку ИТ: только облако или еще железо, лицензии, поддержка?

• Что из этого OPEX, а что CAPEX на амортизации?

• Какую часть бюджета руководство считает нормальной, а какую — уже раздутой?

• Бизнесу сейчас нужно резать косты или нужна предсказуемость? Это, между прочим, совсем разные задачи.

• Идет ли речь о сокращении команд или об оптимизации технологий? Спросить лучше прямо, чем потом узнать случайно.

• Кто в компании отвечает за итоговый бюджет и его защиту?

• В какой детализации руководство хочет видеть отчет: по юрлицам, по продуктам, по командам?

• Как часто нужна отчетность — квартал, месяц, неделя?

• Есть ли уже метрики, по которым бизнес оценивает эффективность ИТ?

• И самый неудобный: готов ли бизнес выделить ресурс — тот самый человеко-час экономиста и небольшой бюджет — на сам FinOps? И как этот бюджет потом защищать?

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

А чтобы посчитать выгоду, нужен тот, кто сядет и посчитает, — то есть те самые выделенные люди, которых тебе еще не дали. Круг замкнулся, приехали. Размыкается он, по моему опыту, ровно одним способом: кто-то берет и считает первую прикидку поверх своей основной работы, на чистом энтузиазме и по вечерам, выкатывает первую находку — и вот уже под нее выбивает и людей, и бюджет. По-другому почти не бывает, как ни крути.

Что спросить у инфраструктурщиков

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

Архитектура и стек:

• Какие провайдеры используются и почему именно они?

• Что крутится в публичке, что в приватке, что на своем железе?

• Какой стек: оркестрация, базы, хранилища, сеть?

• Где managed-сервисы, а где все поднято и обслуживается руками?

• Какие типы и размеры инстансов в ходу? Их вообще кто-то выбирал осознанно или брали с запасом?

• Есть ли тегирование? И если есть — насколько ему можно верить?

Где обычно зарыт жир:

• Где, по ощущениям, мы переплачиваем прямо сейчас?

• Есть ли ресурсы, про которые уже никто не помнит, зачем они?

• Сколько у нас dev- и staging-окружений и работают ли они по ночам?

• Когда последний раз кто-то удалял неиспользуемые диски, снапшоты, балансировщики?

• Есть ли сервисы, которые страшно трогать, потому что исторически так сложилось?

• Какой у нас примерно CPU utilization в проде? Если внятного ответа нет — это уже находка.

Процессы и история болезни:

• Кто и как сейчас решает, что пора поднять новый ресурс?

• Есть ли лимиты, квоты, хоть какие-то guardrails?

• Как инженеры узнают, во что обходится их инфраструктура? Чаще всего ответ — да никак.

• Был ли уже опыт общения с финансами по поводу расходов? И чем, любопытно, закончился?

• Что мешало навести порядок раньше?

• Есть ли в командах люди, которым в принципе не все равно на косты?

• Готовы ли команды к тому, что им начнут показывать их собственные расходы?

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

OPEX и CAPEX: почему цифры финансов и инженеров не сходятся

Ну, допустим, оба опросника отстрелялись и данные с двух сторон у нас на руках. Казалось бы, садись да считай, чего тут сложного. А вот тут-то и вылезает та самая боль, которую я обещал, — и на которой спотыкаются вообще все без исключения. Свел я данные в одну табличку — и обомлел. Финансы видят расходов на ИТ где-то на 10 миллионов рублей. А инженеры в своих консолях наблюдают всего шесть. Те же самые расходы. Тот же самый период. Разница — четыре миллиона. Куда, спрашивается, делись эти четыре миллиона?

А никуда не делись. Просто все смотрят на разные вещи, а называют это одним и тем же словом.

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

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

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

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

• Фиксируем, что финансы считают так, а инженеры эдак;

• Договариваемся о единой модели затрат, где разом видно и OPEX, и CAPEX, и амортизацию;

• Определяем, чего вообще хотим в итоге, — не абстрактно сэкономить, а, например, сделать счет предсказуемым и привязать его к продуктовым метрикам;

• Назначаем следующий шаг.

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

Взгляд практика

Раз уж речь зашла про то, что за цифрами надо видеть бизнес, — вот показательная история. Евгений Седегов в своем разборе на LinkedIn рассказывает, чем заканчивается линейный рез бюджета: финансы честно срезали 20% со всех статей сразу — и в магазинах встали кассы, отвалился интернет, а на приемке сдох единственный комп. Цель по бюджету выполнили, а выручки потеряли кратно больше, чем сэкономили. Вывод у него простой и злой: бюджет нельзя резать процентом, его надо разбирать как карту последствий — какая строка просто стоит денег, а какая держит кассу, склад и связь. И самая опасная строка частенько выглядит самой незаметной — пока не выяснится, что именно на ней висит половина продаж.

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

Итоги: что дает точка ноль перед запуском пилота

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

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

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

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