Actionable alerts
Тема дорожной карты · Observability
Actionable-алерт — это алерт, который при срабатывании чётко указывает на реальную проблему, требующую вмешательства человека, предоставляет достаточно контекста для понимания серьёзности и масштаба проблемы и содержит ссылку на runbook с конкретными шагами по устранению. Принцип, согласно которому каждый алерт должен быть actionable, — это антидот от усталости от алертов: если инженер не может описать, что он сделает при срабатывании алерта, то такого алерта не должно существовать. Actionable-алерты включают название затронутого сервиса, нарушаемый SLI или SLO, ссылку на соответствующий дашборд Grafana и ссылку на соответствующий runbook. Они прописываются в alerting_rules.yml Prometheus с осмысленными полями annotations — summary, description и runbook_url, — которые отображаются непосредственно в уведомлениях PagerDuty и Slack. Регулярный анализ истории алертов в процессах постмортемов помогает командам определять, какие алерты неизменно приводят к содержательным действиям, а какие следует заглушить или преобразовать в информационные тикеты.
Как это работает
Actionable alerts соединяет observability-данные с людьми через on-call ротации. Инструменты: Alertmanager (Prometheus-native), Grafana Alerting (multi-source), PagerDuty / OpsGenie / Squadcast (incident management поверх). Правила оценивают metrics/logs/traces-запросы; срабатывают при for: 5m; роутятся по labels (severity: page vs severity: ticket); идут в каналы (PagerDuty, Slack, Telegram, webhook). SLO burn-rate alerts — современный best practice.
Когда применять
Алертите на симптомы (SLO burn rate, error rate, latency), не на причины (CPU, RAM). Multi-window multi-burn-rate alerts — fast pages для внезапно-плохого, slow tickets для постепенной деградации. Всегда runbook URL в annotations. Тестируйте алерты в staging до production. Аудитьте alert fatigue раз в квартал — убивайте алерты, на которые никто не реагирует.
Типичные ошибки
Ловушки Actionable alerts: pages на инфра-метриках, не затрагивающих юзеров (CPU > 80% на 12-ядерном боксе в 3:00 на non-user-facing job); flapping-алерты (нет for:); алерты без runbook = хаос в 3:00; все алерты в один Slack-канал (alert fatigue).