Nachbereitung von Vorfällen

Wir bei Atlassian nutzen die Nachbereitung ohne Schuldzuweisungen, um die grundlegende Ursache von Vorfällen mit einem Schweregrad von mindestens 2 zu ermitteln und zu beheben. Hier findest du eine Zusammenfassung unserer internen Dokumentation zur Nachbereitung bei Atlassian.

Was ist eine Post-Mortem-Analyse?

Das Ergebnis der Nachbereitung ist die Aufzeichnung eines Vorfalls, in der Folgendes erläutert wird:

• Auswirkungen des Vorfalls

• Zur Minderung oder Erledigung des Vorfalls durchgeführte Aktionen

• Grundlegende Ursache des Vorfalls

• Nachbereitungsaktionen, die ein erneutes Auftreten des Vorfalls verhindern sollen

Bei Atlassian verfolgen wir alle Post-Mortem-Analysen mithilfe von Jira-Vorgängen, um sicherzustellen, dass sie abgeschlossen und genehmigt sind. Wenn deine Anforderungen weniger komplex sind, kannst du auch ein einfacheres System nutzen, beispielsweise eine Confluence-Seite pro Post-Mortem-Analyse.

Warum führen wir eine Nachbereitung durch?

Die Nachbereitung hat das Ziel, alle grundlegenden Ursachen zu ermitteln, den Vorfall zu Referenzzwecken und zur Erkennung von Mustern zu dokumentieren sowie effektive Aktionen festzulegen, um die Wahrscheinlichkeit oder die Auswirkungen eines erneuten Auftretens zu verringern.

Wenn Post-Mortem-Analysen ein erneutes Auftreten des Vorfalls effektiv verhindern sollen, muss der Review-Prozess den Teams Anreize zur Ermittlung und Beseitigung der grundlegenden Ursachen liefern. Wie du dazu genau vorgehst, hängt von eurer Teamkultur ab. Die bei Atlassian für die Incident Response zuständigen Teams nutzen eine Kombination aus folgenden Methoden: 

• Persönliche Meetings tragen zur effektiven Analyse und zur Abstimmung des Teams über geeignete Maßnahmen bei.

• Wenn die Nachbereitung von den Managern der Bereitstellungs- und Operations-Teams genehmigt werden muss, ist dies für die Teams ein Anreiz für gründliches Arbeiten.

• Für die angegebenen "Aktionen mit hoher Priorität" wird ein Service-Level-Ziel (Service Level Objective, SLO) vereinbart, das je nach Service vier oder acht Wochen beträgt. Erinnerungen und Berichte sorgen dafür, dass die Aktionen tatsächlich durchgeführt werden.

Damit dieser Prozess eingehalten wird und effektiv wirkt, müssen sich Mitarbeiter auf allen Unternehmensebenen dafür einsetzen. Die Leiter und Manager unserer Entwicklungsteams haben die Genehmiger und SLOs für die Durchführung der Aktionen in ihren Zuständigkeitsbereichen festgelegt. Dieses System dient nur dazu, ihre Entscheidungen offiziell festzuhalten und umzusetzen.

Wann ist eine Nachbereitung erforderlich?

Wir führen bei Vorfällen mit Schweregrad 1 oder 2 eine Nachbereitung durch. Bei anderen Schweregraden ist sie optional.

Während oder kurz nach der Lösung des Issues erstellt der Nachbereitungsverantwortliche ein neues Nachbereitungs-Issue.

Wer übernimmt die Nachbereitung?

Das für den ausgefallenen Service zuständige Bereitstellungsteam (das Team, das im Vorfalls-Issue für den "fehlerhaften Service" zuständig ist) trägt die Verantwortung für die Durchführung der Nachbereitung. Das Team wählt den Nachbereitungsverantwortlichen aus und weist ihm das Nachbereitungs-Issue zu.

• Der Post-Mortem-Verantwortliche leitet die Post-Mortem-Analyse vom Entwurf über die Genehmigung bis zur Veröffentlichung. Er ist für die Durchführung der Post-Mortem-Analyse verantwortlich. 

