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

ТехSLO

Availability: успешные 2xx/3xx / все запросы.
Latency: p95/p99 по ключевым роутам (`/deposit`, `/bet`, `/game/init`).
Errors: доля 5xx/таймаутов.
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-гейты интегрируются в релизы моделей (A/B/канареечный 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, а значит — лучшую выручку и меньше инцидентов в самые горячие часы.