5 антипаттернов алертов

На новом месте работы я заметил, что алерты сливаются в общий чат и это жутко неудобно. Первое же, что я сделал - отключил уведомления :) Значит, что-то явно не так.
Решил собрать антипаттерны и рассказать об этом.

Алертов много, а пользы мало - значит, в системе есть вот это:

1. Алертит всё подряд
Проблема: Люди настраивают алерт на каждый возможный сценарий. Результат: 2000+ алертов в неделю, но только 3% требуют действия.
Лучшая практика: Google SRE рекомендуют 4 Golden Signals:
• Latency - как быстро отвечает система
• Traffic - сколько запросов приходит
• Errors - сколько ошибок
• Saturation - как насыщена система (CPU, память, диск)
Этого хватает на 80% проблем. Остальное - noise.
Действие: Перепроверьте все алерты. Если алерт не про эти 4 сигнала - удалите или переделайте.

2. Нет severity
Проблема: Все алерты одинаковые. Получаешь 50 нотификаций в час и не знаешь, что критично, а что нет.
Лучшая практика: Четыре уровня:
DISASTER - Сервис упал, есть реальные users affected
→ ЗВОНОК СЕЙЧАС, пока разговариваешь
CRITICAL - Сервис работает, но деградация
→ Разбери сегодня, но можно за час
HIGH - Тренд плохой, может стать проблемой
→ Разбери завтра, добавь в спринт
WARNING - Отслеживаем, но пока OK
→ Смотри в дашборд, не звони
Результат в VK: 98% Critical алертов получают реакцию в первые минуты.

3. Нет runbook
Проблема: Alert сработал в 3 часа ночи. On-call инженер смотрит на название алерта и не понимает, что делать. Результат: 1–2 часа на поиск информации или escalation разработчикам.
Лучшая практика: Каждый Disaster/Critical алерт ДОЛЖЕН иметь runbook.
Что включить в runbook:
• Что произошло - что именно означает этот алерт (на человеческом языке, не техно-жаргон)
• Что проверить - какие логи смотреть, какие метрики
• Как чинить - пошаговые шаги для on-call инженера
• Время - runbook должен решаться за 10 минут без escalation
Правило: Если алерт не решается за 10 минут и в нём нет инструкции - это не алерт, это шум.
LinkedIn пример: On-call получал 50 страниц в неделю из-за плохо структурированных runbook. После переделки - спит по ночам.

4. Нет владельца
Проблема: Алерт срабатывает, но никто не знает, кто за него отвечает. Ticket гуляет по сотрудникам. Никто не знает, чинить ли это или это "expected behavior".
"Алерт без ответственного - это не алерт."
Лучшая практика: Каждый алерт должен иметь владельца (может быть team).
Владелец отвечает за:
• Обновление runbook, когда меняется сервис
• Мониторинг False Positive rate этого алерта
• Удаление/переделку, если алерт не помогает
Мотивация простая: если алерт плохой - его будут будить ночью.

5. Нет SLO
Проблема: Алерты на static thresholds:
• "CPU > 90%" - alert
• "Memory > 85%" - alert
• "Latency > 500ms" - alert
Но 95% времени эти метрики выше threshold, и ничего не ломается. Результат: игнор.
Лучшая практика: Переходи на SLO-based alerting (error budgets + multi-burn-rate).
Что такое SLO-based alerting:
Вместо: "CPU > 90%"
На: "Как быстро горит ваш error budget?"
Примеры:
• SLO: 99,9% uptime (error budget: 43 минуты в месяц)
• Если за день потратили 20 минут budget - спокойно, впереди ещё 23
• Если за день потратили 40 минут - WARNING, тренд плохой
• Если за час потратили 10 минут - CRITICAL, горит со скоростью 240 минут в день!
Multi-burn-rate alerts:
• 14.4x burn rate (будет истощен через 2 дня) = PAGE NOW
• 6x burn rate (будет истощен через 5 дней) = CREATE TICKET
• 3x burn rate (будет истощен через 10 дней) = MONITOR
• 1x burn rate (планируется) = смотри дашборд, не алертим
Результат: SLO-driven approach может снизить alert noise на 80%, но catch real issues ЛУЧШЕ, потому что alert срабатывает только когда реально горит.

#sre #observability #alerts #slo #sla #sli