Vorlage für ein Postmortem

Ein Postmortem ist eine schriftliche Auswertung eines Vorfalls, die nach der Wiederherstellung des Dienstes fertiggestellt wird. Googles SRE-Buch definiert es als Aufzeichnung des Vorfalls, seiner Auswirkungen, der Maßnahmen zur Eindämmung, seiner Grundursachen und der Folgemaßnahmen, die eine Wiederholung verhindern. Eine Postmortem-Vorlage hält diese Aufzeichnung von einem Vorfall zum nächsten einheitlich.

Postmortems sind blameless, also frei von Schuldzuweisungen. Sie gehen davon aus, dass alle nach bestem Wissen mit den verfügbaren Informationen gehandelt haben, und fragen, was das System zugelassen hat, nicht, wem ein Fehler unterlaufen ist. Teams, die mit Schuldzuweisungen rechnen, melden keine Probleme mehr, und der Auswertung fehlen die Details, auf die sie angewiesen ist.

Dasselbe Dokument hat auch andere Namen: Post-Incident Review bei Microsoft und GitLab, Correction of Error (COE) bei Amazon.

Legen Sie die Kriterien vor dem nächsten Vorfall fest, damit niemand sie hinterher diskutieren muss. Googles SRE-Buch nennt typische Auslöser:

• Für Nutzer sichtbare Ausfallzeit oder Beeinträchtigung über einem festgelegten Schwellenwert
• Datenverlust jeglicher Art
• Eingriff durch die Bereitschaft, etwa ein Rollback oder das Umleiten von Traffic
• Eine Lösungszeit über einem festgelegten Schwellenwert
• Ein Versagen des Monitorings, bei dem der Vorfall manuell entdeckt wurde

Jeder Stakeholder kann außerdem eines anfordern. AWS ergänzt, dass ein Vorfall keinen Ausfall voraussetzt: Auch ein Beinahe-Vorfall oder ein System, das sich unerwartet verhält und trotzdem funktioniert, ist eine Auswertung wert. GitLab verlangt eine Auswertung für jeden S1- und S2-Vorfall und erlaubt allen, für niedrigere Schweregrade eine anzufordern.

Schreiben Sie es, solange die Details frisch sind. Googles veröffentlichtes Beispiel erschien weniger als eine Woche nach Abschluss des Vorfalls, und Azure veröffentlicht seine finalen Reviews in der Regel innerhalb von 14 Tagen.

Angaben zum Postmortem

Geben Sie dem Postmortem eine verantwortliche Person, kein Gremium. Google nennt vier Verantwortliche als Kennzeichen eines schwachen Postmortems: Mitwirkende helfen, eine Person treibt es bis zum Abschluss voran. Benennen Sie außerdem eine prüfende Person. Bei GitLab gibt ein „Bar Raiser“ aus dem Kollegenkreis jede Auswertung frei, bevor sie abgeschlossen werden kann. Verlinken Sie den Vorfallsbericht und die Ursachenanalyse, statt sie zu wiederholen.

Zusammenfassung

Schreiben Sie sie zuletzt. AWS empfiehlt, die Zusammenfassung so zu schreiben, als ginge sie per E-Mail an die wichtigsten Stakeholder Ihres Unternehmens: wer betroffen war, wie lange, wie der Vorfall eingedämmt wurde und was eine Wiederholung verhindern soll. Sie sollte für sich allein verständlich sein.

Auswirkungen

Verwenden Sie Zahlen: fehlgeschlagene Anfragen, betroffene Kunden, Minuten mit Auswirkungen, verbrauchtes Error Budget. Google unterteilt die Auswirkungen in Nutzer, Umsatz und Team, weil die Stunden, die die Beteiligten aufgewendet haben, Teil der Kosten sind. Wenn ein Wert geschätzt ist, geben Sie an, wie er geschätzt wurde.

Wichtige Momente der Zeitleiste

Halten Sie nur die Momente fest, die zählen: Auslöser, Erkennung, Eskalation, Eindämmung und Behebung. Beginnen Sie beim Auslöser, etwa einem Deployment oder einer Traffic-Spitze, nicht beim ersten Alarm, und verwenden Sie UTC. Die minutengenaue Zeitleiste bleibt im Vorfallsbericht.

