Что делать при нарушении SLO?

Реакция на нарушение SLO - это одна из ключевых проблем в SRE. Мы следим за SLO, и в один прекрасный момент SLI проседает ниже SLO, что делать? Алертить? Сразу создавать инцидент?

Основная логика: SLO ≠ Alert

SLO (Service Level Objective) — это долгосрочная цель по качеству, а не мгновенный триггер для аварийного реагирования.

Если мы настроим алертинг так, чтобы он срабатывал каждый раз, когда SLI проседает ниже SLO, мы получим ад из алертов и в итоге на них все забьют.

Когда алертить? → правило "Error Budget Burn Rate"

Основной механизм алертинга в SRE строится не на мгновенном значении SLI (которое через 0,0001 секунды может вернуться в "зеленую" зону), а на скорости расходования бюджета ошибок (Error Budget).

Error Budget = 100% - SLO (за определенный период, называется "временнОе окно").

Пример: SLO = 99,9% доступности в месяц → Error Budget = 0,1% простоя (или ~43 минуты в месяц).

А если еще реализовать Observability 2.0, то даже можно делать вот так :)

FROM payment_wide
WHERE status='error'
GROUP BY time(1m)
|> error_budget_burn_rate(slo_target=99.9, window=28d)
|> alert_if(burn_rate > 14.4)

Запрос выполняется над тем же wide event, что и отладка, никаких отдельных метрик. Алерт срабатывает за 5 минут до того, как SLO уйдёт в ноль, а не когда уже всё горит.

Два основных типа алертов:

1. Алерт на скорость сжигания (Alert on Burn Rate) - основной рабочий алерт

Срабатывает, когда бюджет ошибок расходуется слишком быстро.

Классическая формула: - Быстрый алерт (Short Window): "Если за последние 1 час мы израсходовали более 10% месячного бюджета ошибок" → срабатывает быстро, для срочных проблем. - Медленный алерт (Long Window): "Если за последние 24 часа мы израсходовали более 2% месячного бюджета ошибок" → ловит медленные деградации.

Система "прощает" кратковременные мелкие проседания, но реагирует на серьезные или длительные проблемы.

2. Алерт на исчерпание (Alert on Near Exhaustion)

Срабатывает, когда бюджет ошибок почти исчерпан (например, осталось <5% на месяц). Это предупреждение для команды продукта, что нужно быть осторожнее с развертываниями.

Когда создавать инцидент?

Инцидент создается ТОЛЬКО при выполнении ДВУХ условий:

Условие 1: Есть ПОЛЬЗОВАТЕЛЬСКОЕ ВОЗДЕЙСТВИЕ (User Impact)

  • Пользователи здесь и сейчас не могут получить ожидаемый сервис

Условие 2: Требуется НЕМЕДЛЕННОЕ ВМЕШАТЕЛЬСТВО ЧЕЛОВЕКА

  • Автоматические механизмы восстановления не сработали/не существуют
  • Проблема требует скоординированных действий команды для устранения

Алгоритм принятия решений на практике

Сценарий 1: Кратковременное проседание SLI ниже SLO (например, 15 секунд 95% доступности при SLO 99%)

Что делать: → НИЧЕГО (только мониторить)
Почему: 
- Budget burn rate не превысил порог
- Нет значимого пользовательского воздействия
- Может быть статистическим шумом

Сценарий 2: Длительное проседание SLI (например, 10 минут 98% доступности при SLO 99,9%)

1. Проверить burn rate → если превышен порог, получаем АЛЕРТ
2. Оценить пользовательское воздействие:
   - Если пользователи затронуты → ИНЦИДЕНТ
   - Если воздействие минимально → запланировать задачу на анализ

Сценарий 3: Критическое проседание (например, 5 минут 0% доступности)

1. Burn rate зашкаливает → АЛЕРТ срочный
2. Массовое пользовательское воздействие → ИНЦИДЕНТ немедленно
3. Запускается процесс управления инцидентом

Конкретные примеры из практики

Пример для SLO доступности 99,9%:

Ситуация Алерт? Инцидент?
SLI на 0,1% ниже SLO 5 минут Нет Нет
SLI на 5% ниже SLO 10 минут Да (burn rate) Нет (если нет user impact)
SLI на 50% ниже SLO 2 минуты Да (fast burn) Да (если user impact есть)
Burn rate > 10%/час Всегда Да Только если подтвержден user impact
Error budget исчерпан на 80% Да (warning) Нет (планирование)

Практическая иерархия реагирования

  1. Автоматическое восстановление (auto-scaling, перезапуск pods, failover) → Никаких алертов, если сработало

  2. Предупреждение (Warning Alert) → Burn rate повышен, но не критично → Дежурный мониторит в рабочем режиме

  3. Критический алерт (Critical Alert) → Burn rate превысил быстрый порог → Дежурный должен немедленно начать расследование

  4. Инцидент (Incident) → Критический алерт + подтвержденный импакт на пользователя → Запускаются все процедуры управления инцидентом

Что делать, когда видите проседание SLI ниже SLO?

Пошаговый алгоритм для инженера/дежурного:

  1. Оценить масштаб и длительность:
  2. Насколько ниже SLO? (0,01% или 10%?)

  3. Как долго продолжается? (5 секунд или 5 часов?)

  4. Проверить burn rate:

  5. Сработал ли алерт по burn rate?

  6. Если нет → продолжить мониторинг

  7. Оценить пользовательское воздействие:

  8. Есть ли жалобы пользователей?
  9. Затронуты ли ключевые функции?

  10. Каков процент затронутых пользователей?

  11. Проверить автоматическое восстановление:

  12. Сработали ли авто-механизмы?

  13. Восстанавливается ли ситуация сама?

  14. Принять решение:

  15. Нет воздействия + нет алерта → мониторить, запланировать анализ
  16. Есть алерт, но нет критического воздействия → начать расследование как приоритетную задачу
  17. Есть алерт + есть воздействие → объявить инцидент

Культурные аспекты SLO в отношении инцидентов

  • SLO — это не SLA с штрафами. Его превышение — это не "провал", а сигнал для принятия каких-то инженерных или продуктовых решений.
  • Инцидент по burn rate без пользовательского воздействия это нормально! Это значит, команда проактивно ловит проблему ДО того, как пользователи пострадают.

Главное правило: Алерты должны быть редкими, релевантными и требующими действия. Инциденты должны быть объявлены только когда пользователи начинают реально "страдать" и требуются какие-то скоординированные усилия команд.

И очень важно!!! - SLO должно быть больше SLA!!! - В компании должен быть "Регламент реагирования на нарушения SLO (SLO Breach Response Policy)"