Разбор инцидента по записи встречи: шаблон постмортема
Как собрать постмортем после рабочего сбоя: хронология, последствия, подтверждённые причины и действия. Учебный пример и шаблон без поиска виноватого.
Сначала восстановите события
После сбоя участники помнят разные моменты: один заметил ошибку, другой получил сообщение позже, третий начал исправление. Из общей беседы легко получить убедительную историю с неверным порядком событий. Поэтому основу разбора составляет проверяемая хронология.
Постмортем нужен после завершения первичного восстановления, когда команда может спокойно разобраться. В записи встречи содержатся объяснения участников, но время событий лучше сверять с сообщениями, журналами и другими доступными источниками. Не публикуйте внутренние данные в открытом отчёте.
Соберите разбор в четыре слоя
Опишите последствия
Укажите, какая функция или рабочая операция была недоступна, кому и в какой период. Разделите подтверждённое влияние и предполагаемое. Если число затронутых пользователей неизвестно, так и напишите: догадка не становится фактом из-за красивой диаграммы.
Постройте хронологию
Сведите время возникновения, обнаружения, сообщения, первых действий и восстановления. Обязательно укажите часовой пояс. Если событие известно только со слов участника, сохраните источник и степень уверенности; не ставьте приблизительное время как точное.
Проверьте объяснения
Разделите непосредственный триггер и условия, которые позволили проблеме проявиться или затянуться. Спросите, какая информация была у человека в момент решения. Каждую версию свяжите с доказательством и запишите, что могло бы её опровергнуть.
Назначьте проверяемые меры
Выберите действия, которые уменьшают конкретный риск, ускоряют обнаружение или восстановление. Для каждого укажите владельца, результат и способ проверки. «Быть внимательнее» не описывает изменения процесса и не позволяет проверить завершение.
Потеря уведомлений о новых заявках
Ниже — вымышленный учебный пример. Имена, условия и результаты приведены только для объяснения метода.
Заявки сохранялись, но уведомления перестали приходить. Мы узнали об этом от менеджера, проверили список и временно начали смотреть его вручную.
Нельзя записать «заявки пропали»: в примере нарушена доставка уведомлений, а сами записи доступны. Такое различие определяет и последствия, и меры.
Хронология ниже условная. Она показывает промежуток между возникновением проблемы и её обнаружением, но не доказывает техническую причину сбоя.
| Наблюдение | Версия | Следующая проверка |
|---|---|---|
| Записи есть, уведомлений нет | Сбой на этапе доставки | Сверить журнал отправки |
| Узнали от менеджера | Не было подходящего сигнала | Проверить мониторинг доставки |
| Ручной просмотр помог | Есть временный обходной процесс | Описать условия его включения |
Шаблон постмортема
Сохраняйте черновые версии причин как версии, пока они не подтверждены проверкой.
Инцидент и период, часовой пояс: Подтверждённое влияние: Хронология: время / событие / источник: Триггер: Способствующие условия: Что сработало при восстановлении: Что пока не установлено: Мера / владелец / срок / проверка: Когда проверяем выполнение мер:
Проверьте, помогает ли разбор предотвращению
- Влияние описано точнее, чем «всё сломалось».
- Время событий не смешано с временем их обсуждения.
- Причины отделены от непроверенных версий.
- Каждая мера связана с наблюдаемой проблемой и проверкой.
Разберём детали
Постмортем и ретроспектива — одно и то же?
Постмортем сосредоточен на конкретном инциденте и его последствиях. Ретроспектива может охватывать весь период работы команды, включая удачные практики и эксперименты.
Что делать, если причина ещё неизвестна?
Опубликуйте внутри команды подтверждённую часть и список открытых проверок. Не заполняйте раздел причин догадкой ради завершённого вида документа.