Grundursache und Auslöser

Halten Sie beides auseinander. Der Auslöser hat den Vorfall in Gang gesetzt; die Grundursache ist die Bedingung, durch die daraus ein Vorfall werden konnte. In Googles Beispiel-Postmortem war der Auslöser ein plötzlicher Anstieg des Traffics und die Grundursache ein latentes Ressourcenleck. Die Art der Grundursache zeigt, welche Art von Korrektur Sie suchen sollten: GitLab erwartet, dass ein durch eine Code-Änderung verursachter Vorfall zu Maßnahmen führt, die ähnliche Fehler künftig abfangen, nicht nur zu einem Patch. Für die vollständige Analyse nutzen Sie die Vorlage für die Ursachenanalyse.

Erkennung, Diagnose und Eindämmung

Dieser Abschnitt fragt, wie die Reaktion schneller hätte sein können. Für jede Phase fragt der Correction-of-Error-Prozess von AWS, wie Sie die Zeit halbieren könnten. GitLab behandelt langsame Erkennung oder Wiederherstellung als begünstigende Ursache, die eine eigene Korrekturmaßnahme braucht.

Erkenntnisse

Drei Listen aus Googles Vorlage: was gut lief, was schlecht lief und wo Sie Glück hatten. Die letzte erfasst Beinahe-Vorfälle, also Dinge, die den Schaden zufällig begrenzt haben und beim nächsten Mal fehlen werden.

Maßnahmen

Das ist der Teil, der etwas verändert. Jede Maßnahme hat eine verantwortliche Person, eine Priorität, ein Fälligkeitsdatum und einen Link zum Ticket, in dem sie nachgehalten wird. Formulieren Sie einen überprüfbaren Endzustand („Alarm, wenn die Connection-Pool-Auslastung 80 % übersteigt“, nicht „Monitoring verbessern“) und decken Sie Prävention und Erkennung ab, nicht nur die Reparatur. Googles Postmortem-Checkliste verlangt mindestens eine Maßnahme mit hoher Priorität oder die ausdrückliche Zustimmung der Stakeholder, dass das Risiko einer Wiederholung akzeptiert wird.

Checkliste für die Prüfung

Die Checkliste basiert auf Googles Postmortem-Checkliste und den Abschlusskriterien von GitLab. Ein Postmortem ist fertig, wenn die Auswirkungen erfasst sind, jede Maßnahme eine verantwortliche Person hat und nachgehalten wird, schuldzuweisende Formulierungen entfernt sind, die prüfende Person es freigegeben hat und es geteilt wurde.

Ergänzende Informationen

Verlinken Sie Dashboards, Logs und den Incident-Chat, statt sie hineinzukopieren. Listen Sie auch verwandte Vorfälle auf, einschließlich ähnlicher, die keine exakten Wiederholungen sind. Ein Muster über mehrere Vorfälle hinweg ist oft eine wichtigere Erkenntnis als jedes einzelne Postmortem.

Das folgende Beispiel führt den Vorfall INC-2026-017 aus den Vorlagen für den Vorfallsbericht und die Ursachenanalyse fort.

Titel: Erschöpfter Datenbank-Connection-Pool verursachte erhöhte API-Fehler Vorfall: INC-2026-017, SEV-2, 3. September 2026 Verantwortlich: Lead Platform Engineering Prüfung: Staff Engineer, Database Team Status: Freigegeben, Maßnahmen offen Öffentliches Postmortem: Nicht erforderlich

Zusammenfassung

Zwischen 14:03 und 14:31 UTC schlugen etwa 18 % der Anfragen an die öffentliche API fehl. Lang laufende analytische Abfragen hielten Datenbankverbindungen offen, bis der gemeinsam genutzte Pool erschöpft war. Die Beteiligten beendeten die Abfragen und erhöhten die Verbindungskapazität. Wir erzwingen ein Abfrage-Timeout für den Analytics-Workload, verschieben ihn in einen eigenen Connection-Pool und richten einen Sättigungsalarm ein.

