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. Так платформа залишиться швидкою, стійкою і прибутковою - навіть на піках зростання.