Принципы качественного алертинга: "Алерт должен быть срочным, важным, действительным и требовать реакции"¶

Представьте пожарную сигнализацию в офисе. В идеале она должна срабатывать, когда есть реальный пожар, и немедленно вызывать эвакуацию. А теперь представьте, что эта сигнализация вопит каждый раз, когда кто-то жарит тосты, включает паяльник или просто кашляет. Через неделю все начнут игнорировать её, заклеивать скотчем, а в день реального пожара никто не среагирует.

Именно так выглядит плохой алертинг в IT.

Алертинг — это не просто "уведомление о проблеме". Это система экстренной коммуникации, призванная вырвать человека из реальной жизни (сна, ужина с семьёй, важной встречи) и заставить его немедленно действовать. Злоупотребление этой системой ведёт к катастрофе под названием "усталость от алертов" (alert fatigue), когда инженеры перестают реагировать на любые уведомления.

Чтобы этого избежать, в SRE сформулирован золотой принцип, который звучит как клятва Гиппократа для мониторинга:

"На каждый алерт должна быть очевидная, немедленная, полезная реакция человека. Если её нет - алерт не должен существовать."¶

Разложим эту максиму на четыре обязательных свойства качественного алерта.

1. Срочный (Urgent): "Это требует внимания СЕЙЧАС"¶

Суть: Алерт должен требовать реакции в ближайшие минуты (максимум — десятки минут), иначе последствия будут серьёзными и необратимыми.

Что это значит: проблема активно ухудшает пользовательский опыт, наносит ущерб бизнесу (потеря денег, данных, репутации) или угрожает стабильности системы.
Пример срочного алерта: "Частота 5xx ошибок в payment_service превысила 5% и продолжает расти. Тратится Error Budget." → Это требует немедленного исследования и, возможно, отката релиза.
Пример НЕ срочного "алерта": "Использование диска на сервере достигло 85%." → Это не требует реакции в 3 часа ночи. Это можно решить утром или автоматическим скриптом. Это не алерт, а уведомление (notification).

Аллегория: Звонок в службу 112. Вы звоните, когда видите открытое пламя в соседнем доме (срочно), а не когда заметили, что у них треснуло стекло на балконе месяц назад (несрочно).

Как проверить: Задайте вопрос: "Что случится, если мы проигнорируем это на 2 часа?" Если ответ — "ничего критичного" или "проблема решится сама", это не срочный алерт.

2. Важный (Important): "Это затрагивает критичный функционал или SLO"¶

Суть: Алерт должен указывать на проблему в ключевой, пользовательской метрике (SLI), напрямую связанной с бизнес-целями и опытом пользователей. Шум во внутренних, технических метриках — это не повод будить людей.

Что это значит: Проблема влияет на доступность, задержку (latency) или корректность работы сервиса для конечных пользователей.
Пример важного алерта: "p99 задержки основного API превысила SLO в 500 мс." → это напрямую влияет на пользователей.
Пример НЕ важного "алерта": "Количество запущенных горутин в сервисе выросло на 10%." → Само по себе это не говорит о проблеме для пользователя. Это может быть нормальным поведением. Это информация для дашборда, но не для пейджера.

Аллегория: Контрольная лампа "Check Engine" в машине. Она важна, но не каждая её активация означает, что нужно съезжать на обочину и вызывать эвакуатор. Иногда это значит "пора на плановое ТО". Нужна дополнительная диагностика. В IT такая "диагностика" — это дашборды, а не алерты.

Как проверить: задайте вопрос: "Испытывают ли из-за этого реальные пользователи боль или разочарование?" Если нет — алерт, скорее всего, неважный.

3. Действительный (Valid, Actionable): "В алерте есть вся информация для начала работы"¶

Суть: Алерт должен содержать конкретную диагностическую информацию и чётко указывать на симптом, а не быть криком "что-то не так!".

Что это значит: сообщение алерта должно отвечать на вопросы: Что сломалось? Насколько серьёзно? Где локализована проблема (какой сервис, хост, регион)?
Пример действительного алерта: "Сервис catalog_service в регионе pd-77 не отвечает на health checks более 2 минут. 100% трафика на него возвращает 503. Автоматическое восстановление не сработало."
Пример НЕ действительного "алерта": "Высокая латенси." → высокая — это сколько? У какого сервиса? В каком перцентиле? По такому алерту невозможно начать работу.

