Предотвращение переизбытка алертов

1) Проблема и цель

Alert fatigue возникает, когда система шлет слишком много нерелевантных или не actionable уведомлений. Итог — игнорирование пейджей, рост MTTA/MTTR и пропуск настоящих инцидентов.
Цель: сделать сигналы редкими, значимыми и исполнимыми, привязав их к SLO и плейбукам.

2) Таксономия сигналов (канал = последствия)

Page (P0/P1) — будит человека; только когда требуется ручное действие сейчас и есть runbook.
Ticket (P2) — асинхронная работа в часы/день; не будит, но трекается по SLA.
Dash-only (P3) — наблюдение/тренд без активных действий; не создает шум.
Silent Sentry — метрики/аудит в бэкграунде (для RCA/пост-мортемов).

3) Проектирование “правильного” алерта

• Цель/гипотезу (что защищаем: SLO, безопасность, деньги, комплаенс).
• Условия срабатывания (порог, окно, кворум источников).
• Runbook/Playbook (краткий ID шага + ссылка).
• Владельца (команда/ролевая группа).
• Критерии завершения (когда закрывать, авто-резолв).
• Класс уязвимости (user-impact / platform / security / cost).

4) SLO-ориентированный мониторинг

SLI/SLO → первичные сигналы: доступность, латентность, успешность бизнес-операций.

• Короткое: 5% бюджета за 1 час → Page.
• Длинное: 2% бюджета за 6 часов → Ticket.
• Когортность: алерты по регионам/провайдерам/VIP-сегментам — меньше ложных глобальных тревог.

5) Техники снижения шума

1. Кворум зондов: срабатывание только если ≥2 независимых источника (разные регионы/провайдеры) подтверждают проблему.
2. Дедупликация: группировка одинаковых событий (aggregation keys: service+region+code).
3. Гистерезис/длительность: “в красной зоне ≥ N минут”, чтобы отфильтровать шипы.
4. Rate-limit: не более X оповещений/час/сервис; при превышении — один пейдж + сводка.
5. Auto-snooze/интеллектуальное подавление: повторяющийся алерт в окне T → перевод в Ticket до устранения корня.
6. Корреляция событий: один “мастер-алерт” вместо десятков симптомов (напр., “БД недоступна” глушит 5xx из микросервисов).
7. Maintenance окна: плановые работы автоматически подавляют ожидаемые сигналы.
8. Anomaly + guardrails: аномалии — только как Ticket, если нет подтверждения SLO-сигналом.

6) Маршрутизация и приоритеты

Приоритеты: P0 (Page, 15 мин апдейты), P1 (Page, 30 мин), P2 (Ticket, 4–8 ч), P3 (наблюдение).
Роутинг по ярлыкам: service/env/region/tenant → соответствующий on-call.
Эскалации по времени: нет ack за 5 мин → P2 → Duty Manager / IC.
Quiet Hours: ночные часы для некритичных; Page запрещен для P2/P3.
Fatigue-политика: если у инженера >N пейджей/смену — перераспределить на P2, эскалировать загрязнение сигналов.

7) Качество алертов: договоренности

Actionability ≥ 80%: подавляющее большинство пейджей ведут к действию по runbook.
False Positive ≤ 5% для Page-сигналов.
Time-to-Fix-Alert ≤ 7 дней — дефектный алерт должен быть исправлен/удален.
Ownership 100% — каждый алерт имеет владельца и репозиторий с его определением.

8) Жизненный цикл алерта (Alert as Code)

1. Создать PR (описание цели, условия, runbook, владелец, тестовый план).
2. Песочница/Shadow: тень-алерт пишет в чат/лог, но не пейджит.
3. Канарейка: ограниченная аудитория on-call, измеряем FP/TP.
4. Прод: включение с rate-limit + наблюдение 2–4 недели.
5. Еженедельный review: метрики качества, правки/изъятие.
6. Депрекейт: если сигнал дублирует более высокий или не actionable.

9) Метрики зрелости (покажите на дашборде)

Alerts per on-call hour (медиана/95-перцентиль).
% actionable (есть выполненные шаги) и false-positive rate.
MTTA/MTTR вокруг пейджей и доля page→ticket (не должно быть высоким).
Top-talkers (сервисы/правила, генерирующие ≥20% шума).
Mean time to fix alert (от первого FP до изменения правила).
Burn-rate coverage: доля сервисов с SLO-алертами в двух окнах.

10) Чек-лист “Гигиена алертов”

• Алерт привязан к SLO/SLI или к бизнес/безопасности.
• Есть runbook и владелец; указаны контакт и канал war-room.
• Настроены два окна (короткое/длинное) и кворум источников.
• Включены дедуп, rate-limit, auto-resolve и auto-snooze.
• Указаны maintenance окна и suppression при релизах/миграциях.
• Пройден Shadow/Canary; измерены FP/TP.
• Включен отчет по метрикам качества алертов.

11) Мини-шаблоны

Спецификация алерта (YAML-идея)

yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]

Текст апдейта по стандарту (для уменьшения шума)

Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.

12) Процессы: еженедельный “Alert Review”

1. Топ-шумные правила (top-talkers) → правим/удаляем.

2. FP/TP по Page-сигналам → корректируем пороги/окна/кворум.

3. Претенденты на понижение канала (Page→Ticket) и наоборот.

4. Статус “Time-to-Fix-Alert” — просрочки эскалируются владельцам сервисов.

5. Проверка coverage SLO-алертами и наличия runbook’ов.

13) Связь с релизами и операциями

Аннотации релизов автоматически добавляют временные подавления.
Change windows: в первые 30 мин после релиза — только SLO-сигналы.
Плейбуки содержат шаг “понизить/подавить неключевые алерты”, чтобы концентрироваться на корне.

14) Безопасность и комплаенс

Security-сигналы (взлом/утечка/аномальные доступы) — отдельные каналы, без quiet hours.
Аудит-лог всех подавлений/тихих окон: кто, когда, почему, срок.
Требование неизменяемости для критичных алармов (подпись события).

15) Анти-паттерны

“Каждый график = алерт” → лавина.
Порог “!= 0 ошибок” в проде.
Один зонд/один регион как источник истины.
Page без runbook/владельца.
Вечные “временные подавления” без срока.
“Починим потом” дефектные алерты — копятся годами.
Смешивание релизного шума с продукционными инцидентами.

16) Дорожная карта внедрения (4–6 недель)

1. Инвентаризация: выгрузить все алерты, проставить владельцев и каналы.
2. SLO-ядро: ввести burn-rate правила с двойными окнами по критичным сервисам.
3. Шум-контроль: включить кворум, дедуп и rate-limit, завести weekly review.
4. Runbook-покрытие: закрыть 100% Page-сигналов плейбуками.
5. Фатиг-политика: лимиты пейджей/смену, Quiet Hours, перераспределение нагрузки.
6. Автоматизация: Alert-as-Code, Shadow/Canary, отчетность по метрикам качества.

17) Итог

Тишина — это не отсутствие мониторинга, а качественно спроектированные сигналы, связанные с SLO и процессами. Кворум, двойные окна, дедуп и строгая маршрутизация превращают алерты в редкие, точные и исполнимые. Команда спит, пользователи довольны, инциденты — под контролем.