Incident-Postmortems aufzeichnen: Aus Ausfällen Teamwissen machen

Jedes Team schreibt nach einem Ausfall ein Postmortem-Dokument. Deutlich weniger Teams lesen diese Dokumente auch. Eine sauber formulierte Zeitleiste voller Dashboard-Links und Log-Ausschnitte verlangt vom Lesenden, den Vorfall im Kopf zu rekonstruieren — die meisten überfliegen sie, nicken und machen weiter.

Eine kurze Bildschirmaufnahme ändert das. Statt zu beschreiben, wie die Fehlerrate um 02:14 Uhr aussah, zeigen Sie es. Statt zu erklären, welche Abfrage die Ursache zutage gefördert hat, führen Sie sie aus. In diesem Leitfaden erfahren Sie, wie Sie Postmortems aufnehmen, die tatsächlich angesehen werden — und wie sie auch nach Monaten noch nützlich bleiben.

Warum ein Postmortem aufzeichnen?

• Belege schlagen Beschreibungen: Graphen, Traces und Logs sind von Natur aus visuell — Screenshots verlieren die Bewegung, die einen Ausschlag erst offensichtlich macht
• Schneller erstellt: Das zu kommentieren, was ohnehin schon geöffnet ist, geht schneller als ausformulierte Prosa
• Besser für neue Kolleginnen und Kollegen: Ein sechsminütiger Rückblick vermittelt die Fehlermodi Ihres Systems weit schneller als eine Wiki-Seite
• Bewahrt die Denkweise: Dokumente halten fest, was passiert ist; Aufnahmen zeigen, warum die verantwortliche Person in jedem Schritt so entschieden hat
• Asynchron nutzbar: Verteilte Teams können den Review aufnehmen, ohne ein weiteres Meeting über Zeitzonen hinweg zu planen

Was aufnehmen — und was nicht

Eine Postmortem-Aufnahme ist keine Wiederholung des gesamten Vorfalls. Beschränken Sie sich auf die Teile, bei denen Sehen besser ist als Lesen:

Nehmen Sie das auf:

• Den Moment der Entdeckung — den Alert, das Dashboard, die erste Nutzermeldung
• Den zentralen Graphen, der die Auswirkung über den Vorfallszeitraum zeigt
• Die Untersuchungsschritte, die den Kreis eingegrenzt haben (auch die Sackgassen)
• Den konkreten Code, die Konfiguration oder die Abfrage, die den Fehler verursacht hat
• Das Einspielen des Fixes und die Erholung der Metriken

Lassen Sie das weg:

• Lange Wartezeiten auf Deployments oder ladende Daten
• Interne Diskussionen ohne Bezug zur Diagnose
• Alles, was sich in einem Satz Kommentar sagen lässt

Vorbereitung vor der Aufnahme

Incident-Tooling zeigt vieles, was nicht in ein geteiltes Video gehört. Nehmen Sie sich fünf Minuten:

1. Alle Tabs vorab öffnen: Dashboards im richtigen Zeitraum, die relevante Log-Abfrage, den Pull Request, den Alert
2. Zeiträume fixieren: Pinnen Sie Dashboards auf das Vorfallsfenster, damit alle dasselbe sehen wie Sie
3. Sensible Oberflächen schließen: Kundendatensätze, interne Tickets mit personenbezogenen Daten, private DMs, Passwortmanager
4. Benachrichtigungen stummschalten: Nichts untergräbt ein ernsthaftes Postmortem so sehr wie eine Mittagspausen-Erinnerung mitten im Kommentar
5. Eine Gliederung in drei Zeilen schreiben: Auswirkung, Ursache, Prävention. Alles andere hängt an diesen drei Punkten

Nutzen Sie Fensteraufnahme statt Vollbild, wenn Ihr Dashboard in einem einzigen Browserfenster liegt — das ist der einfachste Weg, damit nichts anderes ins Bild gerät.

Eine bewährte Struktur

Halten Sie Aufnahmen zwischen fünf und zehn Minuten. Eine verlässliche Struktur:

1. Auswirkung zuerst (30 Sekunden): Wer war betroffen, wie lange und wie stark. Beginnen Sie damit — deswegen sehen die meisten überhaupt zu
2. Zeitleiste (2–3 Minuten): Entdeckung, Eskalation, Mitigation, Behebung — gezeigt am echten Dashboard
3. Ursache (2–3 Minuten): Zeigen Sie den tatsächlichen Codepfad, die Konfigurationsänderung oder die Abfrage. Zoomen Sie auf die konkreten Zeilen
4. Was es schwer gemacht hat (1 Minute): Fehlende Alerts, verwirrende Logs, unklare Zuständigkeiten — genau das, was Dokumente meist einebnen
5. Maßnahmen (1 Minute): Nennen Sie jede Maßnahme samt verantwortlicher Person laut und verlinken Sie sie in der Beschreibung

