Что такое алертная усталость (alert fatigue)

Алертная усталость — состояние, когда инженеры получают слишком много оповещений (часто шумных или ложных), в результате чего они начинают игнорировать или медленно реагировать на важные тревоги. Происходит снижение внимания к алертам и рост времени отклика и восстановления — именно то, чего мониторинг должен предотвращать.

Почему это происходит (коренные причины)

• Шумные и низкоприоритетные алерты — слишком много алертов на transient-пик или на каждый падший хост.

• Плохая классификация и маршрутизация — неверно настроенные уровни severity и неправильные получатели.

• Высокая кардинальность метрик — алерты на уровне отдельных user_id/instance приводят к лавине сигналов.

• Отсутствие runbook / инструкций — алерт без четкого шага «что делать» тормозит реакцию.

• Частые false positives — ошибки в логике алертов или недостаточное дебаунсирование.

• Человеческий фактор — перегруженность on-call, нет восстановления после ночных вызовов.

Последствия

• Игнорирование реальных проблем;

• Увеличение MTTA/MTTR;

• Рост стресса и выгорание on-call;

• Задержки в бизнес-процессах и ухудшение SLO.

Как избегать — практические меры

1) Делать «умные» алерты (качество, а не количество)

• Алертить на симптомы, а не на первичные сигналы (например: увеличился p95 latency или error rate, а не каждый 5xx в логе).

• Использовать перцентили для latency (p95/p99), а не mean.

• Применять for/debounce (Prometheus for: 5m) — триггер только если проблема держится.

• Префильтрация: аггрегируйте по сервису/кластерам, а не по хостам.

2) SLO-ориентированный подход

• Связать алерты с SLO/error budget: warn → burn-rate → critical. Это уменьшает шум и делает алерты бизнес-контекстными.

3) Группировка, дедупликация и suppression

• Группируйте алерты в Alertmanager/оповещалках; подавляйте повторные/коррелированные сигналы.

• Используйте windows для maintenance/деплоев (suppression during deploy).

4) Разграничение каналов и приоритетов

• Разделяйте paging (SMS/PagerDuty) для критичных P1 и chat/email для низкоприоритетных уведомлений.

• Чёткие правила эскалации и SLA на ACK/response.

5) Runbooks и actionable alerts

• В каждом алерте ссылка на runbook/плейбук с конкретными шагами (и командами).

• Включайте expected outputs и quick checks прямо в текст алерта.

6) Контроль кардинальности и sampling

• Не добавляйте user_id/session_id как label в метриках, используйте их только в логах.

• Для очень «шумных» источников применяйте sampling или rate-limits.

7) Автоматизация и self-healing

• Автоматические mitigations для известных проблем (healthcheck → restart pod / scale out).

• Только проверенные автоспасатели; логируйте и оповещайте об автоматических действиях.

8) Организационные меры

• Ограничение подрядных дежурств, компенсация, recovery time после наводящих смен.

• Регулярный обзор алертов: «alert triage» — удалить устаревшие/неэффективные правила.

• Fire-drills и тренинги on-call с реальными runbooks.

Метрики и мониторинг «мониторинга»

• Pages per on-call per week; alerts per minute; % false positives; time-to-ack; MTTR; % alerts with runbook. Следите за трендами и ставьте целевые значения (например, стремиться к снижению шумных алертов на 50% в квартал).

Пример хорошего правила (Prometheus)

\- alert: HighErrorRate
expr: |
sum(rate(http_requests_total{job="api",status=~"5.."}\[5m\]))
/
sum(rate(http_requests_total{job="api"}\[5m\])) > 0.01
for: 10m
labels:
severity: page
annotations:
summary: "API 5xx rate >1% for 10m"
runbook: "https://wiki/runbooks/api-5xx"

Итоговая логика действий при настройке алертов

1. Сформулируйте цель алерта (что вы хотите увидеть).

2. Сделайте метрики и выражения на уровне симптома.

3. Добавьте debounce и grouping.

4. Привяжите runbook и severity.

5. Мониторьте эффективность и регулярно ревью.

Снижение alert fatigue — это непрерывный процесс: меньше шумных триггеров, больше контекста и автоматизации, и забота об инженерах на on-call.