Postmortem-Dokumentationshandbuch

Störungen und Ausfälle gehören in der Tech-Welt zur Realität, bieten aber auch wertvolle Wachstums- und Verbesserungsmöglichkeiten und stellen weiterhin ein kostspieliges Problem dar. Aktuellen Daten zufolge stiegen die kundenbezogenen Störungen im letzten Jahr um 43 %. kostete fast 800.000 Dollar Obwohl diese Momente sowohl für Kunden als auch für Teams eine Herausforderung darstellen können, können die während und nach einem Vorfall ergriffenen Maßnahmen den entscheidenden Unterschied bei der Stärkung der Systeme und der Vermeidung zukünftiger Probleme ausmachen.

Hier ist eine gut ausgearbeitete Postmortem-Analyse unverzichtbar. Es ist jedoch entscheidend, sich danach die Zeit zu nehmen, das Geschehene, die Lösung und das weitere Vorgehen zu analysieren. In dieser Ressource erläutern wir den Prozess der Erstellung einer effektiven Postmortem-Analyse, um Teams dabei zu unterstützen, das Vorfallmanagement zu verbessern, zu lernen, sich anzupassen und kontinuierlich zu verbessern.

Was ist eine Obduktion?

Eine Post-Mortem-Analyse ist ein strukturierter Prozess nach einem Vorfall. Obduktion des Vorfalls oder Vorfallsnachbesprechung. Sie umfasst eine detaillierte Überprüfung dessen, was passiert ist, warum es passiert ist, wie es gelöst wurde und was zu tun ist, um erneute Vorfälle zu verhindern.

Postmortem-Analysen helfen Teams zu verstehen, was gut läuft, was verbessert werden könnte und wie sie dieselben Fehler vermeiden können. Eine gründliche Postmortem-Analyse mit detaillierter Dokumentation hilft Teams, aus Fehlern zu lernen und Systeme und Prozesse zu verbessern.

Postmortem-Analysen sind nach einem Vorfall unerlässlich und helfen den Teammitgliedern, nachzudenken und Verbesserungsmöglichkeiten zu erkennen.

Fragen zur Projekt-Postmortem-Analyse

Postmortem-Analysen sind nicht nur nach einem Vorfall hilfreich, sie können auch nach Abschluss eines Projekts wertvolle Lernhilfen sein. Diese Art der Postmortem-Analyse gibt Projektteams die Möglichkeit zu beurteilen, was gut gelaufen ist und was verbessert werden kann.

Hier sind einige Fragen, die Sie während einer Projekt-Postmortem-Sitzung stellen sollten:

• Was waren die Ziele des Projekts? Wurden die Ziele erreicht?
• Was waren die Erfolge/Erfolge des Projekts?
• Wie gut hat das Team zusammengearbeitet? Gab es Hindernisse (z. B. Kommunikation, Zeitpläne usw.)?
• Wurden die Anforderungen an die Teammitglieder klar definiert?
• Hatte das Team das Gefühl, über ausreichend Ressourcen zu verfügen, um das Projekt abzuschließen?
• Auf welche Probleme ist das Team gestoßen?
• Wurden bei dem Projekt Budget und Zeitplan eingehalten?
• Was waren die wichtigsten Erkenntnisse aus diesem Projekt? Wie können diese Erkenntnisse auf zukünftige Projekte angewendet werden?
• Welche Qualifikationslücken, die in diesem Projekt aufgedeckt wurden, müssen geschlossen werden?

So schreiben Sie eine Obduktionsanalyse

Die Erstellung eines Post-Mortem-Berichts ist entscheidend für die Dokumentation von Vorfällen, die Identifizierung beitragender Faktoren und die Festlegung von Maßnahmen, die ein erneutes Auftreten verhindern und unterstützen kontinuierliche Verbesserung .

