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

Для чего же нам нужно проводить "вскрытие” системы после инцидента? Тем более, что жизнь "пациента" была сохранена, и команда, работавшая над сохранением жизни, свою долю стресса и опыта уже получила.

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

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

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

Самые важные принцип и цель постмортема: мы не ищем виноватых и никого не наказываем – мы создаем культуру прозрачности, открытости и совместно стремимся к улучшениям. Это значит, что мы не ищем виновного в том, что дефибриллятор не вытащили из коробки и не поставили на реанимационных стол (и не лишаем его премии), мы достаем этот дефибриллятор из шкафа, вытираем пыль и начинаем читать к нему инструкцию, проводить обучение по его эксплуатации и активно внедряем его в свою работу.

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

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

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

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

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

Этапы проведения постмортема

1. Сбор данных

• Какая степень влияния на пользователей? 

• Когда начался и закончился инцидент? Укажите точное время.

• Какие симптомы были замечены? Описание ошибок, записей в логах или необычного поведения системы.

• Кто сообщил о проблеме? Укажите источник: мониторинг, клиент, сотрудник или директор.

• Какие действия предпринимались? Опишите шаги по устранению проблемы.

• Как завершился инцидент? Фиксация результата.

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

2. Восстанавливаем хронологию событий

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

• Ключевые события: что и в какой последовательности происходило с указанием времени (из ключевых событий формируем основные этапы).

• Реакции: в рамках этапов заполняем какое действие/действия были предприняты или что происходило на каждом этапе.

• Результаты: какие результаты были достигнуты/что получилось сделать/что не получилось и так далее.

• Пропуски: время между событиями, где не было реакции или диагностики.

3. Определение источника отказа (Root Cause Analysis)

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

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

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

• Почему произошел сбой?

• Почему это не было предотвращено?

• Почему мониторинг не сработал?

• Почему реакция заняла так много времени?

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

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

• Определите проблему.

• Определите категории, в которых вы будете искать ее причины.

• Напишите возможные причины проблемы в каждой из категорий.

• Отсортируйте и приоритизируйте причины проблемы.

• Протестируйте потенциальные причины и устраните их.

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

4. Разработка плана действий

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

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

• Обновления процессов: пересмотр процедур эскалации, тестирования, мониторинга.

• Обучение команды: проведение тренингов или улучшение качества документации.

 5. Документирование

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

1. Описание инцидента. Что произошло, когда и какие последствия.

2. Хронология событий. Список ключевых моментов.

3. Root Cause. Основные причины сбоя.

4. Рекомендации. Предлагаемые действия для предотвращения подобных ситуаций.

5. Выводы. Основные уроки.

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