Close

Vorfallmanagement für High-Velocity-Teams

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.

Handbuch zum Vorfallmanagement

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.


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

Wir bei Atlassian verfolgen alle Nachbereitungen in Form von Jira-Issues, um sicherzustellen, dass sie ordnungsgemäß durchgeführt und genehmigt werden. Wenn deine Anforderungen weniger komplex sind, kannst du auch ein einfacheres System nutzen, beispielsweise eine Confluence-Seite pro Nachbereitung.


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 ein Jira-Issue im Backlog des zuständigen Teams. Alle Nachbereitungsaktionen 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 ein Jira-Issue im Backlog der zuständigen Teams. Er verlinkt die jeweilige Aktion aus dem Nachbereitungs-Issue als "Aktion mit hoher Priorität" (zur Behebung grundlegender Ursachen) oder als "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 ein, bei dem wir . Wir verzichten bewusst auf Schuldzuweisungen.

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.

Bei diesem Meeting bemühen wir uns, die grundlegenden Ursachen des Vorfalls zu ermitteln und über Gegenmaßnahmen zu entscheiden.

Wenn die zuständigen Entwicklungsmanager nicht am Meeting teilnehmen, solltest du dich noch nicht auf bestimmte Aktionen festlegen, weil dies das Priorisieren erschwert. Die Teammitglieder fühlen sich dann unter Zugzwang, ohne dass sämtliche Informationen vorliegen. Wende dich stattdessen nach dem Meeting an die zuständigen Manager, um sie auf die Umsetzung der ermittelten Aktionen mit hoher Priorität zu verpflichten.


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.

Feld

Anweisungen

Beispiel

Zusammenfassung des Vorfalls

Fasse den Vorfall in einigen Sätzen zusammen. Die Zusammenfassung sollte den Schweregrad, die Begründung dafür und die Dauer der Auswirkungen beinhalten.

Am zwischen traten bei Kunden auf. Das Ereignis wurde durch ein Deployment um ausgelöst. Das Deployment enthielt eine Codeänderung für . Ein Bug in diesem Deployment führte zu .

Das Ereignis wurde von erkannt. Wir haben das Ereignis durch behoben.

Dieser Vorfall mit betraf X % der Kunden.

Zu diesem Vorfall wurden erstellt.

Ereignisse im Vorfeld

Beschreibe die Umstände, die zu diesem Vorfall geführt haben, beispielsweise vorangegangene Änderungen, durch die latente Bugs eingeführt wurden.

Am um , (), wurde eine Änderung an vorgenommen, um … . Die Änderung führte zu … .

Fehler

Beschreibe, was nicht wie erwartet funktioniert hat. Füge Screenshots von relevanten Diagrammen oder Daten an, die den Fehler zeigen.

Im Verlauf von wurden auf X % der Anfragen falsche Antworten gesendet.

Auswirkungen

Beschreibe, was interne und externe Kunden während des Vorfalls beobachtet haben. Gib an, wie viele Supporttickets erstellt wurden.

Am zwischen trat für auf.

Davon waren Kunden (X % aller Kunden von ) betroffen. Sie stellten fest.

Es wurden erstellt.

Erkennung

Wann und wie hat Atlassian den Vorfall erkannt?

Wie könnte die Erkennungszeit verbessert werden? Als Gedankenexperiment: Wie hättest du die Zeit halbieren können?

Der Vorfall wurde erkannt, als ausgelöst und benachrichtigt wurde. Weil dieses Team/diese Person nicht für den auf die Festplatte schreibenden Service zuständig war, musste zusätzlich benachrichtigt werden. Dies verzögerte die Reaktion um .

wird einrichten, damit .

Antwort

Wer hat wann wie reagiert? Gab es Verzögerungen oder Hindernisse bei der Reaktion?