Die Postmortem-Dokumentation muss detailliert sein und eine Zusammenfassung des Vorfalls, den Zeitplan, die Ursachen, die Auswirkungen und die Maßnahmen enthalten, damit die Teams die Ursache eines Vorfalls ermitteln und Maßnahmen zur Vermeidung zukünftiger Vorfälle ergreifen können. Nachfolgend finden Sie die wichtigsten Abschnitte und Details einer Postmortem-Dokumentation.

Überblick

Beschreiben Sie kurz, was passiert ist. Geben Sie an, welche Teams beteiligt waren (z. B. IT, DevOps, Support) und geben Sie eine kurze Zusammenfassung der wichtigsten Meilensteine des Vorfalls (z. B. Erkennung, Eindämmung, Lösung). Geben Sie einen kurzen Überblick über die Auswirkungen des Vorfalls auf Unternehmen und Benutzer, damit die Beteiligten den Umfang schnell verstehen. Dieser Abschnitt sollte eine allgemeine Zusammenfassung des Vorfalls enthalten, einschließlich der Ursachen, des Zeitrahmens und der Auswirkungen.

Was ist passiert?

Geben Sie eine kurze Beschreibung des Vorfalls an.

Geben Sie Details zu folgenden Punkten an:

• Welche Teile der Infrastruktur betroffen waren und welche spezifischen Dienste oder Funktionen gestört waren, wird detailliert beschrieben.
• Notieren Sie alle Auswirkungen auf den Benutzer, wie etwa Verlangsamungen, Zugriffsprobleme oder die Nichtverfügbarkeit von Funktionen, um zu verdeutlichen, inwiefern die Benutzer betroffen waren.
• Wer war an der Reaktion beteiligt?
• Wie wurde der Vorfall gelöst?

Grundursachen

Listen Sie in diesem Abschnitt alle Bedingungen auf, die möglicherweise zu dem Vorfall/Problem beigetragen haben.

• Beschreiben Sie alle Faktoren, die zu dem Vorfall geführt haben könnten, wie etwa kürzliche Änderungen am Code, an der Systemlast oder Konfigurationsfehler.
• Beachten Sie, ob das Team Zwischenlösungen versucht oder das Problem intern eskaliert hat, bevor die Grundursache entdeckt wurde.

Geben Sie unbedingt an, ob Maßnahmen ergriffen wurden, die die Situation verschlimmert haben. Das Ausfüllen dieses Abschnitts kann Teammitgliedern helfen, aus den Fehlern zu lernen, die den Vorfall verursacht haben.

Auflösung

Wie wurde das Problem gelöst? Welche Maßnahmen wurden ergriffen?

Dokumentieren Sie sowohl kurzfristige Lösungen als auch die dauerhafte Lösung in separaten Punkten. Beziehen Sie alle Workarounds und manuellen Eingriffe in die Problemlösung mit ein. Verlinken Sie auf bestimmte Runbooks, Anleitungen oder Verfahren, damit die Helfer im Falle eines erneuten Vorfalls eine Referenz haben.

Auswirkungen

Was ist infolge des Vorfalls passiert? Gehen Sie in diesem Abschnitt sehr detailliert vor und geben Sie Zahlen oder andere Einzelheiten an.

Dieser Abschnitt sollte Folgendes enthalten:

