Runbook для инцидента: шаблон

# Runbook: [{{service}}] {{incident_type}}

**Severity:** SEV-1 / SEV-2 / SEV-3
**Owner:** team-name (slack channel)
**On-call:** PagerDuty schedule name
**Last updated:** YYYY-MM-DD by @author
**Last verified:** YYYY-MM-DD (game day / real incident)

---

## 1. Это оно? (симптомы)

Проверь ВСЕ три условия. Если совпадает — продолжай. Если нет — ищи другой runbook.

- [ ] **Алерт:** `HighLatencyAlert` / `5xxBurst` / `QueueLagCritical` — точное имя
- [ ] **Метрика:** `http_request_duration_seconds{service="X"} p99 > 2s` за последние 5 минут
- [ ] **Симптом у пользователя:** [конкретное наблюдение — медленный checkout / ошибки в логине]

**Похожие но НЕ это:**
- Если только увеличена latency, но 2xx-ответы — см. `high-latency.md`
- Если 5xx, но только из одного региона — см. `regional-outage.md`
- Если только background jobs тормозят — см. `worker-lag.md`

---

## 2. First response (первые 5 минут)

**Дашборд:** [ссылка на grafana / datadog с заранее настроенным view]

**Скажи в #incidents:**

**Сделай СРАЗУ (не думая):**
1. Открой дашборд (выше)
2. Открой логи: `kubectl logs -n {{service}} --tail=200 | grep ERROR`
3. Открой traces: [ссылка на jaeger/honeycomb с фильтром на error]
4. Сделай screenshot текущего состояния (для постмортема)

**НЕ делай в первые 5 минут:**
- НЕ деплой
- НЕ перезагружай поды массово
- НЕ меняй конфиг
- НЕ паникуй в публичных каналах

---

## 3. Escalation (когда звать помощь)

| Условие | Кого | Канал |
|---|---|---|
| SEV-1 (revenue impact) | Incident Commander | PagerDuty escalation |
| Не понял что происходит за 15 мин | Senior on-call | @senior-oncall in #incidents |
| Нужен доступ которого нет | Tech lead | @tech-lead-{{service}} |
| Возможна потеря данных | Database team + CTO | DM + #db-emergency |
| Влияет на другой сервис | Owner того сервиса | их PagerDuty |

**Когда поднимать статус-страницу:** > 1% пользователей затронуто на > 5 минут.

---

## 4. Что в логах и метриках

### Проверка 1: ошибки в логах
```bash
kubectl logs -n prod -l app={{service}} --since=10m | grep -E "ERROR|FATAL|panic"

kubectl rollout undo deployment/{{service}} -n prod
# или
helm rollback {{service}} <previous-revision>

flagctl set {{service}}.new_feature off --reason "incident-NNNN"

kubectl scale deployment/{{service}} --replicas=20 -n prod

# Переключение на standby DB
./scripts/failover.sh --to=replica-2 --confirm

## Принципы хорошего runbook

1. **Команды, не описания.** Не «проверьте логи» — конкретный `kubectl logs ...`.
2. **Копипаст-готово.** Команды должны работать с заменой одной переменной.
3. **Иерархия по времени:** что сделать за 1 минуту, за 5, за 15.
4. **Конкретные пороги:** не «много ошибок», а «`rate(5xx) > 10/s`».
5. **Branching:** если симптом такой → этот runbook, иначе → другой runbook.
6. **Owner viable:** на runbook обязан быть owner который его поддерживает.
7. **Verified:** game day минимум раз в квартал. Не протестированный runbook не работает.
8. **Постмортем-driven updates:** каждый инцидент → пункт в runbook что было неочевидно.

## Anti-patterns

- ❌ Runbook на 50 страниц с теорией системы — никто не прочитает в 3 часа ночи
- ❌ Команды с placeholder'ами без примера (`kubectl logs <pod>`) — какой pod, формат?
- ❌ Ссылки на дашборды без сохранённых фильтров — оператор настраивает grafana вместо тушения
- ❌ «Если что — позвони Алисе» — Алиса в отпуске, нет escalation matrix
- ❌ Не указан severity и нет критериев — нет понимания эскалировать или нет
- ❌ Recovery options без trade-offs — оператор не знает что выбрать
- ❌ Не проверяется (не было game day) — половина команд устарела
- ❌ Не обновляется по постмортемам — те же грабли
- ❌ Описывает «как работает система» вместо «что нажать» — теория не нужна в инциденте
- ❌ Игнорирует communication — статус-страница, stakeholder updates
- ❌ Шаблон постмортема не привязан — постмортем не пишется или формально
- ❌ Нет verification checklist — закрытие инцидента «на ощупь», recurrence через час

## На выходе

- Заполненный runbook по шаблону для {{incident_type}}
- Список зависимостей runbook'а (дашборды, скрипты, доступы) — что нужно подготовить заранее
- Game day сценарий (как протестировать без реального инцидента)
- Owner и расписание review (квартал)
- Связанные runbook'и для соседних симптомов