SLI/SLO модель: как перестать тушить пожары и начать управлять надёжностью

Большинство команд эксплуатации работают в реактивном режиме: алерт сработал — пошли разбираться. SLI/SLO-подход переворачивает игру: вы заранее договариваетесь, какой уровень надёжности вы держите, и автоматизируете решения вокруг этого уровня. Ниже — практический гайд от команды, которая внедряла этот подход в десятке production-окружений.

1. В чём суть подхода

SLI (Service Level Indicator) — измеримая характеристика сервиса. SLO (Service Level Objective) — целевое значение SLI на временном окне. Error budget — допустимое отклонение от SLO. Если бюджет израсходован, релизы приостанавливаются, фокус — на стабильности.

Пример: 99.9% запросов должны возвращать код < 500 за 30 дней. Это даёт error budget в 0.1% × 30d ≈ 43 минуты допустимых ошибок в месяц.

2. Как выбирать SLI

Главный критерий — пользовательская перспектива. Не «процент работающих подов», а «процент успешных запросов с точки зрения клиента». Базовый набор SLI для веб-сервиса:

• Availability: ratio запросов с кодом не 5xx ко всем запросам
• Latency: ratio запросов с временем ответа < N мс к общему числу
• Quality: ratio «полных» ответов к усечённым (degraded mode)

Для batch-задач и пайплайнов SLI выглядят иначе: freshness, completeness, correctness.

3. Burn-rate alerting

Главное преимущество SLO-подхода — осмысленные алерты. Вместо «threshold > 95%» используется multi-window multi-burn-rate:

- alert: ApiSloFastBurn
  expr: |
    (
      slo:burn_rate:1h{service="api"} > 14.4
      and
      slo:burn_rate:5m{service="api"} > 14.4
    )
  for: 2m
  labels:
    severity: page
  annotations:
    runbook: https://runbooks.iteam.site/api-fastburn

Burn-rate 14.4 означает: при таком темпе израсходование 30-дневного бюджета займёт 50 часов вместо 30 дней. Это — действительно срочно.

4. Связь с релизной политикой

Когда error budget израсходован — release blocked. Это формулируется в политике, согласованной между разработкой, эксплуатацией и продуктом:

• 0–25% бюджета сожжено: обычные релизы, безопасные эксперименты
• 25–75%: рискованные релизы требуют sign-off от tech lead'а
• 75–100%: только bug-fix; на новые фичи stop-the-line
• >100%: автоматическая блокировка прод-релизов через ArgoCD policy

5. Постановка приоритетов и культура

SLI/SLO не работает, если:

1. Команды не верят, что метрика честная (нужно регулярно перепроверять);
2. Нарушение SLO ничего не меняет (нужны последствия — блок релизов);
3. SLO выставлен «для галочки» 99.99% при реальной готовности 99.5%.

Ставьте amibitious SLO, но реалистичные. Лучше 99.5% выполняемых, чем 99.99% игнорируемых.

6. Инструменты

Минимально достаточный стек:

• Prometheus + recording rules: вычисление SLI и burn-rate
• OpenSLO или Sloth: декларативные SLO как код
• Grafana: дашборды error budget'ов
• Alertmanager: маршрутизация алертов
• ArgoCD + OPA: блокировка релизов при истощении бюджета

7. Roadmap внедрения

Реалистичный план первого квартала:

• Неделя 1–2: workshop с командой, выбор 2–3 ключевых пользовательских флоу
• Неделя 3–4: реализация recording-rules, базовых дашбордов
• Неделя 5–6: burn-rate alerts (без блокировок)
• Неделя 7–8: postmortem-цикл, корректировка SLO до реалистичных
• Неделя 9–12: внедрение release-policy, обучение команды

Что мы видим у клиентов

Внедрение SLI/SLO в зрелой команде даёт:

• Снижение алертной нагрузки на 60–95%
• Сокращение MTTR на 30–50% за счёт чёткой эскалации
• Рост скорости поставки на 2–4×, потому что error budget'ы закрывают споры «релизим или не релизим»

Хотите, чтобы мы внедрили SLI/SLO в вашей команде? Напишите нам на contact@iteam.site — пришлём оценку объёма работ.