SLO, SLA та моніторинг надійності

(Розділ: Технології та Інфраструктура)

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

SLO - це внутрішня мета якості, SLA - зовнішнє зобов'язання перед клієнтом, SLI - як ми вимірюємо якість. В iGaming ключові SLI: доступність API і оплат, p95/p99 латентності критичних маршрутів, Time-to-Wallet (TTW), конверсія платежів, запуск ігор, а також метрики черг. Управління надійністю будується навколо бюджету помилок, multi-burn алертів, чітких гейтів релізів і наочних дашбордів з анотаціями.

1) Терміни та відмінності

SLI (Service Level Indicator) - вимірюваний індикатор (наприклад, частка успішних запитів за вікно часу).
SLO (Service Level Objective) - цільове значення SLI (напр., "доступність 99. 9% за 30 днів").
SLA (Service Level Agreement) - контракт/зобов'язання з компенсаціями; базується на реальних SLO, але включає юридичні застереження і вікна винятків (planned maintenance, форс-мажор).

Правило: спершу стабілізуйте SLI/SLO всередині, і тільки потім фіксуйте SLA назовні.

2) Каркас SLI для iGaming

TexSLO

Availability: успішні 2xx/3xx/всі запити.
Latency: p95/p99 за ключовими роутами ('/deposit', '/bet', '/game/init').
Errors: частка 5хх/таймаутів.
Saturation/Queues: затримка черг виплат/транзакцій.

Бізнес-SLI

Payment conversion: `success/attempt`.
TTW p95: час від запиту на виведення до зарахування.
Game start success: сесії ігор, ініціалізація провайдера.
KYC/AML flow success: успішне завершення шляху.

3) Бюджет помилок: як рахувати

Error Budget = 1 − SLO.
Приклад: SLO доступності 99. 9 %/30д ⇒ бюджет помилок = 0. 1% часу ≈ 43хв 12с в 30-денному вікні.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO вважається на ковзному вікні (30/7/1 день) і видно на дашбордах.

• Швидке «згоряння» бюджету → freeze релізів, канарію стопимо, працюємо над стабільністю.
• Запас бюджету → допускаємо більш часті зміни (контрольовано).

4) Приклади SLO для ключових потоків

• Availability ≥ 99. 9 %/30д
• Latency p95 `/deposit` ≤ 250 ms / 30д
• Payment conversion ≥ baseline − 0. 3 %/24год
• TTW p95 (вивід) ≤ 3 хв/24год

• Game init success ≥ 99. 5% / 7д p95 game init ≤ 600 ms / 7д

• Job success ≥ 99 %/7д, лаг <5 хв (пікові вікна окремо).

5) Вимірювання: формули та PromQL (ідеї)

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6) Burn-rate алерти (multi-window)

Ідея: порівнюємо поточну швидкість витрати бюджету з допустимою.

• Fast burn: 14 × бюджету за 1 годину → пейдж через 5-15 хвилин.
• Slow burn: 6 × бюджету за 24 години → тікет, розбір причини.

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7) Дашборди «SLO-карта» та операційка

• Картки по сервісах: Availability, p95, Error-rate, Burn-rate, остаток Error Budget.
• Фільтри: `env`, `region`, `tenant`, `version`.
• Анотації релізів: Git SHA, тип (canary/blue-green), час перемикання.

• Порівняння stable vs canary.
• Розріз по PSP/провайдерам ігор.
• Перехід до exemplars (trace_id) і пов'язаних логів.
• Queue lag і saturation (USE-метрики).

8) SLO-процеси: гейти, freeze, ескалації

Gates в CD: промоушен канарки дозволяється тільки при виконанні SLO-проксі (availability, p95, conv).
Freeze: при fast-burn або нульовому залишку бюджету - стоп релізів до відновлення.
Ескалації: SEV-матриця (SEV1 платежі/депозити, SEV2 ігри, SEV3 бекофіс).
RCA: розбір без звинувачень, оновлення тестів/лімітів/фічефлагів.

9) Data/ML-SLO (для рекомендаторів/LLM)

Latency: p95 відповіді моделі ≤ 300 ms (або tokens/s ≥ N).
Quality proxy: частка валідних відповідей/низької токсичності, share of helpful.
Freshness: вік фічів/даних ≤ X годин.
Cost per 1k events: витрати в бюджеті.
SLO-гейти інтегруються в релізи моделей (А/В/канарний rollout).

10) Конструювання SLA на базі SLO

Виберіть консервативні SLO як основу SLA.
Визначте винятки (планові роботи, зовнішні залежні провайдери, регламент інцидентів).
Введіть компенсації за рівнями порушень (кредит/знижка), механізми звітності та верифікації.

11) Часті помилки і анти-патерни

Немає SLO, тільки «uptime 100%» - нереалістично, демотивує і ховає ризики.
Алерти по «кожній метриці» замість burn-rate - алерт-фетіг та ігнор.
Змішування PII в метриках/логах для SLO - ризики комплаєнсу.
Кардинальність вибухає: 'user _ id/session _ id'як лейбли.
Відсутність анотацій релізів - складно пов'язати деградації зі змінами.
Непрозорий бюджет помилок - команда не розуміє, коли «можна» ризикувати.
SLO не прив'язаний до бізнесу - техметрики «зелені», виручка «червона».

12) Чек-лист впровадження

1. Затвердіть базові SLI (Availability, p95/p99, Error-rate, TTW, Conversion).
2. Встановіть SLO на 30/7/1-денних вікнах і порахуйте Error Budget.
3. Додайте recording rules і burn-rate алерти (fast/slow).
4. Побудуйте SLO-карту з анотаціями релізів і порівняннями canary/stable.
5. Увімкніть гейти в CD: без SLO-ок - без промоушену.
6. Введіть freeze-процедури і SEV-матрицю ескалацій.
7. Зв'яжіть SLO з бізнес-метриками (conv, TTW) і платіжними маршрутами.
8. Для Data/ML визначте latency/quality/freshness-SLO.
9. Регулярні RCA і перегляд SLO/порогів (щоквартально).
10. Документуйте SLA тільки після стабілізації SLO.

13) Приклади «готових» цілей (як старт)

API загальні: Availability 99. 9 %/30д; p95 ≤ 250 ms/30д; Error-rate ≤ 0. 3 %/30д.
Payments: Conversion ≥ baseline − 0. 3 %/24год; TTW p95 ≤ 3 хв/24год.
Games init: Success ≥ 99. 5 %/7д; p95 ≤ 600 ms/7д.
Backoffice jobs: Success ≥ 99%/7д; лаг ≤ 5 хв/7д.
LLM/Reco: tokens/s ≥ N, toxicity viol. ≤ 0. 5 %/7д, freshness ≤ 6ч.

Підсумки

SLO/SLA-підхід перетворює надійність з «краще, ніж вчора» в вимірювану дисципліну: прозорі SLI, зрозумілий бюджет помилок, алерти на швидкість згоряння, зрозумілі дашборди і вбудовані в релізи гейти якості. Такий контур дає iGaming-платформі передбачуваний p95/p99, стабільні платежі і TTW, а значить - кращу виручку і менше інцидентів в найгарячіші години.