Линия пульса на дашборде ровная, а дежурный всё равно разбит: тридцать алертов за ночь, из них два настоящих. Когда алертов слишком много, команда перестаёт читать их все — и именно в этот момент проходит настоящий инцидент. Разбираем, как построить алертинг, которому верят.
У алертинга есть пародоксальная точка отказа: слишком много сигналов. Команда, которую будят по пустякам три ночи подряд, на четвёртую ночь не проснётся и по делу — и именно в эту ночь уйдёт платёжный шлюз. Шум не просто раздражает, он статистически гарантирует пропущенный инцидент. Разбираем, как мы перестроили алертинг так, чтобы каждое срабатывание было событием, а не фоновым чириканьем.
Деградация начинается одинаково. Сначала ставится чувствительный порог «на всякий случай»: CPU выше семидесяти процентов, память выше восьмидесяти. Затем выясняется, что по вторникам из-за выгрузок CPU и правда поднимается, — порог двигают, но не убирают правило. Через полгода в системе сорок правил, из которых тридцать срабатывают регулярно, и ни одно из них не требует действия. Дежурный выучивает паттерн: почти всё сработавшее — мусор.
Корень проблемы в том, что алерты создавались от ресурсов, а не от пользовательского опыта. Серверу всё равно, сколько у него CPU; пользователю всё равно, кроме момента, когда страница не открывается. Правило, на которое невозможно ответить действием, — не алерт, а заметка. Заметки должны жить в дашбордах, куда заглядывают, а не в пейджере, который будит.
Второй механизм усталости — размазывание ответственности. Когда один инцидент порождает пятнадцать алертов из пятнадцати систем, ни один из них не выглядит главным, и обсуждение начинается с «у кого тут правда». Дедупликация и группировка — это не украшение, а условие того, что сигнал вообще будет прочитан.
Хороший алерт мы описываем пятью свойствами, и каждое проверяется вопросом, а не вкусом.
—Условие связано с пользовательским опытом : не «CPU выше 80%», а «p95 задержки оформления заказа выше двух секунд»;
—Устойчивость во времени : кратковременный всплеск не будит человека — правило срабатывает, только когда условие держится несколько сэмплов подряд;
—Дедупликация : один инцидент — один алерт, а не по сообщению с каждой реплики;
—Контекст внутри : ссылка на дашборд, последний деплой, runbook с первыми шагами — дежурный не должен начинать с поиска;
—Порог действия : на вопрос «что я сделаю, проснувшись» должен существовать ответ длиннее, чем «посмотрю».
После перехода на эти правила мы сократили ночные срабатывания с тридцати до трёх-четырёх в неделю. Это не значит, что система стала спокойнее — это значит, что будят только когда правда нужно вставать. Остальные сигналы переехали в тикеты и еженедельные отчёты, где им и место.
Алерты, которым верят, поддерживаются процедурой: каждое срабатывание проходит через короткий разбор, и его исход определяет судьбу правила.
01 Подтвердить и назначить владельца в первые пять минут — молчание в канале хуже ложного срабатывания;
02 Классифицировать: инцидент, ложное срабатывание или шум — от класса зависят следующие шаги;
03 Для инцидента — работать по runbook; для ложного срабатывания — исправить порог или окно в тот же день, пока контекст свеж;
04 Шумные правила отключаются без совещаний: вернуть их можно после тюнинга, а вот доверие к алертингу после месяца шума не возвращается;
05 Раз в месяц — ревизия: сколько правил сработало, сколько сработало зря, какие отключить или переписать.
Важно понимать: алертинг — это не про метрики, а про внимание. У команды его конечное количество, и каждый мусорный сигнал тратит его впустую. Бюджет внимания экономят теми же приёмами, что и бюджет ошибок: жёстким порогом входа, регулярной чисткой и честным разбором каждого лишнего будильника. Наблюдаемость, которая не уважает сон инженеров, в итоге перестаёт быть наблюдаемостью — она превращается в обои.
Пара к такому алертингу — измерения, на которых он основан. Если условия алертов считаются от нестабильных бенчмарков или разовых замеров, пороги будут врать систематически; о том, как выстроить измерения, которым можно верить, мы писали в материале про ограничения одиночных бенчмарков . А если правило сработало по медленному запросу — дальше маршрут известен: диагностика от симптома до плана выполнения доведёт до причины быстрее, чем любые догадки.
