Термин пост-мортем (от лат. post mortem — «после смерти») давно вышел за пределы судебной медицины. Сегодня это стандартная практика в IT, DevOps, управлении проектами и даже геймдеве. Суть одна: разобрать инцидент или завершённый проект, чтобы не наступать на те же грабли.
В отличие от обычной ретроспективы, пост-мортем фокусируется на конкретном событии — сбое, релизе, аварии. Цель — не найти виноватых, а выявить системные причины и зафиксировать action items (пункты действий) для предотвращения повторения.
Что такое пост-мортем: определение и происхождение термина
Изначально post-mortem examination — это вскрытие трупа для установления причины смерти. В медицине термин используется веками. В IT он прижился в 1990-х благодаря культуре Site Reliability Engineering (SRE) в Google и практикам Blameless Postmortem.
Ключевое отличие от полицейского допроса: акцент на системе, а не на человеке. Если инженер нажал не ту кнопку — вопрос не в его невнимательности, а в том, почему интерфейс позволил это сделать без подтверждения.
В современном понимании пост-мортем — это структурированный документ с хронологией, анализом причин (часто по методу 5 Why или Fishbone), последствиями и планом мероприятий. Без документа — просто беседа у кулера.
⚠️ Внимание: Называть обычное совещание «пост-мортем» — ошибка. Без письменного фиксированного результата и распределённых ответственных это не пост-мортем, а обсуждение.
Виды пост-мортемов: от медицины до IT
Хотя корни термина медицинские, классификация сегодня шире. В SRE принято делить пост-мортемы по триггерам и масштабу. Понимание типа помогает выбрать глубину анализа и состав участников.
- 🏥 Медицинский / патологоанатомический — установление причины смерти, судебно-медицинская экспертиза.
- 🖥 Инцидентный (Technical Postmortem) — анализ продакшн-сбоя: падение БД, утечка памяти, ошибка деплоя.
- 🚀 Проектный (Project Postmortem) — ретроспектива по завершённому релизу или спринту: что пошло не так с терминами, скоупом, коммуникацией.
- 🎮 Геймдев-постмортем — публичный разбор разработки игры после релиза (классика: посты от Postmortem в Gamasutra / Game Developer).
- 🛡 Security Postmortem — разбор инцидента безопасности: утечка данных, взлом, DDoS.
В Kubernetes-окружении часто проводят пост-мортемы по подам — когда CrashLoopBackOff или OOMKilled становятся системными. Это уже не про один под, а про лимиты ресурсов и QoS-классы.
Что такое Blameless Postmortem?
Концепция Blameless Postmortem (беспристрастный пост-мортем) сформулирована в Google SRE. Главный принцип: человек не может быть причиной инцидента — причина всегда в системе (процессы, инструменты, документация, архитектура). Это создаёт психологическую безопасность: инженеры честно описывают действия, не боясь наказания. Без этого вы получите сглаженные отчёты, где корневая причина скрыта.
Структура эффективного пост-мортема
Хороший пост-мортем читается как повествование, а не как протокол. Обязательные секции:
- 📋 Metadata — дата, длительность инцидента, сервисы, затронутые пользователи, SEV-уровень (severity).
- 🕐 Timeline — хронология с таймзонами: когда детект, когда алерт, когда митигация, когда резолюция.
- 🔍 Root Cause Analysis (RCA) — корневая причина. Используйте 5 Why или диаграмму Ишикавы (Fishbone).
- 💥 Impact — метрики: % пользователей, потеря выручки, SLA breach, репутационные риски.
- ✅ Action Items — конкретные задачи с владельцем и дедлайном. Формат: «Внедрить canary-деплой для сервиса X к Q2 — @ivan».
- 📎 Appendices — графики Grafana, логи, скриншоты дашбордов, ссылки на PR/тикеты.
Секция Action Items — самая важная. Если их нет или они абстрактные («улучшить мониторинг»), пост-мортем бесполезен. Каждый пункт должен быть SMART: конкретным, измеримым, достижимым, релевантным, ограниченным во времени.
⚠️ Внимание: Не смешивайте «мёд с ложкой» — отделяйте факты (логи, метрики) от гипотез и мнений. В таймлайне только факты. Гипотезы — в RCA с пометкой «гипотеза».
Инструменты и шаблоны для проведения
Не пишите с нуля. Используйте проверенные шаблоны и инструменты коллаборации. В Google — внутренний Postmortem Template в Docs. В open source — шаблоны от Atlassian, PagerDuty, GitLab.
| Инструмент | Тип | Особенность | Подходит для |
|---|---|---|---|
| Google Postmortem Template | Документ (Doc/Markdown) | Классическая SRE-структура, секции для RCA и action items | Команды любого размера |
| Atlassian Incident Postmortem | Confluence template + Jira integration | Автосоздание тикетов на action items | Экосистема Atlassian |
| PagerDuty Postmortems | SaaS, встроен в Incident Response | Автотаймлайн из алертов, SEV-уровни | Команды с PagerDuty |
| GitLab Incident Management | Встроено в GitLab | Связь с MR, коммитами, конвейерами | GitLab-native команды |
| Blameless.io | Специализированная платформа | Фокус на Blameless культуре, интеграции со Slack/Teams | Масштабирующиеся SRE-орги |
Для небольших команд достаточно Markdown-файла в репозитории (например, /postmortems/2026-01-15-db-outage.md). Это даёт версионирование, код-ревью процесс и поиск по истории.
Храните шаблон пост-мортема в репозитории инфраструктуры (infra-repo) рядом с runbook-ами. Так новые инженеры найдут его через grep, а не через поиск в Confluence, который никто не обновлял с 2021 года.
Типичные ошибки и как их избежать
Даже опытные команды набивают шишки. Вот частые паттерны провала:
- 🎯 Виновник найден — инцидент закрыт. Инженер уволен/наказан, системная причина (нет code review, нет staging) не устранена. Через месяц повторяется.
- 📝 Action items = «улучшить мониторинг». Без конкретного алерта, метрики, порога и владельца это не задача, а пожелание.
- ⏱ Проводить пост-мортем через 3 недели. Контекст утерян, логи ротировались, участники забыли детали. Золотое правило: в течение 48 часов после резолюции.
- 👥 Только лиды пишут, остальные подписывают. Пост-мортем пишет тот, кто был «руками» на инциденте. Лид ревьюит и фасилитирует.
- 🔒 Документ закрыт для просмотра. Пост-мортемы должны быть публичны внутри организации. Обучение работает только при прозрачности.
Особенно опасна ошибка «виновник найден». Она убивает психологическую безопасность — фундамент Blameless культуры. После первого такого случая инженеры начнут прятать ошибки, а не сообщать о них.
Пост-мортем без конкретных action items с владельцами и дедлайнами — это просто дневник наблюдений, а не инструмент надежности.
Примеры из практики крупных компаний
Публичные пост-мортемы — лучшая учебная база. Крупные игроки регулярно делятся разборами крупных инцидентов.
- ☁️ AWS S3 outage 2017 — опечатка в скрипте удалила больше серверов, чем планировалось. Вывод: blast radius операций должен быть ограничен автоматизацией, а не внимательностью человека.
- 📦 GitLab database incident 2017 — случайное удаление продакшн-БД при попытке починить репликацию. Нет бэкапа, нет тестирования рестора. Урок: регулярные fire drills (учения по восстановлению).
- 🎮 Knight Capital 2012 — флаг в коде не удалили 8 лет, новый деплой активировал мёртвый код. Потеря $440 млн за 45 минут. Урок: feature flags нужно убирать, а не накапливать.
- 📱 Slack outage 2022 — каскадный сбой из-за перегрузки Vitess-кластера. Прозрачный пост-мортем с таймлайном по минутам.
- 🔍 Cloudflare 2019 —-regex в WAF съел CPU по всему миру. Урок: тестировать regex на нагрузке, иметь kill-switch для правил.
Изучайте чужие ошибки — дешевле своих. Подпишитесь на Incident.io blog, Honeycomb blog, Dan Luu's postmortem collection.
Чек-лист подготовки к пост-мортему
Перед встречей убедитесь, что всё готово. Хаотичное совещание съест час и даст ноль результата.
☑️ Подготовка к встрече пост-мортема
Фасилитатор — ключевая роль. Это не менеджер сервиса, а независимый модератор, который следит за временем, не даёт уйти в обвинения, требует конкретики в action items. В зрелых командах фасилитаторы ротируются.
⚠️ Внимание: Не проводите пост-мортем в тот же день, что и инцидент, если команда не спала ночь. Усталость убивает качество анализа. Лучше утро следующего дня.
Культура пост-мортемов: от разового акта к системной практике
Одиночные пост-мортемы не меняют организацию. Нужна система: реестр инцидентов, требование пост-мортема для каждого SEV-1/SEV-2, квартальный обзор повторяющихся паттернов.
В Netflix практикуют Chaos Engineering — намеренное внедрение сбоев в продакшн (Chaos Monkey). Каждый такой эксперимент заканчивается мини-пост-мортемом. Это тренирует мышцу анализа до реальных аварий.
Метрика зрелости: % инцидентов с пост-мортемом и % action items закрытых в срок. Если второе ниже 70% — процесс формальный.
Как внедрить пост-мортемы, если их нет?
Начните с SEV-1 (критичные). Шаблон — один страничный Markdown. Фасилитатор — ротация из SRE/Tech Leads. Внедрите правило: «Нет пост-мортема — инцидент не закрыт». Через 3 месяца добавьте SEV-2. Измеряйте % закрытых action items. Делитесь историями на all-hands — нормализуйте открытость. Главное — поддержка топ-менеджмента: если VP Engineering сам пишет пост-мортем за свой сервис — культура приживётся.
FAQ: Частые вопросы о пост-мортемах
В чём разница между пост-мортемом и ретроспективой спринта?
Ретроспектива — регулярная (каждые 2 недели), про процесс команды в целом. Пост-мортем — событийный, триггерится инцидентом или релизом, фокус на конкретном сбое и системных причинах. Ретроспектива про «как мы работаем», пост-мортем — «почему сломалось это».
Обязателен ли пост-мортем для каждого бага?
Нет. Только для инцидентов с пользовательским влиянием (SEV-1, SEV-2) или повторяющихся паттернах. Для обычных багов достаточно фикса в тикете и, возможно, unit-теста. Перегрузка пост-мортемами девальвирует практику.
Кто должен писать пост-мортем?
Инженер, который был «incident commander» или основным респондером. Он знает контекст. Фасилитатор помогает структурировать, задаёт правильные вопросы, следит за качеством action items. Не делегируйте техническому райтеру — потеряется техническая глубина.
Как долго хранить пост-мортемы?
Бессрочно. Это организационная память. Через 3 года новый архитектор найдёт причину архитектурного решения в пост-мортеме 2021 года. Храните в Git-репозитории или в Confluence с версионированием, не в личных Google Docs.
Что такое SEV-уровни и как они связаны с пост-мортемами?
SEV (Severity) — классификация критичности инцидента. Типичная шкала: SEV-1 (критический, полный даун, деньги горят), SEV-2 (мажорная деградация), SEV-3 (минорная, workaround есть), SEV-4 (косыметично). Правило: пост-мортем обязателен для SEV-1 и SEV-2, рекомендуется для SEV-3 если паттерн повторяется.
Пост-мортем — не бюрократия, а инвестиция в надёжность. Каждый проведённый качественно экономит часы будущих инцидентов, деньги бизнеса и нервы дежурных. Начните с шаблона, привыкните к дисциплине — и через полгода вы удивитесь, как работали без этого.