Мониторинг SLA и SLO

1) Термины и роли

SLA (Service Level Agreement) — внешнее договорное обязательство перед клиентом (штрафные оговорки, кредиты).
SLO (Service Level Objective) — целевой внутренний уровень сервиса, поддерживающий выполнение SLA.
SLI (Service Level Indicator) — измеряемый индикатор, на основе которого оцениваются SLO/SLA.
Error Budget — допустимая доля “недоступности/ошибок” за период: `Budget = 1 − SLO`.
Scope: измеряется глазами пользователя (end-to-end). В микросервисах — и на уровне компонента, и сквозного пути.

2) Выбор SLI: что именно измерять

Критерий — корреляция с пользовательским опытом и бизнес-ценностью.

• Доступность: доля успешных запросов. `SLI = успешные / все`.
• Латентность: доля запросов быстрее порога T. `SLI = P(latency ≤ T)`.
• Качество: доля корректных ответов (без 5xx/функц. ошибок).
• Актуальность данных: задержка репликации/ETL ≤ X минут.
• Результативность бизнес-процесса: доля успешных платежей/регистраций.

Анти-паттерны: считать только 200-ки как “успех”, игнорируя бизнес-ошибки; измерять в тестовой сети вместо пользовательской.

3) Формулы и окна наблюдения

• `Availability = (OK_requests / All_requests) × 100%`.

• `P95 ≤ T` → лучше формулировать как долю: `SLI = % запросов ≤ T`.
• Пример: “99% запросов поиска ≤ 300 мс за 28 дней”.
• Скользящее окно: 28 или 30 дней (баланс чувствительности и стабильности). Для инцидентов — доп. окна: 1 ч, 6 ч, 24 ч.

4) Error Budget и управление скоростью изменений

Расчет: при `SLO = 99.9%` бюджет = `0.1%` ошибок/недоступности за период.

• Бюджет > 50%: релизы и эксперименты по плану.
• Бюджет 10–50%: только низкорисковые релизы, ужесточение канареек.
• Бюджет < 10%: заморозка релизов, корневая причина, улучшения надежности.
• Связь с прогрессивными релизами: canary/feature-flags “едят” бюджет дозированно, с авто-откатом при деградации.

5) Алерт-политики: от порогов к burn rate

Почему не “даупал SLO — подними алерт”: слишком поздно. Нужна проактивность.

• `BR = (наблюдаемая ошибка за короткое окно / допустимая ошибка за это окно)`.
• Если `BR > 1` — бюджет расходуется быстрее нормы.

• Быстрый алерт (шум чувствителен, ловит катастрофы): окно 5–10 мин, порог BR 14–20×.
• Медленный алерт (ловит ползучие деградации): окно 1–6 ч, порог BR 2–4×.
• Условия комбинировать: сработал быстрый или медленный — пейджинг on-call.
• Уровни: пейджер для пользовательских SLO, тикеты/уведомления для серых деградаций внутренних SLI.

6) Наблюдаемость и источники истины

Логи — диагностика причин.
Метрики — числовые SLI (успех/ошибка, перцентили латентности, доли, счетчики).
Трейсы — сквозные пути, локализация “горячих” сегментов.
Синтетика — активные пробы с периферии (region-aware).
Реальные события — RUM/телеметрия клиентов, бизнес-метрики (конверсия, успешные платежи).

Требования: единая картина в дашбордах релизов и инцидентов, аннотации “версия/канарейка/флаг”.

7) Проектирование SLO: пошаговый шаблон

1. Опишите критичный путь (например, “депозит картой”).
2. Определите SLI: успех/ошибка, порог латентности, полнота.
3. Согласуйте SLO: цель на 28 дней + исключения (запланированные окна).
4. Свяжите с SLA: юридическое обязательство ≦ фактический SLO.
5. Назначьте владельца (service owner), RACI и канал алертов.
6. Определите алерт-политики (двухоконные BR) и авто-откаты.
7. Внедрите отчетность: еженедельные обзоры бюджета, пост-инцидентные ревью.
8. Пересматривайте SLO ежеквартально (изменение нагрузки/архитектуры).

