Prozess der Post-Mortem-Analysen von Vorfällen: Verfolgen, dokumentieren und verbessern

Die wichtigsten Punkte

• Post-Mortem-Analysen von Vorfällen helfen Teams dabei, zu verstehen, was passiert ist, warum es passiert ist und was geändert werden muss, um ein erneutes Auftreten derselben Probleme zu verhindern.

• Mit Jira Service Management, Confluence und Jira zusammen entsteht ein verbundener Workflow für Reaktion, Dokumentation und Nachverfolgung.

• Eine einheitliche Vorlage für Post-Mortem-Analysen macht es einfacher, Vorfall-Reviews zu dokumentieren, zu vergleichen und im Laufe der Zeit daraus zu lernen.

• Die Umwandlung von Korrekturmaßnahmen in Jira-Vorgänge mit Verantwortlichen und Fristen erleichtert es deinen Teams, aus gewonnenen Erkenntnissen echte Verbesserungen zu machen. 

Wenn in der Produktion etwas schiefgeht, ist die Fehlerbehebung nur der Anfang. Genauso wichtig ist es, zu verstehen, warum dies passiert ist, und sicherzustellen, dass dasselbe nicht noch einmal passiert. 

Eine Post-Mortem-Analyse von Vorfällen ist eine strukturierte Überprüfung eines Vorfalls von Anfang bis Ende, die abdeckt, was nicht mehr funktionierte, wie das Team reagiert hat und was sich in Zukunft ändern muss.

Mit einer Vorlage für Incident-Response-Pläne, die durch den Prozess führt, kann dein Team jeden Vorfall einheitlich dokumentieren, sodass nichts Wichtiges übersehen wird und jede Überprüfung zu echten Verbesserungen führt.

So funktioniert’s: Vorfälle bearbeiten und Post-Mortem-Analysen erfassen

Gutes Vorfallmanagement bedeutet nicht nur, bereits aufgetretene Vorfälle zu beheben. Vielmehr soll ein System aufgebaut werden, bei dem jeder Vorfall zu besseren Prozessen, besseren Tools und einer besseren Vorbereitung auf den nächsten Vorfall führt. Wenn du Jira Service Management, Confluence und Jira zusammen verwendest, entsteht ein verbundener Workflow für dein Team, der den gesamten Incident Response-Lebenszyklus abdeckt – vom Moment, in dem eine Warnmeldung ausgelöst wird, über die Post-Mortem-Analyse bis hin zu Folgevorgängen. 

Dieser Ansatz sorgt für eine einheitliche Dokumentation bei allen Vorfällen und schafft eine klare Verantwortungskette. Anstatt dass Vorfalldetails verstreut in Slack-Nachrichten, E-Mails und in den Köpfen einzelner Mitarbeiter vorhanden sind, befindet sich alles in einem einzigen, vernetzten Ökosystem, wo es überprüft, referenziert und bearbeitet werden kann. Diese Konsistenz bedeutet auch, dass deine Vorlage für Incident Response-Pläne zentral im Prozess bleibt, anstatt nur bei Gelegenheit sporadisch ausgefüllt zu werden. 

So laufen die einzelnen Phasen des Prozesses ab:

Den Vorfall in Jira Service Management bearbeiten

Jira Service Management ist der Ausgangspunkt für deine Incident Response. Sobald ein Problem gemeldet wird, protokollierst du es in JSM, legst den Schweregrad fest und weist die richtigen Ansprechpartner zu. 

Während des Vorfalls haben deine Teams in JSM folgende Möglichkeiten:

• Aktionen, Entscheidungen und Eskalationen in Echtzeit verfolgen

• Eine klare Aufzeichnung über alle Beteiligten und Änderungen pflegen

• Details zur Unterstützung der späteren Post-Mortem-Analyse erfassen

• Die Führungsebene auf dem Laufenden halten, ohne die Arbeit der Vorfallverantwortlichen zu unterbrechen

Da JSM in Confluence und Jira integriert ist, können die während des Vorfalls gesammelten Daten direkt in die Post-Mortem-Analyse-Dokumentation und die Folgevorgänge einfließen. Für Teams, die JSM als Teil einer umfassenderen ITSM-Software-Konfiguration verwenden, fließen die Vorfalldaten auch in das gesamte Servicemanagement ein.

JSM unterstützt auch umfassende Informationen zu Vorfällen während der gesamten Reaktion, da es deinen Teams folgende Möglichkeiten bietet:

