FinOps и управление бюджетами

Краткое резюме

1. измеряем ценность и стоимость единицы (unit-economics),

2. ставим бюджеты и guardrails,

3. прогнозируем спрос и планируем мощность,

4. управляем закупками/скидками,

5. меняем архитектуру и процессы ради SLO при минимальном TCO.

Роли и ответственность

Product/Business: цели выручки/MAU/LTV, лимиты бюджета.
FinOps: методология, отчетность, закупки, бюджетные сигналы.
Инженерия/SRE: rightsizing, скейлинг, кэш/архитектура, операционные рычаги.
Data/Analytics: прогноз нагрузки и затрат, аномалии.
Security/Compliance: требования хранения/логов/DR, влияющие на TCO.

RACI: FinOps ведет процессы и отчеты → инженеры реализуют экономные изменения → бизнес утверждает бюджеты/приоритеты.

Метрики и unit-economics

$/1000 RPS (или $/1k событий/транзакций) — базовая метрика стоимости сервиса.
$/мс p95 — сколько стоит сдвиг хвоста латентности (важно для конверсии).
$/MAU, $/депозит, $/игрок/месяц — бизнес-единицы.
TCO = compute + storage + network egress + managed-сервисы + лицензии + трудозатраты.
Cost Coverage Ratio: доля «закрытого» on-demand потребления коммит-планами.

Пример: сервис дает 60k RPS при $120/ч → $2/1000 RPS·ч. Любая оптимизация сравнивается с этим эталоном.

Тэгирование и прозрачность

Обязательные тэги: `env`, `product`, `service`, `owner`, `region`, `tier`, `cost-center`.
Без тэгов — ресурсы не создаем и не продлеваем.

Showback/Chargeback: еженедельные отчеты по командам/продуктам, привязанные к unit-метрикам.
Аномалии: ежедневные дельты > X% и «немые» ресурсы (0 RPS, есть стоимость).

Бюджеты, guardrails и алерты

Ежемесячный бюджет по сервису/продукту + soft/hard guardrails.

• дневной burn-rate > план × (дней в месяце/оставшиеся дни),
• egress/лог-ингест > порога,
• spot-вытеснение > N% времени,
• рост «ничейных» ресурсов.
• Политики: запрет ресурсов без тэгов, авто-TTL стейджингов, лимиты на класс хранилищ.

Прогнозирование затрат

1. Драйверы: MAU, DAU, RPS по маршрутам, доля кэша, сезонность/ивенты.
2. Модель: базовый тренд + сезонность + сценарии (база/агрессивный).
3. Перевод в деньги: профили потребления по слоям (edge/proxy/app/DB/логирование).
4. Заложить шаги: headroom 30% для пиков, резерв на DR/коммит-планы.

Cost_month ≈ Σ (RPS_route × $/1kRPS_route × часы) + egress + storage + managed

Закупки и модели потребления

Reserved/Savings/Committed Use (1–3 года) — закрывают стабильную базу (экономия 30–70%).
Spot/Preemptible — CI/аналитика/асинхрон, конвейеры данных.
Микс: база — коммит, пики — on-demand, фон/бэкграунд — spot.
Правило 70/20/10: 70% — коммит, 20% — on-demand эластика, 10% — spot.

Инженерные рычаги экономии (без потери SLO)

Rightsizing: рабочая точка CPU 50–70%, VPA-рекомендации, маленькие инстансы лучше укладываются.
Auto-scaling под SLO: HPA/KEDA по latency/lag/RPS, а не только по CPU.
Кэш и CDN: ключ кэша без «шума», TTL-лестницы, tiered-cache/origin-shield → egress↓, DB↓.
Сеть: Brotli/gzip, webp/avif, дифф-API, keepalive, ограничение ретраев (retry-budget).
Хранилища: классы (горячее/теплое/холодное), lifecycle-политики, TTL на временные данные.
Логи/метрики/трейсы: семплирование, tail-based, хранение high-res 7–14 дней.
Архитектура: gRPC/протобаф между сервисами, батч/стрим вместо чатов, выбор БД по профилю (KV для частых чтений).

Стоимость надежности и DR

RTO/RPO → стоимость: актив-актив vs актив-пассив, холодные бэкапы.
Расчет: сколько стоит минута простоя vs сколько стоит дополнительная реплика/регион.
Политика: «платим за надежность, если окупается риском».

Дашборды FinOps (минимальный набор)

