---
name: sre-incident-postmortem
description: >
  Структурирует blameless-постмортем после инцидента — timeline, impact, root cause,
  contributing factors, action items. Использует данные из incident channel, метрик
  и логов. Используй, когда пользователь хочет «написать постмортем», «разобрать
  инцидент», «оформить разбор», «blameless review», «итоги инцидента».
---

# sre-incident-postmortem — Blameless постмортем

Цель: превратить хаос инцидента в структурированный документ, из которого команда извлечёт уроки.

Перед началом прочитай:
- `~/.claude/rules/sre-incident-severity.md` — шкала и контракт реакции
- `~/.claude/rules/sre-runbook-template.md` — стиль изложения процедур

## Принципы blameless-постмортема

- **Системы и процессы**, не люди. Не «X выкатил плохой код» → «релиз-пайплайн пропустил unsafe-миграцию без guard».
- **Контрфакты и обучение**, не наказание. Цель — чтобы в следующий раз система отработала лучше.
- **Честно про неизвестное.** Если не знаем root cause — пишем «не установлено» с гипотезами, а не выдумываем.

## Шаг 1. Собери исходники

Спроси у пользователя или найди:
- timeline из incident channel (Slack/Teams) — все сообщения от detect до resolved
- alerts, которые сработали (имя, время, severity)
- dashboards / графики с метриками на период инцидента
- логи и трейсы с подозрительными ошибками
- ссылки на затронутые сервисы и тикеты

Если данных не хватает — **остановись и попроси у пользователя**, не выдумывай.

## Шаг 2. Заполни шапку

```markdown
# Postmortem: <короткий заголовок инцидента>

| Поле | Значение |
|------|----------|
| Дата | YYYY-MM-DD |
| Длительность | от HH:MM до HH:MM UTC (X часов Y минут) |
| Severity | SEV-1 / SEV-2 / ... |
| Затронутые сервисы | ... |
| Затронутые пользователи | оценка количества / % |
| Incident commander | имя |
| Authors | имена |
| Status | draft / under review / approved |
```

## Шаг 3. Summary (TL;DR)

Один абзац: что случилось, как долго, кого затронуло, как починили. Без жаргона — чтобы менеджер понял.

## Шаг 4. Impact

Конкретные числа:
- сколько запросов было затронуто (5xx, timeouts)
- сколько пользователей увидели ошибку
- бизнес-метрики (потерянная выручка, заблокированные операции — если применимо)
- SLO budget burn

## Шаг 5. Timeline

Хронология с временными метками, **в UTC** (или явно укажи timezone):

```markdown
| Время | Что произошло |
|-------|---------------|
| 10:23 | Деплой v1.42 в production |
| 10:31 | Alert: API error rate > 5% (PagerDuty paged on-call) |
| 10:34 | On-call ACK, поднял incident channel #inc-2026-05-23 |
| 10:39 | Detected: миграция БД не завершилась, query timeouts |
| 10:42 | Откат деплоя начат |
| 10:51 | Метрики вернулись к baseline |
| 11:06 | Стабильно 15 минут — declared resolved |
```

Включи все ключевые точки: detection, escalation, диагностика, гипотезы, mitigation, recovery, post-incident.

## Шаг 6. Root cause

Опиши **причинно-следственную цепочку**, а не одну строку.

Полезный приём — техника «5 Whys» (но без фанатизма):
- Сервис упал → потому что connection pool exhausted
- Почему pool exhausted? → DB-запросы стали медленнее в 10×
- Почему медленнее? → новая миграция добавила NOT NULL без default, full table scan
- Почему миграция прошла без алерта? → нет автоматической проверки плана миграции на больших таблицах
- Почему не было ручной проверки? → процесс ревью миграций не требует DBA, runbook не упоминает

Финальный root cause не «миграция плохая», а «процесс ревью миграций не покрывает sizing-проверки».

## Шаг 7. Contributing factors

Что усугубило, но не было первопричиной:
- алерт сработал на 8 минут позже, чем должен был
- runbook не был обновлён после прошлой похожей ошибки
- on-call не знал про feature flag, который мог быстро смитигейтить

## Шаг 8. What went well

Не только проблемы — что сработало:
- алерт всё-таки сработал
- rollback занял 2 минуты
- incident commander чётко вёл коммуникацию

Это важно для морали и для понимания, что не нужно менять.

## Шаг 9. Action items

Каждый — с **владельцем**, **дедлайном** и **приоритетом**.

```markdown
| # | Действие | Owner | Due | Priority | Status |
|---|----------|-------|-----|----------|--------|
| 1 | Добавить автопроверку миграций на размер таблиц | @alice | 2026-06-15 | P0 | open |
| 2 | Обновить runbook db-migrations.md разделом про NOT NULL | @bob | 2026-05-30 | P1 | open |
| 3 | Game day: симулировать timeout на больших таблицах | @sre-team | 2026-Q3 | P2 | open |
```

Каждый action item должен **закрывать конкретный gap**, не быть общим («улучшить процесс»).

## Шаг 10. Покажи и спроси

Покажи драфт пользователю. Спроси:
1. Принять и сохранить
2. Поправить (что именно — timeline / root cause / action items)
3. Запросить ещё информации (что нужно)

Не публикуй / не пересылай — только пользователь решает, куда документ идёт.

## Чего не делать

- Не упоминай людей в негативном контексте — даже косвенно
- Не пиши «human error» как root cause — это всегда системная проблема
- Не сваливай action items в один пункт «отрефакторить деплой» — дроби на исполнимые
- Не выдумывай числа impact — лучше «оценка ~5000 запросов» с пометкой «оценка», чем выдуманные «4823 запроса»