• Kunden, Supportteams und Stakeholder auf dem Laufenden halten

• Verwirrung bei aktiven Vorfällen reduzieren

• Einblick in Status und Auswirkungen bereitstellen

• Während Ereignissen mit hohem Schweregrad oder in Krisenmanagement-Szenarien klarer kommunizieren

Zum Abschluss eines Vorfalls hat das Team bereits eine detaillierte Aufzeichnung über dessen Verlauf. Dies erleichtert die Dokumentation der Post-Mortem-Analyse und steigert den Nutzen mit Blick auf zukünftige Verbesserungen.

Die Post-Mortem-Analyse in Confluence erfassen

Sobald der Vorfall erledigt ist, dokumentierst du ihn, solange die Details noch frisch im Gedächtnis sind – idealerweise innerhalb von 24 bis 48 Stunden. Je länger du wartest, desto mehr Kontext geht verloren und desto weniger nützlich wird die Post-Mortem-Analyse. 

Erstelle eine spezielle Confluence-Seite mit einer Vorlage für Post-Mortem-Analysen von Vorfällen und arbeite jeden Abschnitt durch: Zeitleiste, Ursachenanalyse, Auswirkungsbewertung und gewonnene Erkenntnisse. Die Vorlage für eine Incident Response auf dieser Seite bietet ein vollständiges Framework, das dein Team kopieren und für jeden neuen Vorfall ausfüllen kann, damit ihr nicht jedes Mal von Grund auf herausfinden müsst, was dokumentiert werden soll.

Die Aufbewahrung von Post-Mortem-Analysen in Confluence bietet mehrere praktische Vorteile:

• Teamweite Transparenz: Alle, von der Entwicklung bis hin zur Führungsebene, können nachsehen, was passiert ist, ohne den Bereitschaftsdienst für eine mündliche Zusammenfassung kontaktieren zu müssen.

• Mustererkennung: Wenn jeder Vorfall im gleichen Format dokumentiert wird, ist es viel einfacher, wiederkehrende Ausfälle und systemische Schwächen über mehrere Quartale hinweg zu erkennen.

• Dokumentation ohne Schuldzuweisungen: Eine strukturierte Vorlage für eine Incident Response sorgt dafür, dass der Fokus der Diskussion auf Systemen und Prozessen liegt und nicht mit dem Finger auf andere gezeigt wird. Dies führt zu ehrlicherer und nützlicherer Berichterstattung.

• Schnellere Einarbeitung für neue Mitarbeiter: Neue Teammitglieder können vergangene Post-Mortem-Analysen durchlesen, um zu verstehen, wie sich deine Systeme unter Druck verhalten und was das Team bereits aus früheren Vorfällen gelernt hat.

Eine ausführlichere Anleitung zur Durchführung produktiver Post-Mortem-Analysen findest du in unserem Handbuch für Post-Mortem-Analysen von Vorfällen.

Nachfolgeaktionen als Jira-Vorgänge verfolgen

Eine Post-Mortem-Analyse ist nur so nützlich wie die Aktionen, die daraus folgen. Jede Korrekturmaßnahme und jedes wiederkehrende Problem, das während der Überprüfung identifiziert wird, sollte in einen Jira-Vorgang mit einem klaren Besitzer und einer Deadline umgewandelt werden. 

Darin unterscheiden sich Teams, die sich tatsächlich verbessern, von denen, die immer wieder auf dieselben Probleme stoßen. Wenn Korrekturmaßnahmen als nachverfolgbare Vorgänge in Jira vorliegen, können Manager den Fortschritt überwachen und Teams sich gegenseitig für die Umsetzung der vereinbarten Verbesserungen zur Verantwortung ziehen. Dies hilft auch bei der Priorisierung. Wenn aus dem Vorfall entstandene Vorgänge sich in den Rest deines Backlogs einreihen, ist es einfacher, sie gegen andere Prioritäten abzuwägen, anstatt sie stillschweigend an das Ende der Liste wandern zu lassen.

Die richtigen Vorfallmanagementtools verbinden diesen gesamten Workflow von Anfang bis Ende. Wenn deine Reaktions-, Dokumentations- und Nachbereitungssysteme integriert sind, wird die Lücke zwischen der Erkennung eines Problems und der Verhinderung seiner Wiederholung erheblich kleiner.

Vorlage für eine Incident Response