Nachdem er um 14:34 Uhr UTC benachrichtigt wurde, betrat der KITT Engineer um 14:38 Uhr den Chatraum für den Vorfall. Der zuständige Engineer verfügte jedoch nicht über ausreichend Hintergrundwissen zum Escalator-System für die automatische Skalierung. Daher wurde um 14:50 Uhr eine weitere Benachrichtigung versendet, woraufhin um 14:58 Uhr ein erfahrener KITT Engineer den Chatraum betrat.

Wiederherstellung

Beschreibe, wie und wann der Service wiederhergestellt wurde. Wie bist du an den Punkt gelangt, an dem du wusstest, wie die Auswirkungen beseitigt werden können?

Je nach Szenario kannst du weitere Fragen beantworten: Wie könnte die Behebungszeit verbessert werden? Als Gedankenexperiment: Wie hättest du die Zeit halbieren können?

Die Wiederherstellung erfolgte im Rahmen einer dreiteiligen Reaktion:

  • Vergrößerung von BuildEng EC2 ASG, um die Anzahl der verfügbaren Knoten für den Service 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

Zeitlicher Ablauf

Gib den genauen zeitlichen Ablauf des Vorfalls in chronologischer Reihenfolge mit Zeitstempeln und Zeitzonen an.

Berücksichtige dabei mögliche Ereignisse im Vorfeld, den Beginn der Auswirkungen, den Zeitpunkt der Erkennung, Eskalationen, Entscheidungen, Änderungen und das Ende der Auswirkungen.

Alle Zeitangaben sind in UTC.

11:48 Uhr: Control-Plane-Upgrade auf K8S 1.9 fertiggestellt
12:46 Uhr: Goliath-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 300 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.

5-Why-Methode

Wende die Technik zur Ursachenermittlung an.

Beginne bei den Auswirkungen: Frage dich, warum sie aufgetreten sind und weshalb sie sich so geäußert haben. Frage weiter nach dem "Warum", bis du die grundlegende Ursache gefunden hast.

Dokumentiere deine Fragen und Antworten hier oder in einem dem Issue angefügten Diagramm.

  1. Der Service fiel aus, weil die Datenbank gesperrt wurde.

  2. Weil in der Datenbank zu viele Schreibvorgänge abliefen.

  3. Weil eine Änderung am Service vorgenommen wurde und die Steigerung unerwartet war.

  4. Weil wir keinen Entwicklungsprozess für Belastungstests bei Änderungen festgelegt haben.

  5. Wir haben noch nie Belastungstests durchgeführt und stehen vor neuen Dimensionen.

Grundlegende Ursache

Was war die grundlegende Ursache? Hier muss eine Änderung vorgenommen werden, damit Vorfälle dieser Art nicht mehr auftreten.

Ein Bug bei der Verarbeitung von Verbindungspools in führte zu Verbindungslecks bei Fehlerbedingungen. Außerdem war der Verbindungsstatus nicht mehr transparent.

Backlog-Überprüfung

Enthält dein Backlog eine Aufgabe, mit der dieser Vorfall hätte verhindert oder deutlich abgemildert werden können? Falls ja, warum wurde sie nicht umgesetzt?

Eine ehrliche Bewertung an diesem Punkt hilft, vergangene Entscheidungen über Prioritäten und Risiken zu klären.

An sich nicht. Verbesserungen bei der Typermittlung für Datenströme waren bekannte laufende Aufgaben, für die Rituale vorhanden waren (z. B. "Füge Datenstromtypen hinzu, wenn du eine Datei änderst/erstellst."). Es wurden Tickets für die Problembehebung bei Integrationstests erstellt. Versuche in dieser Richtung waren jedoch nicht erfolgreich.

Erneutes Auftreten

Ist dieser Vorfall (mit derselben grundlegenden Ursache) schon einmal aufgetreten? Falls ja, wie konnte es zu einer Wiederholung kommen?

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

Erkenntnisse

Was haben wir gelernt?

Besprich, was gut gelaufen ist, was besser hätte laufen können und wo ihr Verbesserungsmöglichkeiten einfach durch Glück gefunden habt.

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

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

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

Korrekturmaßnahmen

