Was macht ein Postmortem blameless, und was gehört hinein?

Blameless heißt, dass die Aufarbeitung fragt, wie das System einer vernünftigen Person diese Handlung erlaubt hat, und nicht, wer es kaputt gemacht hat. Rein gehören eine Zeitleiste, die gegen das SLO quantifizierte Auswirkung auf User, beitragende Faktoren, was gut lief, und Maßnahmen mit benannten Verantwortlichen und Fristen. Verbiete Konjunktive wie hätte wissen müssen. Der echte Test ist, ob die Maßnahmen tatsächlich erledigt werden, verfolg sie also wie jede andere Arbeit.

Blameless heißt nicht nett sein, es heißt an die Wahrheit kommen. Wenn Leute Bestrafung erwarten, bekommst du geschönte Zeitleisten und erfährst nie, was wirklich passiert ist, und der nächste Incident ist identisch. Konkret will ich eine Zeitleiste mit Zeitstempeln, eine quantifizierte Auswirkung (wir haben 60% des monatlichen Error Budgets verbrannt und 12.000 Checkouts sind gescheitert), beitragende Faktoren statt einer einzelnen Root Cause, und einen Abschnitt darüber, was gut lief, den Leute überspringen und über den du herausfindest, dass dich das Runbook oder das Rollback-Tooling gerettet hat. Maßnahmen brauchen einen Verantwortlichen und ein Datum und wandern mit echter Priorität ins normale Backlog, sonst hast du ein hübsches Dokument geschrieben, das nichts ändert. Die Sprachregel, die ich durchsetze, ist: keine Konjunktive. Nicht der Engineer hätte es merken müssen, sondern das Deploy-Tool hat eine Änderung ohne Canary und ohne Bestätigung rausgehen lassen. Diese Umformulierung produziert fast immer einen besseren Fix als eine Schulungserinnerung.