Nachfolgend findest du eine Vorlage für Incident-Response-Pläne, die dein Team kopieren und für jeden neuen Vorfall anpassen kann. Sie führt durch jede Phase einer Post-Mortem-Analyse, von der ersten Zusammenfassung und Zeitleiste über die Ursachenanalyse bis hin zu den gewonnenen Erkenntnissen und Korrekturmaßnahmen. Die Verwendung einer einheitlichen Struktur für jeden Vorfall stellt sicher, dass nichts übersehen wird und dass deine Post-Mortem-Analysen über die Zeit hinweg leicht zu vergleichen sind.

Die Beispiele in der Vorlage sind ein Ausgangspunkt, kein starres Skript. Passe die Sprache und den Detailgrad an die Arbeitsweise deines Unternehmens an. Das Ziel ist es, genügend Kontext zu dokumentieren, damit jeder, der die Post-Mortem-Analyse Monate später liest, genau verstehen kann, was passiert ist und was das Team dagegen unternommen hat.

Zusammenfassung des Vorfalls

Fasse den Vorfall in einigen Sätzen zusammen. Die Zusammenfassung sollte beinhalten, was passiert ist, warum es passiert ist, wie schwer der Vorfall war und wie lange die Auswirkungen spürbar waren.

Beispiel:

Zwischen {time range of incident, e.g. 15:45 and 16:35} Uhr am {DATE} stießen {NUMBER} Benutzer auf {EVENT SYMPTOMS}. 

Das Ereignis wurde ausgelöst durch eine {CHANGE} um {TIME OF CHANGE THAT CAUSED THE EVENT}. 

Die {CHANGE} umfasste {DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system}. 

Ein Bug in diesem Code verursachte {DESCRIPTION OF THE PROBLEM}. 

Das Ereignis wurde von {MONITORING SYSTEM} erkannt. Das Team behandelte das Ereignis mit {RESOLUTION ACTIONS TAKEN}.

Dieser Vorfall des Schweregrads {SEVERITY LEVEL} betraf {X%} der Benutzer.

Es sind weitere Auswirkungen entstanden, denn es gab {e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS} im Zusammenhang mit diesem Vorfall. 

Ereignisse im Vorfeld

Beschreibe die Abläufe, die zu dem Vorfall geführt haben, beispielsweise vorangegangene Änderungen, durch die bisher unentdeckte Bugs eingeführt wurden.

Beispiel:

Um {16:00} am {MM/DD/YY}, ({AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}) wurde eine Änderung an {PRODUCT OR SERVICE} vorgenommen, um {THE CHANGES THAT LED TO THE INCIDENT}. 

Diese Änderung führte zu {DESCRIPTION OF THE IMPACT OF THE CHANGE}.

Fehler

Beschreibe, was bei der eingeführten Änderung nicht wie erwartet funktionierte. Falls verfügbar, füge zur Veranschaulichung des Fehlers Screenshots relevanter Datenvisualisierungen hinzu.

Beispiel:

{NUMBER} Antworten wurden irrtümlich an {XX%} der Anfragen gesendet. Das passierte über einen Zeitraum von {TIME PERIOD}.

Auswirkungen

Beschreibe, wie der Vorfall interne und externe Benutzer beeinträchtigte. Gib an, wie viele Supporttickets erstellt wurden.

Beispiel:

Für {XXhrs XX minutes} zwischen {XX:XX UTC and XX:XX UTC} am {MM/DD/YY} trat dieser Vorfall {SUMMARY OF INCIDENT} bei unseren Benutzern auf.

Dieser Vorfall betraf {XX} Kunden (X% VON {SYSTEM OR SERVICE} BENUTZERN), bei denen {DESCRIPTION OF SYMPTOMS} aufgetreten ist.

{XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS} wurden erstellt.

Erkennung

Wann hat das Team den Vorfall festgestellt? Woher wusste es, was passiert ist? Wie können wir die Zeit bis zur Erkennung verbessern? Denkt darüber nach, wie diese Zeit halbiert werden kann.

Beispiel:

Dieser Vorfall wurde erkannt, als {ALERT TYPE} ausgelöst und {TEAM/PERSON} benachrichtigt wurde. 

Als Nächstes wurde {SECONDARY PERSON} benachrichtigt, da {FIRST PERSON} nicht über die notwendige Berechtigung für den Service verfügte, was die Reaktion um {XX MINUTES/HOURS} verzögerte.