• Nachbereitungsgenehmiger (einer oder mehrere) prüfen und genehmigen die Nachbereitung. Von ihnen wird erwartet, Nachbereitungsaktionen in ihrem Backlog zu priorisieren.

Wir pflegen eine Confluence-Seite, auf der die (obligatorischen und optionalen) Nachbereitungsgenehmiger nach Servicegruppe aufgeführt sind. In der Regel entspricht die Servicegruppe einem Atlassian-Produkt (z. B. Bitbucket Cloud).

Wie werden Aktionen zur Nachbereitung verfolgt?

Für jede Aktion, die sich aus der Nachbereitung ergibt, gehen wir wie folgt vor:

• Wir erstellen einen Jira-Vorgang im Backlog des zuständigen Teams. Alle Post-Mortem-Aktionen müssen in Jira verfolgt werden.

• Wir verlinken die Aktion aus dem Nachbereitungs-Issue als Aktion mit hoher Priorität (zur Behebung grundlegender Ursachen) oder als "Optimierungsaktion" (bei Optimierungsmaßnahmen für andere als die grundlegenden Ursachen).

Mit den REST-APIs von Jira haben wir einige angepasste Berichtsfunktionen erstellt, um verfolgen zu können, bei wie vielen Vorfällen der einzelnen Schweregrade die grundlegende Ursache nicht durch die Aktionen mit hoher Priorität aus der Nachbereitung behoben wurde. Die Manager der Entwicklungsteams der einzelnen Abteilungen prüfen diese Liste regelmäßig.

Nachbereitungsprozess

Zum Nachbereitungsprozess zählen das Erstellen eines Nachbereitungs-Issues, das Abhalten eines Nachbereitungsmeetings, das Erfassen von Aktionen, das Einholen von Genehmigungen und (optional) das Kommunizieren der Ergebnisse.

Der Nachbereitungsverantwortliche ist für die Umsetzung folgender Aufgaben zuständig:

1. Er erstellt die Nachbereitung und verlinkt sie mit dem Vorfall.

2. Er bearbeitet das Nachbereitungs-Issue, liest die Feldbeschreibungen und füllt die Felder aus.

3. Er verfolgt mithilfe der "5 Warum-Fragen" die Kausalkette, bis er eine plausible grundlegende Ursache für den Vorfall findet. 

4. Er plant das Nachbereitungsmeeting und lädt das Bereitstellungsteam, die betroffenen Teams und andere Verantwortliche ein (unter Verwendung der Vorlage für Meetingeinladungen).

5. Er trifft sich mit dem Team und bespricht den unten genannten Meetingzeitplan.

6. Er wendet sich erneut an die zuständigen Entwicklungsmanager, um sie auf bestimmte Aktionen zu verpflichten, mit denen Vorfälle dieser Art verhindert werden können.

7. Er erstellt zu jeder Aktion einen Jira-Vorgang im Backlog der zuständigen Teams. Er verknüpft die jeweilige Aktion aus dem Post-Mortem-Vorgang als "Priority Action" (Aktion mit hoher Priorität) (zur Behebung grundlegender Ursachen) oder als "Improvement Action" (Optimierungsaktion) (bei anderweitigen Optimierungsmaßnahmen).

8. Er sieht in Confluence nach, wer die zuständigen Genehmiger sind, und trägt diese im "Genehmiger"-Feld der Post-Mortem-Analyse ein. 

9. Er wählt den Übergang zum Anfordern der Genehmigung aus, um die Genehmigung der benannten Genehmiger einzuholen. Per Automatisierung wird der Vorgang mit Kommentaren versehen, die Anweisungen für die Genehmiger enthalten. 

10. Er treibt die Nachbereitung je nach Bedarf weiter voran, bis sie genehmigt wurde.

11. Nach Genehmigung der Nachbereitung wird in Confluence automatisch ein Entwurf für einen Blog zur Nachbereitung erstellt, den der IM nur noch bearbeiten und veröffentlichen muss. Durch die Verbreitung der Nachbereitungsergebnisse als Blog teilt er die hart erarbeiteten Erkenntnisse und steigert so ihren Nutzen.

