Alerting playbook

Действуй как Incident Commander. Спроектируй alerting policy для команды из {{team_size}} человек с текущей нагрузкой {{current_pages_per_week}} page/неделю.

Что сделать

1. Symptom vs cause alerting. Alert на симптом (user-facing impact), не на причину (CPU 90%).

   • Symptom: «availability сервиса < SLO», «p99 latency > 1s», «очередь обработки > 5 минут лага». Алертит на то, что чувствует пользователь.
   • Cause: «CPU 95%», «disk 80%». Полезно как контекст в дашборде, но page'ить ради этого = ложные срабатывания (CPU может быть 95% штатно).
   • Правило: «может ли пользователь жаловаться прямо сейчас?» Нет → не page, скорее ticket.

2. Severity tiers. Чёткие критерии, кто и когда реагирует. Один и тот же alert не может быть P1 в среду и P3 в субботу — это значит критерии нечёткие.

   • P1 (page, 24/7). Active customer impact, SLO выгорает быстро. Reaction: 5 минут. Примеры: API down, checkout не работает, данные теряются.
   • P2 (page в рабочие часы, ticket вне). Угроза SLO, деградация без полного отказа. Reaction: 30 минут в рабочее, утром в нерабочее. Пример: один регион из трёх медленный, fallback работает.
   • P3 (ticket). Деградация без impact'а, capacity warning, expiring cert через 14 дней. Reaction: следующий рабочий день.
   • P4 (FYI, no action). Чисто информационный сигнал в #ops-events. Не должен будить.

3. Routing. Куда летит и кому. Чёткая матрица — иначе alert падает в неправильный канал и теряется.

   • PagerDuty / Opsgenie: только P1 и P2 (в рабочее). Escalation policy: 5 мин primary → 10 мин secondary → 15 мин manager. SMS+phone, не push (push теряются).
   • Slack #alerts-{service}: P3, аккумулируются для daily triage. Threaded по alert ID, не «10 одинаковых сообщений».
   • Email / тикет: P4, для аудита.
   • Маршрутизация по сервису, не по типу alert'а — owner team получает свои alerts, не все подряд.

4. Alert fatigue prevention. Каждый ложный page стоит реальных $ (потерянный сон, дрожащие руки на следующем page) — лечи как production issue.

   • Бюджет page'ей: ≤ 2 P1 page/неделю/инженер. Превышение → ретроспектива «откуда шум».
   • Hysteresis: alert firing for > 5 min, resolving on < 1 min. Иначе flapping заливает чат.
   • Auto-resolve: если состояние ушло — alert закрывается автоматически. Не оставляй «висящие» инциденты.
   • Mute window'ы: запланированные maintenance — silence заранее, чтобы не page'ить дежурного «потому что мы сами делали deploy».
   • Группировка: 100 pods падают за одну минуту = один alert «service X is failing N pods», не 100 отдельных.
   • Ежемесячный audit: список «alert → page count → real incidents». Если alert ни разу не был реальным инцидентом за 3 месяца — удалить или понизить severity.

5. Runbook в каждом alert'е. Без runbook'а alert = «иди разбирайся в 3 часа ночи».

   • Поля alert payload: title, severity, owner, dashboard link, runbook link, последние deploy'и (для корреляции).
   • Runbook структура: Symptoms (что видим) → Verify (как подтвердить, что это реально) → Mitigate (как остановить кровотечение, 1-2 шага) → Investigate (как найти причину) → Escalate (кому звонить, если не помогает).
   • Runbook в репозитории сервиса (markdown), ссылка автогенерируется в alert. Не Confluence страница, которую никто не находит в 3 ночи.

Anti-patterns

• ❌ «Page on every error log» — гарантированный alert fatigue.
• ❌ Один общий канал #alerts на всю компанию — никто не читает, всё теряется.
• ❌ P1 без runbook'а — каждый incident начинается с «а что вообще делать».
• ❌ Alert на основе abs threshold без учёта seasonality (traffic спадает ночью, alert на «low rps» firing-ит каждую ночь).
• ❌ «Дежурим всем отделом» вместо on-call ротации — ответственность размыта, никто не реагирует первым.

Формат вывода

## Severity matrix
| Severity | Page? | Channel | Escalation | Reaction time | Examples |

## Alert catalog (per service)
| Alert | Symptom/Cause | Severity | Threshold | Hysteresis | Runbook |

## Routing rules
| Service | Owner team | Primary | Secondary | Hours |

## Fatigue metrics (track monthly)
- Pages per engineer/week
- False-positive rate
- Top noisy alerts (top-5)
- MTTA / MTTR

## Audit checklist (monthly)
- [ ] Каждый alert fired ≥ 1 раз? Если нет — зачем он?
- [ ] Каждый page → real incident? Если нет → понизить severity
- [ ] Runbook у каждого P1/P2? Если нет — alert disabled

Принцип: alerting — это не «много метрик в чате». Это контракт «когда меня будят, это правда важно». Сломанный контракт — единственная причина, почему опытные SRE уходят.