Was wird unternommen, damit Vorfälle dieser Art nicht mehr auftreten? Wer setzt diese Aktionen bis wann um?

Erstelle Vorgangsverlinkungen für "Aktionen mit hoher Priorität" zu Vorgängen, mit denen die einzelnen Aktionen verfolgt werden können.

  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

  4. Koordinierung großer Migrationen, weil AWS ES keine automatische Skalierung vornimmt

  5. Überprüfung der Tier-2-Klassifizierung der Stride-Suche

  6. Ticket erstellen, damit pf-directory-service nur teilweise statt vollständig ausfällt, wenn xpsearch-chat-searcher fehlschlägt

  7. CloudWatch-Benachrichtigung zur Ermittlung eines Problems mit erhöhten E/A im Elasticsearch-Cluster


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:

Szenario Unmittelbare Ursache und Aktion Grundlegende Ursache Beseitigung der grundlegenden Ursache

Das "Red Dawn"-Squad von Stride hatte für seine Services keine Datadog-Überwachungen und Benachrichtigungen eingerichtet oder diese waren nicht richtig konfiguriert.

Die Teammitglieder hatten für neue Services keine Überwachung und keine Benachrichtigungen konfiguriert.

Hole dies nach.

Es gibt keinen Prozess zur Einrichtung neuer Services, der auch die Überwachung und Benachrichtigungen beinhaltet.

Erstelle einen Prozess zur Einrichtung neuer Services und vermittle dem Team, dass es diesen Prozess befolgen muss.

Stride ist in IE11 nicht nutzbar, weil ein Fabric Editor-Upgrade in dieser Browserversion nicht funktioniert.

Upgrade einer Abhängigkeit.

Setze das Upgrade zurück.

Die Kompatibilität wird nicht browserübergreifend getestet.

Richte automatische kontinuierliche Tests für die browserübergreifende Kompatibilität ein.

Protokolle von Micros EU erreichten den Protokollierungsservice nicht.

Die Rolle, die Micros zum Senden von Protokollen erhalten hatte, war falsch.

Berichtige die Rolle.

Wir erfahren es nicht, wenn die Protokollierung bei einer Umgebung nicht funktioniert.

Füge Überwachungs- und Benachrichtigungsfunktionen für fehlende Protokolle aus allen Umgebungen hinzu.

Ausgelöst durch einen vorangegangenen AWS-Vorfall lasteten die Confluence Vertigo-Knoten ihren Verbindungspool zu Media zu stark aus, wodurch es für Kunden zu vorübergehenden Fehlern bei Anhängen und Medien kam.

AWS-Fehler.

Sieh dir die Ergebnisse der AWS-Nachbereitung an.

Ein Bug bei der Verarbeitung von Verbindungspools in Confluence führte zu Verbindungslecks bei Fehlerbedingungen. Außerdem war der Verbindungsstatus nicht mehr transparent.

Behebe den Bug und füge Überwachungsfunktionen hinzu, mit denen ähnliche Situationen künftig erkannt werden, bevor sie sich auswirken.


Kategorien für grundlegende Ursachen und zugehörige Aktionen

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

Kategorie

Definitionen

Was sollte unternommen werden?

Bug

Eine von Atlassian vorgenommene Codeänderung (eine bestimmte Art von Änderung)

Führe Tests durch. Führe Canary-Tests durch. Nimm inkrementelle Rollouts vor und beobachte diese. Nutze Feature Flags. Sprich mit dem für die Qualitätssicherung zuständigen Engineer.

Änderung

Eine von Atlassian vorgenommene Änderung (jedoch keine Codeänderung)

Verbessere deine Vorgehensweise bei Änderungen, beispielsweise die Reviews für Änderungen oder die Prozesse beim Änderungsmanagement. Alle unter "Bug" genannten Punkte gelten auch hier.

Skalierung

Mangelnde Skalierung (z. B. wegen unbemerkter Ressourceneinschränkungen oder mangelnder Kapazitätsplanung)

