Перейти к содержанию

Расходы и FinOps

Раздел Интеграция с YC → Расходы превращает данные биллинг Яндекс Облака в компактный финансовый слой для пользователя и ИИ.

Его задача — отвечать не только на вопрос:

Сколько денег потрачено?

но и помогать последовательно разобраться:

сколько
    ↓
на что
    ↓
что изменилось
    ↓
какой ресурс дал вклад
    ↓
где есть подтверждённый повод для оптимизации

Почему Студия не передаёт raw Billing API прямо в чат

Детализация расходов может быть очень большой.

Если при каждом вопросе помещать в контекст модели полный набор данных по всем сервисам, SKU и ресурсам:

  • быстро растёт контекст;
  • увеличивается задержка;
  • растёт стоимость облачной модели;
  • повторяются одинаковые запросы к Billing API;
  • модель получает намного больше данных, чем нужно для конкретного вопроса.

Поэтому NiceSoft FinOps сначала нормализует и кэширует данные, а модели отдаёт компактное представление по требованию.

1. Какие понятия нужно знать

Cost

Стоимость потреблённых ресурсов до применения скидок/credits.

Credits

Применённые скидки и компенсации.

В зависимости от ответа Billing сюда могут относиться разные типы credit.

Expense

Фактическая стоимость после применения discounts/credits в модели Usage API.

Для вопросов «сколько реально составили расходы по данным детализации» обычно важнее именно expense, но в отчёте полезно показывать все три величины.

Warning

Суммы Billing Usage API могут быть предварительными. Яндекс Облако указывает, что окончательная сумма за отчётный период может корректироваться и фиксируется в закрывающих документах.

2. Что поддерживает официальный Usage API

ConsumptionCore умеет формировать отчёты по уровням:

  • платёжный аккаунт;
  • облако;
  • каталог;
  • service;
  • SKU/product;
  • resource;
  • label.

И временную агрегацию:

  • DAY;
  • WEEK;
  • MONTH;
  • QUARTER;
  • YEAR.

NiceSoft FinOps использует эти данные как первичный финансовый источник.

3. Необходимая роль

Минимальная роль для получения детализации через Usage API:

billing.accounts.viewer

Она назначается на платёжный аккаунт.

Не на каталог.

Не на объект служебной учётной записи.

Не на виртуальную машину.

4. Подключить Billing

Шаг 1. Найдите платёжный аккаунт

Откройте биллинг Яндекс Облака и выберите платёжный аккаунт, обслуживающий нужное облако.

Шаг 2. Назначьте служебной учётной записи роль

Назначьте:

billing.accounts.viewer

на нужный платёжный аккаунт.

Шаг 3. Подождите распространения IAM

После изменения ролей возможна небольшая задержка.

Шаг 4. Откройте Студию

Перейдите:

Интеграция с YC → Расходы.

Шаг 5. Обновите данные

Проверьте, что overview загружается без 403.

5. USER и ADMIN видят не обязательно один область доступа

платёжный аккаунт может включать много каталог.

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

В текущем профиле шлюз NiceSoft серверно ограничивает данные использования обычного пользователя подключённым рабочим каталогом.

Это означает:

service account имеет Billing role
        ↓
BillingCore может получить account data
        ↓
Gateway применяет пользовательский scope
        ↓
USER получает данные рабочего Folder

Административные возможности могут иметь другой область доступа в зависимости от политики.

6. Overview

Начинайте любой финансовый анализ с обзора.

Пример:

Покажи расходы рабочего Folder за текущий месяц.
Отдельно:
- cost;
- credits;
- expense;
- прогноз до конца месяца;
- дневную динамику.

NiceSoft overview предназначен именно для компактного первого ответа.

Он не должен автоматически разворачивать каждый SKU и каждый resource.

7. Сравнение периодов

Запрос:

Сравни расходы текущего месяца с сопоставимым периодом прошлого месяца.
Покажи:
1. expense обоих периодов;
2. абсолютное изменение;
3. процент изменения;
4. какие сервисы дали основной вклад.

Почему важно слово сопоставимым:

если сегодня 14 число, сравнение полного текущего месяца с полным прошлым месяцем вводит в заблуждение.

Правильнее сравнивать:

1–14 сентября
vs
1–14 августа

если пользователь явно не попросил иное.

8. Drill-down: service → SKU → resource

Когда вы нашли крупный сервис, переходите глубже только по нему.

Пример:

Какой сервис дал самый большой expense за период?

Затем:

Разверни этот сервис по SKU.

Затем:

Для самого дорогого SKU покажи распределение по resource.

Это называется lazy drill-down.

Он существенно эффективнее запроса «покажи всё про всё».

9. Анализ по labels

Labels помогают распределять расходы по:

  • командам;
  • средам;
  • продуктам;
  • cost center;
  • владельцам.

Пример:

Сравни expense для label env=prod и env=test за месяц.

Warning

При группировке по labels один ресурс с несколькими labels может учитываться в каждой соответствующей группе. Нельзя автоматически суммировать все label-группы как независимые части общего расхода.

10. Бюджеты

В Яндекс Облаке бюджет — механизм уведомлений о достижении порога.

Он не является жёстким spending limit и сам по себе не останавливает ресурсы.

Студия может читать список бюджетов и оценивать:

  • текущий burn;
  • projection;
  • риск достижения порога.

Пример:

Покажи бюджеты, относящиеся к нашему scope.
Для каждого укажи текущий прогресс, прогноз и риск превышения.

Не путайте:

budget threshold reached
≠
resources automatically stopped

11. Forecast

Простейшая линейная проекция может быть полезна, но не является гарантией счёта.

