Усталость от алертов: почему команда перестаёт реагировать

MAATRIX

Дежурный видит уведомление, вздыхает и сворачивает чат — «опять, наверное, ложная тревога». Через месяц так реагируют на всё подряд, а настоящий инцидент тонет в том же потоке, что и сотня прошлых пустышек. Это не лень и не недисциплинированность конкретного человека — это предсказуемый психологический эффект, который называется усталостью от алертов (alert fatigue), и с ним можно и нужно работать системно.

Как формируется усталость от алертов

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

В эксплуатации серверов сценарий повторяется один в один. Алерт срабатывает — дежурный идёт проверять — оказывается, что это временный всплеск нагрузки от cron-задачи, или ошибка коннекта к базе, которая сама восстановилась за 10 секунд, или ложное срабатывание из-за неверно выставленного порога. Ничего страшного не произошло, реакция не требовалась. В следующий раз всё повторяется. И ещё раз. Мозг — экономная система: если действие раз за разом не даёт результата (проверка ничего не находит), он снижает приоритет стимула, который это действие запускает. Это называется привыканием (habituation), и это не баг психики, а нормальная адаптивная реакция на бесполезный шум.

Проблема в том, что привыкание не умеет отличать «этот конкретный алерт снова ложный» от «алерты вообще снова ложные». Оно генерализуется на весь канал уведомлений целиком. Человек не думает сознательно «пропущу этот алерт» — он просто реагирует медленнее, откладывает проверку на потом, при накоплении непрочитанных сообщений здоровается с цифрой «200+» и не открывает список вовсе. Каждый следующий цикл «алерт — проверка — ложная тревога» усиливает паттерн. И вот здесь кроется главная опасность: паттерн не разбирает, какой алерт настоящий. Диск заполнился на 95% и SSL-сертификат истекает завтра — сообщения об этом physически ничем не отличаются от привычного шума, приходят в тот же канал, тем же шрифтом, с той же частотой ложных срабатываний за плечами у получателя. Редкий, действительно критичный сигнал рискует остаться непрочитанным именно потому, что система приучила человека не читать.

Отдельно стоит сказать про скорость реакции как метрику ущерба. Даже если алерт в итоге замечают, время до реакции (time to acknowledge) растёт с каждым циклом привыкания — сначала дежурный отвечает за минуту, через месяц игнорирования шума открывает чат раз в час «между делом». Для инцидента, где счёт идёт на минуты (упавший сайт, забитый диск, DDoS), разница между минутой и часом реакции — это разница между «клиенты не заметили» и «клиенты написали в поддержку».

Причина в технической настройке, а не в людях

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

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

Мера 1: аудит реальной полезности алертов

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

Формат аудита простой и не требует специального инструмента — таблица и час времени раз в квартал:

Практический способ собрать эту статистику — не полагаться на память, а завести журнал: если у вас Alertmanager, у него есть история срабатываний через API (/api/v2/alerts и /api/v2/alerts/groups), которую можно выгрузить и посчитать. Если алерты идут через самописный скрипт в Telegram — простейший вариант, добавить логирование каждого отправленного сообщения в файл или таблицу базы с меткой времени, а раз в квартал накатывать grep/awk по логу и смотреть частоту.

# пример: частота алертов по типу за последние 30 дней из простого лог-файла
grep "ALERT_SENT" /var/log/monitoring/alerts.log \
  | awk '{print $3}' \
  | sort | uniq -c | sort -rn

Дальше правило простое: если конкретный алерт систематически (не разово, а стабильно) оказывается ложным или не требует действия — у него два законных исхода. Либо перенастроить порог/логику (обычно это решает проблему сразу), либо удалить его вовсе. Третий вариант — «оставить на всякий случай, вдруг пригодится» — на практике не бесплатен: каждый такой алерт продолжает наполнять канал шумом и снижать доверие ко всем остальным сообщениям в нём. Алерт, который никогда не требовал действия за квартал, не страхует вас ни от чего — он просто тренирует команду его игнорировать.

Мера 2: разделение по уровню срочности

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

Практическая схема — минимум два уровня, лучше три:

• Критичный (page). Сервис недоступен для пользователей, диск вот-вот заполнится полностью, истекает сертификат в ближайшие сутки, обнаружен активный инцидент безопасности. Такой алерт должен реально прерывать — телефонный звонок, push с обходом режима «не беспокоить», SMS. Дежурный обязан среагировать за минуты.
• Важный, но не срочный (ticket). Растёт использование диска, но до критичного порога ещё дни; повышенная задержка ответа, которая не влияет на пользователей напрямую; разовая ошибка, которая сама восстановилась. Такое накапливается в отдельном канале — Slack/Telegram-группа, тикет-система — и разбирается в рабочее время, без экстренного прерывания.
• Информационный (log). Деплой прошёл успешно, backup завершился штатно, ежедневный отчёт по метрикам. Это не алерт в смысле «требует внимания» — это лог для тех, кому интересно, и его вообще не стоит слать туда же, куда критичные сообщения.

Технически разделение обычно реализуется через маршрутизацию в Alertmanager (route с matchers по severity-лейблу и разными receiver для каждого уровня) или, для более простых самописных скриптов, просто разными Telegram-чатами/каналами под разные уровни срочности:

# фрагмент конфигурации Alertmanager: разные каналы под разные уровни
route:
  routes:
    - matchers:
        - severity="critical"
      receiver: pagerduty-oncall
      repeat_interval: 15m
    - matchers:
        - severity="warning"
      receiver: telegram-team-channel
      repeat_interval: 4h
    - matchers:
        - severity="info"
      receiver: telegram-log-channel
      repeat_interval: 24h

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

Мера 3: культура — обсуждение как командной проблемы

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

Практический шаг — вынести тему на регулярное обсуждение открыто, вслух, как рабочий процесс, а не как повод для упрёка:

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

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

Практический план на первый месяц

Если усталость от алертов уже ощущается в команде (симптомы: канал с уведомлениями регулярно накапливает десятки непрочитанных сообщений, дежурные признаются, что «просто смотрят раз в день», реальные инциденты вскрываются не по алерту, а по жалобе пользователя) — порядок действий такой:

1. Неделя 1 — собрать статистику за последний месяц: сколько алертов пришло по каждому типу, сколько из них требовали действия. Не полагаться на память — выгрузить из Alertmanager API или лога скрипта.
2. Неделя 2 — по результатам аудита перенастроить или удалить систематически бесполезные алерты (техническая настройка порогов, дедупликация, группировка — см. статью выше).
3. Неделя 3 — развести оставшиеся алерты по уровням срочности и развести каналы: критичное — в канал с реальным прерыванием (звонок/push), остальное — в спокойный канал для планового просмотра.
4. Неделя 4 — зафиксировать регулярную ревизию как процесс: пункт в ретроспективе раз в месяц или квартал, ответственный за ревизию по ротации.

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

Частые вопросы