Реагирование на инциденты не заканчивается восстановлением — шаблон постмортема (предотвращения повторения) для небольших команд разработки

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

Само реагирование на инцидент — обнаружить, локализовать причину, исправить, выпустить, извиниться — многие команды выполняют исправно. Проблема в том, что происходит после. В момент восстановления все возвращаются к повседневной работе, а запись об инциденте рассеивается по чьим-то почтовым ящикам и чатам и постепенно выветривается. Через полгода структурно тот же самый инцидент повторяется в другом месте, и то же расследование приходится проводить заново с нуля. Реагирование на инциденты по принципу «исправили, извинились, забыли» — это способ раз за разом платить одну и ту же плату за обучение.

В этом блоге мы уже разбирали техническую сторону расследования инцидентов — как добраться до первопричины — в статьях «Введение в сбор дампов сбоев Windows» и «Практика перехвата исключений, логирования и обработки ошибок». Эта статья посвящена следующему шагу: как выстроить разбор (постмортем), который после того, как причина уже известна, не даёт тому же инциденту повториться снова. Речь пойдёт не о крупных веб-сервисах, а конкретно о шаблоне, который реально можно поддерживать команде из 2-5 человек, сопровождающей бизнес-приложения и Windows-софт.

1. Сначала вывод

• Восстановление, установление причины и предотвращение повторения — это разные работы. Восстановление — «вернуть сегодняшнюю работу», установление причины — «суметь объяснить, почему это произошло», предотвращение повторения — «изменить систему». Смешав их, вы получите всё сразу наполовину сделанным.
• Отказ от поиска виноватых (blameless) — это вопрос практической пользы, а не этики. Там, где обвиняют отдельных людей, информация перестаёт всплывать, и до первопричины не добраться. Принцип blameless-постмортема, закрепившийся в SRE, — предполагать, что все причастные действовали правильно, исходя из той информации, которой располагали в тот момент, и искать дыру именно в системе.¹
• Меры против повторения нужно закладывать не в «быть внимательнее», а в систему (код, тесты, мониторинг, процедуры). Меры, зависящие от человеческой внимательности, исчезают со сменой ответственного. В главе 6 приведена таблица для оценки силы меры.
• Разделяйте причину на «прямую причину» и «способствующие факторы». Исправить обычно удаётся именно способствующие факторы, и секрет «анализа пяти почему» — не останавливаться на действии человека, а копать до самой системы.
• Не проводите полный постмортем для каждого инцидента. Проводите триаж по влиянию × вероятности повторения (глава 7), а для незначительных случаев оставляйте запись в один абзац. Удержание объёма работы на посильном уровне — главное условие, чтобы практика не умерла.
• Постмортем должен укладываться в час работы. В главе 4 приведён минимальный шаблон. Оставлять черновую запись каждый раз ценнее, чем не написать ни одного безупречного документа за месяц.
• В заказной разработке отделяйте цель от отчёта для клиента, при этом переиспользуя содержание постмортема (глава 8). Не смешивая документ о привлечении к ответственности с документом о предотвращении повторения, вы сохраняете качество обоих.

2. Почему одни и те же инциденты повторяются

У повторяющихся инцидентов есть закономерность — не техническая, а эксплуатационная.

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

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

Списывают на личную ответственность и не исправляют структуру. Закрыв дело фразой «потому что тот человек пропустил тест», вы оставляете нетронутой саму структуру, которая позволила пропустить тест (в процедуре релиза нет гейта с тестами, пропуски молча допускаются под давлением сроков). В следующий раз то же самое упущение допустит уже другой человек.

Запись не сохраняется, и через несколько лет команда падает в ту же яму. Сопровождение небольшой команды какое-то время работает и без записей именно потому, что «один и тот же человек занимается этим постоянно». Но память этого человека тускнеет за несколько лет и исчезает с увольнением или сменой роли. «Кажется, я уже видел эту ошибку раньше, но не могу вспомнить, что мы с ней делали» превращает расследование, которое заняло бы 10 минут при наличии записи, в целый день работы.

Ни один из этих случаев не связан с недостатком компетенции — это следствие того, что разбор никогда не был определён как часть работы. Именно поэтому заранее определить шаблон (документ и критерии его применения) стоит того.

3. Что такое постмортем — переводим шаблон SRE для небольшого сопровождения

Постмортем (postmortem) — это шаблон разбора, документирующий запись об инциденте: влияние, первопричину, хронологию реагирования и действия по предотвращению повторения; практика широко закрепилась благодаря SRE (Site Reliability Engineering) в Google. В её основе — принцип blameless (без обвинений). «Постмортем, написанный без обвинений, предполагает, что все причастные действовали из добрых побуждений и правильно, исходя из информации, которой располагали на тот момент» — вместо наказания людей исправляется система, которая помешала правильному действию.¹

