Alert Fatigue Management

Я регулярно вижу команды, у которых в Prometheus живёт под две сотни активных алертов, а доля тех, по которым дежурный реально что-то делает, не дотягивает и до трети. Это симптом, не норма. Alert fatigue — операционная проблема, которую можно измерить (сколько алертов в неделю, какая доля из них полезна, сколько проходит до подтверждения) и можно лечить (регулярный разбор, группировка и подавление в Alertmanager, автоматические реакции на повторяющееся). Лист — про это лечение. Соседний к SLI-based Alerting под L1 Observability; вместе с On-Call Rotation они образуют тройку: спроектировать алерты, измерить и сократить шум, выжить на дежурстве.

Что должен уметь

Главный навык на уровне L4 — измерять качество алертов, а не «у нас вроде нормально». Доля полезных срабатываний (actionable rate), число алертов в неделю, время до подтверждения по p50 и p99, MTTR по типам алертов — базовый набор. Без чисел не выйдет ни назначить цель, ни заметить ухудшение, ни объяснить руководителю, почему на разгребание алертов надо потратить спринт вместо фич.

Отличает алерт, требующий немедленного действия, от информационного; понимает, что шумная смена — операционная проблема, а не норма.
После своей смены отчитывается о качестве: по каким алертам действительно что-то делал, какие оказались ложными, какие потянули за собой ненужную эскалацию.

Измеряет качество алертов своего сервиса: сколько прилетает в неделю, какая доля полезна, время до подтверждения по p50 и p99, MTTR по типам.
Убирает или заглушает алерты без runbook и те, что регулярно срабатывают вхолостую, — с явным владельцем и сроком «либо чиним корневую причину, либо удаляем».

Заводит в команде регулярный разбор алертов: раз в неделю или в две, с понятной повесткой и решениями на выходе; разбор связан с SLO-ревью и постмортемами.
Реализует шумоподавление на уровне Alertmanager: group_by для склейки родственных срабатываний, правила inhibition (упал A — не пейджим про зависимые B, C и D), заглушки для известных проблем с обязательным сроком жизни.
Связывает повторяющиеся алерты с автоматизацией: если алерт срабатывает регулярно, а runbook к нему известен, это кандидат на автоматическую реакцию.

L6+

Внедряет гигиену алертов на уровне организации: сквозные метрики по командам (сколько прилетает одному дежурному, индекс усталости, связь с текучкой), SLO для самого алертинга — «не меньше 95% срабатываний полезны».
Балансирует чувствительность и шум: где допустимо ловить меньше ради тишины, а где чувствительность неприкосновенна, как в платежах.

Материалы

Книги

Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 10 «Practical Alerting». Рекомендую: алертинг по временным рядам, white-box против black-box, порог с выдержкой по времени. «May the queries flow, and the pager stay silent» — традиционное SRE-благословение.
Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 5 «Alerting on SLOs». Multi-window multi-burn-rate как способ снизить долю ложных срабатываний.

Статьи

Prometheus Alertmanager — Configuration. Рекомендую прочитать целиком: группировка, подавление и заглушки — три основных механизма управления шумом, и почти всё остальное надстраивается над ними.
Fred Hebert / Honeycomb — How We Manage Incident Response. Рекомендую: про то, во что реально обходится реагирование в небольшой команде — инженерное время, переключения контекста, износ дежурных; отсюда же следует, что гигиена алертов окупается не «качеством мониторинга», а сохранёнными людьми.

Инструменты

Prometheus Alertmanager — рекомендую разобраться со всеми четырьмя встроенными механизмами: группировка (склеить родственные срабатывания в одно сообщение), подавление (A гасит B по меткам), заглушки с обязательным сроком для известных проблем и дерево маршрутизации по severity: critical идёт на пейджер, warning — в тикеты.
PagerDuty Insights — встроенные метрики качества алертинга: сколько прилетело одному дежурному, время до подтверждения, доля полезных, самые частые источники шума. Похожая аналитика была в Opsgenie, но его считать вариантом уже нельзя: Atlassian прекратила продажи в 2025 и отключает продукт в апреле 2027. По моим наблюдениям, такие дашборды чаще остаются неоткрытыми, чем используются, — стоит хотя бы раз в квартал в них заглядывать.
Свои дашборды качества алертов в Grafana: доля полезных по сервисам, тренд числа алертов по неделям, распределение времени до подтверждения, топ самых шумных. Рекомендую заводить их, когда готовая аналитика платформы не ложится на то, что нужно смотреть: без такого экрана остаётся оценка на глаз.
Оркестрация автоматических реакций — AWS Lambda, Argo Workflows, StackStorm. Среда, в которой живёт автоматика по повторяющимся алертам. Рекомендую брать то, что в компании уже развёрнуто: выбирают такую среду обычно не под алерты.

Best practices

