Alerting

Хороший alert требует действия

Alert должен сообщать о состоянии, которое требует внимания или конкретного действия. Если у получателя нет ни полномочий, ни сценария реакции, сигнал становится шумом.

Полезное оповещение отвечает:

• что случилось и где;
• какой пользовательский сценарий затронут;
• когда началось и продолжается ли сейчас;
• насколько это срочно;
• какие данные подтверждают сигнал;
• кто отвечает и какой runbook выполнить первым.

Симптомы и причины

Для дежурного важнее симптом: пользователи не могут оформить заказ, p95 превысил цель, бюджет ошибок быстро расходуется. CPU, память и отдельная строка лога чаще помогают расследовать причину, но не всегда требуют немедленного звонка.

Связь «пользовательский alert → диагностический dashboard → логи/трассы» полезнее набора независимых уведомлений от каждого ресурса.

Способы срабатывания

• Порог — значение выше или ниже заданного уровня в течение заданного времени.
• Отсутствие данных — метрика или heartbeat исчезли; отсутствие данных не считается успехом.
• SLO / burn rate — бюджет ошибок расходуется слишком быстро на одном или нескольких окнах.
• Изменение тренда — новая ошибка, резкий рост частоты или задержки.
• Anomaly detection — отклонение от ожидаемой модели поведения; требует проверки влияния и контекста.

Несколько окон помогают различать быстрый критический всплеск и медленную устойчивую деградацию. Правила выбирают по SLO и бюджету ошибок, а не копируют универсальные проценты.

Severity и маршрутизация

Уровень	Условие	Канал
Critical	Массовая деградация критичного сценария, нужна немедленная реакция	Дежурный, звонок/pager
Warning	Ограниченное влияние или приближение риска	Рабочий канал команды
Info	Наблюдение без немедленного действия	Dashboard, журнал, digest

Уровень определяет не только текст, но и маршрут, ожидания по acknowledgement и эскалацию. Подробнее — в on-call.

Дедупликация и группировка

Один отказ базы может вызвать сотни алертов от зависимых сервисов. Полезны:

• grouping по сервису, окружению и общей причине;
• deduplication одинаковых событий;
• suppression зависимых сигналов при подтверждённом корневом инциденте;
• flap prevention через «for» и recovery conditions;
• maintenance windows с владельцем и сроком окончания.

Silence не должен быть бессрочным способом скрыть проблему.

Runbook и проверка качества

Runbook начинается с проверки влияния и безопасного ограничения последствий, затем ведёт к данным и типовым действиям. Он не заменяет разбор нового инцидента, но устраняет необходимость вспоминать базовые команды ночью.

Качество alerting периодически оценивают:

• доля actionable сигналов и ложных срабатываний;
• время acknowledgement и восстановления;
• число повторов и объединённых инцидентов;
• alerts без владельца или runbook;
• пропущенные реальные деградации.

Шумное правило исправляют, а не приучают команду игнорировать канал.

Связанные инструменты

• Prometheus — recording и alerting rules.
• Grafana — правила и маршрутизация оповещений.
• Better Stack — телеметрия, grouping и on-call.
• PagerDuty — дежурства и эскалации.

Связанные материалы

• Бюджеты ошибок — burn rate и политика действий.
• Управление инцидентами — работа после объявления инцидента.
• Uptime monitoring — подтверждение внешних сбоев.

Материалы и источники

• Google SRE: Practical Alerting — симптомы, правила и actionable оповещения.
• Google SRE Workbook: Alerting on SLOs — burn rate и многовоконные правила.
• Better Stack: Incident management — grouping, workflows и эскалации.