Nach Abschluss des Nachbereitungsprozesses werden die Aktionen vom Entwicklerteam im Rahmen seines normalen Backlogs gemäß dem SLO des Teams priorisiert.

Nachbereitungsmeetings

Unserer Erfahrung nach werden die grundlegenden Ursachen eines Vorfalls genauer analysiert, wenn das Team zu einem Meeting zusammenkommt und seine Erkenntnisse diskutiert. Da unsere Teams in der Regel über mehrere Standorte verteilt sind, halten wir das Meeting oft als Videokonferenz ab. Wenn große Personengruppen an einem Vorfall beteiligt sind, veranstalten wir manchmal auch Gruppenmeetings.

Unser Vorschlag zur Agenda:

1. Erinnere das Team daran, dass und weshalb bei der Nachbereitung keine Schuldzuweisungen geäußert werden sollen.

2. Bestätige den zeitlichen Ablauf der Ereignisse.

3. Bestätige die grundlegenden Ursachen.

4. Ermittle durch "offenes Denken" mögliche Aktionen: "Was könnten wir tun, um Vorfälle dieser Art künftig zu verhindern?"

5. Frage das Team, was gut gelaufen ist, was besser hätte laufen können und wo ihr einfach Glück hattet.

Vorschlag zur Vorlage für eine Kalendereinladung:

Hiermit lade ich dich zu einer Nachbereitung von <Link zum Vorfall> ein, bei dem wir <Zusammenfassung des Vorfalls>. Wir verzichten bewusst auf Schuldzuweisungen.

Felder von Nachbereitungs-Issues

Unser Issue für die Nachbereitung beinhaltet viele Felder, damit wir vor dem Nachbereitungsmeeting alle wichtigen Details zum Vorfall sammeln können. Unten findest du Beispiele, wie wir diese Felder ausfüllen.

Unmittelbare und grundlegende Ursachen

Beim Verfassen und Lesen der Ergebnisse einer Nachbereitung muss zwischen unmittelbaren und grundlegenden Ursachen unterschieden werden.

• Unmittelbare Ursachen sind Faktoren, die direkt zu diesem Vorfall geführt haben.

• Grundlegende Ursachen sind Punkte an einer strategischen Stelle in der Ereigniskette, an denen eine Änderung Vorfälle dieser Art komplett verhindern könnte.

Bei einer Post-Mortem-Analyse gilt es, grundlegende Ursachen zu ermitteln und zu entscheiden, wie diese am besten beseitigt werden können. Diese strategische Stelle in der Ereigniskette zu finden, ist die wahre Kunst bei einer Post-Mortem-Analyse. Mit einer Technik wie den 5 Warum-Fragen kannst du dich entlang der Kette "nach oben hangeln", um die grundlegenden Ursachen zu finden. 

Hier einige ausgewählte Beispiele für unmittelbare und grundlegende Ursachen:

Kategorien für grundlegende Ursachen und zugehörige Aktionen

Wir gruppieren grundlegende Ursachen in die folgenden Kategorien und besprechen die jeweils angemessenen Aktionen. 

Grundlegende Ursachen im Zusammenhang mit Abhängigkeiten

Wenn bei deinem Service wegen eines Fehlers bei einer Abhängigkeit ein Vorfall auftritt, hängen die Zuständigkeit für den Fehler und die grundlegende Ursache des Vorfalls davon ab, ob es sich um eine interne Abhängigkeit von Atlassian oder um eine Drittanbieterabhängigkeit handelt und welche Erwartungen vernünftigerweise an die Leistung der Abhängigkeit gerichtet werden können.

Wenn es sich um eine interne Abhängigkeit handelt, stelle dir die Frage nach dem Service-Level-Ziel (Service Level Objective, SLO) der Abhängigkeit:

• Wurde gegen das SLO der Abhängigkeit verstoßen? 

  • Der Fehler liegt bei der Abhängigkeit. Ihre Zuverlässigkeit muss erhöht werden.

• Gab es einen Fehler bei deinem Service, obwohl das SLO der Abhängigkeit eingehalten wurde? 

  • Die Stabilität deines Service muss erhöht werden.

• Liegt kein SLO für die Abhängigkeit vor?

  • Ein SLO ist unbedingt erforderlich!