• Zeitleiste: Skizzieren Sie die wichtigsten Meilensteine von der Entdeckung bis zur Lösung, einschließlich der Dauer jeder Phase.
• Problemerkennung: Beschreiben Sie, wann und wie das Problem erstmals erkannt wurde, und geben Sie an, wie es entdeckt wurde (z. B. interne Überwachung, Kundenberichte oder automatische Warnmeldungen).
• Schwere: Weisen Sie dem Vorfall einen Schweregrad zu und erläutern Sie detailliert, warum er auf diese Weise kategorisiert wurde und welche speziellen Kriterien bei der Bewertung verwendet wurden.
• Auswirkungen auf den Kunden: Dokumentieren Sie die Anzahl der betroffenen Kunden und die Dauer der Auswirkungen. Geben Sie die Art der Auswirkungen an, die die Kunden erlebt haben (z. B. Serviceunterbrechungen, Leistungseinbußen) und etwaige Abweichungen zwischen den einzelnen Benutzersegmenten.
• Auswirkungen auf interne Teams und Partner: Beschreiben Sie, welche Auswirkungen der Vorfall auf interne Teams und Partner hatte. Berücksichtigen Sie dabei auch etwaige Verzögerungen, Ressourcenumverteilungen und zusätzliche Arbeitsbelastungen.
• Abschließende Auswirkungsanalyse: (Technische und geschäftliche KPIs): Verwenden Sie KPIs, um die technischen und geschäftlichen Auswirkungen zu quantifizieren. Dies können beispielsweise Betriebszeitmetriken, Verstöße gegen Service-Level-Agreements (SLAs), Umsatzeinbußen oder Benutzerabwanderung sein.
• Auflösung: Fassen Sie die zur Problemlösung unternommenen Schritte zusammen, einschließlich etwaiger Zwischenlösungen und der endgültigen Lösung basierend auf der Ursachenanalyse. Fügen Sie gegebenenfalls einen Link zu einer ausführlicheren technischen Dokumentation hinzu.
• Mögliche zukünftige Auswirkungen: Bewerten Sie die Wahrscheinlichkeit, dass sich in Zukunft ähnliche Vorfälle ereignen, und besprechen Sie alle potenziellen langfristigen Auswirkungen auf das System oder das Unternehmen.
• Erkenntnisse und Möglichkeiten zur kontinuierlichen Verbesserung: Überlegen Sie, was das Team aus diesem Vorfall gelernt hat, und skizzieren Sie konkrete Verbesserungsbereiche bei Prozessen, Tools oder der Teamdynamik. Notieren Sie alle Folgemaßnahmen, die ergriffen werden können, um eine Wiederholung zu verhindern.

Nutzen Sie für technische Teams und Stakeholder interessante Opportunitätsmetriken, um die Auswirkungen des Vorfalls zu quantifizieren. Dazu gehören Metriken wie Ereignisübermittlung oder verzögerte Verarbeitung.

Zusätzliche einzubeziehende Metriken:

• Zeit bis zur Erkennung (TTD): Hilft Teams zu verstehen, wie schnell Überwachungs- und Warnsysteme den Vorfall gemeldet haben.
• Reaktionszeit (TTR): Misst die Reaktionsfähigkeit bei der Untersuchung und Zuweisung von Ressourcen.
• Zeit bis zur Lösung (TTR): Wie effizient war das Team bei der Reaktion und Problemlösung?
• Systemverfügbarkeit/Betriebszeit: Die Zeit, in der ein System betriebsbereit ist, ist ein Indikator für die Systemzuverlässigkeit.

Zeitleiste

Die Zeitleiste sollte dokumentieren, wie und wann sich der Vorfall ereignet hat. Sie sollte ausschließlich Fakten enthalten und nicht auf die Auswertung oder Analyse des Geschehens fokussiert sein.

Tipps zum Erstellen der Zeitleiste:

1. Beginnen Sie mit der Zeitleiste vor dem Vorfall und arbeiten Sie sich bis zur Lösung vor.
2. Überprüfen Sie das Vorfallprotokoll in Slack oder einer anderen Methode zur Teamkommunikation und finden Sie die Entscheidungen und Maßnahmen, die während der Reaktion getroffen wurden
3. Fügen Sie Informationen aus Überwachungsprotokollen und Bereitstellungen der betroffenen Dienste hinzu. Fügen Sie alle Änderungen am Vorfallstatus hinzu.
4. Notieren Sie, wann Kunden das Problem erstmals gemeldet haben und wann es von internen Benutzern entdeckt wurde. Welche zeitlichen Unterschiede gab es?
5. Erstellen Sie eine Metrik für jedes Element in der Timeline oder auf der Seite, von der die Daten stammen, z. B. eine Protokollsuche, einen Tweet oder ein Überwachungsdiagramm.

