| 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. Заполни шапку
# 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):
| Время | Что произошло |
|-------|---------------|
| 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
Каждый — с владельцем, дедлайном и приоритетом.
| # | Действие | 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. Покажи и спроси
Покажи драфт пользователю. Спроси:
- Принять и сохранить
- Поправить (что именно — timeline / root cause / action items)
- Запросить ещё информации (что нужно)
Не публикуй / не пересылай — только пользователь решает, куда документ идёт.
Чего не делать
- Не упоминай людей в негативном контексте — даже косвенно
- Не пиши «human error» как root cause — это всегда системная проблема
- Не сваливай action items в один пункт «отрефакторить деплой» — дроби на исполнимые
- Не выдумывай числа impact — лучше «оценка ~5000 запросов» с пометкой «оценка», чем выдуманные «4823 запроса»
