Устали от постоянных alerts? Как настроить оповещения о мониторинге и спать спокойно

Представьте: приходит уведомление «CPU > 85% на node‑worker‑04». Открываете дашборд, а это был 30‑секундный всплеск из‑за бэкап‑скрипта, все уже норм. Через 10 минут снова то же самое. К пятому разу вы отключаете уведомления… и именно тогда база реально падает.

Это то состояние, когда система мониторинга слишком часто кричит “волк”, и вы перестаете обращать внимание. Если вы SRE, инженер DevOps или просто тот самый человек on-call, вы понимаете, о чем мы.

Хорошая новость: так жить не обязательно. То есть работать… Можно вернуть себе сон и здравый смысл.

Что такое alert‑усталость?

Alert‑усталость — это десенсибилизация к сигналам безопасности. Он случается в больницах с бесконечным писком капельниц, в кабинах самолетов с сигналами высоты и в Slack‑каналах, заваленных ботами PagerDuty.

В контексте ИТ-инфраструктуры alert‑усталость часто вырастает из подхода «собрать все данные». Разворачивая новую среду — пусть даже мощный выделенный сервер для высоконагруженных проектов — хочется включить все дефолтные настройки. Кажется, инженеру нужно знать буквально все:

• Диск на 80%? Шлите оповещение.
• Пинг подскочил на 10 мс? Обязательно уведомляйте.
• Контейнер перезапустился? Разбудите меня.
  

Проблема именно в срочности данных, а не в их объеме. Когда каждое уведомление помечено как «critical», ничего уже не критично. Если телефон вибрирует одинаково и из‑за предупреждения о чистке диска, и из‑за полного падения сервиса, мозг со временем отфильтрует оба сигнала.

Почему это опасно и для продакшена, и для вас лично

Цена подобных шумов выше, чем одна бессонная ночь.

Команда со временем начинает игнорировать оповещения («этот сервер по вторникам всегда пищит»), нормализует отклонения и перестает изучать аномалии. В итоге реальный сигнал тонет в потоке писем в папке «Alerts».

И вот вы уже в команде выгоревших инженеров, ведь постоянные прерывания дробят фокус днем и не дают восстановиться ночью. Усталость от тревог (в том числе от того, что в любую секунду вам придет оповещение, что что-то сломалось) — один из факторов выгорания в стрессовых профессиях. Это ведет к замедленной реакции и плохим решениям.

Нельзя построить надежную систему, если люди, которые ее поддерживают, работают с размытым фокусом.

Ложноположительные срабатывания и реальные проблемы

Чтобы исправить ситуацию, нужно быть беспощадными и вести войну с ложноположительными оповещениями.

Ложноположительный в мониторинге не всегда означает, что данные неверны. То есть CPU действительно мог достичь 90%. Ложной была интерпретация, будто это требовало вмешательства человека.

Разделяйте три категории:

1. Alerts (Pages) — чинить немедленно, иначе бизнес теряет деньги.
2. Tickets — посмотреть в следующий рабочий день.
3. Логи и метрики — сохраняем для отладки, но никого не надо будить в моменте.

Если оповещение сработал, а вы ничего не сделали (или просто посмотрели и закрыли), это был ложноположительный сигнал и его место в логах.

Думайте про alert так, будто он приходит ночью. «Если это сработает в три ночи, я проснусь — и окажется, что система в порядке — я разозлюсь?» Если да, alert нужно настроить или удалить.

Тюнинг оповещений для команд DevOps и SRE

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

Сила Duration

В распределенных системах всплески обычное дело: срабатывает сборщик мусора Java, идет cron, пользователь заливает большой файл. Это не обязательно авария.

Большинство инструментов — Prometheus, Zabbix, Datadog — позволяют задать длительность: не оповещать вас в секунду пересечения порога, а только если порог удерживается.

Пример стандартного «шумного» правила Prometheus:

# Так не нужно
- alert: HighCPU
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[2m])) * 100) > 90
labels: severity: page

Добавление for: 10m отсекает значительную долю шума:

# Попробуйте лучше так
- alert: HighCPU
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
for: 10m # The duration filter labels:
severity: ticket # Понизьте степень критичности, если это не влияет на пользователей

Борьба с флаппингом

Нет ничего раздражительнее оповещения, которое само разрешилось и через 30 секунд сработало снова. Это и есть flapping.

Чтобы снизить шум, используйте гистерезис: если идет уведомление при заполнении диска 90%, не закрывайте его, пока значение не упадет ниже 85%.

Группировка оповещений

Если упал корневой роутер, вам не нужно 500 уведомлений про то, что 500 серверов недоступны. Нужен один alert про роутер.

Это решается логикой группировки, например, в Alertmanager:

route:
group_by: ['alertname', 'cluster'] group_wait: 30s
group_interval: 5m repeat_interval: 4h

Эта конфигурация ждет 30 секунд, собирает родственные сигналы в один и присылает вам единую сводку.

При сложной инфраструктуре (в том числе на VPS-хостинге) группировка необходима, чтобы держать каналы уведомлений чистыми во время работ и неожиданных отказов.

Как построить масштабируемую стратегию оповещений

Тюнинг отдельных правил, конечно, помогает, но чтобы навсегда вылечить alert‑усталость, нужна более целостная стратегия. То есть, переход от причин к симптомам.

Не трогайте причины

«Диск заполнен на 90%» — это причина. «Высокий CPU» — тоже причина. Это внутренние метрики. Пользователю важно лишь, что сайт медленный или недоступен.

Смотрите на сиптомы

Руководство Google по SRE продвинуло этот подход, и он считается эталоном лучших практик мониторинга и оповещения.

Сосредоточьтесь на четырех «золотых сигналах»:

1. Latency — сервис медленный?
2. Traffic — пользуются ли сервисом (или трафик внезапно упал до нуля)?
3. Errors — есть ли отказы (например, HTTP 500)?
4. Saturation — система насыщена?

Если задержка мала и ошибок нет, неважно, что CPU на 95%. Система по-прежнему делает свою работу.

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

Вводите окна обслуживания

Если вы выкатываете код или ставите патч, заглушайте крики системы об ошибках.

Большинство инструментов поддерживают «Silences» или «Maintenance Mode». Плюс, это надо автоматизировать: пусть пайплайн деплоя перед стартом отправляет запрос в мониторинг и включает заглушение д ля целевой среды.

Если вы осознанно ломаете систему во время релиза, не позволяйте системе утверждать обратное и раздражать вас еще больше.

Не забываем про ранбуки

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

У каждого алерта должен быть ранбук или плейбук — документ с точными шагами триажа и фикса.

Ссылка на него должна приходить вместе с уведомлением от системы мониторинга и отвечать на три вопроса:

1. Какое влияние это оказывает на пользователя?
2. Каковы первые шаги диагностики?
3. Как я могу эскалировать эту проблему, если не могу ее решить?

Довольно часто, если вы не можете написать ранбук, потому что не знаете, какие действия предпринять, такой alert может быть просто шумом.

Заключение

Мы бережно обращаемся с серверами — мониторим температуру, нагрузку, аптайм. Стоит с тем же уважением относиться к инженерам. Alert‑усталость крадет спокойствие специалистов и надежность компании.

Если беспощадно чистить ложные сработки, фокусироваться на симптомах и использовать группировку, Slack (или любой сервис, где вас дергают) из врага превратится в помощника.

Посмотрите на уведомления за прошлую неделю. По каким вы реально действовали, а какие игнорировали? Игнорируемые удалите или уведите в логи. Инфраструктура утром никуда не денется, а вы будете достаточно бодры, чтобы ей управлять и оперативно решать проблемы.