Einzuschließende Zeiten:

• Zeitpunkt des Einschlags
• Als das Team benachrichtigt wurde
• Zeitpunkt aller wesentlichen Aktionen
• Zeitpunkt des Endes des Aufpralls

Antwortende

Beschreiben Sie die Rolle, die die Teammitglieder bei der Lösung des Vorfalls gespielt haben.

Wer hat das Problem dokumentiert? Wer war sonst noch beteiligt? Geben Sie die Rollen und Verantwortlichkeiten der einzelnen Mitarbeiter an, z. B. Bereitschaftstechniker, Kommunikationsmanager und technischer Support, sowie deren wichtigsten Beiträge zum Vorfallmanagement.

Heben Sie alle konkreten Maßnahmen einzelner Personen hervor, die für die Lösung des Vorfalls von entscheidender Bedeutung waren.

Auswertung

Bewerten Sie den Reaktionsprozess, um Stärken, Wachstumsbereiche und systemische Faktoren zu verstehen.

• Analysieren Sie die beitragenden Faktoren. Betrachten Sie den Vorfall nicht nur als unmittelbaren Vorfall, sondern identifizieren Sie auch eine Kombination beitragender Faktoren (organisatorischer, menschlicher und technischer Natur).
• Vermeiden Sie es, einzelnen Personen die Schuld zu geben. Schuldlose Obduktionen Helfen Sie Teams, voranzukommen, Lösungen zu finden und Verbesserungsmöglichkeiten zu identifizieren. Anonymisieren Sie Fehler und erkennen Sie, dass Aktionen mit ungewissem Ausgang erfolgen.
• Überprüfen Sie die Überwachungsdaten zum Vorfall, einschließlich aller ungewöhnlichen Muster, und stellen Sie sicher, dass Überwachungstools vorhanden sind, um zukünftige Probleme zu vermeiden.
• Stellen Sie kritische Fragen. Überlegen Sie, ob das Problem Teil eines Trends ist, ob es erwartete oder unerwartete Probleme widerspiegelt und ob frühere Entscheidungen dazu beigetragen haben.
• Überlegen Sie, was das Team aus diesem Vorfall gelernt hat, und konzentrieren Sie sich dabei auf die Erkennung von Mustern bei ähnlichen Vorfällen. Diese Erkenntnisse können zu technischen und organisatorischen Verbesserungen führen, insbesondere bei der Entwicklung automatisierter Reaktionen. Teams sollten diese Erkenntnisse nutzen, um Strategien zur automatischen Behebung zu entwickeln, damit das System wiederkehrende Probleme ohne manuelle Eingriffe erkennen und beheben kann.
• Analysieren Sie, wie sich Zusammenarbeit, Kommunikation und Überprüfungsprozesse auf den Vorfall ausgewirkt haben, um zukünftige Reaktionen zu verbessern.

Beschreiben Sie, was gut lief und was nicht. So können Sie die gewonnenen Erkenntnisse nutzen, um zukünftige Vorfälle zu vermeiden.

Nächste Schritte und Aktionspunkte

Nachdem Sie alle Einzelheiten erzählt haben, wie geht es weiter?

Identifizieren Sie Maßnahmen, um ein erneutes Auftreten zu verhindern und die Wahrscheinlichkeit oder Auswirkung ähnlicher Probleme zu verringern.

Fügen Sie Elemente ein wie:

