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.
Игнорирование 4xx/долгих редиректов, которые портят 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-как-код, релизные гейты и деградацию по плану. Сегментируйте по маршрутам/тенантам/регионам; для путей денег держите более жесткие цели и отдельные алерты.