Postmortems, Die Wirklich Etwas Verändern

Ein Postmortem ist leicht abzuhalten und schwer nützlich zu machen. Das Meeting findet statt, ein Dokument wird geschrieben, vier Maßnahmen werden festgehalten, und sechs Monate später tritt derselbe Fehler erneut auf, während jemand das alte Dokument bei der Suche nach etwas anderem findet.

Das Wort schuldfrei bekommt in solchen Diskussionen die meiste Aufmerksamkeit, und es ist auch wirklich wichtig, aber dort steckt das Problem nicht. Viele Organisationen führen peinlich genau schuldfreie Reviews durch, die trotzdem nichts verändern, weil das Review selbst als Ergebnis behandelt wurde und nicht als das, was ein Ergebnis erst hervorbringen soll.

Der Test, ob Ihre funktionieren, ist beschämend einfach: Welcher Anteil der Maßnahmen aus den letzten sechs Monaten ist erledigt? Lautet die Antwort die meisten, dann funktioniert der Prozess, wie er auch aussehen mag. Liegt sie unter der Hälfte, halten Sie Meetings ab, statt einen Prozess zu betreiben, und bessere Vorlagen werden daran nichts ändern. Weniger Punkte, mit Verantwortlichen und Termin, schlagen eine gründliche Liste, für die niemand Zeit hat.

Wozu ein Postmortem tatsächlich dient

Nicht dazu, zu erklären, was passiert ist. Die Beteiligten wissen das am Ende der Störung in aller Regel längst.

Es existiert, um die Bedingungen zu finden, unter denen ein kleines Problem groß werden konnte, und um einige davon zu verändern. Das ist eine andere Frage als die danach, was kaputtgegangen ist, und der Unterschied zeigt sich sofort im Bericht. “Der Datenbank gingen die Verbindungen aus” beschreibt, was kaputtging. “Auf die Auslastung des Verbindungspools hat nichts alarmiert, und das Dashboard, das sie gezeigt hätte, steht nicht im Runbook der Rufbereitschaft” beschreibt eine Bedingung, und daraus lässt sich etwas machen.

Das Zweite, was dabei entsteht und regelmäßig unterschätzt wird, ist eine gemeinsame Darstellung des Vorfalls. Ohne sie behält jeder seine eigene Version, und diese Versionen driften in die Richtung dessen, was die jeweilige Person ohnehin schon über das System geglaubt hat. Ein Jahr später streiten dann zwei Teams über ein Ereignis, das sie beide erlebt haben.

Schuldfrei bedeutet etwas Bestimmtes

Es bedeutet nicht, dass niemand einen Fehler gemacht hat. Es bedeutet, dass die Analyse davon ausgeht, dass eine Person auf Basis der verfügbaren Informationen vernünftig gehandelt und dabei etwas getan hat, das sich als falsch herausstellte, und dass sie fragt, warum diese Handlung in diesem Moment richtig aussah. Googles SRE-Buch beschreibt diese Praxis und die Fehlermuster, die damit einhergehen.

Der Grund, warum das nicht bloß Freundlichkeit ist: Schuldzuweisung zerstört Information. In einer Organisation, in der Störungen an einzelnen Personen hängen bleiben, beschreiben Menschen Ereignisse vorsichtig, lassen das Detail weg, das schlecht aussieht, und melden erst, wenn sie genug verstanden haben, um es sicher darstellen zu können. Das Review arbeitet dann mit einer Darstellung, die zum Selbstschutz überarbeitet wurde, und das ist der denkbar schlechteste Ausgangspunkt.

Praktisch ist schuldfrei vor allem eine Eigenschaft der Sprache. “Warum haben Sie den Dienst neu gestartet?” lädt zur Verteidigung ein. “Was zeigte das Dashboard, als Sie sich für den Neustart entschieden haben?” lädt zu Information ein. Die zweite Frage ist auch die nützlichere, weil die Antwort eine Tatsache über Ihr Monitoring ist und nicht über eine Kollegin.

Wenn ein echtes Leistungsproblem besteht, sprechen Sie es getrennt und direkt an. Es innerhalb des Incident Reviews zu tun, verdirbt das Review, und es ist ohnehin eine schlechte Art, dieses Gespräch zu führen.

Eine Zeitleiste bauen, die etwas lehrt

Die Zeitleiste ist der wertvollste Teil des Dokuments und zugleich der Teil, der am häufigsten schlecht geschrieben wird, nämlich als Folge technischer Ereignisse, aus der die Menschen entfernt wurden.

Halten Sie fest, was die Beteiligten wussten und wann. Nicht nur “der Dienst wurde um 14:32 neu gestartet”, sondern was die Person um 14:32 sehen konnte und was sie in diesem Moment für die Lage hielt. Genau dort liegt das verwertbare Material, denn eine Verzögerung von fünfzehn Minuten, verursacht durch ein mehrdeutiges Dashboard, ist ein behebbares Problem, während eine bloß als Lücke protokollierte Verzögerung keines ist.

Markieren Sie die Momente, auf die es ankam: wann es begann, wann es überhaupt jemandem auffiel, wann die richtige Person eingebunden war, wann die Ursache verstanden war, wann gemildert wurde und wann es behoben war. In den Abständen dazwischen steckt die Verbesserung, und die Zeit bis zur Entdeckung ist sehr oft der größte davon.