Auswirkungen

18 % der API-Anfragen schlugen 28 Minuten lang fehl. Dashboards und Statusseite waren nicht betroffen, und es gingen keine Daten verloren. Vier Engineers haben jeweils etwa eine Stunde für die Reaktion aufgewendet.

Wichtige Momente der Zeitleiste

Grundursache und Auslöser

Grundursache: Auf dem Connection-Pool, den sich Analytics und kundenseitiger Traffic teilten, wurde kein Abfrage-Timeout erzwungen. Auslöser: Ein geplanter Analytics-Job. Art: Kapazität

Erkennung, Diagnose und Eindämmung

Der Alarm für die Fehlerrate wurde vier Minuten nach Beginn der Auswirkungen ausgelöst. Ein Sättigungsalarm für den Connection-Pool hätte ausgelöst, bevor auch nur eine Anfrage fehlschlug. Die Fehler mit dem Pool in Verbindung zu bringen, dauerte acht Minuten, weil das Datenbank-Runbook keinen Schritt für erschöpfte Verbindungen enthielt.

Erkenntnisse

• Gut gelaufen: Der Alarm für die Fehlerrate wurde innerhalb von vier Minuten ausgelöst, und der Vorfall wurde fünf Minuten später ausgerufen.
• Schlecht gelaufen: Analytics- und API-Traffic teilten sich einen Pool, und für dessen Sättigung gab es keinen Alarm.
• Glück gehabt: Der Job lief vor der Spitzenlast aus den USA.

Maßnahmen

Ein Vorfall bringt in der Regel alle drei hervor, in dieser Reihenfolge.

Das Postmortem baut auf den beiden anderen auf, statt den Vorfall neu zu rekonstruieren. Es übernimmt die Fakten aus dem Vorfallsbericht und die Ursache aus der Ursachenanalyse und macht daraus Erkenntnisse und verantwortete Maßnahmen. Vorfälle mit geringem Schweregrad brauchen vielleicht nur den Bericht.

Manche Vorfälle brauchen eine Fassung für Kunden. GitLab veröffentlicht für jeden S1-Vorfall eine öffentliche Ursachenanalyse, und Google empfiehlt, Postmortems so breit wie möglich zu teilen, „perhaps even with your customers“. Ein öffentliches Postmortem ist ein eigenes Dokument, das auf Basis des internen geschrieben wird, nicht das interne mit entfernten Namen.

Die Post-Incident Reviews von Azure beantworten jedes Mal dieselben sechs Fragen:

1. Was ist passiert?
2. Was ist schiefgelaufen und warum?
3. Wie haben wir reagiert?
4. Wie machen wir solche Vorfälle unwahrscheinlicher oder weniger folgenreich?
5. Wie können Kunden die Folgen solcher Vorfälle für sich verringern?
6. Wie können wir unsere Kommunikation bei Vorfällen nützlicher machen?

Behalten Sie die Details, die Vertrauen zurückgewinnen: Zeiten, Umfang, die Ursache in verständlicher Sprache und die Änderungen, die Sie vornehmen. Lassen Sie interne Namen, vorläufige Theorien und alles weg, was einen einzelnen Kunden oder Nutzer identifiziert. Veröffentlichen Sie es dort, wo Kunden während des Vorfalls nachgesehen haben, etwa auf Ihrer Statusseite, und verlinken Sie es im letzten Update zum Vorfall.

• Beschreiben Sie das System, nicht die Person. Die Richtlinien von GitLab zeigen den Unterschied an Beispielen:

  Schreiben Sie	Statt
  „Der Deployment-Prozess hat dieses Problem nicht abgefangen“	„Person X hat einen Fehler gemacht“
  „Wir hatten kein Monitoring für diesen Zustand“	„Sie haben den Prozess nicht befolgt“
  „Das Runbook hatte keinen Schritt für dieses Szenario“	„Die On-Call-Person hätte das wissen müssen“

• Veröffentlichen Sie innerhalb von ein bis zwei Wochen. Googles Beispiel für ein schwaches Postmortem wurde vier Monate nach dem Vorfall veröffentlicht. Der Ausfall aus dieser Fallstudie trat erneut auf, und ein spät geschriebener Bericht verliert die Details, die geholfen hätten.

