Bei der Produktion ist etwas kaputt gegangen. Eine kundenseitige Funktion ist ausgefallen, Daten wurden beschädigt oder eine Bereitstellung verlief um 2 Uhr morgens schief. Das Adrenalin ist verflogen. Das Update ist da. Was nun?
Dies ist der Moment, den die meisten Teams verschwenden. Entweder überspringen sie die Retrospektive komplett („Wir haben es bereits behoben, machen wir weiter“) oder sie führen eine Retrospektive durch, die stillschweigend die Schuld zuweist, während sie so tut, als ob sie es nicht täte. Beides verhindert nicht den nächsten Vorfall.
Eine wirklich tadellose Obduktion ist eine der wirkungsvollsten Aktivitäten, die ein Produktteam durchführen kann. Wenn es gut gemacht wird, verwandelt es ein schmerzhaftes Ereignis in eine systemische Verbesserung. Wenn es schlecht gemacht wird, lehrt es Ihr Team, Probleme zu verbergen.
Hier erfahren Sie, wie Sie tatsächlich funktionierende Vorfall-Retrospektiven durchführen.
Warum „tadellos“ nicht nur ein schönes Wort ist
Lassen Sie uns direkt sagen, was „tadellos“ bedeutet, denn Teams verstehen das ständig falsch.
Schuldlos bedeutet nicht „niemand war beteiligt“ oder „niemand hat einen Fehler gemacht“. Das bedeutet, dass Sie akzeptieren, dass die beteiligten Personen angesichts ihres damaligen Wissens, des Drucks, unter dem sie standen, und der ihnen zur Verfügung stehenden Werkzeuge vernünftige Entscheidungen getroffen haben. Die Frage verlagert sich von „Wer hat es vermasselt?“ zu „Was ist mit unserem System, das diesen Fehler wahrscheinlich gemacht hat?“
Das ist aus einem praktischen Grund wichtig: Wenn Menschen Angst vor Bestrafung haben, verbergen sie Probleme. Versteckte Probleme verschärfen sich. Am Ende kommt es zu Vorfällen, die man hätte frühzeitig erkennen können, die sich aber so lange verschlimmerten, bis sie zu Notfällen wurden.
Das Ziel besteht darin, das Auftauchen von Problemen so sicher wie möglich zu gestalten, was eine Person in Ihrem Team tun kann.
Wann sollte eine Vorfall-Retrospektive durchgeführt werden?
Nicht jeder Fehler erfordert eine formelle Obduktion. Speichern Sie den gesamten Prozess für Vorfälle, die mindestens eines dieser Kriterien erfüllen:
- Auswirkungen auf den Kunden – Benutzer erlebten einen beeinträchtigten Service, Datenverlust oder Ausfallzeiten
- Beinahe-Unfall – Nichts ist kaputt gegangen, aber nur, weil jemand es rechtzeitig erwischt hat
- Wiederholungsmuster – Dieselbe Problemkategorie ist schon einmal aufgetreten
- Teamübergreifende Beteiligung – Der Vorfall erforderte eine Koordination zwischen mehreren Teams
- Neuartige Fehler – Es ist etwas passiert, das Ihre Überwachung oder Ihre Prozesse nicht vorhergesehen haben
Führen Sie die Retrospektive innerhalb von 48 Stunden durch, solange die Details aktuell sind. Eine Woche zu warten garantiert, dass das Gedächtnis jedes Einzelnen im Nachhinein überarbeitet wurde.
Die Zeitleiste: Ihr wichtigstes Artefakt
Bevor Sie etwas analysieren, rekonstruieren Sie, was tatsächlich passiert ist. Das ist schwieriger als es klingt, weil die Erinnerungen der Menschen an Vorfälle notorisch unzuverlässig sind – Stress komprimiert und verzerrt die Zeit.
Erstellen Sie eine gemeinsame Zeitleiste mit objektiven Quellen:
- Überwachung von Warnungen und Dashboards – Wann haben sich die Metriken tatsächlich geändert?
- Protokolle bereitstellen – Was ist ausgefallen und wann?
- Chat-Protokolle – Was haben die Leute in Slack oder Ihrem Vorfallkanal gesagt?
- Kundenberichte -- Wann ist die erste Reklamation eingetroffen?
- Bereitschaftsaufzeichnungen – Wer wurde angerufen und wann hat er geantwortet?
Ordnen Sie diese chronologisch an. Redaktionieren Sie nicht. Die Zeitleiste sollte sich wie ein sachlicher Bericht lesen, nicht wie eine Erzählung mit Helden und Bösewichten.
Allein dieser Zeitstrahl offenbart oft das eigentliche Problem. Möglicherweise stellen Sie fest, dass die Auslösung um 14:03 Uhr erfolgte, der Alarm jedoch erst um 14:47 Uhr ausgelöst wurde, was bedeutet, dass Ihre Überwachung 44 Minuten lang einen toten Winkel aufwies. Diese Lücke ist wichtiger als die Codeänderung, die das Problem verursacht hat.
Ursachenanalyse: Über das Offensichtliche hinausgehen
Der häufigste Fehler bei der Retrospektive von Vorfällen besteht darin, bei der ersten Ursache anzuhalten, die man findet. Ein Server hat nicht mehr genügend Arbeitsspeicher. Es fehlte eine Nullprüfung. Ein Konfigurationswert war falsch. Das ist alles wahr, und sie sind alle unzureichend.
Die 5-Warum-Methode funktioniert, weil sie Sie über das Offensichtliche hinaus zwingt.
Beginnen Sie mit dem Vorfall und fragen Sie „Warum?“ wiederholt:
- Die API hat 20 Minuten lang 500 Fehler zurückgegeben. Warum?
- Der Datenbankverbindungspool war erschöpft. Warum?
- Eine Abfrage wurde ohne Zeitüberschreitung ausgeführt und es wurden Verbindungen gehalten. Warum?
- Die Abfrage wurde in einer aktuellen PR ohne Leistungsüberprüfung hinzugefügt. Warum?
- Für datenbankrelevante Änderungen ist kein Leistungsüberprüfungsschritt erforderlich. Warum?
Jetzt haben Sie etwas, das auf Systemebene umsetzbar ist: Fügen Sie ein Überprüfungstor für Abfragen hinzu, nicht nur eine Erinnerung an den einzelnen Entwickler, der diese Frage geschrieben hat.
Eine Warnung zu 5 Whys: Diese Methode funktioniert gut, wenn es eine einzige Kausalkette gibt. Bei vielen Vorfällen spielen mehrere Faktoren zusammen. In solchen Fällen ist ein Fischgrätendiagramm oder eine einfache Liste „beitragender Faktoren“ ehrlicher, als alles in eine Kette zu zwingen.
Strukturierung der Retrospektivsitzung
Hier ist ein Format, das sich gut für eine 60-minütige Retrospektive eines Vorfalls eignet. Passen Sie den Zeitpunkt je nach Schweregrad an.
1. Zeitleisten-Komplettlösung (15 Minuten)
Präsentieren Sie die rekonstruierte Zeitleiste. Bitten Sie die Teilnehmer, den Text zu korrigieren oder zu ergänzen. Diskutieren Sie noch nicht über die Ursachen, sondern legen Sie einfach Fakten fest.
2. Folgenabschätzung (10 Minuten)
Quantifizieren Sie, was passiert ist. Wie viele Benutzer waren betroffen? Wie hoch waren die Geschäftskosten? Sind Daten verloren gegangen? Dies verankert das Gespräch in der Realität und hilft, die Antwort zu priorisieren.
3. Mitwirkende Faktoren (20 Minuten)
Dies ist die Kernanalyse. Stellen Sie sich für jede Phase des Vorfalls – die Ursache, die Erkennung, die Reaktion, die Lösung – die Frage: Was hat das Problem schlimmer gemacht, als es sein musste? Was hat es besser gemacht?
Nützliche Hinweise:
- Welche Informationen fehlten den Menschen bei der Entscheidungsfindung?
- Wo sind unsere Tools oder unsere Überwachung unzureichend?
- Welche Prozesse haben während der Reaktion gut funktioniert?
- Was hätte die Erkennung beschleunigt?
- Wo scheiterten die Übergaben?
4. Maßnahmen (15 Minuten)
Generieren Sie spezifische, eigene, zeitgebundene Verbesserungen. Kategorisieren Sie sie:
- Sofortige Korrekturen – Patchen Sie die spezifische Sache, die kaputt gegangen ist (diese sollten bereits erledigt sein)
- Erkennungsverbesserungen – bessere Warnungen, Dashboards oder Tests, um diese Problemklasse zu erkennen
- Prozessänderungen – Überprüfen Sie Gates, Runbook-Updates oder Verbesserungen des Eskalationspfads
- Systemische Investitionen – größere Architektur- oder Werkzeugarbeiten, die diese Risikokategorie reduzieren
Beschränken Sie sich auf 3-5 Maßnahmen. Eine Postmortem-Untersuchung, die 15 Maßnahmen generiert, wird null davon abschließen. Priorisieren Sie rücksichtslos.
Die Sprache der Tadellosigkeit
Sprache prägt Kultur mehr als Politik. Hier sind konkrete Verschiebungen:
| Anstatt | Versuchen |
|---|---|
| „John hat einen schlechten Einsatz vorangetrieben“ | „Die Bereitstellung um 14:03 führte die Regression ein“ |
| „Das Team hätte das merken müssen“ | „Unser Überprüfungsprozess hat diese Art von Änderung nicht erkannt.“ |
| „Jemand hat vergessen, die Konfiguration zu aktualisieren“ | „Die Konfiguration wurde im Rahmen des Bereitstellungsprozesses nicht aktualisiert“ |
| „Warum hat es niemand gemerkt?“ | „Was hätte das früher sichtbar gemacht?“ |
Das Muster: Beschreiben Sie Ereignisse und Systeme, nicht Menschen und ihr Versagen. Hier geht es nicht darum, vage zu sein. Sie können sehr genau sagen, was schief gelaufen ist, ohne auf das individuelle Verschulden einzugehen.
Häufige Fallstricke, die Vorfall-Retros untergraben
Bei der unmittelbaren Ursache anhalten. Der Fix ist eingegangen, der Fehler ist behoben, fertig. Wenn Sie hier aufhören, werden Sie weiterhin ähnliche Vorfälle mit unterschiedlichen Besonderheiten erleben.
Maßnahmen generieren, die niemand verfolgt. Ein Maßnahme ohne Eigentümer und Frist ist ein Wunsch. Überprüfen Sie zu Beginn jeder neuen Obduktion den Abschluss von Aktionspunkten aus früheren Vorfällen.
Reinigung der Retrospektive für Führungskräfte. Wenn die schriftlichen Aufzeichnungen bearbeitet werden, um besser auszusehen, bevor sie Direktoren oder Vizepräsidenten erreichen, liegt ein Vertrauensproblem vor. Der springende Punkt ist Transparenz.
Führen Sie sie nur bei Ausfällen aus. Beinaheunfälle sind oft wertvoller für die Analyse, weil die Risiken geringer erscheinen und die Leute freier sprechen. Wenn ein Deploy fast zu einem Ausfall geführt hätte, dieser aber während des Canary-Vorgangs von jemandem bemerkt wurde, ist das ebenfalls verständlich.
Verwandeln Sie es in ein Statusmeeting. Die Retrospektive dient der Analyse und dem Lernen. Lassen Sie es nicht zu einem Überblick darüber werden, wer was während des Vorfalls getan hat. Die Zeitleiste deckt das bereits ab.
Aufbau einer Wissensdatenbank zu Vorfällen
Einzelne Obduktionen sind nützlich. Eine durchsuchbare Bibliothek von Postmortems ist transformativ.
Wenn Sie sechs Monate lang über dokumentierte Vorfälle verfügen, können Sie damit beginnen, Fragen zu stellen wie: Wie viel Prozent unserer Vorfälle stehen im Zusammenhang mit der Bereitstellung? Was ist unsere mittlere Zeit bis zur Entdeckung? Werden unsere Maßnahmen tatsächlich abgeschlossen?
Behalten Sie ein einheitliches Format bei, damit Vorfälle vergleichbar sind. Kennzeichnen Sie sie nach Kategorie (Bereitstellung, Infrastruktur, Daten, Abhängigkeit von Drittanbietern). Machen Sie sie für jeden in der Organisation zugänglich und nicht in einem Team-Wiki.
Mit der Zeit wird diese Bibliothek zu einem Ihrer wertvollsten technischen Vermögenswerte. Neue Teammitglieder können frühere Vorfälle durchlesen, um Ihre Systeme besser zu verstehen, als ihnen jedes Architekturdokument vermitteln könnte.
Damit es kleben bleibt
Der Unterschied zwischen Teams, die aus Vorfällen lernen, und Teams, die sie wiederholen, liegt in der Umsetzung.
Überprüfen Sie frühere Maßnahmen bei jedem Vorfall im Nachhinein. Wenn derselbe beitragende Faktor zweimal auftritt, eskalieren Sie ihn – das ist ein Signal dafür, dass Ihr Verbesserungsprozess selbst verbessert werden muss.
Erkennen Sie Menschen, die Probleme frühzeitig zum Vorschein bringen. Wenn jemand Bedenken äußert, die einen Vorfall verhindern, lohnt es sich, dies öffentlich zu feiern. Sie verstärken das gewünschte Verhalten.
Und akzeptieren Sie, dass Zwischenfälle passieren werden. Das Ziel sind nicht null Vorfälle. Das Ziel besteht darin, dass jeder Vorfall neu ist – Sie scheitern auf neue und interessante Weise und wiederholen nicht die gleichen Fehler in einer Schleife.
Probieren Sie NextRetro kostenlos aus – Führen Sie mit Ihrem Team strukturierte, unschuldige Vorfall-Retrospektiven durch, indem Sie integrierte Vorlagen und anonyme Kartensammlung verwenden.
Letzte Aktualisierung: Februar 2026
Lesezeit: 7 Minuten
