Инцидент не закрывается восстановлением — постмортем для небольшой команды

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

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

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

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

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

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 16, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

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 случай, когда чуть не отгрузили повторно по ошибке
- Длительность: 15.07 примерно 09:10–11:40 (около 2,5 часов)

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

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

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

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

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

Чтобы шаблон можно было копировать как есть, ниже пустая заготовка. Положите её в репозиторий как docs/postmortem/_template.md и при инциденте копируйте в файл с датой в имени.

# Постмортем: явление в одну строку (YYYY-MM-DD)

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

## Краткое описание (не больше 3 строк)

## Влияние (кто / что / насколько)
- Затронуты:
- Что произошло:
- Длительность: MM/DD HH:MM — HH:MM (около   часов)

## Хронология
- HH:MM  (обнаружение: кто и как заметил)
- HH:MM
- HH:MM  (временная мера)
- HH:MM  (подтверждение восстановления)

## Прямая причина

## Способствующие факторы
- (условие, из-за которого дефект смог попасть)
- (условие, из-за которого его не заметили)
- (условие, из-за которого ущерб вырос)

## Что сработало хорошо
-

## Действия против повторения (ответственный и срок)
- [ ]  (ответственный, MM/DD)
- [ ]  (ответственный, MM/DD)

Несколько правил по заполнению.

• «Краткое описание» — не больше 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. Для каких инцидентов проводить: триаж

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

Три рабочих правила.

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

7.1 Как решить, что причина системная

Горизонталь таблицы «легко повторяется / системный» бесполезна, пока нет критерия. На практике достаточно простого правила: если выполняется хотя бы один пункт, считайте причину системной.

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

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

7.2 Как провести 30-минутное совещание

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

• Участников 3–5. Тот, кто разбирал инцидент; другие, кто может трогать тот же код; тот, кто ведёт заказчика. Тех, кто будет решать вопрос об ответственности, не зовите. Как только такой человек в комнате, высказывания становятся защитными, и способствующие факторы перестают всплывать. При необходимости хватит рассылки результата.
• Черновик раздайте заранее. На месте писать с нуля нельзя. При этом рассчитывать, что все прочитают заранее, нельзя, поэтому в начале закладывают время на чтение.
• Раскладка 30 минут. (1) 0–5 мин: каждый молча читает (2) 5–10 мин: сверка фактов в хронологии. Закрыть расхождения и пропущенные отметки времени (3) 10–20 мин: добавить способствующие факторы. Это основная часть (4) 20–28 мин: оценить силу действий по таблице главы 6 и закрепить ответственных и сроки (5) 28–30 мин: назначить день, когда проверите прогресс.
• Проверяйте только два вопроса. «Где ещё можно было заметить?» и «нет ли той же дыры в другом месте?». Если задать оба всем, всплывут факторы, которые один разбиравший не увидит.
• Ведёт не тот, кто разбирал инцидент. Как только в реплике подлежащим становится имя человека, ведущий меняет подлежащее на механизм. «А забыл проверить» → «проверки не было в процедуре». Одна эта замена, если делать её машинально, меняет тон комнаты.
• Не оставляйте действия без решения. То, что нельзя решить на месте, превращайте в действие «к такому-то числу выбрать подход», ставьте срок и закрывайте.

7.3 Куда класть журнал инцидентов

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

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

8. Заказная разработка: связь с отчётом для заказчика

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

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

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

8.1 Как формулировки меняются на практике

В абстракции это плохо видно, поэтому ниже те же формулировки из шаблона главы 4 и то, как они звучат в отчёте для заказчика.

Три правила переписывания.

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

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

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

9. Итог

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

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

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

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

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

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

Источники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Об авторе

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

Го Комура

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

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