У компаний, которые работают в облаке, каждый новый месяц начинается с сюрприза. Его преподносят счета, которые почему-то всегда оказываются процентов на 30-40 больше прогноза. И тут начинается. Финдир смотрит на тимлида. Тимлид — на команду. Команда — в логи. А в логах — тишина. Ничего же не меняли. Или меняли?
В прошлой статье мы собрали типовые сцены из жизни. Помните наших героев?
SRE, который не мог объяснить, почему счет вырос.
Head of Infrastructure, которому велели посчитать онпрем в деньгах.
Тимлида, не знающего, сколько стоит конкретный сервис.
Архитектора, запутавшегося в гибриде.
DevOps, который боится резать запас.
Руководителя без прогноза.
Разные отрасли, разные масштабы, разные технологии. А вопросы одни и те же.
Почему? Не потому что кто-то глуп или неквалифицирован. Просто системы не было, как и не было задачи – а вернее потребности – ее создавать.
Отсюда и ��роблемы. По данным Flexera, половина предприятий не может правильно оценить затраты на облачные услуги. Треть вообще не понимает, как ими управлять. А 83% — это больше четырех из пяти — не могут оптимизировать.
Gartner прогнозирует, что мировые расходы на публичные облака к 2027 году превысят триллион. Причем быстрее всего растет именно инфраструктура — IaaS. Примерно на 30% в год.
То есть проблема есть не только у вас. И она не уменьшается, а растет. А значит, надо разбираться.
FinOps — это управление затратами на облака
Если отбросить маркетинг, это самое честное определение. Именно так его чаще всего понимают инженеры на старте.
Только вот тут начинаются нюансы.
Многие думают, что FinOps — это только про публичные облака. Поэтому неудивительно, что даже на Reddit люди спорят, применим ли FinOps к онпрем-инфраструктуре, гибридам и Kubernetes на своем железе?
Применим.
Компании вроде Heineken и Priceline давно используют FinOps для частных облаков, SaaS-подписок, лицензирования и даже дата-центров. Благодаря ему Priceline централизовала данные о затратах на SaaS, распределила по отделам, получила прозрачность для решений о закупках.
Потому что FinOps — это не про платформу. Это именно про то, как вы управляете своими технологическими затратами. А уж какими они будут – не суть важно.
Еще одно заблуждение: FinOps — это просто сокращение расходов. Типа пришли, порезали все подряд, получили экономию.
Нет.
Сокращение ради сокращения, без учета бизнес-ценности, отказоустойчивости и производительности — это просто плохая практика. FinOps — это когда каждая копейка, потраченная на облако, используется максимально эффективно в привязке к бизнес-ценности.
Правильная и сложная формулировка - это методология управления технологическими инвестициями, которая связывает ИТ-затраты с бизнес-результатами и помогает принимать управленческие решения на основе данных
Потому что без этого никак. Бизнесу нужна предсказуемость. Руководителям важно не только видеть итоговый счет, но и понимать, как он соотносится с результатами: сколько стоит привлечение клиента, выполнение запроса, работа сервиса и т.п.
Да, по мере усложнения инфраструктуры и ухода в гибрид добиваться этого становится все труднее. Но это лишь означает, что просто старый подход перестал работать.
Так что же работает?
>>> Наш канал, чтобы ничего не пропустить <<<
Почему FinOps — это не один инструмент и не один проект
Несмотря на что FinOps действительно эффективнее работает, когда у вас есть какие-то инструменты, этим все не ограничивается. Не будет такого, что вы просто оплатили платформу, внедрили и деньги стали экономиться сами собой. Или настроили дашборд для CFO, и все счастливы. Или запустили скрипт оптимизации раз в квартал.
Так это не работает.
FinOps — это процесс. Непрерывный и, что самое главное, поэтапный. Поэтапный – потому что каждая стадия закрывает свой класс задач. А непрерывный – потому что инфраструктура постоянно растет, меняется и усложняе��ся. Прямо как темные искусства в определении Северуса Снейпа.
Нельзя просто включить FinOps и успокоиться. Остановишься – и через какое-то время обязательно откатишься назад.
Стадии зрелости FinOps
Все эти истории из первой статьи кажутся разными. Их, в общем, и рассказывали разные люди, работающие на разных должностях. Но если приглядеться, то становится видно, что они имеют единую структуру:
SRE не может объяснить рост — это проблема видимости.
Тимлид не знает стоимость сервиса — это проблема распределения затрат.
DevOps боится резать запас — это проблема оптимизации без ущерба.
Архитектор запутался в гибриде — это проблема сравнения альтернатив.
И решаются они не разово. Ниже мы разложим эти этапы по порядку.
Главное – сразу зафиксировать: это не строгая модель и не линейный путь от хаоса к совершенству. Стадии могут пересекаться, компании могут откатываться назад, а иногда и вовсе жить на двух уровнях сразу. Кто-то застревает на первом этапе годами, кто-то проскакивает второй за месяц и упирается в третий. Но структура в целом работает. Мы проверили.
Этап 1. Видимость и понимание
На этом этапе мы должны понять, что вообще происходит с затратами.
Помните нашего SRE, который убеждал финотдел, что они ничего не меняли, а счета все равно выросли? Или руководителя инфраструктуры, которого просили дать прогноз, а он не понимал, на основании чего его делать?
Обе истории про одно и то же — про отсутствие видимости. В первом случае непонятно, почему счет вырос. Во втором — на основании чего делать прогноз. Хотя корень, в общем, один: данные есть, а понимания нет.
На первом этапе задачи, которые нам предстоит решить, предельно приземленные.
Аллокация расходов — понять, кто сколько жрет. Расставили теги на ресурсах (Environment: prod/test, Team: backend/frontend, Service: auth/payments), и уже видно, чей тестовый кластер сжигает половину бюджета или чья команда забыла выключить dev-окружение на выходные.
Контроль аномалий — понять саму структуру расходов: что уходит на compute, что на storage, что на трафик, что на managed-сервисы. И главное — как это меняется во времени. Потому что скачок на 30% в один месяц может быть нормой, а может быть и утечкой.
Сбор данных — подключить все источники (AWS, VK Cloud, Yandex, on-prem), привести к общему виду и сохранить историю хотя бы за год. Потому что без истории не поймешь, что нормально, а что нет.
Отчетность — настроить дашборды под каждого, библейски выражаясь, по делам их. Инженерам — их сервисы с drill-down до подов. Финансам — бюджеты с алертами. Бизнесу — продукты и ROI.
По сути, ничего сверхъестественного. Достаточно просто перестать объяснять скачки магией вне Хогвартса и признать, что фраза "ну, был пик" — это не объяснение. Как следствие, исчезнет и неопределенность. Это, конечно, еще не финансовая осознанность, но уже и не полный хаос.
Теперь SRE может не просто мямлить перед финансами про сработку автоскейлинга, а показать им реальные цифры: команда backend подняла 15 новых инстансов под новый релиз, команда data science забыла выключить тестовый кластер на выходные. А руководитель инфраструктуры – дать прогноз на основе ретроспективных данных: летом нагрузка растет на 25%, осенью падает на 10%, миграция на новый регион в Q2 добавит еще 30%
Правда, большинство компаний застревают уже на первом этапе. Они получают видимость и останавливаются. Потом радуются пару месяцев, а потом снова получают хаос. Почему? Да потому что видеть проблему и решить ее — не одно и то же.
Этап 2. Распределение и ответственность
Видимость появилась. Дашборды настроены. Отчеты летят. И тут выясняется: видеть — это одно, а делать что-то с этим — совсем другое.
Помните тимлида, к которому ходил бизнес-аналитик и спрашивал, закрывать сервис или нет, и DevOps, который не хотел быть крайним, если продакшен упадет? Так вот объединяющая их проблема – это отсутствие понимания, кто за что отвечает.
Сначала механика:
Выключаем Idle-инстансы (или ставим auto-scaling с разумными лимитами). Пересматриваем права доступа (те же разработчики не должны иметь права админов на прод-кластере).
Ротируем ресурсы (тестовые окружения на ночь переводим в спящий режим, а dev-окружения переводим на работу по расписанию).
Переносим бэкапы на дешевые диски (ни в коем случае не на NVMe).
Но механика — только полдела. Главное — выстроить процессы таким образом, чтобы ничего не откатывалось назад. Поэтому нужно нормально разложить, кто за что отвечает.
Во‑первых, распределяем ответственность между конкретными людьми. За теги отвечают владельцы сервисов: бэкендеры берут теги "Service: auth", "Service: billing", фронтендеры — "Service: checkout", "Service: frontend", data-инженеры — свои пайплайны и хранилища. В общем, принцип прост: если у сервиса есть бюджет и дашборд — у него должен быть и владелец, который этот дашборд хотя бы иногда (а желательно как минимум раз в спринт) открывает.
Во‑вторых, работа с алертами. Просто настроить уведомления на почту будет мало, потому что там они и умрут. Нам нужны понятные правила: при росте затрат по сервису на 20% команда в течение, скажем, 24–48 часов должна дать объяснение: что случилось, норма это или нет, нужно ли что‑то менять. Если это запланированный релиз или маркетинговая акция — окей, фиксируем как ожидаемое. Если нет — ищем утечки и чиним.
В‑третьих, бюджеты и формат взаимодействия с финансами. Кто‑то начинает с showback: просто показываем командам их реальные расходы, без жестких лимитов, чтобы люди привыкли к цифрам. Дальше можно переходить к chargeback, когда бюджеты уже не виртуальные, а вполне себе реальные, и перерасход бьет по планам команды. Главное здесь — не превратить это в штрафную историю, а связать затраты с ценностью. Нам важнее не просто начать "жрать меньше", а понимать, сколько в реальности стоит пользователь, заказ, запрос.
Хотя тут вас почти наверняка ждет парадокс: когда команды начинают видеть реальную стоимость, счета могут начать расти. Не падать, а расти. Дело в том, что люди начинают считать то, что раньше не считали. Только через месяц-два, когда команды разберутся со своими бюджетами, начнется реальная оптимизация. Но многие компании пугаются роста и откатываются.
А зря, потому что именно после этого периода адаптации начинается настоящая работа. Тимлид получает возможность дать бизнесу точную цифру по сервису на основе реальной аллокации затрат. А DevOps – показать финансам расчет с обоснованием каждой строки: базовая нагрузка, пики, запас на деплои и инциденты.
Этап 3. Оптимизация без ущерба бизнесу
Видимость есть. Ответственность распределена. Команды знают свои бюджеты. И тут начинается самое чувствительное — сэкономить так, чтобы ничего не сломать.
Помните DevOps, который держал запас ресурсов? Или Head of Infrastructure, которому велели посчитать онпрем в деньгах и сравнить с облаком?
Обе истории про поиск разницы между надежностью и избыточностью, которую никак не могли найти. Важно лишь понять, что на этом этапе простых решений уже не будет.
Резать запас, но не перерезать. Запас нужен для пиков нагрузки, для сбоев нод, для деплоев без даунтайма. Вопрос не в том, нужен ли запас, а в том, сколько именно. 10%? 20%? 40%? Чтобы ответить на этот вопрос, нужна фактура: история пиков, частота инцидентов, время восстановления. Найдете фактуру – сможете принять правильное решение. А без этого будете просто резать наугад.
Сравнивать несравнимое. Публичное облако, приватное, гибрид — разные модели затрат. В облаке платишь за час, в онпреме заплатил один раз. Как их сравнить? Через TCO с учетом амортизации, электричества, зарплат инженеров на поддержку, стоимости простоя, разумеется. Только тогда можно честно сравнить варианты. Тогда и выберете, что для вас важнее: стабильность и прогнозируемость или дешевизна.
Выбирать между альтернативами с разными рисками. Managed-сервис дороже на 50%, но не требует инженеров на поддержку. Spot instances дешевле на 70%, но могут выключиться в любой момент. Reserved instances дают скидку 40%, но привязывают на год. Что выбрать — зависит от конкретной ситуации, масштаба и того, что для бизнеса критичнее: предсказуемость или экономия.
Когда это работает, DevOps сможет показать финансам вполне конкретный расчет, а не просто ссылаться на необходимость иметь запас. А Head of Infrastructure – сравнить онпрем и облако через единую модель с учетом всех факторов, а не по ощущениям.
На этом этапе оптимизация перестает быть разовой акцией. Решения принимаются на основе реальных, и инфраструктура начнет способствовать реализации бизнес-целей, а не мешать их достижению.
Этап 4. Инвестиционное управление
На этом этапе предстоит выяснить, куда действительно нужно вкладывать, а куда — нет.
«Мы переехали в гибрид ради экономии. Но стало только сложнее», — говорил наш архитектор из первой статьи, потому что жить пришлось сразу с тремя системами учета вместо одной.
Задачи, которые стоят перед нами на этом этапе:
Сравнивать сценарии оставить/перенести/закрыть.
Оценивать эффективность инфраструктурных решений.
Работать с CAPEX и OPEX в единой логике.
Когда это выстраивается, архитектор может дать бизнесу честное сравнение гибрида, а инфраструктура становится частью инвестиционной модели. И вот с этого момента бизнес реально начинает понимать реальную цену и ценность технологий.
На этом уровне FinOps уже трудно откатить.
FinOps — это цикл, а не лестница
Ну вот, все четыре этапа прошли – и что дальше? А дальше все заново.
Помните, мы говорили, что FinOps — это не цель, а процесс? Так оно и есть. Поэтому “видимость – распределение – оптимизация – решения” теперь с вами навсегда. Появилось что-то новое – сервисы, команды, архитектуры, провайдеры — и цикл запускается снова. Да, на другом уровне, да, с другими инструментами, с опытом и знаниями, но базовые задачи-то все равно остаются теми же.
С чего начать на практике
Сначала все предельно легко. Мы просто задаем себе вопросы. Почему чек растет? Сколько стоит этот сервис? Что будет, если удвоим нагрузку?
Потом смотрим, куда уходит больше всего денег. Выявляем самые большие суммы, самые частые инциденты. Подойдут даже эмоции финансистов. Уж если у них от чего-то бомбит, возможно, стоит обратить на это внимание.
Дальше — выбираем, с чего начать. То есть мы не пытаемся сделать FinOps везде и сразу. Мы просто берем один конкретный класс задач и решаем его нормально.
Например, видимость затрат. Настраиваем теги, собираем данные по всем облакам, делаем дашборды. Доводим до конца, чтобы каждый мог открыть и увидеть, кто сколько тратит.
Или распределение ответственности. Назначаем владельцев сервисов, настраиваем алерты, вводим showback. Делаем так, чтобы у каждого был свой бюджет с именем и фамилией.
Или считаем стоимость продукта. Разбираемся, сколько реально стоит поддержка конкретного сервиса с учетом всей инфраструктуры.
Главное: одна задача – один результат. До талого.
И одновременно с этим начинаем строить процесс. Регулярные встречи ИТ, финансов и бизнеса. Общие определения, чтобы все говорили на одном языке. Общие источники данных, чтобы все смотрели на одни цифры.
Но есть вещи, которые ломают FinOps чаще всего:
FinOps не работает без инженеров. Нельзя строить финансовую модель инфраструктуры, не меняя архитектуру и практики разработки. "Оптимизируйте нам тут, но ничего не трогайте" — так не получится.
FinOps не взлетает без бизнеса. Если для бизнеса это просто очередная ИТ-инициатива — ее легко обойдут при первом конфликте интересов. Результаты должны быть в терминах бизнеса: не "сэкономили 10% на инстансах", а "увеличили маржу продукта на 5%".
FinOps ломается, если его делают ради экономии. Экономия — побочный эффект, а не цель. Как только цель становится единственной, начинается резня в ущерб качеству и надежности. Потом инциденты, откаты — и доверие к FinOps рушится.
FinOps начинается с вопросов, а не с инструментов. Купить платформу и думать, что она все решит — классическая ошибка. Сначала договариваемся: на какие вопросы хотим ответы, что будем с ними делать, кто за что отвечает. А уже потом смотрим, какие инструменты помогут.
Вебинар по FinOps
Теория понятна. А как запустить это завтра, не нанимая консультантов и не покупая enterprise-платформу за космические деньги?
На вебинаре разберем:
Как запустить FinOps без бюджета на платформы и консультантов
Где компании чаще всего ошибаются (и как не повторить их путь)
Как пройти все этапы на практике, а не в теории
Покажем инструмент Радар, который позволяет начать прямо сейчас.
>>> Сcылка на вебинар <<<
*Не забудьте зарегистрироваться и сразу добавить мероприятие в календарь