{DESCRIBE THE IMPROVEMENT} wird vom {TEAM OWNER OF THE IMPROVEMENT} umgesetzt, damit {EXPECTED IMPROVEMENT}.

Antwort

Wer reagierte auf den Vorfall? Wann hat der Zuständige reagiert und was hat er unternommen? Notiere Verzögerungen oder Hindernisse bei der Reaktion.

Beispiel:

Nach Erhalt einer Benachrichtigung um {XX:XX UTC} ging {ON-CALL ENGINEER} um {XX:XX UTC} in {SYSTEM WHERE INCIDENT INFO IS CAPTURED} online. 

Dieser Mitarbeiter hatte keine genaueren Kenntnisse von {AFFECTED SYSTEM}. Daher wurde um {XX:XX UTC} eine zweite Warnmeldung an {ESCALATIONS ON-CALL ENGINEER} gesendet, der um {XX:XX UTC} hinzukam.

Wiederherstellung

Beschreibe, wie der Service wiederhergestellt und der Vorfall als beendet eingestuft wurde. Gib Details an, wie der Service erfolgreich wiederhergestellt wurde, und wie ihr herausgefunden habt, welche Maßnahmen zur Wiederherstellung ergriffen werden mussten. 

Berücksichtige je nach Szenario die folgenden Fragen: Wie kann die Zeit bis zur Problemminderung verbessert werden? Wie könnte diese Zeit um die Hälfte verkürzt werden?

Beispiel:

Wir haben einen dreigliedrigen Ansatz zur Wiederherstellung des Systems verwendet: 

{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME} 

Beispiel: Vergrößerung von BuildEng EC3 ASG, um die Anzahl der verfügbaren Knoten zur Unterstützung des Workloads zu erhöhen und die Wahrscheinlichkeit einer Planung mit überbelegten Knoten zu verringern

• Deaktivierung des Escalator-Systems für die automatische Skalierung, um eine aggressive Abwärtsskalierung des Clusters zu verhindern

• Zurücksetzung der Build Engineering-Planungslösung auf die vorherige Version

Zeitleiste

Gib den zeitlichen Ablauf des Vorfalls im Detail an. Wir empfehlen die Verwendung von UTC zur Standardisierung von Zeitzonen.

Füge alle nennenswerten vorangegangenen Ereignisse, alle Aktivitätsstarts, die ersten bekannten Auswirkungen und die Eskalationen hinzu. Notiere alle getroffenen Entscheidungen oder Änderungen, die Beendung des Vorfalls sowie alle wichtigen Ereignisse nach dem Vorfall. 

Beispiel:

Alle Zeitangaben sind in UTC.

11:48 Uhr: Control-Panel-Upgrade auf K8S 1.9 fertiggestellt 

12:46 Uhr: Upgrade auf v1.9 fertiggestellt, einschließlich der automatischen Clusterskalierung und der BuildEng-Planungsinstanz 

14:20 Uhr: Build Engineering meldet ein Problem an KITT Disturbed.

14:27 Uhr: KITT Disturbed beginnt mit der Untersuchung von Fehlern bei einer bestimmten EC2-Instanz (ip-203-153-8-204). 

14:42 Uhr: KITT Disturbed isoliert den Knoten. 

14:49 Uhr: BuildEng meldet, dass mehrere Knoten von dem Problem betroffen sind. 86 Vorkommen des Problems zeigen, dass die Fehler weiter im System verbreitet sind. 

15:00 Uhr: KITT Disturbed schlägt einen Wechsel zur Standardplanungslösung vor. 

15:34 Uhr: BuildEng meldet den Ausfall von 200 Pods. 

16:00 Uhr: BuildEng beendet alle fehlgeschlagenen Builds mit OutOfCpu-Berichten. 

16:13 Uhr: BuildEng meldet, dass die Fehler bei neuen Builds konsistent erneut auftreten und nicht nur vorübergehend waren. 

16:30 Uhr: KITT erkennt die Fehler als Vorfall an und behandelt sie ab sofort entsprechend. 

16:36 Uhr: KITT deaktiviert das Escalator-System für die automatische Skalierung, damit es keine weiteren Rechenressourcen zur Minderung des Problems beansprucht.

16:40 Uhr: KITT bestätigt, dass ASG stabil ist, die Clusterlast sich normalisiert hat und die Auswirkungen auf Kunden beseitigt sind.

VORLAGE:

XX:XX UTC – VORFALLAKTIVITÄT; DURCHGEFÜHRTE AKTION

XX:XX UTC – VORFALLAKTIVITÄT; DURCHGEFÜHRTE AKTION

XX:XX UTC – VORFALLAKTIVITÄT; DURCHGEFÜHRTE AKTION

Ursachenermittlung: Die fünf Warum-Fragen

Die 5 Warum-Fragen sind eine Technik der Ursachenermittlung. Du wendest sie folgendermaßen an:

• Beginne mit einer Beschreibung der Auswirkungen und frage, warum sie aufgetreten sind. 

• Notiere die Auswirkungen.  

• Frage, warum dies geschehen ist und warum die daraus resultierenden Auswirkungen auftraten. 

• Stelle anschließend so lange weiter "Warum"-Fragen, bis du die Ursache herausgefunden hast.

Liste diese "Warum"-Fragen in der Dokumentation deiner Post-Mortem-Analyse auf.

Beispiel:

1. Die Anwendung ist ausgefallen, da die Datenbank gesperrt war.

2. Die Datenbank wurde gesperrt, weil es zu viele Schreibvorgänge in die Datenbank gab.

3. Weil wir eine Änderung des Service vorangetrieben und die erhöhten Schreibvorgänge nicht erwartet haben.

4. Weil wir keinen Entwicklungsprozess für Belastungstests nach Änderungen etabliert haben.

5. Weil wir nie der Meinung waren, dass Belastungstests notwendig seien, bevor wir dieses Ausmaß erreicht haben.

Grundlegende Ursache

Notiere die grundlegende Ursache des Vorfalls. Hier muss eine Änderung vorgenommen werden, damit Vorfälle dieser Art nicht mehr auftreten.

Beispiel:

Ein Bug in

Backlog-Überprüfung

Überprüfe das Entwickler-Backlog, um herauszufinden, ob dort ungeplante Arbeiten zu finden sind, die diesen Vorfall möglicherweise verhindert oder zumindest seine Auswirkungen reduziert hätten. 

Eine ehrliche Bewertung des Backlogs hilft, vergangene Entscheidungen über Prioritäten und Risiken zu klären.

Beispiel:

Keine spezifischen Elemente im Backlog, die diesen Service hätten verbessern können. Es gibt eine Anmerkung zu Verbesserungen der Flow-Typisierung, und dies waren laufende Tasks mit eingerichteten Workflows.  

Es wurden Tickets zur Verbesserung der Integrationstests eingereicht, aber bisher waren sie nicht erfolgreich.

Erneutes Auftreten

Nachdem du nun die Ursache kennst, kannst du zurückblicken, ob andere Vorfälle dieselbe Ursache gehabt haben könnten. Wenn ja, notiere, welche Maßnahmen bei diesen Vorfällen versucht wurden, und stelle die Frage, warum dieser Vorfall erneut aufgetreten ist.

Beispiel:

Dieselbe grundlegende Ursache hatte bereits die Vorfälle HOT-13432, HOT-14932 und HOT-19452 zur Folge.

Erkenntnisse

Besprecht, was bei der Incident Response gut gelaufen ist, was hätte besser laufen können und wo Verbesserungsmöglichkeiten bestehen.

Beispiel:

• Es ist ein Unit-Test erforderlich, um zu überprüfen, ob die Ratenbegrenzung für die Arbeit richtig gepflegt wurde.

• Massenhaft auftretende Workloads, die für den Normalbetrieb ungewöhnlich sind, sollten überprüft werden.

• Massen-Workloads sollten langsam gestartet und überwacht werden. Eine Steigerung sollte erst erfolgen, wenn die Metriken des Service normal erscheinen.

Korrekturmaßnahmen

Beschreibe die angeordneten Korrekturmaßnahmen, um diese Art von Vorfällen in Zukunft zu verhindern. Notiere, wer verantwortlich ist, wann die Verantwortlichen ihre Arbeit abschließen müssen und wo diese Arbeit verfolgt wird.

Beispiel:

1. Vorübergehende Festlegung einer manuellen Ratenbegrenzung für die automatische Skalierung, um Fehler zu reduzieren

2. Unit-Tests und Wiedereinführung der Jobratenbegrenzung

3. Einführung eines sekundären Mechanismus zur clusterübergreifenden Erfassung verteilter Rateninformationen als Leitfaden für Skalierungseffekte