Как настроить алерты, чтобы не было 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. Каждый алерт должен вести к конкретному действию:

• проверить доступность;

• переключить трафик;

• откатить релиз;

• связаться с провайдером;

• эскалировать инцидент.

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

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

Не 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-задаче.

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

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

• Что такое uptime monitoring и как он работает
• Как выбрать интервал проверки сайта для мониторинга
• Что такое false positive в мониторинге и как его уменьшить

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

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

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

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

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

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

Вывод

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

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