Mit dem Editor lesbar machen

Rohes Incident-Material ist dicht. Der Editor von Recorded macht daraus etwas Nachvollziehbares:

• Zoom-Effekte: Dashboards und Log-Zeilen sind klein. Zoomen Sie auf den Ausschlag, die Fehlermeldung, das fragliche Diff — niemand sollte auf einem 4K-Screenshot die Augen zusammenkneifen müssen
• Geschwindigkeitsbereiche: Spulen Sie durch Deploy-Pipelines und Abfragen, kehren Sie zur Normalgeschwindigkeit zurück, wenn die Ursache sichtbar wird
• Text-Overlays: Blenden Sie Zeitstempel ein (02:14 UTC — erster Alert), damit sich Video und Dokument zuordnen lassen
• Trimmen: Schneiden Sie den Fehlstart heraus, bei dem das Dashboard noch im falschen Zeitraum stand
• Cursor-Effekte: Heben Sie Klicks hervor, wenn Sie den exakten Reproduktionsweg zeigen

Setzen Sie die Webcam nur für Einleitung und Abschluss ein. Ein Gesicht hilft beim Ton für Auswirkung und Maßnahmen; während der Log-Analyse verdeckt es nur das Terminal.

Vor der Kamera schuldfrei bleiben

Video transportiert Tonfall anders als Text. Derselbe Satz wirkt je nach Vortrag wie Analyse oder wie Vorwurf.

• Sagen Sie „das Deployment hat eingeführt” statt zu nennen, wer es ausgeliefert hat
• Schildern Sie Entscheidungen im damals verfügbaren Kontext: „Zu diesem Zeitpunkt hatten wir die Queue-Depth-Metrik noch nicht”
• Zeigen Sie Sackgassen ohne Entschuldigung — sie belegen, dass das System schwer zu diagnostizieren war, und genau das ist eine Maßnahme
• Nehmen Sie das Intro neu auf, wenn der erste Versuch frustriert klingt. Zwei Minuten Aufwand setzen den Ton für alle Zuschauenden

Video und Dokument kombinieren

Die Aufnahme ergänzt das Postmortem-Dokument, sie ersetzt es nicht. Dokumente sind durchsuchbar, verlinkbar und überfliegbar — Video ist das nicht.

Eine gute Kombination:

• Das Dokument bleibt die maßgebliche Quelle für Zeitleiste, Maßnahmen und Verantwortliche
• Die Aufnahme wird oben eingebettet, mit einer Zeile dazu, was sie abdeckt
• Kapitel-Zeitstempel in der Beschreibung führen direkt zum Ursachenabschnitt
• Maßnahmen gehören in Ihr Ticketsystem, nicht nur ins Video

Eine Incident-Bibliothek aufbauen

Einzelne Aufnahmen sind nützlich. Eine Sammlung ist weit wertvoller.

• Einheitlich benennen: 2026-09-28-checkout-latency-postmortem lässt sich sauber sortieren und durchsuchen
• Nach System taggen: Gruppieren Sie nach beteiligtem Dienst, dann können Sie neuen Bereitschaftskolleginnen alles zu einer Komponente auf einmal geben
• Quartalsweise durchsehen: Sehen Sie die Aufnahmen eines Quartals am Stück — wiederkehrende Fehlermuster fallen sofort auf
• Im Onboarding nutzen: Drei bis vier kuratierte Vorfälle sind der schnellste Weg zu verstehen, wie Ihr System wirklich kaputtgeht

Häufige Fehler

• Während des Vorfalls aufnehmen: Erst die Mitigation. Nehmen Sie den Review danach auf, wenn Sie ruhig sprechen können
• Rohmaterial teilen: Ein ungeschnittener 40-Minuten-Screenshare ist kein Postmortem — niemand sieht ihn an
• Kundendaten preisgeben: Sehen Sie die Aufnahme einmal ganz an und achten Sie gezielt auf personenbezogene Daten in Logs und Dashboards
• Die Auswirkungszusammenfassung auslassen: Wer nur die erste Minute sieht, sollte die wichtigsten Fakten trotzdem mitnehmen
• Das Dokument ersetzen: In sechs Monaten, wenn ein ähnlicher Vorfall beginnt, lässt sich ein Video nicht durchsuchen

Fazit

Postmortems scheitern, wenn sie zum Ablegen geschrieben werden statt zum Verstehen. Eine fokussierte Bildschirmaufnahme — Auswirkung vorweg, echte Belege am Bildschirm, schuldfreier Kommentar, klare Maßnahmen — macht aus jedem Ausfall etwas, das Ihr ganzes Team in zehn Minuten lernen kann.

Nehmen Sie Ihr nächstes Postmortem auf, statt es nur zu schreiben — und sehen Sie zu, wie viel mehr Menschen sich damit befassen.