Простыми словами
Представьте разбор аварии, где ищут не «кто плохой», а какие условия сделали ошибку вероятной и незаметной. Такой postmortem помогает людям честно сообщать детали, поэтому организация исправляет систему, а не только наказывает последнего участника цепочки.
Пример при разработке
После сбоя команда разбирает, какие условия и защиты позволили ошибке дойти до пользователей, а не ищет виноватого разработчика. Итогом становятся конкретные изменения системы.
Это редакционный пример применения, а не часть определения или доказательство концепции.Механизм действия
Сначала проверяют, есть ли исходное условие из определения. Затем смотрят, как оно влияет на структуру компонентов, потоки данных, ограничения и действия участников. Если эту связь не удаётся наблюдать, принцип не стоит использовать как готовое объяснение.
Пример в работе
Применять локальное решение без проверки контекста, ограничений и вторичных последствий.
Сначала определить механизм, затем выбрать минимальное изменение и измерить результат.
Ограничения
«Blameless Postmortem» объясняет только часть происходящего в области «Надежность и SRE». Сам принцип не говорит, насколько сильным будет эффект в вашем случае, и не заменяет измерения. При другом масштабе, среде или временном горизонте результат может отличаться.
Источник
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy. Site Reliability Engineering: Postmortem Culture. 2016. ISBN 9781491929124.