Этот подход не уникален для Google. В архитектурных рекомендациях Microsoft (Azure Well-Architected Framework) постмортем тоже определяется как «структурированный разбор без обвинений с участием всех причастных команд», и рекомендуется возвращать результаты анализа первопричин (RCA) в систему в виде улучшения процесса реагирования, усиления обнаружения (наблюдаемости) и улучшения архитектуры.²

Легко подумать «у нас не крупный веб-сервис, это нас не касается», но, на мой взгляд, всё наоборот. Постмортем особенно эффективен именно там, где небольшая команда без выезда к клиенту сопровождает настольное приложение. Причин тому три.

1. Один и тот же человек занимается всем постоянно, поэтому без записей знание полностью замыкается в одной голове. В крупной организации кто-то ещё обычно помнит, но в команде из 2-3 человек «тот, кто помнит» — единственная существующая база данных. Постмортем становится этой внешней памятью.
2. Инциденты происходят редко. В отличие от веб-сервиса, серьёзные инциденты бизнес-приложения случаются лишь несколько раз в год. Следующий обычно приходит как раз тогда, когда память о предыдущем реагировании уже стёрлась, что относительно повышает ценность письменной записи.
3. Раз выехать на место нельзя, доказательства и записи становятся спасательным кругом. При удалённом сопровождении всё держится на способности впоследствии восстановить, «что происходило в тот момент», а это напрямую связано с хронологической записью постмортема.

В качестве ориентира для того, что заслуживает постмортема, в книге по SRE приводятся такие примеры критериев, как видимые пользователю простои, потеря данных или случаи, потребовавшие вмешательства дежурного (on-call).¹ Критерии, подходящие небольшой команде, ещё раз разберём в главе 7.

4. Минимальный шаблон постмортема

Важнейшее условие того, чтобы практика жила, — объём работы. Приведём Markdown-шаблон, спроектированный с ограничением: первую версию можно написать за час. Рекомендуется хранить его в виде файла с датой в каталоге вроде docs/postmortem/ репозитория, под контролем версий в том же месте, что и код.

# Постмортем: дублирование данных за прошедшую дату в списке заказов (2026-07-15)

- Статус: завершён / действия выполняются / только зафиксирован
- Автор: Комура
- Серьёзность: средняя (бизнес продолжался, но потребовалась ручная сверка)

## Краткое описание (не более 3 строк)
Во время выполнения обработки закрытия месяца при открытии списка
заказов накладные за предыдущий день отображались дважды. Проблема
только в отображении, данные в БД были корректны.

## Влияние (кто / что / насколько)
- Затронуты: 3 сотрудника отдела продаж
- Что произошло: дублирование строк на экране списка. 1 случай,
  когда чуть не произошла повторная отгрузка по ошибке
- Продолжительность: примерно 09:10-11:40 15.07 (около 2,5 часов)

## Хронология
- 09:10 Звонок пользователя: «одна и та же накладная показывается
  дважды» (обнаружение)
- 09:30 Удалённая демонстрация экрана, уточнение условий воспроизведения
- 10:15 Временное решение: попросить не открывать список во время
  обработки закрытия
- 11:40 Развёрнута исправленная версия, восстановление подтверждено

## Прямая причина
Запрос списка выполнял UNION ALL основной таблицы со строками,
которые обработка закрытия скопировала во временную таблицу
(без блокировки).

## Способствующие факторы
- Одновременное выполнение обработки закрытия и запроса экрана
  не было заложено ни в один тестовый сценарий
- Существование временной таблицы не было отражено в проектном
  документе, поэтому не было учтено при доработке экрана
- Не было механизма обнаружения дублирования отображения;
  обнаружение полностью зависело от пользователя

## Что сработало хорошо
- Пользователь записал время в собственный журнал операций,
  что позволило быстро определить условия воспроизведения
- Механизм развёртывания был автоматизирован, поэтому исправленную
  версию удалось выпустить в тот же день

## Действия по предотвращению повторения (ответственный и срок)
- [ ] Добавить ассерт обнаружения дублирования в запрос списка (Комура, 22.07)
- [ ] Добавить тест на одновременное выполнение закрытия и запроса (Комура, 29.07)
- [ ] Отказаться от подхода с временной таблицей, рассмотреть изоляцию через снапшоты (Комура, решение к концу августа)

Приведём несколько замечаний по написанию.

