OrgDevTools
OrgDevToolsСистема повышения операционной эффективности
МетодикиРацухиБиржаБлогТарифы
O
OrgDevTools

Операционная система для организационного развития. Переводим сложные методологии в пошаговые инструменты с AI-поддержкой.

Продукты

  • Методики
  • Инструменты
  • Сценарии
  • Рацухи
  • Новости

Ресурсы

  • Блог
  • Кому подходит
  • Тарифы
© 2026 OrgDevTools. Все права защищены.
КонтактыПолитика конфиденциальностиДоговор-офертаCookies

ООО «НИИ Цифровые технологии»

ИНН 9709075179 · info@orgdevtools.ru

ГлавнаяМетодикиPost-Mortem анализ (Анализ после инцидента)
Управление инцидентами

Post-Mortem анализ (Анализ после инцидента)

Как безвинный разбор инцидента с поиском системной первопричины и конкретным планом предупреждающих действий превращает повторяющиеся сбои в источник улучшения.

Заполните фрейм «Post-Mortem анализ (Анализ после инцидента)» в OrgDevTools

Впишите свои данные в поля ниже — это настоящий фрейм методики, тот же, что в рабочей тетради.

Изменения не сохраняются анонимно — войдите, чтобы не потерять заполненное

Сохранить в рабочую тетрадь →

Что внутри

  • Заполняйте фрейм прямо сейчас, без регистрации
  • 3 рабочие тетради бесплатно при авторизации
  • Больше функций по подписке: экспорт PNG/PDF, планы работ, MindMap, BPMN, Wiki и пр.
Начать бесплатно →

Без карты. Регистрация — 30 секунд.

Post-Mortem анализ решает проблему повторяющихся сбоев: без структурированного разбора инцидента после его завершения команда устраняет только непосредственное последствие («откатили деплой», «извинились перед клиентом») и переходит к следующей задаче, а системная причина остаётся нетронутой и вызывает тот же сбой снова через какое-то время. Post-Mortem превращает завершившийся инцидент в источник системного улучшения, а не просто в закрытый тикет.

Проблема, которая была «решена» пять раз одним и тем же способом, — это не пять разных проблем, это одна нерешённая системная причина, которую никто не удосужился найти.

Происхождение и исследовательская база

Post-Mortem (посмертный анализ, разбор инцидента) — практика, широко распространённая в индустрии эксплуатации ИТ-систем (SRE, DevOps), но применимая к любым операционным сбоям; метод предполагает структурированный разбор произошедшего инцидента сразу после его разрешения, пока детали свежи в памяти участников.

Ключевые идеи и принципы

Принцип: Разбор без поиска виноватого (blameless post-mortem)

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

Принцип: Хронология событий восстанавливается точно и подробно

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

Принцип: Различение непосредственной причины и системной первопричины

Непосредственная причина («сервер упал») отличается от системной первопричины («не было мониторинга нагрузки и автоматического масштабирования») — Post-Mortem должен докопаться до системной причины, а не остановиться на первом очевидном объяснении.

Принцип: Конкретные действия по предотвращению повторения с ответственными и сроками

Разбор без конкретного списка предупреждающих действий с ответственными и сроками остаётся просто интересным чтением — ценность Post-Mortem реализуется только через реальные изменения, предотвращающие повторение.

Ограничения, слепые зоны и критика

Culture безвинного разбора требует зрелой организационной культуры — в компаниях с сильной культурой поиска виноватого blameless post-mortem легко превращается в формальность, где участники всё равно опасаются откровенности. Post-Mortem отнимает время сразу после напряжённого инцидента, когда команда уже устала — если процесс становится слишком тяжёлым, со временем он начинает восприниматься как бюрократическая обязанность. Наконец, метод по своей природе реактивен — он анализирует то, что уже произошло, и не заменяет превентивные методы, такие как FMEA, предугадывающие сбои до их возникновения.

Типовые ошибки

Ошибка 1: Разбор инцидента фокусируется на том, кто виноват, а не на системной причине.

Участники скрывают детали из страха наказания, реальная причина остаётся невыявленной.

Как избежать: Явно устанавливать культуру безвинного разбора — фокус на системе, а не на человеке.

Ошибка 2: Анализ останавливается на первой очевидной непосредственной причине.

Устраняется симптом, а не системная первопричина, инцидент повторяется в другой форме.

Как избежать: Систематически докапываться до системной первопричины, а не первого очевидного объяснения.

Ошибка 3: Post-Mortem заканчивается документом с описанием без конкретного плана предупреждающих действий.

Знание о причине инцидента не приводит к реальным изменениям, предотвращающим повторение.

Как избежать: Обязательно фиксировать конкретные предупреждающие действия с ответственными и сроками.

Ошибка 4: Разбор проводится значительно позже инцидента, когда детали уже забыты.

Хронология событий восстанавливается неточно, важные детали теряются.

Как избежать: Проводить Post-Mortem сразу после разрешения инцидента, пока детали свежи в памяти участников.

Ошибка 5: Процесс Post-Mortem становится тяжёлой бюрократической обязанностью для каждого мелкого сбоя.

Команда начинает избегать или формально проводить разбор, теряя реальную ценность метода.

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

Главное, что нужно знать

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

План внедрения

Неделя 1: установить культуру безвинного разбора и определить формат Post-Mortem документа.

Неделя 2: провести первый разбор недавнего значимого инцидента с восстановлением точной хронологии.

Неделя 3: докопаться до системной первопричины и сформировать список предупреждающих действий.

Неделя 4: назначить ответственных и сроки по предупреждающим действиям, отследить выполнение.

Далее: проводить Post-Mortem для каждого значимого инцидента на регулярной основе.

Книги по теме

Beyer B. et al. — «Site Reliability Engineering» (Google, 2016). Практическое руководство по построению культуры безвинного разбора инцидентов в технологических компаниях.

Чек-лист качества: Post-Mortem Analysis (Анализ после инцидента)

Отметьте пункты — прогресс анонимно не сохраняется, войдите, чтобы не потерять

0 из 4 выполнено0%

Похожие методики

Шкалы этики (Ethics Scales)

Градуированная шкала организационных состояний от нижних (коррекционных) до верхних (ростовых) с жёстко предписанной формулой действий для каждого — из административной технологии Хаббарда.

МетодикаБесплатно

Инициативный трекер (Initiative Tracker)

Как декомпозиция стратегической инициативы на конкретные задачи с исполнителем и сроком превращает абстрактное намерение в реально движущуюся работу.

МетодикаБесплатно

OKR+I (Objectives and Key Results + Initiatives)

Расширение OKR явным слоем инициатив — конкретных гипотез и экспериментов под каждым Key Result, с еженедельным чек-ином уверенности в достижении цели.

МетодикаБесплатно

Начните бесплатно — 3 рабочие тетради, без карты

Живая библиотека методик и неограниченное количество заполненных фреймов.

Создать бесплатный аккаунт