8) Примеры SLO (шаблоны)

• Доступность: `≥ 99.95%` (28д, исключая объявленные окна ≤ 30 мин/мес).
• Латентность: `≥ 99%` ответов `≤ 400 мс`.
• Успех бизнес-операций: `≥ 98.5%` успешных авторизаций (fraud-фильтры учтены).

• Латентность: `≥ 99%` запросов `≤ 300 мс`.
• Актуальность кэша: `≤ 5 мин` отставание в 99% случаев.

• Доставка: `≥ 99.9%` в течение `≤ 60 с` (end-to-end, с ретраями).
• Потеря: `≤ 0.01%` сообщений (идемпотентность/дедупликация включены).

9) Мульти-регион и мульти-тенант

SLO “по когортам”: страна, платежный провайдер, VIP-сегмент, устройство.
Локальные SLO на краю: метрики из ближайших к пользователю точек (edge/PoP).
Агрегирование: общий SLO не должен скрывать провалы по важным когортам.
Переключение провайдеров: автоматические fallback-маршруты на уровне SLO-гейтов.

10) Дашборды и отчетность

Релизный дашборд: версия, канарейка (% трафика), SLI (успех/латентность), BR, аннотации флагов.
Операционный дашборд: burn-down бюджета по дням, топ-инциденты, MTTR, проблемные когорты.
Еженедельные отчеты: остаток бюджета, тренды BR, технический долг (узкие места), план улучшений.

11) Процессы: инциденты, RCA и улучшения

Инцидент-менеджмент: алерт → оценка BR → масштаб канареек/флагов → откат/фикс.
RCA (корневая причина): факты/таймлайн/гипотезы/исправления/проверка эффекта по SLI.
Извлеченные уроки: некарательные пост-мортемы, обязательные action items с владельцами и сроками.
Замыкание цикла: изменения в тестах, фича-флагах, лимитах, кэшах, ретраях, квотах.

12) Комплаенс и аудит

SLO/SLI как артефакты контроля (policy-as-code, неизменяемые логи).
Привязка к требованиям (например, доступность платежных операций).
Доказательства: протоколы алертов, отчеты по бюджету, журналы релизов/откатов.

13) Частые ошибки и как их избежать

“99.99% или смерть”: недостижимые цели → постоянный алерт-шум. Выбирать реалистичные SLO.
Глобальные средние скрывают локальные провалы → вводить когорты.
Метрики не e2e: высокие SLO при фактической деградации на клиенте → добавлять RUM/синтетику.
Алерты по одному порогу → переходить на двухоконные burn rate.
Нет связи с изменениями → релизы не аннотированы, нет авто-отката.

14) Мини-чек-лист внедрения

• Описаны критичные пути и их SLI/SLO.
• Задано окно наблюдения и исключения.
• Настроены двухоконные BR-алерты (быстрые и медленные).
• Дашборды релизов и операций с аннотациями версий/флагов.
• Политика error budget влияет на релизы.
• Регулярные обзоры бюджета и пост-инцидентные RCA.
• Документация и владельцы показателей.

15) Пример расчета (конкретика)

SLO доступности API: 99.9% за 28 дней → бюджет = 0.1%.
За 7 дней накопилось 0.06% ошибок → израсходовано 60% недельного бюджета.
На коротком окне 15 мин наблюдается 2% ошибок. Допустимо на этом окне: `0.1% × (15 мин / 40320 мин) ≈ 0.000037%`.
Burn Rate ≫ 1 (десятки ×) → срабатывает быстрый пейджер, канарейка откатывается до 1%, включается фича-флаг “degrade-payments-UX”, запускается RCA.

16) Итог

Мониторинг SLA/SLO — это не только цифры в отчете, а механизм управления риском изменений и качеством сервиса. Правильные SLI, реалистичные SLO, управление error budget, двухоконные burn-rate алерты и e2e-наблюдаемость превращают метрики в рабочие решения: быстрее выпускать ценность и держать пользовательский опыт предсказуемым.