• Bleiben Sie sachlich. Dramatische Beschreibungen lenken von den Erkenntnissen ab und machen Menschen defensiv. Belegen Sie jede Aussage mit Daten.

• Beziehen Sie alle Beteiligten ein. Ein Postmortem, das ein Team allein schreibt, übersieht oft begünstigende Faktoren, die andere Teams gesehen haben.

• Teilen Sie es breit. Der Wert eines Postmortems wächst mit der Zahl der Menschen, die daraus lernen. Geben Sie standardmäßig der gesamten Engineering-Organisation Zugriff.

• Halten Sie Maßnahmen bis zum Abschluss nach. Jede Maßnahme gehört in Ihr Ticketsystem, und jemand prüft den Fortschritt. Ein Postmortem mit offenen Maßnahmen ist nicht fertig.

• Achten Sie auf Wiederholungen. Wenn Vorfälle früheren ähneln, fragen Sie, ob Maßnahmen zu lange bis zum Abschluss brauchen oder ob überhaupt die richtigen Maßnahmen erfasst wurden.

Was ist der Unterschied zwischen einem Postmortem und einem Post-Incident Review?

Inhaltlich keiner. Beides ist eine schriftliche Auswertung eines Vorfalls nach der Wiederherstellung des Dienstes, mit Auswirkungen, Ursache, Erkenntnissen und Folgemaßnahmen. Microsoft und GitLab nennen es Post-Incident Review, Amazon nennt es Correction of Error, und viele Teams sagen Postmortem.

Was ist ein Blameless Postmortem?

Ein Blameless Postmortem sucht nach den Bedingungen in System und Prozess, die einen Vorfall ermöglicht haben, statt nach der Person, die eine Änderung vorgenommen hat. Es geht davon aus, dass alle nach bestem Wissen mit den verfügbaren Informationen gehandelt haben. So melden Menschen Probleme offen, und die Auswertung erhält die Details, die sie braucht.

Wer sollte das Postmortem schreiben?

Eine verantwortliche Person, in der Regel aus dem Team, dem der betroffene Dienst gehört, mit Beiträgen von allen, die an der Reaktion beteiligt waren. Bei GitLab ist das für den Dienst zuständige Team für die Auswertungen seiner Vorfälle verantwortlich, und eine separate prüfende Person gibt das Ergebnis frei.

Wie bald nach einem Vorfall sollten Sie ein Postmortem schreiben?

Innerhalb von ein bis zwei Wochen nach der Behebung, solange die Details frisch sind. Googles veröffentlichtes Beispiel erschien weniger als eine Woche nach Abschluss des Vorfalls, und Azure veröffentlicht finale Post-Incident Reviews in der Regel innerhalb von 14 Tagen.

Braucht jeder Vorfall ein Postmortem?

Nein. Legen Sie Kriterien vorab fest, etwa für Nutzer sichtbare Ausfallzeit über einem Schwellenwert, jeden Datenverlust, einen Eingriff durch die Bereitschaft oder ein Versagen des Monitorings. Jeder Stakeholder kann außerdem eines anfordern. Kleinere Vorfälle brauchen vielleicht nur einen Vorfallsbericht.

Legen Sie vor dem nächsten Vorfall fest, welche Schweregrade ein Postmortem erfordern, wer es verantwortet, wer es prüft, wo es gespeichert wird und wie seine Maßnahmen nachgehalten werden. Wenn das vorab geklärt ist, ist das Schreiben des Postmortems Routine statt Diskussion.

Konsequent geschrieben, werden Postmortems zu einem durchsuchbaren Nachweis darüber, wie Ihre Systeme ausfallen und was Sie daraufhin geändert haben. Dieser Nachweis ist es, der den nächsten Vorfall kürzer macht.

Die Struktur dieser Vorlage folgt der Art, wie diese Organisationen Postmortems schreiben und prüfen. Sie unterscheiden sich vor allem darin, wann eine Auswertung erforderlich ist, wie schnell sie veröffentlicht wird und wer sie freigibt.