Начинать приходится с измерения. Скучно, зато без чисел улучшения невозможны в принципе: нечего поставить как цель, не видно ухудшения, нечем объяснить руководителю, почему на разгребание алертов надо потратить спринт вместо фич. Минимум — доля полезных по сервисам и тренд числа алертов в неделю, разбор раз в месяц. Что измеряют, то и чинят.

Алерт без runbook либо получает runbook, либо удаляется. Третьего состояния нет. Через полгода такой алерт либо забыт всеми, либо пейджит ночью, и инженер тратит полчаса просто на то, чтобы понять, что это вообще было и стоит ли реагировать. На разборе каждый алерт уходит в одну из двух корзин: runbook плюс владелец — или срок, к которому его заглушат или удалят.

Группировка и подавление в распределённой системе — не тюнинг, а условие выживания. Один инцидент превращается в полсотни оповещений, потому что задымил каждый сервис, и первые пятнадцать минут уходят на разгребание шума вместо диагностики. group_by в Alertmanager собирает родственное в один пакет. Правило inhibition — упала база, не пейджим про ошибки подключения во всех сервисах — сводит те же полсотни сообщений к одному-двум диагностическим.

Доля полезных срабатываний от 95% — реалистичная цель для зрелого алертинга. Я регулярно вижу, как половину ложных принимают за норму. На таком уровне инженер перестаёт верить алертам, подтверждает их на автомате и пропускает реальные инциденты. Каждое бесполезное срабатывание — это либо ложная тревога (лечится тюнингом), либо информационное сообщение (переезжает в тикеты), либо известная неисправленная болячка. 95% — не «недостижимый идеал», а планка, под которую вырастают постепенно.

Разбор алертов раз в неделю или в две, а не «после инцидента подумаем». По моим наблюдениям, команды, которые обсуждают алерты только после крупного инцидента, доходят до выгорания первыми. К этому моменту дежурные уже на грани, и качество реакции падает вместе с ними. Нормальный ритм — раз в неделю или в две: что прилетело, что было вхолостую, что требует починки, что удаляем. Хоть куском ретро, хоть отдельным получасом.

Гистерезис и сглаживание живут в самом пороге, иначе получается бегущий пейджер. Алерт срабатывает каждые пять минут, потому что система ходит туда-обратно около границы, и инженер получает дюжину сообщений в час об одном и том же событии, которое само себя чинит между срабатываниями. Лечится тремя стандартными приёмами: гистерезис — загорается на A%, тушится на A-N%; сглаживание — минимальный интервал устойчивого состояния перед срабатыванием; плюс for: 5m в правиле Prometheus.

Повторяющийся алерт с известным runbook — кандидат на автоматизацию, а не на ротацию. Он срабатывает пять раз в неделю, инженер выполняет три шага из runbook, за год набегают сотни часов на «нажать кнопку». Дальше просто: реакция уезжает в Lambda, оператор или workflow, а на разборе алерт исключается из ротации после проверки. Из всего, что я наблюдал, это самый быстрый способ убрать toil.

Граница у всего этого простая. Практика начинается там, где алертов больше, чем помещается в голову: в команде из трёх человек с двумя десятками правил еженедельный разбор — лишний ритуал, дешевле чинить по факту, а весь набор метрик качества сведётся к одной строчке в ретро. Не спасает она и в обратную сторону. Если алертов сотни, а дежурство фиктивное и на пейджер никто не смотрит, чинить надо дежурство, а не алерты.

Связанные листья

SLI-based Alerting — как алерты проектируются. Без правильного дизайна (multi-window burn rate, симптомы вместо причин) даже идеальная гигиена не спасёт.
On-Call Rotation — где усталость проявляется; гигиена алертов — основной инструмент защиты дежурства. Этот лист и On-Call Rotation — пара.
Runbooks — каждый алерт ведёт к runbook; качество runbook определяет, можно ли по алерту вообще что-то сделать.
Toil Tracking — усталость от алертов — крупный класс toil; учёт ловит сигнал «слишком много ручных реакций, пора автоматизировать».
Postmortem Culture — шумная смена сама по себе кандидат на постмортем: это системная проблема, а не норма.
SLO Engineering — SLO для алертинга как мета-практика: «не меньше 95% срабатываний полезны».
Symptom vs Cause Alerting — гигиена начинается с правильного выбора того, на что вообще алертить: алерт на симптом снижает долю ложных в принципе, а не задним числом.

Открытые вопросы

Самая большая дыра — Auto-Remediation Patterns (TBD): детальные паттерны на Lambda, операторе Kubernetes и Argo Workflows есть, а внятного ответа, как автоматизировать постепенно и безопасно, у меня нет.

Ещё два долга поменьше. Alert Routing & Escalation Patterns — детализация деревьев маршрутизации в Alertmanager и уровней критичности (SHEDDABLE и CRITICAL_PLUS из SRE Book, глава 21). И Maintenance Window / Silencing Practices: как делать плановые заглушки без потери видимости и не копить вечные заглушки без срока.