Как настроить алерты, чтобы не было alert fatigue

Alert fatigue — это состояние, при котором команда получает слишком много уведомлений и постепенно перестает на них реагировать с должным вниманием. В такой момент алерты формально работают, но как инструмент раннего обнаружения инцидентов уже почти бесполезны.

Парадокс в том, что alert fatigue возникает не из-за отсутствия мониторинга, а из-за его плохой настройки. Когда сигналов слишком много, важные инциденты тонут в шуме.

Что такое alert fatigue простыми словами

Если команда за день получает десятки однотипных уведомлений вроде:

«latency выше порога»;
«проверка не прошла»;
«сертификат скоро истечет»;
«CPU выше 80%»;

то через какое-то время люди начинают:

отключать уведомления;
читать их с задержкой;
считать большинство алертов неважными;
откладывать реакцию «на потом».

Именно это и есть alert fatigue.

Почему alert fatigue опасен

Главная проблема в том, что он маскирует действительно критичные события.

Последствия обычно такие:

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

Если после каждого сигнала никто не понимает, нужно ли что-то делать, значит конфигурация требует пересмотра.

Из-за чего возникает alert fatigue

Слишком много низкоценных алертов. Например:
уведомления по каждому краткому всплеску latency;
алерт на одну неудачную проверку;
отдельные сигналы по симптомам, а не по реальному влиянию на пользователей.
Нет разделения по критичности. Если истекающий через 14 дней SSL-сертификат и полная недоступность сайта приходят одинаково и в один канал, система быстро теряет смысл.
Дубликаты уведомлений. Один и тот же инцидент может породить:
несколько HTTP-алертов;
алерты по latency;
алерты по ошибкам 5xx;
сообщения от инфраструктурных метрик.

Без дедупликации команда получает лавину похожих сигналов.

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

Как понять, что у команды уже есть alert fatigue

Признаки обычно видны довольно быстро:

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

Если алертов много, а пользы мало, проблема уже есть.

Как настроить алерты без alert fatigue

Оставляйте только actionable alerts. Каждый алерт должен вести к конкретному действию:
проверить доступность;
переключить трафик;
откатить релиз;
связаться с провайдером;
эскалировать инцидент.

Если после уведомления команда не понимает, что делать, такой алерт стоит убрать, ослабить или перевести в отчет.

Разделите сигналы по уровням критичности. Базовая схема может быть такой:

Уровень	Что означает	Канал
`P1`	Полная недоступность критичного сервиса	немедленно: Pager/Telegram/Slack
`P2`	Сильная деградация, рост ошибок, проблемы у части пользователей	рабочие каналы + дежурный
`P3`	Предупреждения, не срочные задачи, SSL, рост ресурсов	email, backlog, отчеты

Не every event должен быть page-worthy.

Используйте retries и подтверждение инцидента. Одна ошибка проверки не должна будить команду ночью. Подтверждайте сбой повторными проверками или сигналами из нескольких локаций. Здесь полезно прочитать статью что такое false positive в мониторинге и как его уменьшить.
Дедуплицируйте уведомления. Если один корневой инцидент уже открыт, не нужно создавать еще 5-10 похожих уведомлений о его симптомах.

Полезный принцип:

один инцидент;
один основной канал эскалации;
обновления внутри существующего треда или карточки.
Стройте алерты вокруг пользовательского влияния. Лучшие алерты обычно отвечают не на вопрос «что-то изменилось?», а на вопрос «пострадали ли пользователи?».

Например, сигнал ценнее, если он означает:

сайт недоступен;
API не отвечает;
checkout сломан;
логин не работает;
резко выросла доля 5xx.

Алерт «CPU = 85%» сам по себе часто менее полезен, чем кажется.

Разведите оперативные алерты и информационные уведомления. Не смешивайте в один поток:
боевые инциденты;
отчеты;
предупреждения о сертификатах;
уведомления о плановых работах.

Чем чище оперативный канал, тем выше шанс, что его действительно будут читать.

Настройте maintenance windows. Во время релизов, миграций и плановых работ алерты должны либо приглушаться, либо маршрутизироваться отдельно. Иначе команда получит предсказуемый шум и перестанет воспринимать уведомления серьезно.

Практический шаблон здоровой системы алертов

Для типового веб-проекта рабочая схема может быть такой:

Критичный алерт: сайт или API недоступны после 2-3 подтвержденных проверок.
Высокий приоритет: рост 5xx, сильная деградация latency, проблемы с логином или checkout.
Средний приоритет: ресурсные метрики, если они уже влияют на доступность.
Низкий приоритет: SSL-сертификаты, домены, плановые напоминания.

Отдельно полезно определить:

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

В Statuser такие сценарии удобно собирать вокруг конкретных проверок: настроить каналы уведомлений, разделить критичность инцидентов и убрать лишний шум еще до того, как команда устанет от алертов.

Что стоит вынести в отчеты вместо боевых алертов

Часть сигналов лучше вообще не отправлять как срочные уведомления:

краткосрочные всплески CPU;
разовые пики памяти без пользовательского влияния;
единичные ошибки без тренда;
предупреждения с длинным горизонтом, например сертификат истекает через 30 дней.

Такие данные полезны, но им чаще место в дашборде, weekly report или backlog-задаче.

Что почитать дальше

Чтобы алерты работали как система, а не отдельно от мониторинга, полезно связать эту тему с соседними статьями:

Частые ошибки при настройке алертов

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

Самая дорогая ошибка — сохранять «как есть», если команда уже не верит алертам.

Как понять, что настройка стала лучше

Хорошая система алертов выглядит так:

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

Вывод

Настроить алерты без alert fatigue — значит оставить только те сигналы, которые действительно требуют действия, и убрать все лишнее из оперативного контура. Ключевые инструменты здесь простые: критичность, retries, дедупликация, маршрутизация и maintenance windows.

Если команда устала от уведомлений, это не значит, что алертов слишком много «по природе». Обычно это значит, что пришло время пересобрать правила и вернуть мониторингу доверие. А если хотите быстро настроить понятные уведомления без ручной сборки своей схемы, в Statuser можно сразу подключить мониторинг и алерты для сайта, API и SSL.