Wenn es sich um eine Drittanbieterabhängigkeit handelt, stelle dir die Frage, welche (angemessenen) Erwartungen* ihr an die Verfügbarkeit/Latenz/etc. der Drittanbieterabhängigkeit habt:

• Hat die Drittanbieterabhängigkeit eure Erwartungen nicht erfüllt?

  • Unsere Erwartungen waren falsch. 

    • Seid ihr überzeugt, dass dies nicht erneut geschehen wird? Ihr überprüft und akzeptiert beispielsweise die RCA des Drittanbieters. In diesem Fall ist die RCA des Drittanbieters die Aktion.

    • Oder müsst ihr eure Erwartungen anpassen? In diesem Fall bestehen die Aktionen darin, die Stabilität auf eurer Seite zu erhöhen und eure Erwartungen anzupassen.

    • Sind eure angepassten Erwartungen inakzeptabel? In diesem Fall müsst ihr die Diskrepanz zwischen den Anforderungen und der Lösung irgendwie beheben, beispielsweise indem ihr einen anderen Anbieter wählt.

• Gab es einen Fehler bei eurem Service, obwohl die Drittanbieterabhängigkeit eure Erwartungen erfüllt hat? 

  • In diesem Fall müsst ihr die Stabilität eures Service erhöhen.

• Habt ihr eigentlich gar keine Erwartungen?

  • Der für die Drittanbieterabhängigkeit zuständige Mitarbeiter muss dies festhalten und den Teams mitteilen, damit sie wissen, wie stabil sie ihre abhängigen Services gestalten müssen.

* Warum sprechen wir von "Erwartungen"? Haben wir keine SLAs mit Drittanbietern? In der Praxis sind die vertraglich mit den Drittanbietern festgelegten SLAs zu niedrig angesetzt, um bei der Fehlersuche und -behandlung hilfreich zu sein. AWS veröffentlicht beispielsweise fast gar kein SLA für EC2. Daher müssen wir im Fall einer Abhängigkeit vom Service eines Drittanbieters entscheiden, welches Maß an Zuverlässigkeit, Verfügbarkeit, Leistung oder anderen wichtigen Metriken wir vernünftigerweise von diesem Anbieter erwarten. 

Nachbereitungsaktionen

Sue Lueder und Betsy Beyer von Google haben eine hervorragende Präsentation und einen Artikel zu Aufgaben bei der Nachbereitung erstellt, die wir bei Atlassian als Leitfaden für Fragen an das Team nutzen.

Gehe die unten aufgeführten Fragen durch, um sicherzustellen, dass beim Review nach Vorfällen sowohl kurzfristige als auch langfristige Problembehebungen abgedeckt werden.

Die Punkte "Abmilderung künftiger Vorfälle" und "Verhinderung künftiger Vorfälle" sind wahrscheinlich die wichtigsten Quellen für Aktionen zur Behandlung der grundlegenden Ursache. Achte darauf, dass mindestens eine dieser Kategorien behandelt wird.

Auch beim Formulieren unserer Nachbereitungsaktionen halten wir uns an die Ratschläge von Lueder und Beyer.

Formulieren von Nachbereitungsaktionen

Die Formulierung kann darüber entscheiden, ob eine Nachbereitungsaktion schnell und leicht umgesetzt oder aufgrund mangelnder Umsetzbarkeit oder andauerndem Aufschieben immer weiter hinausgezögert wird. Eine sorgfältig ausgearbeitete Nachbereitungsaktion sollte folgende Eigenschaften aufweisen:

Umsetzbar: Formuliere jede Aktion als Satz, an dessen Anfang ein Verb steht. Die Aktion sollte zu einem nützlichen Ergebnis führen, nicht zu einem Prozess. Beispiel: "Erstelle eine Liste der kritischen Abhängigkeiten" ist eine gut formulierte Aktion, "Untersuche die Abhängigkeiten" dagegen nicht.

Konkret: Grenze den Umfang der einzelnen Aktionen so eng wie möglich ein. Stelle klar, was Teil der Aufgabe ist und was nicht.

