Eine Präsentation zur Nachbesprechung eines Vorfalls, häufig Incident-Postmortem genannt, sollte vier Fragen beantworten: Was haben die Betroffenen erlebt? Wie wurde der Betrieb wiederhergestellt? Was lässt sich über den Fehler belegen? Und welche Änderungen stehen als Nächstes an? Dafür müssen Sie nicht jede Nachricht aus dem Incident-Kanal nacherzählen. Eine sauber aufgebaute Präsentation darf auch nicht den Eindruck erwecken, eine noch offene Ursache sei bereits geklärt.
Ausgangspunkt ist der geprüfte Vorfallsbericht. Die Folien machen die wichtigen Unterschiede sichtbar: betroffene Aufträge und betroffene Personen, wiederhergestellter Betrieb und abgearbeiteter Rückstand, beobachtetes Ereignis und mögliche Erklärung. Das folgende Beispiel zeigt, wie sich diese Unterscheidungen auf den Aufbau auswirken.
Klären Sie, welche Frage die Besprechung beantworten soll
Schreiben Sie vor dem Erstellen der Folien auf, was die Runde entscheiden muss. In einem Serviceteam könnte die Frage lauten: „Verstehen wir den Fehler gut genug, um dieses Release erneut auszurollen, und welche Arbeiten haben vorher Vorrang?“ In einer Besprechung mit Kunden stehen womöglich die Auswirkungen und die nächste Information an die Betroffenen im Mittelpunkt. Verwenden Sie die für diesen Empfängerkreis freigegebene Fassung.
Die SRE-Empfehlungen von Google (englisch) beschreiben ein Postmortem als Dokumentation von Auswirkungen, Gegenmaßnahmen, Ursachen und Folgearbeiten. Dabei geht es um die Bedingungen, unter denen Entscheidungen entstanden sind, statt um Schuldzuweisungen. Für Ihre Präsentation heißt das: zuerst den Sachverhalt dokumentieren, dann verständlich erklären. Folien ersetzen keine Untersuchung.
Wenn Sie den laufenden Projektstand vorstellen und keinen konkreten Fehler untersuchen, passt eine Struktur für Fortschrittsberichte besser. Ein vollständiges Statusupdate innerhalb des Postmortems kann dessen offene Fragen verdecken.
Beispiel: Berichtserstellung gestört, Rückstand später abgearbeitet
Das folgende Beispiel ist frei erfunden. Ein Dienst erstellt Berichte zum Herunterladen. Alle Uhrzeiten beziehen sich auf denselben Ereignistag und auf UTC.
| Uhrzeit | Was die Dokumentation belegt | Quelle für eine echte Nachbesprechung |
|---|---|---|
| 09:00 | Ein Release beginnt. Auch die ersten protokollierten Fehler bei Berichtsaufträgen treten um 09:00 auf. | Deployment-Protokoll und Auftragslogs, einschließlich der Genauigkeit der Zeitstempel. |
| 09:04 | Eine Warnmeldung informiert den Bereitschaftsdienst über fehlschlagende Aufträge. | Warnereignis und Zustellnachweis. |
| 09:12 | Das Team beginnt, das Release zurückzunehmen. | Vorfallsprotokoll und Aufzeichnung des Rollbacks. |
| 09:27 | Das Monitoring zeigt, dass neu eingehende Aufträge wieder normal abgeschlossen werden. | Prüfung der Wiederherstellung samt Beobachtungszeitraum. |
| 10:00 | Der Abgleich auf Auftragsebene weist alle 180 ermittelten betroffenen Aufträge als abgeschlossen aus. | Einzelabgleich einschließlich der Behandlung wiederholter Ausführungen. |
Die ergänzenden Notizen zeigen, dass die verarbeitenden Prozesse während der Störung einen unbekannten Status protokollierten. Welche Komponente diesen Status erzeugte und weshalb die Prüfungen vor dem Release ihn nicht erfassten, ist noch ungeklärt. Dokumentiert sind 180 unterschiedliche Auftragskennungen. Eine verifizierte Zahl betroffener Kunden und eine Berechnung wirtschaftlicher Folgen liegen nicht vor.
Damit lässt sich bereits eine sinnvolle Besprechung vorbereiten, ohne die Lücken zu füllen. Halten Sie die Verweise auf die Logs bereit. Sensible Nutzdaten, Zugangstoken oder Kundendetails gehören nicht auf eine projizierte Folie.
Trennen Sie Wiederherstellung und Abbau des Rückstands
Eine naheliegende Einstiegszeile wäre: „Ein 27-minütiger Ausfall betraf 180 Kunden.“ Beide Angaben gehen zu weit. Das Beispiel belegt Fehler bei Berichtsaufträgen, keinen vollständigen Ausfall des Dienstes. Gezählt werden Aufträge, nicht Personen. Eine Person kann mehrere Aufträge eingereicht haben.
Präziser ist: „Über 27 Minuten wurden Fehler bei Berichtsaufträgen beobachtet; bis 10:00 waren die 180 ermittelten betroffenen Aufträge abgeglichen und abgeschlossen.“ Zeigen Sie darunter zwei Zeitabschnitte:
- 09:00–09:27: vom ersten protokollierten Fehler bis zur normalen Fertigstellung neuer Aufträge.
- 09:27–10:00: weitere 33 Minuten bis zum vollständigen Abgleich der betroffenen Aufträge.
Der zweite Abschnitt ist für jemanden, der noch auf seinen Bericht wartet, durchaus wichtig, obwohl neue Aufträge bereits wieder laufen. Behaupten Sie nicht, jeder betroffene Auftrag habe sich um eine Stunde verzögert. Dafür bräuchten Sie die jeweiligen Eingangs- und Abschlusszeiten. Ebenso belegt „Aufträge abgeschlossen“ weder die inhaltliche Richtigkeit jedes Berichts noch, dass keine Daten verloren gingen.
Verwenden Sie eine waagerechte Zeitleiste mit getrennten Markierungen für Wiederherstellung und Rückstandsabbau. Schreiben Sie die Zeitzone an die Achse. Ist der Zeitpunkt des ersten Fehlers in einem echten Vorfall nur geschätzt, kennzeichnen Sie diese Unsicherheit, statt ersatzweise den Release-Beginn einzusetzen.
Bauen Sie die Besprechung auf sieben Folien auf
Für diesen Vorfall sind sieben Folien ein brauchbarer Ausgangspunkt. Bei einfachen Sachverhalten reichen weniger. Ergänzende Seiten sind sinnvoll, wenn die Runde einen strittigen Punkt genauer prüfen muss.
- Was ist passiert, und was braucht jetzt Aufmerksamkeit? Nennen Sie die belegten Auswirkungen, den aktuellen Zustand des Dienstes und die noch offene Release-Entscheidung.
- Wer oder was war betroffen? Zeigen Sie die 180 unterschiedlichen Aufträge, den betroffenen Ablauf und die unbekannte Kundenzahl. Ersetzen Sie eine fehlende Angabe nicht durch eine plausible Schätzung.
- Wie verlief der Vorfall? Stellen Sie die fünf dokumentierten Zeitpunkte dar. Warnmeldung, Rollback, Wiederherstellung und Rückstandsabbau bleiben getrennt.
- Was erklären die vorhandenen Belege? Stellen Sie die Beobachtung des unbekannten Status neben die noch offene Untersuchungsfrage. Die Abfolge beim Rollback ist relevant, beweist für sich aber nicht den vollständigen Fehlermechanismus.
- Was half, und was verzögerte die Reaktion? Besprechen Sie konkrete Informationen, Werkzeuge oder Abstimmungsprobleme aus der Dokumentation. Erfinden Sie keine „Erkenntnisse“, nur damit die Folie ausgewogen aussieht.
- Welche Änderungen werden vorgeschlagen? Trennen Sie Vorbeugung von Verbesserungen der Reaktion. Benennen Sie Zuständigkeiten und einen überprüfbaren Abschlussnachweis.
- Was muss die Runde klären? Halten Sie Prioritäten, noch fehlende Belege und Bedingungen für eine erneute Release-Prüfung fest.
Detaillierte Logs, Testbedingungen und Definitionen für den Auftragsabgleich bleiben im Begleitmaterial. Eine Management-Zusammenfassung (englischer Leitfaden) hilft einem breiteren Publikum bei der Orientierung. Auch sie muss zwischen wiederhergestellter Verarbeitung und fortbestehenden Auswirkungen unterscheiden.
Erklären Sie den Stand der Ursachenanalyse ohne Schuldzuweisung
„Jemand hat eine fehlerhafte Änderung ausgerollt“ hilft dem nächsten Entwickler kaum, den Fehler zu erkennen oder zu verhindern. Zudem fehlen dann die Fragen, die das Beispiel aufwirft: Welche Versionen der erzeugenden und verarbeitenden Komponenten liefen? Welche Statuswerte verstanden sie? Was wurde vor dem Release tatsächlich geprüft?
Teilen Sie die Folie in Beobachtung, mögliche Erklärung und noch benötigte Belege. Beobachtet wurde hier die Fehlermeldung zum unbekannten Status. Ein möglicher Versionskonflikt bleibt eine Hypothese, bis die betreffenden Versionen und eine Reproduktion ihn stützen. Ein sinnvoller nächster Untersuchungsschritt ist deshalb, die Versionen abzugleichen und den Fehlerfall in einer geeigneten Testumgebung nachzustellen.
Widersprechen sich zwei Quellen bei einer Uhrzeit, bewahren Sie beide Aufzeichnungen auf, während Sie den Widerspruch klären. Wird die Ursache bestritten, begrenzen Sie die Überschrift auf das Gesicherte. Auch die Entscheidung, weiter zu untersuchen, ist ein sinnvolles Besprechungsergebnis. Dafür muss noch keine vollständige Ursachenerklärung vorliegen.
Formulieren Sie Maßnahmen konkreter als „besser aufpassen“
Für den erfundenen Vorfall könnte das Team die folgenden Maßnahmen diskutieren. Es handelt sich um Vorschläge, nicht um abgeschlossene Korrekturen oder bereits angenommene Verpflichtungen.
| Vorgeschlagene Änderung | Zugehörige Frage | Überprüfbarer Abschlussnachweis |
|---|---|---|
| Einen Kompatibilitätstest für die beteiligten Versionen der erzeugenden und verarbeitenden Komponenten ergänzen. | Kann der Release-Prozess diesen Fehler vor dem Ausrollen sichtbar machen? | Ein dokumentierter Test reproduziert den zurückgewiesenen Status mit der fehlerhaften Kombination und hält das erwartete Verhalten der korrigierten Kombination fest. |
| Wiederherstellung und Rückstandsabbau als eigenen Abschnitt in das Vorgehen bei Vorfällen aufnehmen. | Kann das Team zwischen wieder laufenden neuen Aufträgen und noch offenen betroffenen Aufträgen unterscheiden? | Eine geprüfte Anleitung und eine Übung erfassen Wiederherstellung, Auftragsabgleich und ungelöste Fälle getrennt. |
Lassen Sie die zuständigen Teams Verantwortliche, Prioritäten und Termine bestätigen. Tragen Sie niemanden allein deshalb ein, weil diese Person zuerst auf den Vorfall reagiert hat. Vermeiden Sie die Zusage „Das passiert nie wieder“: Weder ein Test noch eine Anleitung beweist das. Erklären Sie stattdessen, welchen konkreten Fehler oder welche Verzögerung die jeweilige Maßnahme angehen soll.
Aus dem geprüften Bericht einen Entwurf in Presenti erstellen
Bereiten Sie eine von sensiblen Angaben bereinigte Arbeitsgrundlage vor: Auswirkungsdefinition, Chronologie, Quellenverweise, gesicherte Erkenntnisse, offene Fragen und Maßnahmenvorschläge. Mit Presenti für Präsentationen aus Text (englische Produktseite) können Sie daraus die sieben Folien entwerfen lassen. Geben Sie ausdrücklich vor, die Meilensteine 09:27 und 10:00 getrennt zu lassen und die Kundenzahl weiterhin als unbekannt auszuweisen.
Prüfen Sie die Gliederung vor der Gestaltung. Macht der Entwurf aus „möglichem Kompatibilitätsproblem“ eine „bestätigte Ursache“, korrigieren Sie zuerst diese Aussage. Geben Sie der Zeitleiste im bearbeitbaren Entwurf genügend Platz für lesbare Beschriftungen. Stellen Sie den Abschlussnachweis direkt neben die vorgeschlagene Maßnahme. Presenti kann die Erklärung ordnen; es kann weder die Vorfallslogs bestätigen noch die Sicherheit eines Releases beurteilen.
Arbeitsgrundlage und Gliederung für sieben Folien herunterladen. Für den Entwurf können Sie auch diese kurze Anweisung verwenden:
Erstelle aus der vorliegenden Dokumentation einen Entwurf für die Nachbesprechung des Vorfalls. Trenne Auswirkungen, Erkennung, Rollback, Wiederherstellung neuer Aufträge und Abgleich betroffener Aufträge. Unterscheide Beobachtungen von Hypothesen. Erhalte unbekannte Angaben, Quellenverweise und Zeitzonen. Erfinde keine betroffenen Kunden, finanziellen Verluste, Ursachen, bestätigten Zuständigkeiten oder abgeschlossenen Maßnahmen.
Halten Sie zum Ende der Besprechung fest, was tatsächlich vereinbart wurde und welche Belege noch fehlen. Nehmen Sie genau diese Punkte in die nächste Prüfung mit. Das Ergebnis sollte ein klareres Bild des Vorfalls und begründete Entscheidungen über Änderungen sein, keine Folie, die eine Wiederholung für unmöglich erklärt.
