От Gross Spend к Net Spend: реальная стоимость облака

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

Представьте покупку авиабилета. На сайте указана цена 10 000 рублей. Это базовая стоимость (gross spend). Но у вас есть промокод на 1 000 рублей, а банк после покупки вернет еще 500 рублей в виде кэшбэка. В итоге из вашего кармана уйдет ровно 8 500 рублей. Это ваша чистая трата (net spend).

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

🫥 Как это считать правильно

Для вычисления чистой стоимости ресурсов в FinOps используют формулу:

Net Spend = Gross Spend - (Discounts + Credits + Rebates)

Каждое корректирующее значение имеет свою специфику в структуре данных.

Discounts (скидки). Сюда относятся корпоративные скидки за объем потребления или за обязательства по выкупу мощностей (commitments).

Credits (кредиты). Это бесплатные гранты от провайдера на тестирование новых сервисов, компенсации за нарушение SLA или маркетинговые ваучеры.

Rebates (рибейты). Прямые возвраты денег или бонусов на счет при выполнении определенных условий годового контракта.

С точки зрения аналитики данных, если мы оцениваем общую эффективность ИТ-бюджета на уровне руководства, мы всегда используем амортизированные чистые затраты (Amortized Net Costs). Но при расчете юнит-экономики отдельных сервисов мы обязаны сохранять видимость базовых цен (Gross Unblended Costs). Это позволяет инженерам видеть реальную рыночную стоимость их архитектурных решений, а финансистам фиксировать фактические оттоки денег.

🫥 Почему это важно

Большинство нативных дашбордов по умолчанию показывают розничные цены, что создает слепую зону для бизнеса по нескольким причинам.

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

Во-вторых, ломается логика справедливой аллокации. Если один департамент потратил время, закоммитился на использование конкретных типов серверов и получил скидку 30%, эти сэкономленные деньги должны уменьшать счет именно этой команды, а не размываться по всей компании.

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

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

#finops_inform #finops_walk

💬 Чат | 💬 Практики FinOps

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

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

Формула:

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

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

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

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

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

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

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

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

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

#FinOps_Inform #FinOps_Crawl