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

Тут мы открываем вторую причину – с помощью аналитики посмотрема, когда мы выявили причины сбоя, мы можем предотвратить повторение инцидента

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

Самые важные принцип и цель постмортема:

Посмортемы строятся на нескольких основополагающих принципах

Первый принцип – без обвинений. Постмортем это не еще одна часть Ван Хельсинга, где начальник пытает бледного сотрудника с темными кругами под глазами, аллергией на чеснок и яркий свет, в попытках определить не он ли тот упырь, что убил продакшен прошлой ночью. В первую очередь ориентироваться на факты, процессы и улучшения

Второй принцип – фокус на объективных данных. Догадки, подозрения, ощущения и предчувствия – основа для разговора с психологом, но не для формирования технических выводов. Все выводы должны основываться на объективной информации

Третий принцип – коллективная работа. Думай, как детектив: чтобы получить максимально полную картину случившегося, необходимо поговорить со всеми свидетелями. Но главная цель не замыкать анализ информации на себе, а вовлечь всех участников в коллективное обсуждение, чтобы совместно генерировать идеи, отбрасывать нерелевантные и тем самым совместно учиться на новом опыте

Четвертый принцип – документирование. Да, это та самая неприятная часть с бумажной волокитой. Но именно перенос на “бумагу” итогов постмортема помогает разложить все по полочкам в голове и отрефлексировать новый опыт. Кроме того, этот документ сможет стать основой для анализа в будущем при выявлении закономерностей сбоев или обучении сотрудников

• Какая степень влияния на пользователей? 
• Когда начался и закончился инцидент? Укажите точное время.
• Какие симптомы были замечены? Описание ошибок, записей в логах или необычного поведения системы.
• Кто сообщил о проблеме? Укажите источник: мониторинг, клиент, сотрудник или директор.
• Какие действия предпринимались? Опишите шаги по устранению проблемы.
• Как завершился инцидент? Фиксация результата

Инструментами для сбора данных могут послужить: логи системы, алерты, данные мониторинга, скриншоты или сохраненная информация об ошибках.

Создайте таймлайн, который покажет:

• Ключевые события: что и в какой последовательности происходило с указанием времени (из ключевых событий формируем основные этапы)
• Реакции: в рамках этапов заполняем какое действие/действия были предприняты или что происходило на каждом этапе
• Результаты: какие результаты были достигнуты/что получилось сделать/что не получилось и так далее
• Пропуски: время между событиями, где не было реакции или диагностики

Можем предложить методику "5 Почему" (подходит для более легкой и быстрой аналитики), метод “Что пошло как надо?” и диаграмму "Исикавы (Рыбий скелет)" (более глубокий уровень)

Метод «5 почему» помогает найти первопричину проблемы или конфликта. Столкнувшись с инцидентом, мы можем задать вопрос, почему так произошло. Найдя прямую причину, мы задаем следующий вопрос уже отталкиваясь от этой причины — почему произошла она? Так выстраивается цепочка причин, в конце которой (в среднем через 5 вопросов) обнаруживается истинная причина нашей изначальной проблемы

(Пример) Метод 5 почему:

• Почему произошел сбой?
• Почему это не было предотвращено?
• Почему мониторинг не сработал?
• Почему реакция заняла так много времени?

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

(Пример) Диаграмма «Исикавы»:

• Определите проблему.
• Определите категории, в которых вы будете искать ее причины.
• Напишите возможные причины проблемы в каждой из категорий.
• Отсортируйте и приоритизируйте причины проблемы.
• Протестируйте потенциальные причины и устраните их.
• И не забываем хвалить себя и команду! Метод “что пошло как надо” позволяет обратить внимание не только на проблемные точки, но и отметить сильные стороны команды и ее работы, повышая мотивацию к воспроизведению правильных методов и процессов. В целом можно использовать абсолютно любой метод, главное дойти до самой глубинной причины, будь то ошибка кода, пропуск в документации или организационная проблема

На основании анализа создайте четкий план (состоящий из задач в формате: Что нужно сделать? Кто отвечает? Крайний срок), который будет включать в себя:

• Технические улучшения: какие ошибки в системе будут нуждаться в исправлении, добавления новых проверок
• Обновления процессов: пересмотр процедур эскалации, тестирования, мониторинга
• Обучение команды: проведение тренингов или улучшение качества документации

Структура постмортем-документа:

1. Описание инцидента. Что произошло, когда и какие последствия
2. Хронология событий. Список ключевых моментов
3. Root Cause. Основные причины сбоя
4. Рекомендации. Предлагаемые действия для предотвращения подобных ситуаций
5. Выводы. Основные уроки