Dein Blog zum Thema digitales Business

Der Vorfall ist vorbei, der Dienst läuft wieder, und irgendwo liegt ein Dokument mit dem Titel Postmortem. Ob es beim nächsten Vorfall hilft oder nur ablegt, was ohnehin alle wussten, entscheidet sich am Inhalt, nicht an der Existenz. Die meisten Postmortems scheitern nicht daran, dass niemand sie schreibt. Sie scheitern daran, dass sie die falschen Fragen beantworten.

Blameless heißt nicht folgenlos

Ein brauchbares Postmortem sucht keine Schuldigen. Das ist keine Höflichkeit, sondern Methodik: wer mit Konsequenzen rechnet, erzählt nicht mehr, was wirklich passiert ist, und ohne die echte Geschichte ist das Dokument wertlos. Blameless heißt aber nicht, dass nichts passiert. Es heißt, dass die Konsequenzen am System ansetzen statt an der Person. Der Satz „ein Kollege hat das falsche Skript auf Produktion ausgeführt“ ist kein Urteil über den Kollegen. Er ist ein Befund über ein System, in dem das falsche Skript auf Produktion ausführbar war.

Der Zeitstrahl kommt vor der Bewertung

Kern jedes Postmortems ist ein Zeitstrahl mit Uhrzeiten: wann begann die Störung, wann ist sie aufgefallen, wer wurde wann alarmiert, was wurde wann versucht, wann lief der Dienst wieder. Zwei Lücken in diesem Zeitstrahl sind oft interessanter als die Ursache selbst. Die Zeit zwischen Beginn und Entdeckung zeigt, ob die Überwachung das Problem gesehen hat oder ein Kunde schneller war. Die Zeit zwischen Entdeckung und Reaktion zeigt, ob klar war, wer zuständig ist.

Der Zeitstrahl entsteht aus Logs, Chat-Verläufen und der Deployment-Historie, nicht aus dem Gedächtnis. Drei Tage nach dem Vorfall erinnert sich jeder Beteiligte anders, und zwar jeder in die Richtung, die seine Rolle gut aussehen lässt. Das ist menschlich und genau der Grund, das Dokument innerhalb weniger Tage zu schreiben, solange die Belege greifbar sind.

Beitragende Faktoren statt einer Wurzelursache

Die Frage nach der einen Root Cause führt in die Irre. Vorfälle mit ernsthaften Folgen entstehen fast immer aus mehreren Faktoren, die einzeln harmlos gewesen wären: eine Änderung löst aus, eine Prüfung hätte sie gestoppt und lief nicht, die Überwachung hätte gewarnt und tat es nicht, die Zuständigkeit für die Reaktion war unklar. Wer nur den Auslöser behandelt, hat drei von vier Faktoren stehen lassen. Der nächste Vorfall nimmt denselben Weg mit anderem Auslöser.

Praktisch heißt das: statt einer Ursache eine Liste beitragender Faktoren, jeder mit der Frage, warum er an diesem Tag wirken konnte. Dazu gehört auch, was funktioniert hat. Ein Rollback, der nach acht Minuten saß, ist ein Befund, den man festhalten sollte, damit er beim nächsten Mal wieder klappt.

Maßnahmen mit Namen, Datum und Wirkungsprobe

Ein Postmortem ohne Maßnahmen ist ein Protokoll. Jede Maßnahme braucht drei Dinge: eine benannte Person, ein Datum und ein Kriterium, an dem man erkennt, ob sie wirkt. „Monitoring verbessern“ erfüllt keines davon. „Alarm auf Fehlerrate der Checkout-API, Schwellwert X, bis Ende September, danach Testalarm“ erfüllt alle drei.

Weniger ist dabei mehr. Drei umgesetzte Maßnahmen schlagen zehn offene, die nach einem Quartal niemand mehr zuordnen kann. Und die offenen gehören in denselben Backlog wie die übrige Arbeit. Maßnahmen, die in einem separaten Dokument leben, konkurrieren nie um Zeit und werden deshalb nie erledigt.

Der Wert entsteht beim Wiederlesen

Ein Postmortem, das nach der Besprechung niemand mehr öffnet, hat seinen Zweck verfehlt. Deshalb: zentral ablegen, auffindbar nach Symptom und betroffenem System, nicht nur nach Datum. Beim nächsten Vorfall ist die erste Frage, ob es so etwas schon gab. Und in ruhigen Wochen lohnt der Blick über mehrere Postmortems hinweg. Wiederkehrende Muster, etwa dass die Entdeckung dreimal in Folge über Kunden lief statt über die eigene Überwachung, sind die eigentliche Erkenntnis, die kein einzelnes Dokument liefern kann.

Wer damit anfängt, braucht keine Vorlage mit zwanzig Feldern. Zeitstrahl, beitragende Faktoren, Maßnahmen mit Person und Datum, zentrale Ablage. Das erste Postmortem nach diesem Muster ist in zwei Stunden geschrieben und trägt mehr als jedes Formular.

---

Wir helfen kleinen Softwarehäusern beim Aufbau ihrer Nachweis- und Freigabeketten in der Pipeline, bei der Frage, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen, und bei der Klärung, wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de.