Error Budgets і SLO управління

1) Навіщо SLO і бюджет помилок

SLO (Service Level Objective) - цільовий рівень якості, що сприймається користувачем; SLI - вимірювана метрика; Error Budget - допуск на відхилення за вікно (зазвичай 30/90 днів).
Бюджет помилок перетворює надійність з «абстракції» в керований ресурс: коли бюджет згорає швидко - заморожуємо фічі і чинim; коли бюджет здоровий - можна прискорювати релізи.

2) Вибір SLI: що вважати «хорошим»

Критерій: «успішно з точки зору користувача».

2. 1 Класичні SLI

Availability: частка успішних запитів (виключаючи скасовані клієнтом).
'success = http_status ∈ {2xx, 3xx, 404} і без таймауту'( 404 може вважатися успіхом для read API, якщо це очікувана семантика).
Latency: частка запитів швидше порогу (наприклад, p95 ≤ 300 мс).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness: «дані не старше X хвилин» (кеш, каталоги, коефіцієнти).
Quality: правильність результату (проходження бізнес-валідаторів/бекенд-інваріантів).

2. 2 Межі та сегменти

SLI потрібно вважати за важливими зрізами: `route`, `tenant/brand`, `region/jurisdiction`, `payment_provider`. Так ви не «розмажете» збій однієї критичної ручки по всій системі.

3) Формули і бюджет

3. 1 Request-based (переважно для API)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 Time-based (для фонових сервісів/стрімінгу)

SLO_uptime = good_minutes / total_minutes

3. 3 Приклад цілей

API загальні: 99. 9% доступності за 30 днів → бюджет = 0. 1%.
Критичні платіжні ручки: 99. 95%; каталоги/пошук: 99. 5%.
Латентність: p95 ≤ 300 мс на '/v1/payments', p99 ≤ 800 мс.

4) Інструментування SLI

4. 1 Принципи

Логи/трейси → метрики RED (Rate/Errors/Duration) з явними buckets.
Обов'язково проставляйте'tenant','region','route _ class'( без PII).
Рахуйте дві метрики: «успіх» і «всього», а для latency - «швидко» і «всього».

4. 2 Приклад Prometheus (rate за 5m)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) Алерти по burn rate (multi-window, multi-burn)

5. 1 Ідея

Дивимося, з якою швидкістю згоряє бюджет щодо мети. Якщо швидкість висока на короткому і довгому вікні - сигналимо.

5. 2 Порогові профілі (для SLO 99. 9%)

Пейджинг: burn rate ≥ 14. 4 × (10% бюджету за 1 годину і 5% за 6 годин).
Тікет: burn rate ≥ 6 × (2% за 6 годин і 1% за 24 години).

5. 3 Приклад правил (Prometheus, псевдо)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

Аналогічно на 6ч/24ч для тікету.

6) Управління з бюджету: процеси

6. 1 Релізні гейти

Якщо залишок бюджету <25% і тренд негативний - «код-заморожування» на фічі, пріоритет SRE/стійкість.
Канарні релізи повинні мати окремий SLO-зріз ('deployment. environment="canary"`).

6. 2 Пріоритизація беклога

Розподіляйте ємність команди пропорційно швидкості згоряння і впливу на виручку.
Обґрунтовуйте технічний борг метриками: «фікс X знизить burn rate на Y%».

6. 3 Пост-інцидент

Кожному інциденту - RCA і «фікс, який не можна відкотити» (actionable), контроль «повернулося в SLO».

7) SLO як код

7. 1 Приклад маніфесту SLO (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 Генерація правил

Використовуйте генератори (slo-generator, pyrra, sloth) для автоматичного створення правил, дашбордів і звітів.

8) Деградація та захист SLO

Load shedder: віддавати швидкі відповіді без «дорогих» залежностей при піку.
Cache & stale: `stale-while-revalidate` для read.
Rate/Concurrency limits: захищає бекенди; важливі маршрути - пріоритет.
Circuit/Timeout: швидкі таймаути і «fallback» гілки.
Feature flags: відключення важких фіч однією кнопкою.

9) Спостережуваність для SLO

Дашборди: SLO actual vs target, залишок бюджету, burn rate, внесок за маршрутами/провайдерам.
Кореляція: з «діри» SLO → в exemplar → конкретний trace → логи/профайли.
Звіти: щотижня - тренди, споживання бюджету, топ-причини деградацій.

10) Антипатерни

Один «глобальний» SLO для всього → маскує проблеми. Сегментуйте.
«99. 99% на все" без урахування вартості та реальності. Вибирайте цілі з досвіду користувача.
Алерти по CPU/heap замість burn rate/SLO.
Ігнорування 4хх/довгих редиректів, які псують UX.
Непрозоре вікно (rolling vs календарне) - порівняння «яблук з апельсинами».

11) Специфіка iGaming/фінансів

Шляхи грошей (депозити/висновки): окремі SLO вище загального рівня (напр., 99. 95% доступності; p95 ≤ 250 мс).
Провайдери PSP/KYC: SLO по кожному провайдеру + алерти на їх внесок в burn; автоматичне перемикання маршрутів (smart routing).
Юрисдикції/тенанти: SLO і бюджети по'region/jurisdiction/brand', щоб локальна проблема не «залила» глобальну метрику.
Відповідальна гра: SLO на час застосування лімітів/самовиключення (compliance-формули).
Аудит/регуляторика: зберігайте звіти SLO та інцидентів; прозорість для внутрішніх аудитів.

12) Чек-лист prod-готовності

• Визначені SLIs (availability/latency/quality/freshness) і сегменти (route/tenant/region).
• Цілі (SLO) реалістичні, узгоджені з бізнесом; є rolling вікна 30/90 днів.
• Алерти по burn rate з мульти-вікнами (пейджинг/тікет).
• SLO як код (генератор правил/дашбордів); звіти по бюджету.
• Релізні гейти зав'язані на залишок бюджету; канарні зрізи.
• Механізми деградації (shedder, cache stale, circuit, ліміти) реалізовані і протестовані.
• Кореляція метрик ↔ трейсів (exemplars), чіткі runbooks.
• Фінансові/юрисдикційні шляхи - окремі SLO/алерти; PSP/KYC розукрупнені.
• Регулярні ретро по інцидентах і інвестиції в надійність, засновані на burn.

13) TL; DR

Визначте SLI за призначеною для користувача цінністю, задайте реалістичні SLO, а управління ведіть через Error Budget і burn rate з мульти-вікнами. Увімкніть SLO-як-код, релізні гейти і деградацію за планом. Сегментуйте за маршрутами/тенантами/регіонами; для шляхів грошей тримайте більш жорсткі цілі і окремі алерти.