Ein Incident-Postmortem ist eine kurze schriftliche Auswertung eines Ausfalls: was passiert ist, wie es sich auf Nutzer ausgewirkt hat, warum es passiert ist und was Sie ändern, damit es nicht wieder vorkommt. Ein Blameless Postmortem konzentriert sich auf Systeme und Prozesse statt darauf, wer einen Fehler gemacht hat. Die Grundvorlage hat sechs Teile: Zusammenfassung, Auswirkungen, Zeitablauf, Ursache, was gut und was schlecht lief, und Maßnahmen mit Verantwortlichen und Terminen.
Im Folgenden erfahren Sie, wann Sie eines schreiben sollten, welche Prinzipien es nützlich halten, und Sie finden eine vollständige Vorlage zum Kopieren, ein ausgefülltes Beispiel und eine Anleitung, wie Sie daraus eine Zusammenfassung für Kunden machen.
Wann Sie ein Postmortem schreiben sollten
Nicht jeder kurze Aussetzer braucht ein Dokument. Legen Sie klare Auslöser fest, damit die Entscheidung nicht unter Druck fällt. Übliche Auslöser:
Kunden konnten eine Kernfunktion wie Checkout, Login oder die API länger als ein paar Minuten nicht nutzen.
Daten gingen verloren, wurden beschädigt oder offengelegt.
Der Vorfall hat einen großen Teil Ihres monatlichen Error Budgets verbraucht.
Kunden oder ein Auftraggeber haben das Problem vor dem Monitoring gemeldet.
Ein Vorfall dieser Art ist schon einmal passiert.
Schreiben Sie es innerhalb weniger Arbeitstage, solange Erinnerungen und Logs frisch sind. Ein Postmortem, das drei Wochen später entsteht, ist größtenteils Raterei.
Blameless-Prinzipien
Ein Blameless Postmortem geht davon aus, dass alle mit den Informationen, die sie damals hatten, vernünftig gehandelt haben. Wenn eine Person die Website mit einem einzigen Befehl lahmlegen konnte, liegt das Problem darin, dass ein einziger Befehl die Website lahmlegen konnte. Schuldzuweisungen bringen Menschen dazu, Details zu verschweigen, und genau die Details brauchen Sie.
Handlungen beschreiben, nicht Personen. „Der Import-Job wurde während der Spitzenzeit gestartet“ statt „Anna hat den Import zur falschen Zeit gestartet“.
„Wie“ fragen, nicht „wer“. Wie konnte das System das zulassen? Wie haben wir es bemerkt? Wie hätten wir es früher bemerken können?
Nach mehreren Ursachen suchen. Vorfälle haben selten nur eine Ursache. Meist trifft ein Auslöser auf eine Schwachstelle, die eine fehlende Schutzmaßnahme nicht abgefangen hat.
Fakten und Zeitstempel verwenden. Monitoring-Daten, Logs und Chatverläufe sind besser als das Gedächtnis.
Die Maßnahmenliste kurz halten. Zwei oder drei Änderungen, die umgesetzt werden, sind besser als zehn, die liegen bleiben.
Die Postmortem-Vorlage
Kopieren Sie sie in Ihr Wiki, Ihr Repository oder Ihr Dokumenten-Tool. Unter jeder Überschrift steht ein Hinweis, was dorthin gehört.
# Postmortem: [kurzer Titel]
Datum des Vorfalls: [JJJJ-MM-TT]
Autor(en): [Namen]
Status: [Entwurf / in Prüfung / final]
Schweregrad: [z. B. SEV1 / SEV2 / SEV3]
## Zusammenfassung
[Zwei oder drei Sätze: was ausgefallen ist, wie lange und wie es behoben wurde.]
## Auswirkungen
– Betroffene Dienste und Komponenten:
– Dauer (Beginn bis Wiederherstellung):
– Betroffene Nutzer oder Kunden:
– Geschäftliche Auswirkungen (Bestellungen, Anmeldungen, SLA):
– Kundenkommunikation (Statusseite, E-Mails, Tickets):
## Erkennung
– Wie wurde der Vorfall erkannt? (Monitor, Kunde, Teammitglied)
– Zeit vom Beginn bis zum Alarm:
– Zeit vom Alarm bis zur Bestätigung:
## Zeitablauf
[Alle Zeiten in einer Zeitzone. Eine Zeile pro Ereignis.]
HH:MM Ereignis
HH:MM Ereignis
## Ursache und begünstigende Faktoren
– Auslöser:
– Eigentliche Ursache:
– Warum Schutzmaßnahmen es nicht abgefangen haben:
## Behebung
[Was getan wurde, um den Dienst wiederherzustellen, und von wem (Rolle, keine Schuld).]
## Was gut lief
–
## Was schlecht lief
–
## Wo wir Glück hatten
–
## Maßnahmen
| Maßnahme | Art (verhindern / erkennen / reagieren) | Verantwortlich | Fällig | Ticket |
|———-|—————————————–|—————-|——–|——–|
| | | | | |
## Zusammenfassung für Kunden
[Kurzfassung für die Statusseite oder die E-Mail an Auftraggeber.]
Der Abschnitt „Wo wir Glück hatten“ wird leicht übersprungen und ist oft der wertvollste. Er hält die Beinahe-Katastrophen fest: Der Vorfall passierte nachts, das Backup war eine Stunde vorher gelaufen, die einzige Person, die das System kannte, war zufällig wach.
Ein ausgefülltes Beispiel
Hier ist die Vorlage, angewendet auf einen fiktiven Vorfall bei einem Onlineshop, northwind.shop. Die Details sind zur Veranschaulichung erfunden, aber die Struktur entspricht dem, wie ein echtes Postmortem aussehen sollte.
Zusammenfassung
Von 03:12 bis 03:19 MEZ lieferte der Checkout von northwind.shop 503 Service Unavailable. Ein nächtlicher Produktimport belegte alle PHP-FPM-Worker, sodass Checkout-Anfragen abgewiesen wurden. Der Entwickler in Rufbereitschaft stoppte den Import und startete PHP-FPM neu. Gesamte Ausfallzeit: 7 Minuten.
Auswirkungen
Checkout und Warenkorb waren 7 Minuten lang nicht verfügbar. Produktseiten wurden aus dem Cache ausgeliefert und blieben erreichbar.
Die Serverlogs zeigen 23 fehlgeschlagene Checkout-Anfragen in diesem Zeitraum (Beispielwert).
Die Statusseite zeigte ab 03:13 „Checkout: schwerer Ausfall“. Es gingen keine Support-Tickets ein.
Zeitablauf
03:00 Der nächtliche Produktimport startet.
03:12 Der Uptime-Check auf northwind.shop/checkout liefert 503.
03:13 Ein zweiter Check bestätigt den Fehler. Ein Incident wird eröffnet, der Entwickler in Rufbereitschaft wird über Telegram alarmiert, und die Details erscheinen im Slack-Channel des Teams. Die Statusseite markiert den Checkout als down.
03:15 Die Rufbereitschaft bestätigt in Slack und öffnet das Server-Dashboard. Speicher und CPU sind auf web-01 hoch.
03:17 Der PHP-FPM-Status zeigt alle Worker mit Import-Anfragen beschäftigt. Der Import-Job wird gestoppt.
03:18 PHP-FPM wird neu gestartet.
03:19 Die Checks sind wieder erfolgreich. Eine Entwarnung mit einer gesamten Ausfallzeit von 7 Minuten wird verschickt.
Ursache und begünstigende Faktoren
Auslöser: Der Lieferanten-Feed war nach einer Katalogaktualisierung dreimal so groß wie üblich.
Eigentliche Ursache: Der Import läuft über denselben PHP-FPM-Pool wie der Shop. Große Importe können jeden Worker belegen.
Fehlende Schutzmaßnahme: Der Import hat kein Limit für gleichzeitige Anfragen, und es gab keinen Alarm bei ausgelasteten Workern.
Warum ausgelastete Worker genau diesen Fehler erzeugen, erklärt unser Ratgeber zum Fehler 503 Service Unavailable.
Was gut lief, was schlecht lief und wo wir Glück hatten
Gut: Die Erkennung dauerte eine Minute, die Bestätigung zwei. Die Statusseite aktualisierte sich ohne Handarbeit.
Schlecht: Die Ursache zu finden dauerte vier Minuten, weil nichts den Import-Job mit den Webservern in Verbindung brachte.
Glück: Es passierte um 03:12 und nicht während der Abendspitze.
Maßnahmen
MaßnahmeArtVerantwortlichFälligImport in einem eigenen Worker-Pool mit Parallelitätslimit ausführenVerhindernBackend-LeitungInnerhalb von 2 WochenAlarm, wenn der Speicher von web-01 dauerhaft über 85% liegtErkennenOpsDiese WocheHeartbeat ergänzen, der meldet, wenn der Import abgeschlossen istErkennenBackend-LeitungDiese WocheRunbook „503 im Checkout“ am Monitor hinterlegenReagierenBereitschaftsrotationDiese Woche
Eine Zusammenfassung für Kunden veröffentlichen
Das interne Postmortem ist für das Team. Kunden brauchen eine kürzere Version ohne Servernamen: was passiert ist, wie lange, ob ihre Daten sicher sind und was Sie ändern. Veröffentlichen Sie sie auf Ihrer Statusseite und verlinken Sie sie in jeder Incident-E-Mail und jedem Update an Auftraggeber. In Uptimecheck schreiben Sie die Incident-Auswertung direkt am Incident, neben seinem Zeitablauf, und können wählen, ob sie auf Ihrer Statusseite unter dem Incident erscheint.
Checkout nicht verfügbar, 03:12 bis 03:19 MEZ
Zwischen 03:12 und 03:19 MEZ konnten Kunden auf northwind.shop keine
Käufe abschließen. Das Stöbern in Produkten war nicht betroffen, und es
gingen keine Bestellungen oder Zahlungsdaten verloren.
Ursache war eine geplante Produktaktualisierung, die mehr Serverkapazität
beanspruchte als erwartet. Wir haben sie gestoppt, und der Checkout lief
ab 03:19 wieder.
Wir verlagern diese Aktualisierungen auf eigene Kapazität, damit sie den
Checkout nicht mehr beeinträchtigen können, und haben frühere Warnungen
für diese Art von Last eingerichtet.
Bleiben Sie sachlich und machen Sie konkrete Zusagen. „Zuverlässigkeit hat für uns höchste Priorität“ sagt nichts; „Importe laufen jetzt auf eigener Kapazität“ sagt etwas. Unser Ratgeber So erstellen Sie eine Statusseite geht ausführlicher auf Formulierungen für Incident-Updates ein.
Es hilft auch zu wissen, wie viele Menschen etwas bemerkt haben. Uptimecheck bietet zu jeder Statusseite Statusseiten-Analysen mit Besuchen pro Tag sowie nach Land, Referrer und Gerät für die letzten 30 Tage. So können Sie im Postmortem ergänzen, wie viele Menschen die Seite am Tag des Vorfalls aufgerufen haben. Zusammen mit dem Incident-Zeitablauf haben Sie Beginn, Alarm, Bestätigung, Wiederherstellung und Reichweite, ohne Logs durchforsten zu müssen. Website-Incidents enthalten außerdem die fehlerhafte Antwort mit einem Screenshot oder einem Traceroute, ein guter Ausgangspunkt für die Abschnitte zu Erkennung und Ursache.
Maßnahmen nachverfolgen
Ein Postmortem ohne erledigte Maßnahmen ist eine Geschichte, keine Lösung. Behandeln Sie die Maßnahmen wie jede andere Arbeit:
Legen Sie für jede Maßnahme ein Ticket im Tracker an, den das Team ohnehin nutzt, und verlinken Sie es im Postmortem.
Geben Sie jeder Maßnahme genau eine verantwortliche Person und einen Termin.
Kennzeichnen Sie Maßnahmen nach Art: verhindern, erkennen oder reagieren. Lautet jede Maßnahme „vorsichtiger sein“, ist die Auswertung nicht fertig.
Gehen Sie offene Postmortem-Maßnahmen in einem regelmäßigen Meeting durch, zum Beispiel alle zwei Wochen.
Setzen Sie das Postmortem erst auf final, wenn alle Maßnahmen erledigt oder ausdrücklich mit Begründung verworfen sind.
Mit der Zeit werden die Postmortems selbst zu Daten. Zählen Sie, wie viele Vorfälle das Monitoring und wie viele Kunden entdeckt haben, und verfolgen Sie Erkennungs- und Reaktionszeiten von einem Vorfall zum nächsten. Unser Artikel zu MTTR, MTTA und MTBF erklärt, wie Sie sie berechnen.
Das Review-Meeting leiten
Bei größeren Vorfällen hilft ein Meeting von 30 bis 45 Minuten. Teilen Sie den Entwurf vorab, lassen Sie die Person, die die Reaktion geleitet hat, den Zeitablauf durchgehen, und verwenden Sie die meiste Zeit auf begünstigende Faktoren und Maßnahmen. Eine neutrale Moderation, die nicht am Vorfall gearbeitet hat, hält das Gespräch schuldfrei und im Zeitrahmen. Bestätigen Sie zum Schluss Verantwortliche und Termine für jede Maßnahme.
Holen Sie sich die Zeitstempel für Ihr nächstes Postmortem automatisch. Uptimecheck 14 Tage kostenlos testen, keine Kreditkarte erforderlich.