Постмортем (postmortem, post-incident review) — структурированный документ и процесс анализа инцидента, произошедшего в IT-системе. Цель — понять корневые причины сбоя, задокументировать хронологию событий и разработать конкретные меры для предотвращения повторения. Постмортем составляется после каждого значимого инцидента: крупного даунтайма, потери данных, нарушения безопасности.
Как работает
Стандартный формат постмортема включает разделы:
- Summary — одним абзацем: что случилось, когда, как долго, сколько затронуто пользователей.
- Impact — конкретные числа: 3200 пользователей не могли войти в систему, выручка -$12 000 за 47 минут.
- Timeline — хронология событий с временными метками: 14:23 — первое уведомление мониторинга, 14:31 — инженер начал диагностику, 15:10 — проблема устранена.
- Root cause — корневая причина. Не «упал сервер» (симптом), а «неверный конфиг nginx после деплоя привёл к переполнению буфера при нагрузке выше 500 RPS».
- Contributing factors — сопутствующие факторы: недостаточное покрытие тестами, отсутствие канареечного деплоя, мониторинг не покрывал данный сценарий.
- Action items — задачи с владельцами и дедлайнами: «Добавить нагрузочный тест в CI pipeline — Иван, до 15.03».
- What went well — что сработало хорошо: мониторинг обнаружил проблему за 8 минут, rollback выполнен за 3 минуты.
Blameless postmortem
Ключевой принцип Google SRE и DevOps-культуры: постмортем без виноватых (blameless). Люди делают ошибки в системах, которые позволяют их допускать — значит, проблема в системе, не в человеке. Поиск виноватых создаёт культуру страха и скрытия инцидентов; blameless-подход поощряет открытость и обучение на ошибках. Постмортем анализирует системные причины, а не поведение индивидуумов.
История
Термин «postmortem» (вскрытие, посмертное вскрытие) перешёл из медицины в IT в 1990-е. В разработке ПО анализ завершённых проектов (project postmortem) практиковался с 1970-х: Том Де Марко описывал их как «извлечение уроков». Систематизацию практики постмортемов в операциях принесли Google и Amazon в 2000-е годы. Книга «Site Reliability Engineering» (Google, O'Reilly, 2016) включает главу об инцидентном постмортеме и blameless-культуре, что ввело термин в mainstream DevOps-сообщество. Публичные постмортемы — AWS, Cloudflare, GitHub публикуют постмортемы крупных инцидентов на своих статус-страницах.
На что обращать внимание
Постмортем нужно составлять пока память свежа — в течение 24–48 часов после инцидента. Задержка ведёт к потере деталей. Action items без конкретных владельцев и дедлайнов — мертворождённые задачи. Каждый action item должен иметь ответственного, срок и систему трекинга (Jira, GitHub Issues). Не ищите единственную root cause — реальные инциденты имеют несколько contributing factors. Метрика успеха практики постмортемов — повторные инциденты по тем же причинам должны сокращаться. Если постмортемы не влияют на повторяемость — процесс формальный, а не рабочий.
Постмортем в хостинге
Постмортем (post-mortem, incident review) — анализ инцидента после его устранения. Ключевой принцип: blameless (без поиска виноватых) — анализ систем и процессов, не людей. Структура постмортема: хронология событий → root cause → влияние (затронутые пользователи, downtime) → что сработало хорошо → что можно улучшить → action items с ответственными. Даунтайм на VPS: постмортем помогает выявить, почему мониторинг не сработал вовремя. Rollback: если откат решил проблему, постмортем анализирует почему деплой прошёл без проверки. Инцидент: порог открытия постмортема определяется серьёзностью — p0/p1 всегда требуют постмортем.