1. Cost Overview: по продуктам/сервисам/регионам, тренды, прогноз до конца месяца.
2. Unit-economics: $/1k RPS, $/мс p95, $/MAU (по неделям).
3. Egress/Storage: egress ГБ/$, распределение классов хранилищ.
4. Logging/Observability: ingest по источникам, % полезных логов, стоимость «хвостов» p99.
5. Commit Coverage: доля закрытого потребления, риск недоиспользования.
6. Anomalies: топ-спайки и «немые» ресурсы.

Процессы и ритуалы

Weekly FinOps: топ-10 утечек, owner → action → ETA.
Monthly Cost Review: факт vs бюджет, эффективность закупок, пересмотр коммитов.
Pre-event Review: план пиков (мин-реплики, warm-пулы, кэш, лимиты PSP).
Blameless пост-морем по ценовым инцидентам (утечка логов, runaway autoscale).

Чек-лист внедрения

• Тэгирование строгое, showback/chargeback по командам.
• Unit-метрики определены ($/1k RPS, $/мс p95, $/MAU).
• Бюджеты/guardrails/алерты настроены.
• Прогноз затрат связан с прогнозом трафика и SLO.
• Коммит-планы и портфель spot/on-demand сбалансирован.
• Rightsizing и SLO-скейлинг включены (HPA/KEDA/VPA/CA).
• Кэш/CDN/egress оптимизированы, lifecycle на хранилищах.
• Логи/метрики/трейсы — семплирование и TTL.
• DR-политика по RTO/RPO и ее стоимость зафиксированы.
• Еженедельные и ежемесячные обзоры работают.

Типичные ошибки

Нет unit-economics → спорим «на ощущениях».
Ресурсы без тэгов, «ничейные» окружения живут месяцами.
Хранение всего в горячем классе без lifecycle.
Логи как «черная дыра» — 100% ingest, 5% чтений.
Коммит на «все подряд» → недоиспользование и штрафы.
Авто-скейл по CPU без учета latency/lag → переплата или срыв SLO.
Переизбыточный DR без бизнес-обоснования.

Мини-плейбуки

1) Быстрый «трехдневный» FinOps-аудит

1. Срез топ-10 сервисов и egress. 2) Включить lifecycle на «старые» объекты.
2. Срезать шумные логи/включить tail-based. 4) Ввести TTL стейджингов/превью.
3. Зафиксировать $/1k RPS и цели на −15%/мес.

2) −25% egress за неделю

1. Tiered-cache + origin-shield. 2) Перевод картинок в webp/avif.
2. Дифф-API и Brotli. 4) Снизить retry-rate и включить request-collapsing.

3) Атака «runaway autoscale»

1. Увеличить stabilization/cooldown, minReplicas на пике.
2. Перенести часть фоновых в spot и batch окна.
3. Прогреть образы (image pre-pull) и TLS/коннекты.

4) Недоиспользование коммитов

1. Пересобрать портфель, перевести часть on-demand в коммит.
2. Мигрировать подходящие ворклоады на ARM/другой тип.
3. Включить auto-parking в нерабочие часы.

Примеры артефактов

sql
SELECT product, service, date_trunc('week', usage_date) AS wk,
SUM(cost_usd) AS cost, SUM(rps) AS rps,
ROUND(SUM(cost_usd) / NULLIF(SUM(rps)/1000,0), 3) AS usd_per_1k_rps
FROM finops_daily
GROUP BY 1,2,3
ORDER BY 3 DESC;

rego package finops deny[msg] {
input. resource. tags. owner == ""
msg:= "resource without owner tag"
}
deny[msg] {
input. resource. env == "dev"
input. resource. ttl == ""
msg:= "dev resource without TTL"
}

Специфика для iGaming/финтех

Пики (матчи/турниры): заранее поднять minReplicas/minNodes, прогреть CDN/TLS/кэши, серые маршруты для ботов; headroom точечно на горячих эндпойнтах (лобби/каталоги/матч-фиды).
Платежи/PSP: учет квот/стоимости по провайдерам, отдельный egress-пул и идемпотентность → меньше дублей.
Антифрод/AML: многоступенчатая проверка (дешевый грей-чек на краю → дорогой скоринг только при необходимости).
Контент-провайдеры: CDN-кэш, лимиты частоты обновления, пересмотр контрактов к крупным ивентам.

Итог

Эффективный FinOps — это не «урезать затраты», а управлять ими в связке со скоростью продукта и SLO.
Держите прозрачную стоимость единицы, стройте бюджеты и guardrails, сочетайте закупки с инженерными рычагами, автоматизируйте экономию и регулярно делайте cost review. Так платформа останется быстрой, устойчивой и прибыльной — даже на пиках роста.