🟢 Какая часть облачного счета уже управляется?

Разбираем метрику, которая показывает, какая часть облачных затрат уже привязана к понятному владельцу: команде, продукту, сервису, проекту или ЦФО.

Формула:

Покрытие аллокации = затраты с назначенным владельцем / общие облачные затраты × 100%

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

Что попадает в числитель:
🟥ресурсы с корректными тегами владельца, продукта, среды или приложения
🟥аккаунты, проекты и подписки, привязанные к бизнес-юниту или ЦФО
🟥общие сервисы, распределенные по согласованному правилу
🟥затраты, связанные с владельцем через CMDB, каталог сервисов или внутреннюю модель аллокации

Важно считать показатель на одной базе затрат.

Если используете Amortized Cost, значит и распределенные, и общие затраты считаются в Amortized. Если компания работает в Net-Net с учетом договорных скидок, покрытие тоже нужно считать в этой логике.

Зачем это нужно:
🟥видно, какая часть счета уже управляется
🟥проще найти неразмеченные ресурсы и общие расходы без правил
🟥появляется база для showback, chargeback и продуктовой экономики
🟥команды начинают видеть не абстрактный облачный счет, а свои реальные затраты

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

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

Источник: FinOps Foundation, Allocation

#FinOps_Inform #FinOps_Crawl

🟩«Раз, два, три, четыре, пять — вышел зайчик посчитать»

А как посчитал косты — прослезился.

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

Во второй статье FinOps-цикла разбираем ручной пилот: биллинг на уровне ресурсов, разметку owner / project / environment, зомби-диски, старые снапшоты, dev/test как production и ловушку «нашли потенциал, но это еще не экономия».

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

Читать продолжение на Хабр

💬 Практики FinOps

⚡️ FinOps по фасттреку: как снизить облачные расходы и не сломать сервис

В идеальном мире компания спокойно проходит весь цикл FinOps: Inform, Optimize, Operate, выстраивает роли, процессы, отчётность и регулярную работу с затратами.

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

⚪️ В новом выпуске поговорили с Вячеславом Бессоновым, генеральным директором Hilbert Team.

Разобрали, как работает FinOps по фасттреку: с чего начинать, если бизнесу нужен quick win, почему биллинга провайдера обычно недостаточно, как проверять гипотезы оптимизации и когда экономия превращается в полноценный IT-проект

Темы выпуска:
🟥 почему FinOps в России часто начинается с запроса «порезать косты»
🟥 зачем считать ROI оптимизации, если нужно менять архитектуру
🟥 когда можно получить быстрые 5–10%, а когда 20–30% требуют отдельного проекта
🟥 почему нельзя просто срезать ресурсы без проверки влияния на сервис
🟥 как работают резервы и бронирование ресурсов
🟥 почему теги всё ещё скорее исключение, чем правило
🟥 как делить общую инфраструктуру между продуктами
🟥 что меняется в FinOps из-за гибридной инфраструктуры, workload first и AI-токенов

Смотреть выпуск:
🎞 YouTube
📺 Rutube
📺 VK Видео

Слушать выпуск:
💬 Telegram Player (Mave)
🎵 Яндекс. Музыка
🎵 VK Музыка

💬 Практики FinOps