• «Краткое описание» — не более 3 строк. Тот, кто будет искать этот документ позже, — это вы в будущем. Способность понять содержание за 3 строки при находке через поиск важнее красоты структуры разделов.
• В хронологию пишите только факты с указанием времени. Интерпретацию («должно было быть…», «следовало бы…») выносите отдельно, в разделы о причинах. Если в хронологию попадает интерпретация, при повторном чтении невозможно восстановить, что происходило на самом деле.
• Обязательно пишите «что сработало хорошо». Это не даёт разбору превратиться в самобичевание и служит входной точкой для того, чтобы возвести случайную удачу (например, «случайно оказался лог») в постоянный механизм.
• У каждого действия обязательно должны быть ответственный и срок. Действие без них и без срока никогда не выполняется. Реальная эффективность постмортема определяется тем, рецензируется ли он и отслеживаются ли действия.¹

5. Практика анализа причин — разделяем прямую причину и способствующие факторы

У разделения поля причины на два есть основание.

Прямая причина (direct cause) — это техническое событие, непосредственно вызвавшее инцидент. «Исключение из-за отсутствующей проверки на NULL», «UNION ALL без блокировки». Именно это исправляет патч.

Способствующие факторы (contributing factors) — условия, позволившие прямой причине проникнуть, остаться незамеченной или расширить ущерб. «Для этого случая не было теста», «не было записано в проектном документе», «обнаружение зависело от пользователя». Именно здесь разворачивается основная битва за предотвращение повторения, и таких факторов обычно несколько.

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

5.1 Не останавливайте «анализ пяти почему» на «действии человека»

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

• Почему проверку можно было забыть? → Потому что проверки не было ни в процедуре, ни в чек-листе, и она полагалась исключительно на память
• Почему она полагалась на память? → Потому что процедура релиза не была задокументирована и каждый раз собиралась на ходу

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

5.2 Без доказательств анализ не начнётся

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

• Дампы сбоев: если настроить WER LocalDumps, дамп при аварийном завершении сохраняется без необходимости просить пользователя что-либо делать. Настройка описана в статье «Введение в сбор дампов сбоев Windows», а как их читать — в статье «Чтение дампов сбоев с помощью WinDbg + SOS».
• Логи приложения: время, коррелируемый идентификатор, синхронная запись критических событий. О том, как спроектировать надёжное сохранение логов даже при сбое, см. «Как проектировать сохранение логов и дампов при сбое Windows-приложения».
• Журнал событий: даже если собственное логирование сломано, в стандартном журнале событий ОС сохраняется запись о сбое приложения (Application Error). О том, как им пользоваться, рассказано в статье «Введение в журнал событий Windows и ETW».

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

6. Качество мер против повторения — таблица оценки силы

Написав действия по предотвращению повторения, оцените их силу. Ось оценки — насколько мера зависит от человеческой внимательности.

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

Если приходят в голову только слабые меры, переспросите себя ещё раз следующими вопросами.

• «Если бы новый сотрудник оказался в точно такой же ситуации, этот инцидент бы всё равно не произошёл?» — если ответ «нет», это ещё не система.
• «Можно ли поручить обнаружение этой ошибки компилятору, тесту или CI?» — например, если проблема была в том, что «при завершении глотали исключение», сильной мерой будет не информирование, а реализация в виде общего обработчика исключений в коде политики, аналогичной той, что разобрана в статье «Таблица решений: завершать работу или продолжать при неожиданном исключении».
• «Можно ли сделать так, чтобы ошибку нельзя было допустить? Можно ли сделать так, чтобы её замечали быстрее?» — если предотвращение обходится дорого, ставка на обнаружение (мониторинг, сигналы, сверочное пакетное задание) — тоже вполне достойная сильная мера. Идея возвращать уроки инцидента в усиление обнаружения и улучшение архитектуры рекомендуется в той же логике и в рекомендациях Microsoft.²

Поскольку сильные меры требуют затрат труда, практично вносить в список действий одновременно «среднюю меру на эту неделю» и «сильную меру на следующий месяц», управляя обеими по сроку.

7. Для каких инцидентов это делать — триаж применения

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

Есть три ключевых момента для этого процесса.

• «Повторение инцидента того же рода» повышает уровень на одну ступень независимо от влияния. Сам факт повторения — доказательство того, что предыдущая мера так и не стала системой.
• Даже для мелочи обязательно оставляйте хотя бы запись. Достаточно одного абзаца. Всего четырёх пунктов — «дата, симптом, причина, реагирование» — достаточно, чтобы через несколько лет спасти вас же самого через поиск. Когда накопится достаточно записей о мелких инцидентах, станет видна и структурная неравномерность вроде «сбои концентрируются именно на этом экране».
• В сомнительных случаях склоняйтесь к тому, чтобы писать, но сокращайте объём. Если вы тратите время на раздумья «полный или нет», быстрее начать с упрощённой версии.

8. Как это устроено в заказной разработке — связь с отчётом об инциденте для клиента

В заказной разработке и договорах на сопровождение после инцидента клиент часто запрашивает «отчёт об инциденте». Заранее продумав отношения постмортема и отчёта, можно избежать двойной работы.

