Проблема Alert Fatigue
Alert fatigue — главный враг эффективного мониторинг сайтов. Когда команда получает сотни уведомлений в день, важные алерты теряются среди шума. По данным исследования, до 70% алертов игнорируются в командах с неправильно настроенным мониторингом.
Цель алертинга — уведомить правильного человека о правильной проблеме в правильное время. Не больше и не меньше.
Принципы эффективного алертинга
Алерт должен требовать действия
Каждый алерт должен подразумевать конкретное действие. Если алерт не требует немедленной реакции — это не алерт, а информационное уведомление. Переведите его в дашборд или лог.
Задайте вопрос: «Что мне делать, когда я получу этот алерт?» Если ответа нет — удалите алерт.
Избегайте дублирования
Один инцидент = один алерт. Если база данных недоступна, вы не должны получить 50 алертов от всех сервисов, которые от неё зависят. Настройте зависимости и подавление каскадных алертов.
Приоритизируйте
Не все проблемы одинаково срочны:
- Critical — сайт недоступен, потеря данных, утечка безопасности. Немедленная реакция, звонок.
- Warning — деградация производительности, заканчивается место на диске. Реакция в течение часа.
- Info — плановое обслуживание, скоро истекает сертификат. Реакция в рабочее время.
Настройка порогов (Thresholds)
Статические пороги
Простейший подход: «если время отклика больше 2 секунд — алерт». Работает для стабильных метрик, но плохо адаптируется к изменениям.
Рекомендации:
- Установите пороги на основе исторических данных, а не интуиции
- Используйте два уровня: warning (85% от критического) и critical
- Пересматривайте пороги ежеквартально
Динамические пороги
Пороги рассчитываются автоматически на основе исторических данных. Если обычное время отклика 100ms, а сейчас 300ms — это аномалия, даже если 300ms кажется приемлемым абсолютным значением.
Подавление кратковременных всплесков
Не алертите на единичные превышения. Используйте условия вроде «метрика превышает порог более 3 минут подряд» или «5 из последних 10 проверок неуспешны». Это отсекает кратковременные сетевые глюки.
Каналы уведомлений
Выбирайте канал по важности
- SMS/звонок — только для critical-алертов, требующих немедленной реакции
- Мессенджеры (Telegram, Slack) — для warning-алертов, требующих реакции в течение часа
- Email — для информационных уведомлений, не требующих срочной реакции
- Дашборд — для метрик, которые важно видеть, но не нужно активно уведомлять
Не дублируйте каналы
Отправка одного алерта в SMS, Telegram, email и Slack одновременно — верный путь к игнорированию всех каналов. Один приоритет = один канал.
Эскалация
Настройте цепочку эскалации для critical-алертов:
- 0 мин — уведомление дежурному инженеру (Telegram)
- 15 мин — если не подтверждён, SMS дежурному
- 30 мин — если не подтверждён, звонок руководителю
- 1 час — уведомление всей команде
Без эскалации critical-алерт может остаться незамеченным, если дежурный спит или недоступен.
Группировка и корреляция
Связывайте алерты с одним источником проблемы:
- Если сервер не отвечает на Ping, не отправляйте отдельные алерты для HTTP, DNS и SSL
- Группируйте повторяющиеся алерты — 100 одинаковых уведомлений за 10 минут превращаются в одно с пометкой «повторяется»
- Добавляйте контекст: не «HTTP 500», а «HTTP 500 на /API документацию/checkout, 15 ошибок за 5 минут»
Содержание алерта
Хороший алерт содержит:
- Что произошло — «Время отклика /api/checkout превысило 3 секунды»
- Когда — «14:32 UTC, продолжается 5 минут»
- Масштаб — «Затронуто 15% запросов»
- Контекст — «Последний деплой 30 минут назад»
- Ссылка — ссылка на дашборд или runbook
Регулярный аудит алертов
Раз в квартал проводите ревью:
- Какие алерты срабатывали чаще всего? Можно ли исправить root cause?
- Какие алерты ни разу не сработали? Порог слишком высокий или проблема не существует?
- Какие инциденты не были обнаружены алертами? Нужны ли новые проверки?
- Сколько алертов было ложными срабатываниями? Нужно ли скорректировать пороги?
Практическая настройка с Enterno.io
Настройте мониторинг uptime с Enterno.io для ваших ключевых страниц. Используйте панель мониторов для отслеживания доступности всех сервисов. Начните с 2-3 критических проверок и постепенно расширяйте покрытие.
Итоги
Эффективный алертинг — это баланс между полнотой и шумом. Каждый алерт должен требовать действия, иметь правильный приоритет и канал доставки. Регулярно пересматривайте пороги и удаляйте бесполезные алерты. Лучше 5 точных алертов, чем 500 шумных.