Инцидент закрыт. Что дальше?
Сервис восстановлен, пользователи довольны, status page зелёная. Команда выдохнула и вернулась к обычной работе. Через три недели тот же сервис падает по той же причине.
Это не невезение. Это предсказуемый результат отсутствия post-incident review. Инциденты — сигналы о слабых местах в системе. Если не разобрать сигнал, система сообщит о проблеме повторно — уже громче.
Post-incident review (PIR), также известный как post-mortem, — структурированный процесс анализа инцидента. Цель — не найти виноватого, а понять, какие системные условия привели к сбою, и предотвратить повторение.
Blameless-культура: что это на практике
«Blameless» — не buzzword и не благотворительность. Это инженерный подход, который даёт лучшие результаты. Когда люди боятся наказания, они скрывают информацию. Когда скрывают информацию, root cause analysis неполный. Когда анализ неполный, action items не решают настоящую проблему.
Вместо: «Кто задеплоил этот код без тестов?»
Спрашиваем: «Почему CI/CD pipeline позволил деплой без прохождения тестов? Какие guardrails отсутствовали?»
Вместо: «Почему ты не заметил алерт 40 минут?»
Спрашиваем: «Почему алерт пришёл только через 40 минут? Как настроен routing? Есть ли escalation policy?»
Blameless не значит «без ответственности». Ответственность переносится с людей на системы. Инженер, который задеплоил баг, не виноват. Виновата система, где нет canary-деплоя, автоматических rollback-ов и smoke tests после деплоя.
Когда проводить PIR
Не каждый инцидент требует формального PIR. Если проводить review на каждый P4, команда быстро устанет, и process потеряет ценность. Критерии для проведения PIR:
| Критерий | Проводить PIR? |
|---|---|
| P1 (Critical) — полный outage | Всегда |
| P2 (Major) — значительная деградация | Всегда |
| P3 с customer impact > 15 минут | Да |
| Near-miss (чуть не стало P1) | Да |
| P3 без пользовательского влияния | По решению команды |
| P4 (Low) — косметические проблемы | Нет |
Оптимальное время для PIR — 24-48 часов после восстановления. Раньше — команда ещё в стрессе, не все детали собраны. Позже — люди забывают нюансы, логи могут ротироваться, Slack-треды уходят в архив.
Кто должен присутствовать
Правильный состав участников — половина успеха PIR. Слишком мало людей — неполная картина. Слишком много — встреча превращается в лекцию.
Обязательные участники
Incident commander (или тот, кто координировал response). Все инженеры, которые непосредственно участвовали в устранении. Engineering lead затронутого сервиса. Если инцидент затронул несколько команд — lead от каждой.
Опциональные участники
Product manager — если нужен контекст по customer impact и бизнес-последствиям. Customer support lead — если были обращения пользователей, и важно понять, как улучшить коммуникацию. SRE/platform team — если инцидент вскрыл системную проблему (например, недостаток мониторинга или слабость инфраструктуры).
Оптимальное количество — 4-8 человек. Больше 10 — встреча теряет продуктивность. Остальные могут прочитать документ после.
Структура PIR-встречи
Встреча длится 30-60 минут. Для сложных P1 с multi-team involvement — до 90 минут, но не больше. Структура из четырёх блоков:
1. Реконструкция таймлайна (10-15 мин)
Восстановите хронологию событий от первых признаков до полного восстановления. Источники: данные мониторинга (когда алерт сработал, когда detection произошёл), Slack-логи, git history, deployment logs, status page updates.
Ключевые точки в таймлайне: когда проблема началась (не когда заметили — а когда реально началась), когда мониторинг обнаружил, сколько прошло до первого ответа, когда начался активный troubleshooting, когда нашли причину, когда применили fix, когда подтвердили восстановление.
Если используете мониторинг с multi-region проверками, данные detection и recovery timestamps берутся напрямую из incident timeline — не нужно восстанавливать по памяти.
2. Root Cause Analysis (15-20 мин)
Техника «5 Whys» — проверенный способ добраться до корневой причины. Каждый «почему» должен двигать глубже, от симптома к системной причине.
Проблема: API возвращал 500 ошибок 47 минут
Why 1: Почему API возвращал 500?
→ Database connection pool исчерпан.
Why 2: Почему connection pool исчерпан?
→ Один медленный query держал соединения по 30 секунд вместо 200ms.
Why 3: Почему query стал медленным?
→ Вчера задеплоили миграцию, которая удалила индекс.
Why 4: Почему миграция удалила индекс?
→ Автогенерированная миграция Django включила DROP INDEX,
и это не заметили на code review.
Why 5: Почему это не поймали?
→ Нет автоматической проверки миграций на destructive operations.
Review checklist не включает проверку SQL-плана миграций.
Root cause: Отсутствие automated migration review в CI pipeline.Обратите внимание: root cause — не «кто-то задеплоил плохую миграцию». Root cause — отсутствие автоматизированной проверки. Это системная проблема, которую можно исправить.
3. Что сработало / что не сработало (10 мин)
Не пропускайте позитивную часть. Если detection time составил 2 минуты вместо обычных 10 — это победа, и нужно понять, что именно сработало, чтобы закрепить результат. Если rollback прошёл за 3 минуты — зафиксируйте, какие процессы это обеспечили.
Что не сработало: runbook был устаревшим, escalation пошёл не тому человеку, monitoring не покрывал failed endpoint, rollback потребовал ручных действий вместо автоматических. Каждый пункт — потенциальный action item.
4. Action Items (10 мин)
Каждый action item должен иметь три атрибута: описание, owner и deadline. «Улучшить мониторинг» — не action item. «Добавить алерт на connection pool utilization > 80% — @alex — до 15 апреля» — action item.
Категории action items: prevent (не допустить повторения), detect (обнаружить быстрее), respond (реагировать эффективнее), mitigate (уменьшить последствия).
Шаблон Post-Incident Review
Готовый шаблон, который можно скопировать в Notion, Confluence, Google Docs или любой wiki. Заполняется во время или сразу после PIR-встречи.
# Post-Incident Review: [Название инцидента]
## Summary
- **Date**: YYYY-MM-DD
- **Duration**: X hours Y minutes
- **Severity**: P1 / P2 / P3
- **Incident Commander**: @name
- **Author**: @name
- **Status**: Draft / Reviewed / Final
## Impact
- Users affected: [число или % пользователей]
- Revenue impact: [если применимо]
- SLA impact: [нарушен ли SLA, какой именно]
- Customer communications sent: [да/нет, сколько]
## Timeline (UTC)
| Time | Event |
|-------|------------------------------------------|
| 14:00 | Deployment of v2.3.1 started |
| 14:05 | First 500 errors in monitoring |
| 14:07 | Alert fired, on-call paged |
| 14:12 | IC confirmed, incident channel opened |
| 14:25 | Root cause identified: missing index |
| 14:30 | Rollback initiated |
| 14:33 | Rollback complete, errors clearing |
| 14:45 | Monitoring confirms full recovery |
## Detection
- How was the incident detected? [monitoring alert / user report / internal]
- Time from start to detection: [X minutes]
- Time from detection to first response: [X minutes]
## Root Cause
[5 Whys или развёрнутый анализ]
## Contributing Factors
- [Фактор 1: что усугубило ситуацию]
- [Фактор 2: что замедлило recovery]
## What Went Well
- [Что сработало: быстрый detection, эффективный rollback и т.д.]
## What Didn't Go Well
- [Что подвело: устаревший runbook, медленный escalation и т.д.]
## Action Items
| # | Action | Owner | Deadline | Status |
|---|---------------------------------|--------|------------|--------|
| 1 | Add migration lint to CI | @alex | 2026-04-01 | Open |
| 2 | Set up connection pool alerts | @maria | 2026-03-28 | Open |
| 3 | Update rollback runbook | @ivan | 2026-04-05 | Open |
| 4 | Add canary deployment stage | @alex | 2026-04-15 | Open |
## Lessons Learned
[2-3 ключевых вывода]Action Items: от документа к результату
Action items — самая ценная часть PIR и одновременно самая уязвимая. По данным Google SRE, около 40% action items из post-mortem-ов не выполняются в срок, если за ними не следить отдельно.
Правила эффективных action items
Каждый action item должен быть SMART: конкретный (не «улучшить», а «добавить»), измеримый (чёткий definition of done), с ответственным, реалистичный, с дедлайном.
Заведите action items в тот же трекер, где живут обычные задачи — Jira, Linear, GitHub Issues. Если action items хранятся только в PIR-документе, их не увидят на sprint planning и не включат в работу. Отдельный лейбл (например, pir-action) помогает фильтровать и отслеживать.
Еженедельный review открытых PIR action items — 5-минутный блок на standup или отдельная секция в SRE-weekly. Если action item буксует две недели подряд — эскалация к engineering manager.
Как данные мониторинга помогают PIR
Качественный мониторинг превращает PIR из «кажется, было так» в «данные показывают вот что». Ключевые метрики для PIR:
Time to Detect (TTD) — от начала проблемы до срабатывания алерта. Если TTD больше 5 минут на P1, нужны дополнительные health checks или уменьшение интервала проверок.
Time to Acknowledge (TTA) — от алерта до первого ответа. Если TTA больше 15 минут, проблема в on-call rotation или notification routing.
Time to Mitigate (TTM) — от первого ответа до восстановления. Если TTM больше 30 минут, нужны лучшие runbooks или автоматизированный rollback.
Recovery Confirmation — данные мониторинга подтверждают, что сервис действительно восстановлен, а не просто «вроде работает». Multi-region проверки из нескольких локаций дают объективное подтверждение.
Типичные ошибки при проведении PIR
Поиск виноватого вместо системных причин
Если после PIR инженер чувствует себя виноватым — review провалился. В следующий раз этот инженер будет скрывать контекст, и root cause analysis станет неполным. Фасилитатор должен перенаправлять обсуждение: «Мы не обсуждаем, кто ошибся. Мы обсуждаем, почему система позволила эту ошибку».
Нет follow-through по action items
Самая распространённая проблема. Команда проводит отличный PIR, пишет правильные action items, а через месяц ни один не выполнен. PIR без execution — трата времени. Если вы не готовы отслеживать action items, лучше не проводить PIR вообще — хотя бы не будет иллюзии, что «мы разобрались».
PIR-документ как роман
Документ на 15 страниц никто не прочитает. Эффективный PIR-документ: 2-3 страницы максимум. Таймлайн — таблица, не проза. Root cause — 5 Whys, не диссертация. Action items — таблица с owner и deadline. Всё остальное — в appendix или ссылками на Slack-треды и dashboards.
Пропуск PIR для «простых» инцидентов
«Мы просто перезагрузили сервер, всё починилось». Без PIR вы не узнаете, почему сервер потребовал перезагрузки. Memory leak? OOM killer? Zombie processes? Первый раз — случайность. Второй — паттерн. Третий — системная проблема, о которой вы ничего не знаете, потому что «просто перезагружали».
Action items без приоритетов
10 action items одинакового приоритета — это 0 action items. Разделите на «prevent» (предотвращение повторения — высший приоритет), «detect» (ускорение обнаружения — средний), и «improve» (улучшение процессов — может подождать). Первые 2-3 «prevent» items должны быть выполнены до следующего sprint review.
Чеклист перед PIR-встречей
1. Таймлайн черновик готов (из данных мониторинга + Slack logs)
2. Все участники приглашены, конфликтов в расписании нет
3. Фасилитатор назначен (не incident commander — нужен свежий взгляд)
4. Шаблон PIR-документа создан и предзаполнен
5. Доступ к dashboards, логам, deployment history открыт для участников
6. Severity и impact предварительно оценены
7. Напоминание о blameless-подходе в приглашении
PIR как инструмент роста команды
Команды, которые регулярно проводят PIR, не просто меньше падают — они быстрее растут. Каждый PIR даёт инженерам deeper understanding системы, которую они строят. Junior-разработчик, который участвует в разборе P1-инцидента, за один час узнаёт о production-реальности больше, чем за месяц чтения документации.
PIR-документы со временем становятся библиотекой знаний. Новые члены команды читают последние 5-10 PIR и получают реальную картину: какие сервисы проблемные, какие паттерны сбоев повторяются, как команда решает проблемы. Это контекст, который не получить из README или architecture docs.
Связанные материалы
Incident Management от А до Я — полный гайд по управлению инцидентами: от обнаружения до закрытия.
Incident Severity Levels: P1-P4 Classification Guide — как правильно классифицировать инциденты по уровню критичности.
Incident Communication Templates — шаблоны коммуникации во время инцидентов: status page, email, Slack.
On-Call Rotation Best Practices — как построить дежурство без выгорания и alert fatigue.
FAQ
What is a post-incident review (PIR)?
A post-incident review is a structured meeting held after a significant incident to analyze what happened, why it happened, and how to prevent recurrence. Unlike blame-focused investigations, modern PIRs follow a blameless approach: they focus on systemic causes rather than individual mistakes. The output is a document with timeline, root cause analysis, contributing factors, and actionable follow-ups with owners and deadlines.
When should you conduct a post-incident review?
Run a PIR for every P1 and P2 incident. For P3 incidents, run one if customer impact exceeded 15 minutes or if the incident revealed a systemic weakness. Also consider a PIR for near-misses that could have escalated. Schedule the review 24-48 hours after resolution: soon enough that details are fresh, but late enough that the team has recovered from incident stress.
What is a blameless post-mortem?
A blameless post-mortem assumes that people acted with the best information available at the time. Instead of asking 'who caused this?', it asks 'what conditions allowed this to happen?' and 'what systemic changes prevent recurrence?' This doesn't mean no accountability—it means accountability shifts from individuals to systems. Engineers who deployed bad code aren't blamed; instead, the review asks why CI/CD didn't catch the issue, why rollback was slow, or why monitoring didn't detect the regression.
How long should a post-incident review meeting take?
30-60 minutes for most incidents. P1 incidents with complex timelines may need 90 minutes. If your PIR regularly exceeds 60 minutes, you're likely going too deep during the meeting itself. Focus the meeting on timeline alignment, root cause discussion, and action item assignment. Detailed writeup can happen asynchronously after the meeting. Never let a PIR run past 90 minutes—diminishing returns are severe.
Who should attend a post-incident review?
Required: incident commander, all responders who participated, engineering lead for the affected system. Optional: product manager (for customer impact context), customer support lead (for user communication learnings), SRE/platform team (for systemic patterns). Keep it under 10 people. Observers can read the document afterward. If someone wasn't involved in the incident or doesn't own a contributing system, they don't need to be in the room.
How do you ensure action items from PIRs actually get completed?
Three practices: (1) Every action item gets an owner and a deadline during the meeting—no unassigned items. (2) Track PIR action items in the same issue tracker as regular work (Jira, Linear, GitHub Issues)—not in a separate document that nobody checks. (3) Review open PIR action items weekly in team standup or SRE review. If action items consistently stall, escalate to engineering management. Incomplete PIR actions are a leading indicator of repeat incidents.