80% содержания можно переиспользовать напрямую. Краткое описание, влияние, хронология, прямая причина и меры против повторения — это как раз составляющие отчёта для клиента. Если сначала писать внутренний постмортем, а затем редактировать его для клиента, не придётся сочинять текст только ради отчёта.

Однако важно осознавать, что это два документа с разными целями, и разделять их.

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

Отдельно отметим: как только запланированная мера против повторения попадает в отчёт для клиента, она становится обещанием этому клиенту. Управляйте сроком тем же механизмом, что и полем действий постмортема, и отчитывайтесь по завершении. Именно этот один цикл превращает инцидент в возможность на самом деле укрепить доверие.

9. Итог

• Реагирование на инцидент не заканчивается восстановлением. Встройте разбор (постмортем) в рабочий процесс, рассматривая восстановление, установление причины и предотвращение повторения как отдельные работы.
• Основной принцип постмортема — blameless (без обвинений). Обвинив человека, вы лишаетесь потока информации и не доберётесь до первопричины. Не останавливайте анализ на действии человека — копайте до самой дыры в системе (способствующих факторов).¹
• Достаточно минимального шаблона, который пишется за час (краткое описание, влияние, хронология, прямая причина, способствующие факторы, что сработало хорошо, действия с ответственным и сроком). В качестве предпосылки для заполнения хронологии заранее настройте сохранение доказательств: дампы сбоев, логи и журнал событий.
• Поднимайте меры против повторения от «быть внимательнее» (слабо) к процедуре (средне) и по возможности до механического предотвращения тестами, ассертами, мониторингом или изменением архитектуры (сильно). Идея возвращать уроки в обнаружение и архитектуру общая как для SRE, так и для рекомендаций Microsoft.¹²
• Не проводите полный процесс для каждого инцидента. Проводите триаж по влиянию × вероятности повторения, и даже для мелких случаев обязательно оставляйте хотя бы запись в один абзац.
• В заказной разработке сначала пишите внутренний постмортем, а отчёт об инциденте для клиента редактируйте из него. Разделение документа об ответственности/компенсации и документа о предотвращении повторения сохраняет качество обоих.

Похожие статьи

• Введение в сбор дампов сбоев Windows - WER/ProcDump/WinDbg
• Чтение дампов сбоев с помощью WinDbg + SOS — практическое введение в анализ после сбора
• Как проектировать сохранение логов и дампов при сбое Windows-приложения
• Введение в журнал событий Windows и ETW — переносим логи бизнес-приложения на стандартный механизм ОС
• Практика перехвата исключений, логирования и обработки ошибок
• Таблица решений: завершать работу или продолжать при неожиданном исключении

Смежные направления консультаций

KomuraSoft LLC занимается расследованием и анализом причин трудновоспроизводимых дефектов, построением механизмов сохранения доказательств (сбор логов и дампов), а также выстраиванием системы эксплуатации и сопровождения, включающей предотвращение повторения. Мы рады консультациям и на этапе «один и тот же инцидент повторяется снова» или «меры против повторения в отчётах об инцидентах превратились в формальность».

• Расследование сбоев и анализ первопричин
• Доработка и сопровождение существующего Windows-ПО
• Техническая консультация и ревью проекта
• Контакты

Источники

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что такое постмортем? Чем он отличается от отчёта об инциденте?

Постмортем — это структурированный документ и процесс разбора, проводимый после восстановления от инцидента; практика закрепилась в области SRE (Site Reliability Engineering). Исходя из принципа blameless (без поиска виноватых), в нём фиксируются хронология, прямая причина, способствующие факторы и действия по предотвращению повторения. Если отчёт об инциденте для клиента — это документ, выполняющий обязательство отчитаться о том, «что произошло и как на это отреагировали», то постмортем — внутренний документ для решения вопроса «как изменить систему, чтобы это больше не повторилось». Однако значительная часть содержания совпадает, поэтому эффективнее сначала написать постмортем, а из него уже редактировать отчёт для клиента.

Меры против повторения у нас всё время сводятся к «впредь будем внимательнее». Что делать?

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

Мы небольшая заказная студия, и у нас нет ресурсов писать постмортем по каждому инциденту.

Полный постмортем не нужен для каждого инцидента, и если пытаться писать его для всех, сама практика не выживет. Проведите триаж по влиянию и вероятности повторения: полный процесс — для инцидентов с остановкой бизнеса или повреждением данных, а также при повторении инцидента того же рода; для незначительных достаточно оставить запись в один абзац в журнале инцидентов. Важно, что запись остаётся обязательной даже для мелочи — от того, можно ли найти прошлую запись через поиск, когда то же самое повторится через несколько лет, сильно зависит время расследования.

Разве отказ от поиска виноватых (blameless) — это не способ замять ответственность?

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

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.