Два часа ночи. Телефон вибрирует. Вы вскакиваете в кровати, сердце бешено стучит, и кидаетесь к ноутбуку, потому что ваш монитор доступности кричит, что всё горит.
Проверяете серверы. Пингуете базу данных. Идёте по всему театральному представлению incident response.
Всё в порядке.
Алерт был просто шумом.
Это происходит дважды в неделю. Иногда трижды. А если вы запускаете несколько сервисов с несколькими мониторами, то вы фактически крутитесь на колесе депривации сна—о котором никто не говорит публично, но все жалуются в приватные Slack-каналы в три часа ночи.
Alert fatigue—это не просто мелкое неудобство. Это грязный секрет индустрии мониторинга, и стоит командам намного дороже, чем кажется.
Почему ваше тело ненавидит ложные сработки больше, чем вы думаете
Когда срабатывает алерт, вашей нервной системе всё равно, настоящий ли это случай. Тело мгновенно переходит в режим кризиса. Поднимается кортизол. Учащается пульс. Расширяются зрачки. Префронтальная кора—логическая часть—захватывается амигдалой, которая знает только одно: обнаружена угроза.
Теперь представьте, что это происходит дважды в неделю целый год.
Исследования показывают мрачную картину. Инженеры, имеющие дело с частыми ложными алертами, теряют в среднем 45 минут сна на один инцидент, плюс ещё 20–30 минут, пока заснут снова. Это не просто 45 минут один раз. Это 45 минут, умноженные на 100+ ложных тревог в год. Речь идёт о недельном недосыпе.
Но потеря сна—это только начало.
«После достаточного количества ложных срабатываний команда перестаёт верить алертам. Отключают уведомления в Slack. Муют PagerDuty. Пока наконец не произойдёт реальный outage, и никто не подойдёт.»
Это классический эффект мальчика, кричащего об овце, и он намного опаснее, чем одна потерянная ночь сна. Как только команда перестаёт верить мониторам, она перестаёт реагировать на них. Реальные outage проходят незамеченными, потому что всех приучили относиться к каждому алерту как к шуму.
Добавьте сюда налог на переключение контекста. Каждый алерт вырывает вас из глубокой работы—того состояния, в котором инженеры действительно создают что-то. Исследования показывают: чтобы восстановить полную когнитивную фокусировку, нужно в среднем 23 минуты после прерывания. Три ложных алерта с утра? Вы только что загубили весь послеполуденный продакшен.
Добавьте выгорание команды, и у вас получится идеальный шторм. Инженеры начинают ненавидеть свои инструменты мониторинга. Некоторые просто отключают их полностью. Вот тогда-то и начинается реальная беда.
Архитектурная проблема, которую никто не хочет признавать
Большинство мониторов доступности используют один и тот же примитивный подход: попасть по URL, проверить код HTTP-ответа, выстрелить алерт, если что-то выглядит неправильно.
Это просто. Это дёшево в эксплуатации. Это также фундаментально сломано.
Вот что вы на самом деле измеряете, когда выполняете проверку из одного географического региона:
Тайм-ауты TCP-соединения, которые вообще не связаны с вашим реальным сервисом. Ваш сервер мониторинга может иметь нестабильный маршрут к вашему серверу 30 секунд—и уже у вас алерт. Ваш сайт в порядке. Сеть монитора—нет.
Агрессивные таймауты, которые срабатывают во время обычных всплесков трафика. Установили 5-секундный таймаут на API, который обычно отвечает за 200 мс, трафик скачет в 10 раз—и бум, ложный алерт, хотя всё работает нормально.
Прыгающие SSL-сертификаты. Валидация, которая первый раз не проходит, но со второй попытки проходит,—создаёт фантомные outage, которые на реальных пользователей не влияют.
Географические слепые пятна. Монитор в us-east-1 не заметит проблемы маршрутизации, которые затрагивают только пользователей в ap-southeast-1. Вы можете активно терять клиентов со всего мира, пока ваш дашборд светит зелёным.
И самое обидное: простая HTTP-проверка не поймёт, что ваша база данных медлит, ваш CDN ломается или ваш API
