---
title: Postmortem
description: "Blameless postmortem: хронология, влияние, факторы, корневые причины, actionable follow-ups и проверка улучшений."
---

## Зачем нужен postmortem

**Postmortem** — структурированный разбор значимого инцидента после восстановления. Его цель — понять, как система и процесс допустили влияние, и уменьшить вероятность или тяжесть повторения. Это не отчёт для поиска виноватого.

**Blameless** не означает отсутствие ответственности за действия. Означает, что разбор описывает решения в доступном тогда контексте и ищет системные факторы: интерфейс, права, проверки, обучение, нагрузку, архитектуру и организацию работы.

## Что включить

- краткое описание и влияние на пользователей и бизнес;
- severity, затронутые сценарии и длительность;
- хронологию сигналов, решений и восстановления;
- что сработало хорошо и что замедлило реакцию;
- технические и организационные contributing factors;
- первопричину или оставшуюся неопределённость;
- действия по устранению и снижению риска с владельцами и сроками;
- уроки и способ проверить эффект.

Не выдумывайте единственную «коренную причину», если факты показывают цепочку условий. Откат не является доказательством, что причина найдена.

## Хронология и факторы

Хронология опирается на [живой документ инцидента](https://wpcraft.ru/kb/infrastructure/incidents.md), alerts, deploy history, логи, traces и сообщения команды. Время и источник важны: они позволяют отличить наблюдение от более позднего предположения.

Полезные вопросы:

- почему проблема не была обнаружена раньше;
- почему существующие проверки не остановили изменение;
- почему влияние распространилось;
- какие действия помогли или усугубили;
- какие данные и права были нужны для решения;
- повторяется ли фактор в других сервисах.

## Actionable follow-ups

Плохой пункт: «быть внимательнее» или «улучшить мониторинг». Хороший пункт описывает проверяемое изменение:

```text
Добавить synthetic checkout check из двух регионов.
Владелец: команда платформы. Срок: 2026-11-15.
Проверка: искусственный сбой создаёт alert и ссылку на runbook.
```

Приоритеты распределяют по снижению риска, а не по лёгкости закрытия списка. Крупные действия попадают в обычное планирование; их выполнение проверяют на последующих обзорах.

## Роль AI

AI может собрать черновую хронологию из канала и документа, сгруппировать события и предложить вопросы. Перед публикацией инженер проверяет время, выводы и влияние. Неподтверждённые формулировки модели нельзя превращать в официальную первопричину.

## Когда проводить

Правила определяют заранее: значимое влияние, крупный расход [бюджета ошибок](https://wpcraft.ru/kb/infrastructure/sre/error-budgets.md), потеря данных, повторяющийся сбой или near miss с высоким потенциальным риском. События без page особенно полезны для обнаружения пробелов мониторинга.

## Связанные инструменты

- [Better Stack](https://wpcraft.ru/kb/infrastructure/tools/better-stack.md) — хронология и AI-черновики postmortem.
- [PagerDuty](https://wpcraft.ru/kb/infrastructure/tools/pagerduty.md) — данные реакции и инцидентов.
- [OpenTelemetry](https://wpcraft.ru/kb/infrastructure/tools/open-telemetry.md) — доказательства из телеметрии.

## Связанные материалы

- [Управление инцидентами](https://wpcraft.ru/kb/infrastructure/incidents.md) — источник хронологии и решений.
- [On-call](https://wpcraft.ru/kb/infrastructure/incidents/on-call.md) — улучшение маршрутизации и runbooks.
- [SRE](https://wpcraft.ru/kb/infrastructure/sre.md) — превращение выводов в инженерную работу.

## Материалы и источники

- [Google SRE: Postmortem Culture](https://sre.google/sre-book/postmortem-culture/) — blameless-философия и внедрение практики.
- [Google SRE: Example Postmortem](https://sre.google/sre-book/example-postmortem/) — пример структуры разбора.
- [Better Stack: Incident management](https://betterstack.com/incident-management) — AI-черновики и данные хронологии.