Алерты, которые бесят

На первом шаге модуля мы коротко уже упомянули проблему, которая звучит так: если завести оповещения на все подряд, наступает alert fatigue, и настоящая авария тонет в шуме. Представьте канал в мессенджере, куда за ночь упало двести алертов: диск на 81%, всплеск нагрузки на десять секунд, под перезапустился, снова диск, снова нагрузка. К утру уведомления на этом канале у всех будут выключены, а где-то в середине ленты останется единственное сообщение про реально лежащий сервис, которое никто не увидел. Это та ситуация, когда мониторинг есть, а толку нет.

Почему алерты превращаются в шум

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

Чаще всего виноваты алерты на все подряд. Завели оповещение на каждую метрику, чтобы знать, и теперь приходит CPU 80% (через минуту прошло), отдельный медленный запрос, перезапуск одного пода. Само по себе ни одно из этих событий не требует, чтобы человек что-то делал. Рядом стоят штормы из одного сбоя: упал узел, а с ним пятьдесят подов, и прилетает пятьдесят отдельных сообщений вместо одного, так что один инцидент превращается в лавину. Бывает и дребезг порога, когда метрика болтается ровно на границе срабатывания и алерт включается-выключается каждую минуту, спамя «сломалось, починилось, сломалось». И поверх всего этого часто нет приоритетов: мелочь и катастрофа приходят в один канал с одним и тем же звуком, и отличить важное от ерунды на глаз невозможно.

Итог всегда один. Человек привыкает к потоку и начинает его игнорировать, а вместе с шумом пропускает и настоящую беду. Это басня про мальчика, который кричал «волки»: после десятка ложных тревог на настоящую уже никто не приходит. За пределами IT ту же беду знают как alarm fatigue: в больницах мониторы у коек пищат так часто, что персонал перестает реагировать, и это официально признано угрозой безопасности пациентов. Механизм тот же, слишком много сигналов, и мозг учится отключать их все, включая важные.

Один вопрос, что я сделаю

На первом шаге прозвучало правило «алерт должен требовать действия». Вот его рабочая форма, вопрос, который отсекает половину будущего шума еще до того, как вы заведете оповещение: что я сделаю, когда это придет?

Если на сигнал нет осмысленного ответного действия, это не алерт. «Просто чтобы видеть», это работа дашборда с первого шага, а не повод будить человека. Информация, на которую вы все равно не реагируете ночью, должна жить на графике, в логах или в задаче на потом, но не в канале, который пищит.

Как делать алерты по-человечески

Дальше идет набор приемов, которые превращают шумный канал в рабочий.

Первое, алерты на симптомы, а не на причины. Будить нужно, когда плохо пользователю: сервис не отвечает, доля ошибок растет, под угрозой SLO с прошлого шага. А вот внутренние причины вроде высокого CPU или одного медленного пода сами по себе пользователя не трогают и в алерт не годятся, их смотрят на дашборде, когда симптом уже привел вас расследовать. Привязка к error budget здесь прямая: алерт оправдан, когда проблема жжет бюджет ошибок, а не когда метрика просто шевельнулась.

Второе, пороги с выдержкой. То самое «в течение N минут» с первого шага: алерт срабатывает на устойчивую проблему, а не на секундный пик, и это же лечит дребезг порога.

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

Звонком ночью поднимают только на то, что нельзя отложить до утра. Остальное идет в чат и ждет рабочего дня. Этим занимается Alertmanager с первого шага, он же группирует связанное, чтобы упавший узел давал одно сообщение вместо пятидесяти, и умеет глушить алерты на время плановых работ, чтобы не звенеть, когда вы и так все знаете.

Четвертое, контекст в самом сообщении. Хороший алерт говорит не «что-то не так», а что сломалось, где и что делать в первую очередь, со ссылкой на короткую инструкцию. Сонный человек в три часа ночи не должен расследовать с нуля.

И последнее, прополка. Алерты, это код, и за ними нужен уход. Правило, которое месяц никто не трогал, или то, что вечно срабатывает впустую, это кандидат на починку или удаление. Без регулярной чистки шум нарастает сам собой.

Лучший алерт, тот, что не понадобился

Самый тихий канал получается там, где система чинит себя сама. Вспомните self-healing из модуля про Kubernetes: упавший контейнер пересоздается автоматически, и инженер узнает об этом утром из графика, а не ночью из звонка. Поэтому, прежде чем заводить алерт, который будит человека, стоит спросить, нельзя ли это починить без человека вовсе. Каждая проблема, закрытая автоматикой, это минус один ночной звонок, и хороший мониторинг стремится будить людей как можно реже.

Причем здесь DevOps

Алертинг, это не только техника, но и забота о людях. За оповещениями стоит живой дежурный из разговоров про три часа ночи, и каждый лишний ночной звонок ведет к выгоранию, а выгоревший человек пропускает уже настоящую аварию, круг замыкается. Поэтому грамотный алертинг входит в работу девопса наравне с настройкой метрик: завести алерты мало, их нужно пропалывать, держать на симптомах и беречь канал от мусора. На собеседованиях про эксплуатацию вопрос «как вы боретесь с alert fatigue» из частых, и теперь у вас есть на него ответ: меньше алертов, но таких, на каждый из которых есть действие.

Словарик

Термин	Что означает
Alert fatigue	Усталость от лишних алертов, из-за которой пропускают настоящие
Алерт = действие	Если на сигнал нет ответного действия, это не алерт
Симптом, не причина	Будить на боль пользователя (ошибки, недоступность), а не на каждую метрику
Шторм алертов	Один сбой рождает множество сообщений; лечится группировкой
Дребезг (flapping)	Срабатывание у границы порога; лечится выдержкой «в течение N минут»
Уровни алертов	info на дашборд, warning в чат, critical звонком дежурному
Silence	Временное глушение алертов на период плановых работ
Прополка алертов	Регулярное удаление и починка бесполезных правил