Welche Ressourceneinschränkungen gelten für deinen Service? Werden diese überwacht und sind Benachrichtigungen eingerichtet? Wenn noch kein Kapazitätsplan vorhanden ist, erstelle einen. Wenn ein Plan vorhanden ist: Welche neuen Einschränkungen müssen berücksichtigt werden?

Architektur

Diskrepanz zwischen Design und Betriebsbedingungen

Überprüfe das Design. Solltest du die Plattform wechseln?

Abhängigkeit

Fehler beim Service eines Drittanbieters (d. h. nicht bei Atlassian)

Managst du das Risiko von Fehlern bei Drittanbietern? Hat sich das Unternehmen entschieden, Risiken zu akzeptieren, oder sind Maßnahmen zur Risikominderung erforderlich? Siehe "Grundlegende Ursachen im Zusammenhang mit Abhängigkeiten" unten.

Unbekannt

Nicht zu ermitteln (die Aktion besteht in der Erweiterung der Diagnosemöglichkeiten)

Verbessere die Beobachtungsmöglichkeiten für dein System, indem du beispielsweise Funktionen für Protokollierung, Überwachung und Debugging hinzufügst.


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.

Kategorie Zu stellende Frage Beispiele

Untersuchung dieses Vorfalls

"Welches Ereignis hat diesen Vorfall verursacht und welchen Grund hatte es?" Letztlich geht es darum, die grundlegende Ursache zu ermitteln.

Analyse von Protokollen, Erstellung von Diagrammen zum Anfragepfad, Überprüfung von Heap-Dumps

Abmilderung dieses Vorfalls

"Welche sofortigen Maßnahmen haben wir ergriffen, um dieses konkrete Ereignis zu erledigen und zu managen?"

Rollbacks, "Cherry Picking", Push-Übertragung von Konfigurationen, Kommunikation mit betroffenen Benutzern

Behebung von Schäden aus diesem Vorfall

"Wie haben wir unmittelbare oder Kollateralschäden aus diesem Vorfall behoben?"

Wiederherstellung von Daten, Reparatur von Systemen, Entfernung von Umleitungen für den Datenverkehr

Erkennung künftiger Vorfälle

Wie können wir die zur präzisen Erkennung eines künftigen ähnlichen Vorfalls benötigte Zeit reduzieren?

Überwachung, Benachrichtigung, Plausibilitätsprüfungen für den Input/Output

Abmilderung künftiger Vorfälle

"Wie können wir den Schweregrad und/oder die Dauer künftiger ähnlicher Vorfälle verringern?"

"Wie können wir den von einem Vorfall dieser Art betroffenen Prozentsatz der Benutzer beim nächsten Mal reduzieren?"

Geplante Leistungsminderung, Verwerfen nicht kritischer Ergebnisse, Fail-Open, Optimierung der aktuellen Verfahren mit Dashboards/Playbooks, Änderungen an den Prozessen zum Umgang mit Vorfällen

Verhinderung künftiger Vorfälle

"Wie können wir verhindern, dass ein Fehler dieser Art erneut auftritt?"

Stabilitätsverbesserungen für die Codebasis, gründlichere Unit-Tests, Input-Validierung und Robustheit gegenüber Fehlerbedingungen, Bereitstellungsänderungen

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.

Nicht gut Besser

Untersuche die Überwachung für dieses Szenario.

(Umsetzbar) Füge Benachrichtigungsfunktionen für alle Fälle hinzu, in denen dieser Service > 1 % Fehler zurückgibt.

Behebe den Fehler, der den Ausfall verursacht hat.

(Konkret) Sorge dafür, dass ungültige Angaben zur Postleitzahl in Benutzeradressformularen sicher verarbeitet werden.

Bitte den Engineer, vor dem Aktualisieren zu überprüfen, ob das Datenbankschema geparst werden kann.

(Begrenzt) Füge für Schemaänderungen eine automatische Prüfung vor der Übermittlung hinzu.


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.