Шаблон инженерного постмортема (без обвинений, с конкретными действиями)

Почему постмортемы превращаются в поиск виноватых

Постмортемы проваливаются вполне определённым образом: зал начинает назначать причину, прежде чем у зала есть общий таймлайн. Кто-то говорит «это вызвал деплой», прежде чем подтверждено время деплоя. Кто-то другой говорит «алерт не сработал», не зная, был ли алерт вообще настроен на этот сценарий. Разговор превращается в спор о причинности прежде, чем кто-либо установил, что́ вообще произошло и в каком порядке.

Исправление структурно: постройте таймлайн инцидента вместе в начале постмортема, прежде чем кто-либо назовёт корневую причину. Как только весь зал посмотрел на последовательность событий — что́ изменилось и когда, кто что видел и в какое время, — причину куда легче обсуждать и куда меньше вероятность, что она свалится в обвинения. Это та ошибка в порядке, которую совершает большинство шаблонов: они ставят корневую причину перед таймлайном, потому что шаблон и создан ради корневой причины. Но именно таймлайн делает разбор корневой причины честным.

Повестка (копируйте и вставляйте)

Длительность: 60 минут для простого инцидента; 90 минут для сложных многосистемных отказов
Формат: с ведущим; присутствуют все, кто реагировал, и дежурный инженер; готовьтесь асинхронно с предварительным документом

Раздел 1 — Сводка по инциденту (5 мин)

Даты и длительность инцидента
Классификация серьёзности и затронутые системы
Кто его обнаружил и как (обращение клиента, алерт, инженер, мониторинг)
Этот раздел только фактический; никакого анализа пока

Раздел 2 — Таймлайн (20 мин)

Стройте таймлайн совместно на экране — не заранее написанный документ
Последовательность: что изменилось, что наблюдалось, кто действовал, что решили
Каждая временна́я метка должна иметь источник (строка лога, PagerDuty, сообщение в Slack)
Когда таймлайн готов, спросите: все согласны, что произошло именно это? Разрешите разногласия, прежде чем идти дальше

Раздел 3 — Сводка последствий (5 мин)

Влияние на клиентов: кого затронуло, на сколько, каким образом
Влияние на бизнес: выручка, SLA, репутация
Внутреннее влияние: часы дежурства, срыв работы команды
Держите фактическим; это закрепляет вопрос «насколько всё было плохо» без публицистики

Раздел 4 — Корневая причина и способствующие факторы (20 мин)

Корневая причина: наиболее непосредственное изменение или условие, сделавшее инцидент возможным
Способствующие факторы: условия, которые сделали его хуже, труднее обнаружимым или медленнее устранимым
Наиболее полезные постмортемы выявляют 3–5 способствующих факторов наряду с корневой причиной; исправление одной лишь корневой причины часто упускает системные условия
По каждому фактору спрашивайте: принимал ли какой-то человек или команда решение, казавшееся разумным при доступной тогда информации? Если да, фактор системный, а не персональный

Раздел 5 — Что прошло хорошо (5 мин)

Что в обнаружении или реагировании сработало лучше ожидаемого?
Какой существующий процесс или инструмент ограничил радиус поражения?
Это практики, достойные формализации — если раннбук сэкономил 20 минут, отметьте это, чтобы раннбук поддерживали

Раздел 6 — Задачи (15 мин)

Каждая задача адресует корневую причину или способствующий фактор — не общее улучшение
Один ответственный на пункт; срок поставки, отражающий срочность
Классифицируйте: обнаруживать раньше / восстанавливаться быстрее / предотвращать повторение
Ограничьтесь действиями, которые команда реально успеет завершить до следующего инцидента, а не всеобъемлющей дорожной картой надёжности

Что заставляет шаблоны постмортема проваливаться

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

Третий режим отказа — пропуск «что прошло хорошо», потому что он ощущается как неуместный оптимизм после инцидента. Это не так — это единственный систематический способ выявить и формализовать практики, сработавшие под давлением. Если мониторинг, поймавший проблему, не был ни у кого в дорожной карте, то узнать, что он оказался важен, стоит задокументировать. Иначе его задвинут после того, как инцидент забудется, и в следующий раз вы окажетесь слепы.

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

Почему фиксировать постмортем особенно трудно

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

Pavleur фиксирует всё обсуждение постмортема и формирует отчёт автоматически — таймлайн в реконструированном виде, способствующие факторы в названном виде, задачи с ответственными и категориями в том виде, как их заявили на встрече. Если кто-то показывал экран с выдержкой из лога, графиком мониторинга или конфигурацией алерта, который не сработал, этот визуал становится частью отчёта. Чисто аудиоинструменты упускают это полностью; запись постмортема без графиков — это запись без доказательств. Любой в команде — включая инженеров, присоединившихся после инцидента, — может прочитать полную запись с визуальным контекстом, не прося кого-то её реконструировать. Прямое сравнение с другими инструментами по этому пункту: Pavleur и альтернативы.

О ритме постмортемов

Проводите постмортем в течение 48 часов после устранения инцидента, пока детали свежи. Чем дольше вы ждёте, тем сильнее реконструкция таймлайна зависит от памяти, а не от логов, а память под стрессом ненадёжна. Для инцидентов высокой серьёзности лучше 24 часа. Для мелких инцидентов асинхронные постмортемы — общий документ со структурированными вопросами, просмотренный синхронно, — могут быть эффективнее полноценной встречи. Формат встречи наиболее ценен, когда инцидент был достаточно неоднозначным или высокоставочным, чтобы общая интерпретация имела значение.