Норм или стрём в FinOps

😁 — Согласен
🤓 — Я бы поспорил

@finops_ru

Поддержать канал бустом ☁️

Бабки! Бабки! Где бабки?!

Продакшн стабилен, метрики зеленые, архитектура не менялась, а финансовый отдел присылает очередное письмо с вопросом «Где деньги, Зин?». Знакомая картина? И самое обидное — ответить толком нечего, ведь каждый компонент по отдельности работает нормально, а вместе они почему-то дают +40% к счёту.

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

Добавим сюда вечный спор с DevOps про запас ресурсов с противопоставлением мнений: «нам надо 60% запаса для надёжности» vs «у вас утилизация CPU 40%, давайте экономить». Приправим требованием CFO дать прогноз на год для инфраструктуры, которая масштабируется динамически и получим одни и те же вопросы о том, кто должен принимать решения, где граница между инженерией и экономикой и можно ли вообще управлять этим системно?

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

👉Читайте новую статью на Хабр и делитесь, с чем вам ещё приходится жить в суровой реальности разбираться по ходу дела.

@finops_ru

🧬 Бесплатный FinOps-инструмент доступен на новом сайте!

Облачные расходы растут, аллокация по тегам не даёт полной картины, онпрем и облако считаются в разных системах, а прогноз по инфраструктуре требуется регулярно

ФинОпс Радар уже используют команды, но теперь у инструмента есть отдельный сайт.

Он подключается к облаку в режиме только для чтения через API, собирает данные по расходам и показывает конкретные точки перерасхода:

🟣 недогруженные или выключенные ВМ
🟣 «зомби»-ресурсы
🟣 неприсоединённые диски
🟣 забытые IP
🟣 аномалии в динамике затрат

Отчёт даёт целостный срез расходов и помогает оценить потенциал оптимизации без ручной сборки данных.

ФинОпс Радар полезен:

🟢FinOps, DevOps, SRE, кто анализирует рост счетов
🟢тимлидам и CTO, которым важна структура затрат

Если вы ещё не подключали ФинОпс Радар, зайдите на сайт и проведите диагностику своего облака. Инструмент бесплатный, подключение занимает несколько минут, первые результаты видны сразу после синхронизации.

👉 Перейти на сайт

Посмотреть инструкцию для быстрого подключения

@finops_ru

📣Всем привет! В декабре мы спрашивали у вас о первом знакомстве с ФинОпс Радар. Многие отметили, что вернутся к нему после праздников.

Вот уже и февраль наступил. Как быстро идет время…

Мы будем очень признательны, если вы уделите пару минут своего времени, и поможете нам сделать бесплатный finops инструмент лучше.

Опрос доступен по ссылкам:
🟢Для тех, кто подключил облако
🟣Для тех, кто не подключил облако

@finops_ru

🥹 Почему счета за облако растут, хотя все «и так на минималках»?

Если вы каждый месяц смотрите на счет за облако, выдергиваете волосы на ногах и не понимаете, почему там стабильно +30–40% к плану, вы не одни. Инфраструктура та же, релизов немного, метрики зеленые — а финдир уже бежит к вам по коридору, с вопросами про бюджеты и «кто за это отвечает».

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

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

@finops_ru

🤓Резервы на стадии Walk: где теряется экономия

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

На стадии Walk проблема возникает не в самом инструменте, а в качестве прогноза. Если фактическое потребление отклоняется от запланированного, часть обязательств остается недозагруженной, а ожидаемая экономия существует только в сравнительной модели.

@finops_ru

Итак вопрос 💫

📣 Открыты слоты на совместные статьи

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

Что уже писали:

🟢 Showback или chargeback: почему отчёты сами по себе не экономят ни рубля
🟢 Облако или свой ЦОД: что лучше в 2025 году

Есть желание и время подключиться 💫 пишите @finops_admin с пометкой «статья». Обсудим идею, детали и выйдем на Хабр с анонсом в канале 💫

За репост — отдельный плюс к карме 🥹

@finops_ru

💫 Кто в компании решает, какое облако покупать

По данным отчёта FinOps Foundation State of FinOps 2026, 78% команд FinOps напрямую подчиняются CTO или CIO.

Когда работа выстроена на уровне топ-менеджмента, влияние на технологические решения заметно выше:

🟢 выбор конкретных облачных сервисов, 53% против 12% при уровне только директора;
🟢 выбор облачного провайдера, 47% против 8%;
🟢 решение, размещать нагрузку в облаке или строить собственный ЦОД, 28% против 6%.

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

Источник: State of FinOps 2026

🥹 — берем в работу

🥹 — живем сегодняшним днем

@finops_ru

📣 Хотите оптимизировать свои облачные расходы без лишних затрат?

Приглашаем на вебинар 11.03 в 11:00, где мы дадим четкий план действий, как получить максимальную пользу от каждого рубля, потраченного на облако

Что вас ждёт:
🟣 Разбор причин роста облачных расходов
🟣 Эффективные стратегии для снижения затрат
🟣 Принятие решений на основе реальных данных

Вебинар для: специалистов в области финансовой оптимизации и облачных вычислений, технических и директоров по продукту, лидеров бизнеса и руководителей команд

🎁 Бонус для участников: Получите чек-лист, чтобы оценить зрелость вашей компании абсолютно бесплатно!

👉 Зарегистрироваться на вебинар: "здесь была ссылка"

Узнайте, как сделать каждый вложенный рубль в облако более эффективным!

@finops_ru

Почему не надо оптимизировать облако, пока не разобрался в счёте

Первый порыв, когда счёт за облако опять вырос сильнее, чем планировали, — взять и что-нибудь урезать. Лишь бы цифра стала поменьше.

Вот только потом может выясниться, что вы угробили целую неделю на компонент, который даёт только 2% от счёта, а 60% так и уходит непонятно куда.