На прогноз влияют:

  • сезонность;
  • плановые выключения;
  • reserved usage;
  • скачки нагрузки;
  • новые ресурсы;
  • скидки и grants;
  • корректировки Billing.

Поэтому хороший ответ должен показывать прогноз как оценку:

При сохранении текущего темпа...

а не:

Итоговый счёт точно будет...

12. FinOps Advisor

Advisor в Студии работает по принципу evidence-first.

То есть рекомендация должна опираться на уже полученные финансовые данные.

Хорошо:

Сервис X дал 41% expense и вырос на 28% к сопоставимому периоду. Имеет смысл начать технический drill-down по его ресурсам.

Плохо:

Удалите половину виртуальных машин — это сэкономит деньги.

Одни Billing данные не доказывают, что ресурс не нужен бизнесу.

13. Пример полного FinOps-диалога

Вопрос 1

Сколько мы потратили с начала месяца?

Вопрос 2

Что изменилось относительно такого же периода прошлого месяца?

Вопрос 3

Какие три сервиса дали основной рост expense?

Вопрос 4

Для первого сервиса сделай drill-down по SKU.

Вопрос 5

Для самого дорогого SKU покажи resources.

Вопрос 6

Сформулируй три направления для проверки оптимизации.
Для каждого укажи факты, на которых основана рекомендация, и чего пока не хватает для решения.

Такой диалог значительно надёжнее, чем одна команда:

Сократи мои расходы на 30%.

14. Кэширование NiceSoft FinOps

В текущем профиле используются несколько уровней TTL.

Ориентировочный базовый профиль релиза 0.3.66:

текущий snapshot: около 15 минут
breakdown/drill-down: около 1 часа
закрытая история: около 24 часов

Кроме того, базовый Usage слой ограничивает частоту запросов к внешний сервис.

Причины кэширования:

  • уменьшение числа обращений к Billing API;
  • защита от rate limit;
  • быстрые повторные вопросы;
  • одинаковая финансовая база для интерфейс и ИИ;
  • уменьшение LLM context.

Note

Если вы только что создали/удалили крупный ресурс, FinOps dashboard может некоторое время показывать не моментальное, а последнее доступное финансовое состояние. Billing сам по себе также не является real-time telemetry.

15. Почему интерфейс и ИИ должны показывать одни цифры

И dashboard, и диалоговая FinOps-функция используют общий BillingCore.

Это специально сделано для предотвращения ситуации:

Dashboard: 10 000
ИИ: 11 700

из-за независимых методов агрегации.

Если цифры всё же расходятся, первым делом проверяйте:

  • период;
  • область доступа;
  • cost vs expense;
  • кэш;
  • валюту;
  • сопоставимость временной зоны/границ периода.

16. Что такое «аномалия»

Не всякий рост — аномалия.

Например, расходы могли вырасти потому что:

  • начался новый проект;
  • увеличился трафик;
  • был проведён load test;
  • куплено reserved consumption;
  • изменился тариф;
  • закончился grant.

Поэтому Студия должна говорить:

необычное изменение относительно выбранной базы

а не автоматически:

проблема.

17. Подготовить отчёт руководителю

Пример:

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

Формат:
- executive summary — до 7 пунктов;
- expense за период;
- сравнение с предыдущим сопоставимым периодом;
- топ-5 сервисов;
- три крупнейших изменения;
- бюджеты и риск порогов;
- рекомендации для проверки;
- отдельный блок «ограничения данных».

Не включай технические SKU, если они не нужны для объяснения изменения.

18. Что нельзя делать на основании только FinOps

Не принимайте автоматически решения:

  • удалить VM;
  • уменьшить диск;
  • отключить backup;
  • убрать репликацию;
  • перевести БД на слабую конфигурацию;
  • удалить snapshot;
  • прекратить logging.

Финансовая эффективность должна сопоставляться с:

  • SLA;
  • RPO/RTO;
  • производительностью;
  • безопасностью;
  • бизнес-назначением;
  • прогнозом нагрузки.

19. Безопасность Billing

Финансовые данные сами по себе конфиденциальны.

Они могут раскрывать:

  • масштаб инфраструктуры;
  • используемые сервисы;
  • периоды нагрузки;
  • внутренние проекты по labels;
  • относительную важность систем.

Поэтому:

  • не выдавайте billing.accounts.viewer всем служебные учётные записи;
  • ограничивайте USER область доступа;
  • не публикуйте FinOps отчёты через общие ссылки без проверки;
  • учитывайте активную модель при передаче финансового контекста.

20. Диагностика

403 PERMISSION_DENIED

Проверьте billing.accounts.viewer на самом платёжный аккаунт.

Инфраструктура работает, Billing нет

Нормальная ситуация при отсутствии billing роль.

Expense равен нулю

Проверьте:

  • период;
  • область доступа каталога;
  • действительно ли ресурсы привязаны к этому платёжный аккаунт;
  • задержку появления детализации;
  • фильтры.

Цифры отличаются от счёта

Usage API может содержать предварительные данные. Закрывающие документы имеют собственный финансовый статус.

Очень медленно

Проверьте, не выполняется ли глубокий drill-down вместо cached overview.

21. Контрольный набор FinOps

1. Expense текущего месяца.
2. Cost и credits отдельно.
3. Сравнение с прошлым сопоставимым периодом.
4. Top services.
5. Drill-down одного сервиса по SKU.
6. Drill-down одного SKU по resources.
7. Список budgets.
8. Forecast.
9. Advisor с доказательствами.

Если все девять сценариев работают и область доступа соответствует политике, FinOps готов к эксплуатации.

Что дальше