Post-Mortem
Ein Post-Mortem ist ein schriftlicher Bericht, den ein Technikteam nach einer Störung verfasst: Was ist passiert, warum, und was ändern wir, damit es nicht wieder passiert? Große Anbieter wie Cloudflare oder OpenAI veröffentlichen solche Berichte nach Ausfällen oft öffentlich.
Wenn ein großer Online-Dienst plötzlich nicht mehr erreichbar ist, endet die Arbeit nicht mit der Reparatur. Danach setzt sich das zuständige Team hin und schreibt auf, was schiefgelaufen ist. Dieser Bericht heißt Post-Mortem, wörtlich „nach dem Tod“ — der Begriff kommt aus der Medizin, wo damit die Untersuchung einer Leiche gemeint ist. In der Technik ist damit die Untersuchung einer Störung gemeint, nicht die Suche nach einem Schuldigen. Ein solcher Bericht hält den Zeitverlauf fest, die Ursache, die Folgen für die Nutzer und eine Liste von Maßnahmen. Viele Firmen veröffentlichen ihn im Internet, damit Kunden und Fachleute nachlesen können, was passiert ist.
Warum Firmen ihre eigenen Ausfälle öffentlich aufschreiben
Der wichtigste Grund ist banal: Ohne Aufschreiben wiederholt sich der Fehler. Nach einem stressigen Einsatz um drei Uhr morgens erinnert sich in zwei Monaten niemand mehr an die Details. Ein Post-Mortem macht aus einem einmaligen Schrecken dauerhaftes Wissen des Unternehmens. Neue Mitarbeiter können nachlesen, welche Schwachstellen das System schon einmal hatte.
Der zweite Grund ist Vertrauen. Wer einen Cloud-Dienst bezahlt, also gemietete Rechenleistung in einem fremden Rechenzentrum, will nach einem Ausfall eine Erklärung. Ein ausführlicher, technisch ehrlicher Bericht wirkt dabei oft besser als eine knappe Entschuldigung. Bleibt die Erklärung aus, entstehen stattdessen Gerüchte — etwa über einen Hackerangriff, obwohl nur eine Konfigurationsdatei falsch war.
Ein zentrales Prinzip heißt „blameless“, also schuldfrei. Der Bericht nennt keine Personen, sondern nur Abläufe und Systeme. Der Gedanke dahinter: Wenn ein einzelner Klick eine weltweite Störung auslösen kann, ist nicht der Klick das Problem, sondern das System, das ihn zulässt. Wo Mitarbeiter mit Strafe rechnen müssen, verschweigen sie Fehler — und dann lernt niemand etwas.
Vom Zeitstrahl zur Ursachenkette
Fast jedes Post-Mortem beginnt mit einer Zeitleiste, oft minutengenau. Sie hält fest, wann der Fehler eingebaut wurde, wann die Überwachung Alarm gab, wann Menschen reagierten und wann der Dienst wieder lief. Aus der Zeitleiste lassen sich zwei wichtige Zahlen ablesen: wie lange es dauerte, das Problem zu bemerken, und wie lange, es zu beheben. Häufig ist die erste Zahl die peinlichere.
Danach folgt die Ursachenanalyse. Sie fragt nicht nur, welches Bauteil versagt hat, sondern warum das überhaupt möglich war. Eine verbreitete Methode ist, fünfmal „warum“ zu fragen: Die Seite war offline, weil ein Server überlastet war. Der war überlastet, weil eine automatische Verteilung ausfiel. Die fiel aus, weil ein Update nicht getestet war — und so weiter, bis man an der eigentlichen Lücke ankommt.
Am Ende steht eine Liste von Maßnahmen, jede mit Verantwortlichem und Frist. Genau hier scheitern schwache Post-Mortems: Der Bericht ist gut geschrieben, aber die Aufgaben werden nie abgearbeitet. Ein Post-Mortem ohne Nachverfolgung ist reine Beruhigung. Deshalb behandeln viele Teams die Maßnahmen wie normale Arbeitsaufträge und prüfen ihren Stand in festen Terminen.
Ausfallberichte in der KI-Branche
Post-Mortems begegnen dir vor allem als Meldung nach einer großen Störung. Wenn ChatGPT stundenlang keine Antworten liefert oder ein Bezahldienst ausfällt, erscheint kurz darauf ein Bericht auf der Statusseite oder im Technikblog des Anbieters. Bekannt sind etwa die Berichte von Cloudflare, Amazon Web Services und GitHub. Fachmedien greifen sie auf, weil sie seltene Einblicke in das Innere sehr großer Systeme geben.
In der KI-Branche kommen eigene Fehlerarten dazu. Ein Modell kann plötzlich seltsam antworten, weil eine Änderung am Antwortverhalten schlecht getestet wurde. Auch Datenlecks, bei denen Nutzer fremde Gesprächstitel sehen, wurden schon per Post-Mortem erklärt. Für Anleger sind solche Berichte interessant, weil sie zeigen, wie belastbar die Technik eines Anbieters wirklich ist.
Der Begriff wird außerdem lockerer verwendet, etwa für die Nachbesprechung eines gescheiterten Produkts oder eines Projekts, das den Termin gerissen hat. In der Spielebranche sind Post-Mortems zu fertigen Spielen eine eigene Textsorte. Verwechseln solltest du den Bericht nicht mit dem Incident selbst: Der Incident ist die Störung, das Post-Mortem die Auswertung danach.