Schreiben Sie die Zeitleiste, solange alles frisch ist, idealerweise innerhalb von ein bis zwei Tagen. Die Erinnerung daran, was jemand in einem bestimmten Moment geglaubt hat, verblasst deutlich schneller als die Erinnerung daran, was tatsächlich geschehen ist.

Es gibt selten eine einzige Ursache

Die Formulierung verleitet dazu, bei der ersten plausiblen Erklärung stehen zu bleiben, und Störungen jeder Größe sind Ketten, in denen mehrere Dinge gleichzeitig zutreffen mussten.

Ein brauchbares Review führt stattdessen beitragende Faktoren auf: die Änderung, die es auslöste, den Test, der es gefunden hätte und den es nicht gab, den Alarm, der in einen Kanal lief, den niemand beobachtet, das Runbook, das für eine frühere Architektur zutraf. Jeder davon ist eine eigene Gelegenheit, und Sie können die zwei billigsten beheben statt desjenigen, der zufällig als Erster in der Kette stand.

Das verringert auch eine verbreitete Verzerrung. Wenn ein Review eine einzige Ursache benennt, lautet diese sehr oft “menschliches Versagen”, was eine Beschreibung ist und keine Erklärung, und was die Untersuchung genau dort beendet, wo sie hätte beginnen müssen.

Die Nachverfolgung zum Laufen bringen

Hier entscheidet sich, ob Postmortems etwas taugen, und die Mittel dafür sind unspektakulär.

Weniger Punkte. Zwei, die erledigt werden, schlagen acht, die es nicht werden. Sortieren Sie danach, ob sie Entdeckungszeit, Reichweite oder Wahrscheinlichkeit verringern, und streichen Sie den Rest.

Eine benannte verantwortliche Person und ein Termin, im normalen Arbeits-Tracker statt im Dokument. Punkte, die nur im Postmortem leben, sind während der Planung unsichtbar, und genau dann wird Arbeit eingeplant.

Prüfen Sie die offenen Punkte im nächsten Postmortem. Diese eine Gewohnheit bewirkt mehr als jede Vorlage. Sie macht Unerledigtes sichtbar und macht aus einer Reihe unverbundener Meetings einen Prozess.

Nehmen Sie manche Punkte ehrlich an. Ein Team, das dauerhaft die Hälfte seiner Zusagen schafft, sollte halb so viel zusagen. Eine Absicht festzuhalten, die niemand finanzieren wird, ist schlechter als die Entscheidung festzuhalten, nichts zu tun, denn Letztere ist wenigstens wahr.

Die Verbesserungen daraus gehören meist zur selben Familie wie in unserem Leitfaden zur Notfallwiederherstellung und in den Softwaretest-Strategien: schnellere Entdeckung, kleinere Reichweite, ein betreibbares System.

Mecanik führt im Rahmen der Server-Sicherheitsanalyse Incident Reviews für betreute Systeme durch. Das Muster ist fast immer dasselbe: Die technische Ursache war schnell verstanden, und die Lücke bis zur Entdeckung war der teure Teil.

Häufig gestellte Fragen

Wozu dient ein Postmortem? Dazu, die Bedingungen zu finden, unter denen ein kleines Problem groß werden konnte, und einige davon zu verändern, was eine andere Frage ist als die danach, was kaputtging. Es erzeugt außerdem eine gemeinsame Darstellung des Vorfalls, ohne die jeder eine private Version behält, die in Richtung dessen driftet, was er ohnehin über das System glaubte.

Was bedeutet schuldfrei konkret? Dass die Analyse davon ausgeht, dass eine Person auf Basis der verfügbaren Informationen vernünftig gehandelt und dabei etwas Falsches getan hat, und fragt, warum es damals richtig aussah. Es zählt, weil Schuldzuweisung Information zerstört: Menschen überarbeiten ihre Darstellung zum Selbstschutz, und das Review arbeitet dann mit einem verdorbenen Ausgangspunkt.

Soll ein Postmortem eine einzige Ursache benennen? Nein. Störungen jeder Größe sind Ketten, in denen mehrere Bedingungen gleichzeitig zutreffen mussten, deshalb ist eine Liste beitragender Faktoren nützlicher. Sie können damit die zwei billigsten beheben statt dessen, was zufällig als Erstes kam, und Sie enden nicht bei “menschlichem Versagen”, was eine Beschreibung ist und keine Erklärung.

Was gehört in eine Incident-Zeitleiste? Was die Beteiligten wussten und wann, nicht nur, was die Systeme taten. Halten Sie fest, wann es begann, wann es überhaupt jemandem auffiel, wann die richtige Person eingebunden war, wann die Ursache verstanden war, wann gemildert wurde und wann es behoben war. In den Abständen steckt die Verbesserung, und die Entdeckungszeit ist meist die größte.

Warum werden Postmortem-Maßnahmen nie erledigt? Weil sie im Dokument leben statt im Arbeits-Tracker und deshalb unsichtbar sind, wenn Arbeit geplant wird. Beheben Sie es mit weniger Punkten, einer benannten verantwortlichen Person und einem Termin im normalen Tracker sowie einer Durchsicht der offenen Punkte zu Beginn des nächsten Postmortems, die Unerledigtes sichtbar macht.