FOCUS и детализация биллинга: почему облачный счёт нельзя просто сложить
Оптимизация облачных расходов начинается не с прайса, а с детализации биллинга: cost & usage выгрузки должны отвечать, сколько стоил продукт вчера. Разбираем кейс, нужные поля и стандарт FOCUS.
В понедельник облачные расходы выросли на 18%. Финансовый директор спрашивает, какой продукт стал дороже. В отчёте провайдера видно рост категории Storage, но на этом расследование заканчивается: часть строк — объём данных, часть — API-запросы, часть — исходящий трафик, а одна корректировка вообще пришла за прошлый месяц.
Команда хранения говорит, что объём почти не изменился. Дашборд прав по сумме. Инвойс сходится. Ответить, какой workload подорожал, нельзя.
Именно здесь начинается FinOps и любая осмысленная оптимизация расходов — не с поиска самой дешёвой ВМ, а с вопроса: достаточно ли детализирована биллинговая выгрузка (cost & usage / billing export API), чтобы связать начисление с ресурсом, владельцем и бизнес-метрикой? В одном облаке различия ещё прячут в SQL. Во втором появляется отдельный словарь сервисов. В третьем — модель нормализации. FOCUS (FinOps Open Cost and Usage Specification) — открытый стандарт детализации облачного биллинга: он выравнивает смысл строк cost & usage, а не публичные цены. Cloud FinOps — этот сайт; FOCUS — спека FinOps Foundation.
Биллинговая выгрузка: две строки, которые нельзя сравнить
Синтетический, но типичный фрагмент cost & usage. Провайдер A отдаёт суточные строки по ресурсу. Провайдер B — месячный rollup по «виртуальной инфраструктуре».
Provider A 2026-07-24 | vm-123 | Compute | 24 h | 960 ₽ | tags: team=search Provider B 2026-07 | — | Virtual Infrastructure | 744 h | 27 900 ₽ | project-17
Вопрос не риторический: можно ли эти строки честно сравнить и сказать, где дешевле search-workload?
- Разные периоды: день против месяца.
- Разная агрегация: ресурс против «всё compute сразу».
- Разные идентификаторы: vm-123 vs пусто.
- Неясно, включены ли скидки и обязательства в 27 900 ₽.
- Неизвестно, финальные ли данные или ещё будут корректировки.
Пока строки живут в разных моделях, сравнение «как есть» врёт — даже если обе цифры взяты из официальной выгрузки.
Детализация cost & usage: четыре опоры данных
Из понедельничного инцидента обычно вылезает не «мало колонок в API», а отсутствие четырёх опор детализации:
- Когда начислено — charge period и отдельно billing period (корректировка прошлого месяца ломает «рост за вчера»).
- За что — service, SKU, resource; «Storage» без разделения объёма, запросов и egress недостаточно.
- Кому отнести — account, project, tags, owner; без контракта на теги chargeback превращается в переговоры.
- Какой это тип денег — usage, commitment, credit, tax, adjustment; смешивать их в одном KPI нельзя.
| Вопрос | Чего недостаточно | Какие данные нужны |
|---|---|---|
| Сколько стоил workload вчера? | Итог по аккаунту | Resource ID, период начисления, Effective Cost, tags |
| Почему сумма изменилась? | Название сервиса | Charge Category, SKU, usage quantity, признак correction |
| Почему дашборд ≠ инвойс? | Один столбец Cost | Billed Cost, Billing Period, Invoice Issuer, adjustments |
| Какая команда владеет расходом? | Project name | Owner / cost center и правило аллокации |
FOCUS — стандарт детализации биллинга
FOCUS нужен не потому, что аналитикам раздражают разные названия колонок в выгрузке. Он нужен, чтобы один и тот же запрос к cost & usage имел одинаковый смысл у нескольких поставщиков: chargeback, budgeting, forecasting, сверка с инвойсом, контроль роста расходов.
Кратко: открытая vendor-neutral схема детализации биллинга (актуальная линейка — на focus.finops.org; на момент материала ратифицирована 1.4). Строка — начисление; колонки задают смысл суммы, периода, сервиса, ресурса и категории. Granularity (день/час/ресурс) — capability, не одинаковый SLA у всех вендоров. Документацию billing export / FOCUS dataset удобно смотреть через Get Started.
| Понятие | Зачем на практике |
|---|---|
| Charge / строка начисления | Единица разбора вместо «итога в Excel» |
| Billed Cost | Сколько выставили к оплате |
| Effective Cost | Экономика после обязательств и распределения |
| Charge Category | Отделить usage от credit, tax, commitment |
| Billing Period vs Charge Period | Поймать корректировки прошлого периода |
| Resource / Service / SKU | Дойти от категории Storage до конкретного объекта |
| Tags / attribution fields | Связать spend с командой (если теги заполнены) |
| Completeness / freshness metadata | Понять, provisional ли данные |
Пайплайн: от биллинговой выгрузки к chargeback
Billing export / cost & usage API
↓
Сырой слой без изменений
↓
Нормализация в FOCUS-подобную модель
↓
Обогащение владельцами и cost centers
↓
Showback / chargeback / unit economics / алерты- Сырой экспорт сохраняем как есть — иначе невозможно переиграть спор через три месяца.
- Версию схемы и timestamp выгрузки кладём в пайплайн.
- Корректировки загружаем повторно; дашборд должен уметь «плавать», пока данные provisional.
- Attribution — отдельный слой: теги, справочник владельцев, правила для shared-кластеров.
- Бизнес-метрики (cost per request) не часть FOCUS: их стыкуют сами.
Публичный прайс и калькулятор — другой слой: план «сколько будет стоить конфигурация». На Cloud FinOps это прайс-слой. Факт для оптимизации расходов живёт в детализации cost & usage. Путать слои — частая причина разочарований: «в калькуляторе было дешевле».
Чек-лист детализации биллинговой выгрузки
Семь вопросов к cost & usage / billing export — можно забрать на встречу с провайдером или платформенной командой:
- Можно ли сверить сумму строк с инвойсом?
- Есть ли стабильный Resource ID?
- Можно ли отделить usage от credit, tax и commitment?
- Видно ли, что данные ещё provisional?
- Можно ли пересчитать эффективную стоимость workload за вчера?
- Какая доля расходов не имеет владельца?
- Можно ли повторить тот же расчёт спустя три месяца?
Если на три и больше вопросов ответ «нет» или «не знаем» — у вас не проблема дашборда. У вас проблема модели данных. FOCUS (или внутренний канон в тех же терминах) снижает стоимость нормализации; ownership и теги всё равно придётся договориться отдельно.
Итог: прайс, детализация и FOCUS
- Публичный прайс нужен для планирования — каталог и калькулятор.
- Детализация cost & usage нужна, чтобы объяснить факт и оптимизировать расходы: ресурс, период, тип денег, владелец.
- FOCUS — стандарт этой детализации между поставщиками; он не заменяет процессы и attribution.
Спецификацию FOCUS и материалы по adoption удобно отслеживать на focus.finops.org. Материал информационно-аналитический, не аудит вашей выгрузки.