• Priorisierte Handlungsschritte. Weisen Sie den Aktionspunkten Prioritätsstufen (z. B. hoch, mittel, niedrig) basierend auf Dringlichkeit und potenziellen Auswirkungen zu. Weisen Sie außerdem jedem Aktionspunkt ein verantwortliches Team oder eine verantwortliche Person zu, um die Verantwortlichkeit sicherzustellen.
• Alle erforderlichen Korrekturen, um ein erneutes Auftreten des Problems zu verhindern.
• Erwägen Sie Verbesserungen bei der Überwachung, Alarmierung und Reaktion auf Vorfälle zur Erkennung von Problemen und die Auswirkungen zu minimieren.
• Alle Vorbereitungsaufgaben, die die Erkennung und Eindämmung eines ähnlichen Problems verbessern könnten.
• Beheben von Prozess- oder Workflow-Problemen, die im Postmortem-Prozess identifiziert wurden. Dazu gehören interne E-Mails, Aktualisieren öffentlicher Statusseiten usw.
• Jede Verbesserung des Vorfallreaktionsprozesses.
• Geben Sie Fristen an. Geben Sie Zieldaten für die Fertigstellung jedes Aktionselements an.

Protokollieren Sie alle Folgemaßnahmen in einem Aufgabenverwaltungstool und kennzeichnen Sie Tickets zur einfachen Nachverfolgung mit Schweregrad und Datum.

Alle Aktionspunkte sollten umsetzbar, spezifisch und zeitlich begrenzt sein, um sicherzustellen, dass sie zu sinnvollen Verbesserungen führen und ähnliche Vorfälle in der Zukunft verhindern.

• Umsetzbar: Beginnen Sie mit einem klaren, richtungsweisenden Verb, um der verantwortlichen Person mitzuteilen, was zu tun ist. Seien Sie konkret und verwenden Sie Begriffe wie „implementieren“ oder „dokumentieren“ anstelle von vagen Formulierungen.
• Spezifisch: Definieren Sie den Umfang jedes Aktionselements detailliert, um Fehlinterpretationen oder Unklarheiten zu vermeiden. Geben Sie an, auf welche Systeme, Prozesse oder Teams sich die Aktion bezieht, und skizzieren Sie alle wichtigen Schritte, die durchgeführt werden müssen.
• Zeitlich begrenzt: Legen Sie klare Fristen oder Zieltermine für die Fertigstellung fest, um Aufgaben mit offenem Ende zu vermeiden.

Nachrichten

Es ist außerdem wichtig, Richtlinien für Folgenachrichten an Mitarbeiter und öffentliche Nachrichten an Kunden einzuschließen.

Interne E-Mail

Senden Sie nach der Vorfallsbesprechung eine interne E-Mail an die relevanten Mitarbeiter. Diese E-Mail sollte eine kurze Zusammenfassung des Vorfalls und einen Link zum vollständigen Post-Mortem-Dokument enthalten.

Überlegen Sie, welche Mitarbeiter diese Nachricht erhalten müssen. Bei einem größeren Ausfall oder einem unternehmensweiten Vorfall kann es angebracht sein, alle Mitarbeiter zu benachrichtigen, um Transparenz zu gewährleisten. Bei isolierten Vorfällen sollten Sie die Verteilung auf die direkt betroffenen Teams oder Abteilungen beschränken.

Überlegen Sie, ob die Nachricht auf verschiedene Zielgruppen zugeschnitten sein sollte. Selbst nach einem großflächigen Vorfall benötigen Teams, die direkt betroffen waren oder an der Nachverfolgung beteiligt sind, möglicherweise spezifische Anweisungen, die über die Anweisungen für das gesamte Unternehmen hinausgehen. Durch die Anpassung der Kommunikation können Sie sicherstellen, dass jede Gruppe die nächsten Schritte und ihre Rolle bei der Verhinderung zukünftiger Vorfälle versteht.

Externe Nachricht

Dies wird auf der Website erscheinen/ Statusseite Für Partner und Kunden. Entscheiden Sie, was Sie Kunden und Partnern mitteilen möchten, einschließlich des Vorfalls und der ergriffenen Maßnahmen. Nehmen Sie das Problem respektvoll zur Kenntnis und zeigen Sie Verständnis für die betroffenen Kunden.