Begrenzt: Gib zu jeder Aktion an, wann sie als fertig umgesetzt gilt, statt das Ende offen zu lassen oder fortlaufende Aktionen vorzugeben.

Genehmigungen bei der Nachbereitung

Atlassian sorgt mithilfe eines Jira-Workflows mit Genehmigungsschritt dafür, dass Nachbereitungsergebnisse genehmigt werden. In der Regel sind die Genehmiger die Service Owner oder andere für den Betrieb eines Service zuständige Manager. Die Genehmigung der Nachbereitungsergebnisse bedeutet:

• Zustimmung zu den Erkenntnissen aus dem Review nach dem Vorfall, u. a. hinsichtlich der grundlegenden Ursache

• Zustimmung zu den verlinkten "Aktionen mit hoher Priorität" als akzeptable Möglichkeit zur Beseitigung der grundlegenden Ursache

Oft fordern unsere Genehmiger zusätzliche Aktionen an oder erkennen eine Kausalkette, die von den vorgeschlagenen Aktionen nicht abgedeckt wird. So steigern Genehmigungen deutlich den Wert unseres Nachbereitungsprozesses bei Atlassian.

Bei Teams mit einer geringeren Anzahl von Vorfällen oder einer weniger komplexen Infrastruktur ist eine Genehmigung der Nachbereitungsergebnisse möglicherweise nicht erforderlich.

Nachbereitung ohne Schuldzuweisungen

Wenn etwas schiefgeht, neigen die meisten Menschen dazu, einen Schuldigen zu suchen. Atlassian bemüht sich sehr, dies zu vermeiden. Darauf musst du bei der Nachbereitung gezielt achten. Wir gehen davon aus, dass unsere Mitarbeiter immer in guter Absicht handeln, und beschuldigen niemanden, wenn Fehler passieren. Bei der Nachbereitung müssen die Umstände, die zu dem Fehler geführt haben, ehrlich und objektiv untersucht werden. Nur so ist es möglich, die wahren grundlegenden Ursachen zu finden und zu beseitigen. Schuldzuweisungen behindern dies aus folgenden Gründen:

• Wenn Mitarbeiter ihr gutes Ansehen bei Kollegen oder Vorgesetzten gefährdet sehen, wiegen diese Bedenken in der Regel für sie schwerer als "die besten Unternehmensinteressen meines Arbeitgebers". Deshalb versuchen sie in einer solchen Situation meist, die Wahrheit zu verbergen oder zu vertuschen, um ihre eigenen Bedürfnisse zu schützen.

• Selbst wenn eine Handlung eines Mitarbeiters direkt zu einem Vorfall geführt hat, sollten wir nicht fragen, warum er sich so verhalten hat, sondern weshalb das System dies nicht verhindert hat oder den Mitarbeiter glauben ließ, er handle richtig.

• Jemandem die Schuld zu geben, ist unfreundlich und führt oft zu einer Kultur der Angst und des Misstrauens. 

Bei der Nachbereitung schaffen wir mit folgenden Techniken persönliche Sicherheit für alle Beteiligten:

• Erkläre gleich zu Beginn des Post-Mortem-Analyse-Meetings, dass keine Schuldzuweisungen erfolgen sollen, und begründe dies. 

• Benutze Rollenbezeichnungen (z. B. "der zuständige Widgets-Engineer") statt Namen (wobei die Fakten dennoch klar und unmissverständlich dargelegt werden müssen).

• Achte darauf, dass der zeitliche Ablauf des Vorfalls, die Kausalkette und die Problembehebungsmaßnahmen in den Kontext von Systemen, Prozessen und Rollen statt von Personen gestellt werden.

Die Anregung für eine Nachbereitung ohne Schulzuweisungen und das hilfreiche Konzept der "Geschichte hinter der Geschichte" (second stories) stammt aus dem bahnbrechenden Artikel von John Allspaw.

Das Handbuch in gedruckter Form oder als PDF

Wir haben eine begrenzte Auflage unseres Handbuchs zum Vorfallmanagement drucken lassen und versenden diese Handbücher kostenlos. Alternativ kannst du die PDF-Version herunterladen.

Handbuch herunterladen