Хотя чему тут удивляться?
➖ Теги проставлены кто во что горазд
➖ Shared-ресурсы жрут треть бюджета, но выставить за них счёт некому
➖ Про аномалии узнаёшь через три недели, когда по счёту уже заплатили.

А происходит так потому, что без нормальной картины расходов оптимизация — суть вредительство. Именно поэтому в FinOps всё начинается не с Optimize, а с Inform.

👉 В новом материале на Хабр разбираем, как эту фазу выстроить с нуля и какими инструментами пользоваться, если платить не хочется от слова совсем.

✅ Практики FinOps | Чат | Бот

💫Экономия от миграции в облако (Total Migration Cost Savings)

Экономия от миграции даёт простой и понятный ответ на главный вопрос любой трансформации: снижает ли облако итоговые расходы или перенос создаёт дополнительные издержки.

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

Как считается

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

Формула:

(Текущие инфраструктурные затраты – затраты на целевую облачную платформу) + (общие операционные затраты на инструменты и команду в текущей инфраструктуре – аналогичные затраты в целевой архитектуре).

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

Что учитываем в расчётах

🟢отчёты по потреблению и стоимости инфраструктуры в дата-центре или приватном облаке
🟢 калькуляторы стоимости публичных облаков
🟢 собственные оценки общих расходов на инструменты, поддержку и участие команды

Что даёт этот анализ

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

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

Источник: FinOps Foundation.
#считаем_finops

✅ Практики FinOps | Чат | Бот

Что же пишут эксперты комьюнити в чате об экономии от миграции в облако

🟢Вячеслав Бессонов (Hilbert Team)

Подход здравый и действительно часто используется для первичного обоснования экономической целесообразности миграции в облако. Он хорошо отвечает на вопрос "Становится ли инфраструктура дешевле?".
В нашей практике, однако, мы обычно используем фреймворк Forrester TEI (Total Economic Impact). Он позволяет оценивать не только сокращение затрат, но и совокупный экономический эффект от инвестиций в миграцию: влияние на выручку и маржинальность за счет ускорения time-to-market, снижения операционных рисков, повышения масштабируемости и использования managed-сервисов.
Такой подход позволяет обосновывать целесообразность миграции даже в случаях, когда прямые инфраструктурные затраты в облаке выше текущих, но сама миграция является драйвером для достижения стратегических целей Заказчика и роста финансовых показателей.

🟢Екатерина Чичкова (Flowwow)

Как говорится, гладко было на бумаге, да забыли про овраги 😃

Калькуляторы и внутренние оценки редко отражают фактические расходы после запуска. Помимо базовой стоимости инфраструктуры в зависимости от провайдера всплывают затраты на трафик, хранение данных, резервное копирование, техническую поддержку, отказоустойчивость и сопутствующие сервисы. В свою очередь сотрудники склонны недооценивать затраты на миграцию и дальнейшую поддержку новой среды. Я считаю что очень важно учитывать, что облако не является выгодным автоматически — без внедрения finops практик оно легко становится источником неожиданных затрат, черной дырой для денег 💸 и причиной выпадения последних волос у вашего CFO👨‍🦲
На мой взгляд решение о миграции это не вопрос одной формулы, а взвешенный комплексный подход, где важны не только расходы, но и цели, понимание рисков и реальных преимуществ облака: гибкости, масштабируемости, скорости изменений и устойчивости инфраструктуры.

🟢Ксения Кроха (зарубежный эксперт, компания NDA)

От себя бы добавила, что стоит особенно внимательно оценить следующие риски:
- так называемый "double-bubble" - период времени, когда поддерживаются обе инфраструктуры (и новая, и старая). Этот период может быть затянут, если слишком рано приступить к миграции, либо сотрудники не успели пройти необходимое обучение и т.д.
- К слову об обучении - не стоит недооценивать расходы на подготовку персонала к миграции. Надо учесть, что может появиться необходимость в дополнительных специалистах. А также сам процесс переподготовки существующих сотрудников нередко занимает больше времени, чем планировалось.
- Расходы на целевую архитектуру: значимо не только приблизиться к эквиваленту уже имеющейся архитектуры, только в облаке, но и здесь необходимо сразу подумать о рисках. На первых порах могут быть совершены ошибки в настройке сервисов, выборе не тех резерваций и т.д., что сопряжено с существенными расходами. То есть мы топорно не сравниваем 2 возможные архитектуры между собой, а понимаем, что на деле все будет иначе. После этого нужно стремиться не просто к эквиваленту, а к оптимальной новой инфраструктуре. Но это уже совсем другой разговор, и, конечно же, это не решить одной формулой.

А вы что думаете? Примененимо в наших реалиях? 💫

💫Как компания NielsenIQ сократила расходы на Kubernetes до 80% без риска для продакшен-среды

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

Что сделали
➖ При выборе решения исходили из того, что Kubernetes и провайдер остаются базой, архитектуру сервисов не меняют, а поведение production-среды должно оставаться предсказуемым
➖ Фокус сместили с прямого снижения стоимости на управление жизненным циклом нод
➖ Подбор типов и размеров ВМ вынесли в отдельный автоматизированный слой управления инфраструктурой, появился воспроизводимый паттерн кластеров
➖ В тестовых и разработческих средах начали использовать прерываемые виртуальные машины (spot / preemptible) без ручного контроля. Это снизило ручную нагрузку, стабилизировало поведение инфраструктуры и позволило учитывать влияние изменений на расходы до их внедрения.

Результат
Экономия составила 60–80% в тестовых средах и 40–50% в production. Инвестиции окупились примерно за два месяца.

Источник: кейс NielsenIQ

#кейсы_finops

✅ Практики FinOps | Чат | Бот