Genau wie die interne Kommunikation können diese Nachrichten je nach Schwere des Vorfalls und den beteiligten Personen variieren.

Es kann auch hilfreich sein, ein Framework zu haben, anstatt bei Null anzufangen. Hier ist ein hilfreiches Postmortem-Vorlage .

Tipps zum Schreiben einer Obduktionsanalyse

Wir haben das grundlegende Framework zum Erstellen einer Postmortem-Analyse behandelt. Hier sind einige bewährte Vorgehensweisen, die Sie befolgen sollten.

DOS

• Dokumentieren Sie Ereignisse und Ergebnisse so genau wie möglich und detailliert. Beschreiben Sie Ereignisse und deren Hergang ehrlich und ehrlich.
• Besprechen Sie Lösungen, nicht nur Probleme. Mit anderen Worten: Trennen Sie das Geschehene von der Lösungsstrategie.
• Schreiben Sie umsetzbare Folgeaufgaben.
• Definieren Sie Sprache und Terminologie. Bedenken Sie, dass einige Teilnehmer oder Leser des Post-Mortem-Meetings möglicherweise neu sind. Stellen Sie daher sicher, dass jeder mit der Terminologie und den Abkürzungen vertraut ist.

Verbote

• Geben Sie Personen oder Teams die Schuld. Jemanden beim Namen zu nennen oder bloßzustellen, wird ihn nur verärgern, anstatt ihm die Möglichkeit zu geben, zu lernen und sich zu verbessern.
• Ändern Sie Details oder Ereignisse, um Ihr Gesicht zu wahren. Postmortems sind nur dann effektiv, wenn sie genaue Daten enthalten.
• Geben Sie menschlichem Versagen die Schuld. Oftmals sind mehrere Faktoren für einen Vorfall verantwortlich. Identifizieren Sie die zugrundeliegenden Ursachen.

Wer ist für die Erstellung der Postmortem-Analyse verantwortlich?

Der Einsatzleiter , in der Regel ein Mitglied des IT- oder DevOps-Teams, sollte einen der Responder als Verantwortlichen für die Postmortem-Analyse auswählen. Obwohl der Verantwortliche bei der Erstellung der Postmortem-Analyse mit anderen Respondern zusammenarbeiten kann, ist er im Wesentlichen für die Durchführung verantwortlich.

Der Obduktionsleiter ist verantwortlich für:

• Untersuchen Sie den Vorfall, um herauszufinden, was passiert ist.
• Erstellen Sie das Post-Mortem-Dokument und halten Sie es mit den neuesten Informationen auf dem neuesten Stand.
• Aktualisieren der öffentlich zugänglichen Website-Seite mit relevanten Informationen.
• Ansetzen des Post-Mortem-Meetings innerhalb einer bestimmten Anzahl von Tagen, abhängig von der Schwere des Vorfalls (innerhalb von drei Kalendertagen bei Sev-1 und fünf Werktagen bei Sev-2).

Eine erfolgreiche Postmortem-Analyse ist ein strategisches Instrument für kontinuierliches Wachstum, Resilienz und Verbesserung. Durch die sorgfältige Analyse aller Aspekte eines Vorfalls – von den Ursachen über die Lösung bis hin zu den Aktionspunkten – können Teams Herausforderungen in Chancen zur Verbesserung von Systemen und Prozessen verwandeln. Das Verständnis der Schritte und Prozesse einer detaillierten Postmortem-Analyse kann Teams dabei helfen, Vorfälle in Chancen für Lernen, Wachstum und Verbesserung zu verwandeln.

Entdecken Sie, wie PagerDuty Teams dabei unterstützt, Vorfälle souverän zu bewältigen und einen stabilen Betrieb aufzubauen. Starten Sie noch heute Ihre kostenlose 14-tägige Testversion .