Согласно определению postmortem – это процедура, посмертное вскрытие и исследование тела, обычно с целью установить причину смерти. Не очень приятное описание, но очень полезная практика, благодаря которой о человеческом организме и причинах его болезней и смерти удалось узнать много жизненно важной информации и использовать ее для сохранения огромного количества судеб. Заимствование практик из соседних наук не редкость – из медицинской практики в нашу рабочую повседневность и пришел принцип создания постмортемов.
Для чего же нам нужно проводить "вскрытие” системы после инцидента? Тем более, что жизнь "пациента" была сохранена, и команда, работавшая над сохранением жизни, свою долю стресса и опыта уже получила.
Во-первых, постмортемы помогают установить причину возникновения проблемы. Да, мы спасли нашу систему от комы, но, если не понять из-за чего она пыталась впасть в предсмертный припадок, с большой долей вероятности она попытается отправиться на тот свет снова и вполне возможно, что очень скоро.
Тут мы открываем вторую причину – с помощью аналитики посмотрема, когда мы выявили причины сбоя, мы можем предотвратить повторение инцидента.
В-третьих, при проведении посмотрема “вскрытия” могут обнаружиться на первый взгляд неочевидные системные недостатки внутри наших процессов, которые оказывают опосредованное влияние на работу и нуждаются в оптимизации. Возможно, у нас в шкафу пылится дефибриллятор, в то время как мы в каждый экстренный момент используем ручной массаж сердца, хотя эффективность применения дефибриллятора снизила бы временные и физические затраты команды на реанимацию и уменьшила бы риски человеческой ошибки.
Самые важные принцип и цель постмортема: мы не ищем виноватых и никого не наказываем – мы создаем культуру прозрачности, открытости и совместно стремимся к улучшениям. Это значит, что мы не ищем виновного в том, что дефибриллятор не вытащили из коробки и не поставили на реанимационных стол (и не лишаем его премии), мы достаем этот дефибриллятор из шкафа, вытираем пыль и начинаем читать к нему инструкцию, проводить обучение по его эксплуатации и активно внедряем его в свою работу.
Посмортемы строятся на нескольких основополагающих принципах
Первый принцип – без обвинений. Постмортем это не еще одна часть Ван Хельсинга, где начальник пытает бледного сотрудника с темными кругами под глазами, аллергией на чеснок и яркий свет, в попытках определить не он ли тот упырь, что убил продакшен прошлой ночью. В первую очередь ориентироваться на факты, процессы и улучшения.
Второй принцип – фокус на объективных данных. Догадки, подозрения, ощущения и предчувствия – основа для разговора с психологом, но не для формирования технических выводов. Все выводы должны основываться на объективной информации.
Третий принцип – коллективная работа. Думай, как детектив: чтобы получить максимально полную картину случившегося, необходимо поговорить со всеми свидетелями. Но главная цель не замыкать анализ информации на себе, а вовлечь всех участников в коллективное обсуждение, чтобы совместно генерировать идеи, отбрасывать нерелевантные и тем самым совместно учиться на новом опыте.
Четвертый принцип – документирование. Да, это та самая неприятная часть с бумажной волокитой. Но именно перенос на “бумагу” итогов постмортема помогает разложить все по полочкам в голове и отрефлексировать новый опыт. Кроме того, этот документ сможет стать основой для анализа в будущем при выявлении закономерностей сбоев или обучении сотрудников.
Этапы проведения постмортема
1. Сбор данных
Какая степень влияния на пользователей?
Когда начался и закончился инцидент? Укажите точное время.
Какие симптомы были замечены? Описание ошибок, записей в логах или необычного поведения системы.
Кто сообщил о проблеме? Укажите источник: мониторинг, клиент, сотрудник или директор.
Какие действия предпринимались? Опишите шаги по устранению проблемы.
Как завершился инцидент? Фиксация результата.
Инструментами для сбора данных могут послужить: логи системы, алерты, данные мониторинга, скриншоты или сохраненная информация об ошибках.
2. Восстанавливаем хронологию событий
Создайте таймлайн, который покажет:
Ключевые события: что и в какой последовательности происходило с указанием времени (из ключевых событий формируем основные этапы).
Реакции: в рамках этапов заполняем какое действие/действия были предприняты или что происходило на каждом этапе.
Результаты: какие результаты были достигнуты/что получилось сделать/что не получилось и так далее.
Пропуски: время между событиями, где не было реакции или диагностики.
3. Определение источника отказа (Root Cause Analysis)
Можем предложить методику "5 Почему" (подходит для более легкой и быстрой аналитики), метод “Что пошло как надо?” и диаграмму "Исикавы (Рыбий скелет)" (более глубокий уровень).
Метод «5 почему» помогает найти первопричину проблемы или конфликта. Столкнувшись с инцидентом, мы можем задать вопрос, почему так произошло. Найдя прямую причину, мы задаем следующий вопрос уже отталкиваясь от этой причины — почему произошла она? Так выстраивается цепочка причин, в конце которой (в среднем через 5 вопросов) обнаруживается истинная причина нашей изначальной проблемы.
(Пример) Метод 5 почему:
Почему произошел сбой?
Почему это не было предотвращено?
Почему мониторинг не сработал?
Почему реакция заняла так много времени?
В использовании метода Исикавы идея заключается в том, чтобы сформулировать проблему, затем определить факторы, которые могут влиять на ее появление, и внутри каждого фактора найти конкретные причины проблемы. В результате анализа получится схема, по форме напоминающая скелет рыбы.
(Пример) Диаграмма «Исикавы»:
Определите проблему.
Определите категории, в которых вы будете искать ее причины.
Напишите возможные причины проблемы в каждой из категорий.
Отсортируйте и приоритизируйте причины проблемы.
Протестируйте потенциальные причины и устраните их.
И не забываем хвалить себя и команду! Метод “что пошло как надо” позволяет обратить внимание не только на проблемные точки, но и отметить сильные стороны команды и ее работы, повышая мотивацию к воспроизведению правильных методов и процессов. В целом можно использовать абсолютно любой метод, главное дойти до самой глубинной причины, будь то ошибка кода, пропуск в документации или организационная проблема.
4. Разработка плана действий
На основании анализа создайте четкий план (состоящий из задач в формате: Что нужно сделать? Кто отвечает? Крайний срок), который будет включать в себя:
Технические улучшения: какие ошибки в системе будут нуждаться в исправлении, добавления новых проверок.
Обновления процессов: пересмотр процедур эскалации, тестирования, мониторинга.
Обучение команды: проведение тренингов или улучшение качества документации.
5. Документирование
Структура постмортем-документа:
Описание инцидента. Что произошло, когда и какие последствия.
Хронология событий. Список ключевых моментов.
Root Cause. Основные причины сбоя.
Рекомендации. Предлагаемые действия для предотвращения подобных ситуаций.
Выводы. Основные уроки.
P.S. через двое суток после публикации: мы осознаем и понимаем, что описали только кусочек инцидент менеджмента. Если статья понравилась, будем переносить сюда другие статьи про SRE из нашего канала.
