Представьте: приходит уведомление «CPU > 85% на node‑worker‑04». Открываете дашборд, а это был 30‑секундный всплеск из‑за бэкап‑скрипта, все уже норм. Через 10 минут снова то же самое. К пятому разу вы отключаете уведомления… и именно тогда база реально падает.
Это то состояние, когда система мониторинга слишком часто кричит “волк”, и вы перестаете обращать внимание. Если вы SRE, инженер DevOps или просто тот самый человек on-call, вы понимаете, о чем мы.
Хорошая новость: так жить не обязательно. То есть работать… Можно вернуть себе сон и здравый смысл.
Alert‑усталость — это десенсибилизация к сигналам безопасности. Он случается в больницах с бесконечным писком капельниц, в кабинах самолетов с сигналами высоты и в Slack‑каналах, заваленных ботами PagerDuty.
В контексте ИТ-инфраструктуры alert‑усталость часто вырастает из подхода «собрать все данные». Разворачивая новую среду — пусть даже мощный выделенный сервер для высоконагруженных проектов — хочется включить все дефолтные настройки. Кажется, инженеру нужно знать буквально все:
Проблема именно в срочности данных, а не в их объеме. Когда каждое уведомление помечено как «critical», ничего уже не критично. Если телефон вибрирует одинаково и из‑за предупреждения о чистке диска, и из‑за полного падения сервиса, мозг со временем отфильтрует оба сигнала.
Цена подобных шумов выше, чем одна бессонная ночь.
Команда со временем начинает игнорировать оповещения («этот сервер по вторникам всегда пищит»), нормализует отклонения и перестает изучать аномалии. В итоге реальный сигнал тонет в потоке писем в папке «Alerts».
И вот вы уже в команде выгоревших инженеров, ведь постоянные прерывания дробят фокус днем и не дают восстановиться ночью. Усталость от тревог (в том числе от того, что в любую секунду вам придет оповещение, что что-то сломалось) — один из факторов выгорания в стрессовых профессиях. Это ведет к замедленной реакции и плохим решениям.
Нельзя построить надежную систему, если люди, которые ее поддерживают, работают с размытым фокусом.
Чтобы исправить ситуацию, нужно быть беспощадными и вести войну с ложноположительными оповещениями.
Ложноположительный в мониторинге не всегда означает, что данные неверны. То есть CPU действительно мог достичь 90%. Ложной была интерпретация, будто это требовало вмешательства человека.
Разделяйте три категории:
Если оповещение сработал, а вы ничего не сделали (или просто посмотрели и закрыли), это был ложноположительный сигнал и его место в логах.
Думайте про alert так, будто он приходит ночью. «Если это сработает в три ночи, я проснусь — и окажется, что система в порядке — я разозлюсь?» Если да, alert нужно настроить или удалить.
Дальше про техническую реализацию. Лучшие практики мониторинга и оповещений начинаются с изменения того, как мы детектируем сбои, а не только что мы детектируем.
В распределенных системах всплески обычное дело: срабатывает сборщик мусора 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 продвинуло этот подход, и он считается эталоном лучших практик мониторинга и оповещения.
Сосредоточьтесь на четырех «золотых сигналах»:
Если задержка мала и ошибок нет, неважно, что CPU на 95%. Система по-прежнему делает свою работу.
Подробнее в нашем гайде по показателям производительности сервера, чтобы глубже понять, какие конкретные сигналы указывают на реальные проблемы, а какие — на мнимые.
Если вы выкатываете код или ставите патч, заглушайте крики системы об ошибках.
Большинство инструментов поддерживают «Silences» или «Maintenance Mode». Плюс, это надо автоматизировать: пусть пайплайн деплоя перед стартом отправляет запрос в мониторинг и включает заглушение д ля целевой среды.
Если вы осознанно ломаете систему во время релиза, не позволяйте системе утверждать обратное и раздражать вас еще больше.
Даже безупречная система мониторинга бесполезна, если получивший уведомление о поломке не знает, что делать.
У каждого алерта должен быть ранбук или плейбук — документ с точными шагами триажа и фикса.
Ссылка на него должна приходить вместе с уведомлением от системы мониторинга и отвечать на три вопроса:
Довольно часто, если вы не можете написать ранбук, потому что не знаете, какие действия предпринять, такой alert может быть просто шумом.
Мы бережно обращаемся с серверами — мониторим температуру, нагрузку, аптайм. Стоит с тем же уважением относиться к инженерам. Alert‑усталость крадет спокойствие специалистов и надежность компании.
Если беспощадно чистить ложные сработки, фокусироваться на симптомах и использовать группировку, Slack (или любой сервис, где вас дергают) из врага превратится в помощника.
Посмотрите на уведомления за прошлую неделю. По каким вы реально действовали, а какие игнорировали? Игнорируемые удалите или уведите в логи. Инфраструктура утром никуда не денется, а вы будете достаточно бодры, чтобы ей управлять и оперативно решать проблемы.
Изучите VPS‑решения под ваши требования по производительности. Только не забудьте настроить alerts!