В DevOps-практиках не хватает* термина
alert fatigue. Это состояние, когда инженеры и операторы перегружены тысячами уведомлений от систем мониторинга, observability-инструментов, инфраструктурных алертов и метрик приложений.
В 2025 году, с обилием инструментов и тестов, поток алертов превращается в шум.
Даже тщательно настроенные системы мониторинга со временем становятся неуправляемыми: уведомления поступают непрерывно, теряют ценность, и команды начинают их игнорировать или отключать.
Это не просто раздражение - это угроза надежности систем, когда критические сигналы теряются в потоке бесполезных сообщений.
Смартфон с отдельным приложением, слак, почта, звонки, смс, голуби и совы бьются в окна, доставляя уведомления.
Что с этим делать?
Пока точного решения нет.
Есть общие идеи, которые кажутся очевидными всем:
- Сократить количество алертов, настраивая их на основе SLA/SLO, чтобы фокусироваться только на метриках, - влияющих на бизнес-цели и пользовательский опыт.
- Группировать связанные уведомления в единые инциденты.
- Регулярно пересматривать и удалять устаревшие алерты.
- Автоматизировать рутинные действия для низкоприоритетных проблем.
Мне кажется, что наше будущее - за группировкой алертов в единые инциденты.
Рассмотрим пару примеров.
Представьте ситуацию: на одном из подов с базой данных закончилось место на диске (PV).
В результате мы получаем множество алертов:
- Ошибка репликации между нодами кластера.
- Нехватка места на PV.
- Рестарт проб на поде (не всегда).
- Ошибки от приложений, подключающихся к базе данных (до 50 алертов).
- Высокий IOPS (честно говоря не понимаю природу почему IOPS растёт, когда диск резко в 0 уходит, возможно, из-за интенсивных попыток записи при заполненном диске).
- Ошибки самого приложения (около 4-6 алертов), не связанные с инфраструктурой.
- Status Page тоже сигнализирует о проблеме.
И это далеко не всё.
Добавим вторую ситуацию.
Выпустили новую версию приложения и допустили ошибку в работе с API.
В результате мы видим алерты:
- Повышенная латентность API (ответы >500 мс)
- Увеличение количества HTTP 500 ошибок
- Превышение лимита времени ожидания (timeout) на стороне клиента
- Высокая загрузка CPU на серверах приложения из-за бесконечного цикла в коде
- Ошибки в логах приложения, связанные с некорректной обработкой запросов(opensearch monitor).
- Status page сервиса пишет о деградации
В единичном случае такая картина полезна: мы видим полную информацию и быстро понимаем источник проблемы. Но при масштабировании или повторении подобных инцидентов количество алертов становится неуправляемым, и мы начинаем их игнорировать.
При группировке алертов, например, в Slack, логично создавать отдельный тред для каждого инцидента.
Все связанные алерты отправляются в этот тред. Внутрь одного инцидента
Если в компании есть дежурный (on-call), он автоматически подписывается на тред (современные инструменты, такие как PagerDuty или Opsgenie, это поддерживают) и видит все уведомления в контексте.
Остальные инженеры и продакт-оунеры не отвлекаются на шум.
Как это реализовать?
Пока идей немного.
Можно разработать собственную систему управления инцидентами(Incident Management System) или использовать готовое решение с поддержкой AI, таких как PagerDuty или Splunk On-Call, которые уже умеют коррелировать алерты.
Чего ждать в будущем?
Думаю мы всё же должны прийти к группировке алёртов в единые инциденты.
Что получится в итоге мы узнаем лишь спустя время.
* Скорее всего этот термин уже есть, возможно его придумали миллиард лет до моего рождения, но во всяком случае мы в компании и все мои коллеги/приятели уделяем ему слишком мало времени и не понимаем реальной угрозы бизнесу.