SLO-based alerting: как сделать не хуже, чем было

В прошлом посте про алерты я сказал про SLO-based alerting. Время раскрыть что это такое и как с этим жить.
Когда люди «внедряют SLO», часто всё заканчивается тем, что к старым алертам просто добавляют ещё пару дашбордов и одну-две новых нотификации. В итоге шум остался, SLO «есть», но на них никто не смотрит.

Антипаттерны SLO-алертинга

SLO как ещё один threshold на метрику
«Если за 10 минут ошибок ≥ порога - шлём алерт». Формально это SLO, по факту - тот же метрик-алерт, только сложнее. Любой всплеск = пейджер, даже если по error budget мы вообще не страдаем.

Оповещаем «по симптомам», а не по SLO
Алерты идут по CPU, памяти, очередям, отдельным эндпоинтам - но не по тому, что реально описано в SLO. В итоге on-call живёт в мире инфраструктуры, а не пользовательского опыта.

Один burn rate на все случаи жизни
Одна граница «если burn rate > X - буди» не различает: «горит всё, срочно просыпайся» и «медленно проедаем бюджет, можно спокойно посмотреть завтра».

SLO-алерты дублируют старые
Вместо того чтобы выключать/переформулировать старые, поверх них навешивают новые. Команда злится на SLO, а не на то, что их не связали с процессами.

Паттерны, которые работают лучше

Многооконный burn rate (multi-window, multi-burn)
Идея из Google SRE:
- короткое «быстро горим» окно (минуты–часы) → пейджер;
- длинное «медленно утекаем» окно (сутки–недели) → тикет/задача.
Так SLO-алерты и про пожар, и про «мы системно ухудшаемся».

Пейджим только по угрозе error budget
Не по каждому 5xx, а когда текущее поведение реально угрожает выбить нас из SLO за период. Всё остальное - в тикеты, отчёты, дашборды, но не к on-call ночью.

SLO → правила игры, а не просто график
Есть SLO → есть политика: что делаем, если бюджет выжгли (freeze релизов, приоритет на фиксы, ограничения экспериментов). Иначе алерт «SLO нарушен» - просто ещё один красный прямоугольник.

Генерация правил, а не ручной зоопарк
Инструменты вроде Sloth помогают: описал SLO в YAML → получил Prometheus recording rules, burn-rate алерты и дашборды. Не нужно каждый раз изобретать запросы. Ребята из коммунити ALLSLO на этом месте вообще запилили свой форк под свои требования - и это нормальный путь, когда SLO становятся частью платформы, а не «ручной магией». Аналогично сделали ВсеИнструменты в лице Димы @r3code - их форк. А Кир @silabeer в ВК сделал свой инструмент.

Постепенное внедрение, а не «SLO везде»
1) Берём 1-2 критичных сервиса.
2) Для каждого - один SLO (например, 99.9% успешных запросов за 30 дней).
3) Описываем его в Sloth (или аналогичный инструмент), настраиваем multi-window burn rate, выводим на дашборд.
4) Проживаем пару инцидентов, учимся принимать решения по бюджету.
5) Только потом разматываем это на остальные сервисы.


В итоге «SLO-based alerting» - это не про ещё один вид алертов, а про смену логики: мы пейджим только тогда, когда страдают пользователи и реальный error budget, и делаем это по понятным правилам. Всё остальное - фон.