Postmortem

Зачем нужен postmortem

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

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

Что включить

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

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

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

Хронология опирается на живой документ инцидента, alerts, deploy history, логи, traces и сообщения команды. Время и источник важны: они позволяют отличить наблюдение от более позднего предположения.

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

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

Actionable follow-ups

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

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

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

Роль AI

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

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

Правила определяют заранее: значимое влияние, крупный расход бюджета ошибок, потеря данных, повторяющийся сбой или near miss с высоким потенциальным риском. События без page особенно полезны для обнаружения пробелов мониторинга.

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

• Better Stack — хронология и AI-черновики postmortem.
• PagerDuty — данные реакции и инцидентов.
• OpenTelemetry — доказательства из телеметрии.

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

• Управление инцидентами — источник хронологии и решений.
• On-call — улучшение маршрутизации и runbooks.
• SRE — превращение выводов в инженерную работу.

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

• Google SRE: Postmortem Culture — blameless-философия и внедрение практики.
• Google SRE: Example Postmortem — пример структуры разбора.
• Better Stack: Incident management — AI-черновики и данные хронологии.