Аллегория: Вызов скорой помощи. Вы говорите: "У мужчины 50 лет сильная боль в груди, отдающая в левую руку, уже 15 минут, находится по адресу...". Это действительный вызов. Фраза "Мне плохо!" без деталей — нет.

Как проверить: Получив алерт, инженер должен понимать, куда ему идти (какой дашборд открыть) и что искать, а не гадать с чего начать.

4. Требующий реакции (Requiring Human Action): "Человек может и должен что-то сделать"¶

Самый важный критерий. Алерт должен быть направлен на проблему, которую человек может исправить или хотя бы начать исследование. Если система уже делает всё, что может, или проблема не требует вмешательства, алерт бесполезен.

Что это значит: У инженера, получившего алерт, должен быть набор возможных действий: перезапустить сервис, откатить релиз, позвонить в ЦКЗ, запустить диагностический скрипт, эскалировать другой команде.
Пример алерта, требующего реакции: "База данных master-реплика упала. Автоматическое переключение на standby не удалось. Требуется ручное вмешательство для восстановления отказоустойчивости." → чёткое требование действия.
Пример НЕ требующего реакции "алерта": "Сеть между дата-центрами имеет повышенную потерю пакетов (0.5%)." → что должен сделать инженер? Позвонить провайдеру? У него нет таких полномочий. Это мониторинг для сетевой команды, а не алерт для дежурного SRE.

Аллегория: Датчик давления в шинах. Если он просто показывает низкое давление — это информация. Если он начинает громко пищать и показывает инструкцию "Немедленно остановиться, опасность разрыва шины!" — это требует реакции.

Как проверить: спросите: "Какое конкретное действие должен предпринять дежурный инженер в течение 5 минут после получения этого алерта?" Если ответа нет — алерт ложный.

Что происходит, когда принципы нарушаются? Эпидемия "усталости от алертов"¶

Представьте команду, где каждый инженер получает сотни алертов в неделю, и 95% из них - ложные или не требуют реакции. Вот последствия: 1. Игнорирование всех алертов. Люди отключают пейджеры, пропускают звонки. 2. Выгорание. Постоянный стресс из-за ложных срабатываний разрушительнее, чем работа над реальными инцидентами. 3. Пропуск реальной катастрофы. Когда на фоне сотен криков "мальчик" появляется настоящий "волк", на него уже не обратят внимания. 4. Потеря доверия к инструментам и данным.

Практика: Как строить систему алертинга по-взрослому¶

Начинайте с "чёрного ящика" и SLO. Первые и главные алерты должны быть на нарушение ключевых SLO (ошибки, задержка, доступность). Это гарантирует важность.
Реализуйте многоуровневый подход.
- Уровень 1: Автоматическое восстановление. Система сама перезапускает упавший под, переключает трафик. Никаких алертов!
- Уровень 2: Алерты для человека. Срабатывают, когда автоматизация не справилась или требуется решение, выходящее за рамки скриптов (откат релиза, расследование аномалии).
Регулярно (ежеквартально) проводите "охоту на алерты". Просматривайте историю всех срабатываний за период. По каждому алерту задавайте вопросы:
- Он был срочным и важным? (если нет — понизить порог или превратить в уведомление)
- Он был действительным? (если нет — добавить информации в сообщение)
- Он требовал реакции? (если нет — удалить или автоматизировать реакцию)
Создавайте Runbooks. Для каждого важного алерта должен быть сопутствующий документ (runbook) с пошаговыми инструкциями по диагностике и действиям. Это делает алерт действительным.

Качественный, нормальный алертинг - это не количество, а точность. Его цель — не информировать, а мобилизовать. Каждый алерт, который срабатывает в системе, должен быть настолько весомым и обоснованным, чтобы инженер, проснувшись от него посреди ночи, первым делом не ругнулся, а понял — да, это серьёзно, и я знаю, что делать. Это культура уважения к времени и вниманию людей, без которой невозможно построить надёжную команду и, как следствие, надёжный сервис.