Was macht eine gute Postmortem aus?

Eine gute Postmortem ist schuldfrei, konkret und erzeugt Veränderung. Sie enthält eine akkurate Timeline, den echten Nutzerimpact, wie das Problem erkannt und mitigiert wurde und beitragende Faktoren statt einer einzigen Ursache. Maßnahmen sind konkret, haben Owner und werden wie jede andere Arbeit priorisiert, keine Wunschliste. Der Fokus liegt darauf, warum das System den Fehler zugelassen hat, inklusive Lücken bei Alerting und Schutzmechanismen, nicht darauf, wer das Kommando getippt hat.

Schuldfrei zuerst, und nicht als Nettigkeit. Wenn Leute damit rechnen, benannt zu werden, erzählen sie dir nicht mehr, was wirklich passiert ist, und dann ist deine Timeline Fiktion und du lernst nichts. Das Framing ist also immer, warum das System das zugelassen hat, nicht wer es getan hat. Inhaltlich will ich eine ehrliche Timeline mit Zeitstempeln, den tatsächlichen Nutzerimpact in Zahlen statt des Wortes degradiert, wann wir es erkannt haben gegenüber wann es begann, und wann wir mitigiert haben gegenüber wann wir es verstanden haben. Die Lücke zwischen Beginn und Erkennung ist meist das Wertvollste im Dokument, und sie erzeugt oft eine bessere Maßnahme als den ursprünglichen Bug zu fixen. Ich vermeide den Begriff Root Cause, weil er einlädt, bei der ersten plausiblen Antwort stehenzubleiben. Es gibt meist drei oder vier beitragende Faktoren, und die interessanten sind die fehlenden Leitplanken. Maßnahmen brauchen einen Namen mit Datum, eine ehrliche Schätzung und einen Platz im echten Backlog. Eine Postmortem, deren Maßnahmen nie eingeplant werden, ist schlechter als keine, denn sie lehrt die Leute, dass der Prozess Deko ist.