Vorlage: Nachbearbeitung und Störungsanalyse

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:

Im Zeitraum von {Uhrzeit des Vorfalls, z. B. 15:45 bis 16:35 Uhr} am {DATUM} verzeichneten {ANZAHL} Benutzer {EREIGNISSYMPTOME}.

Das Ereignis wurde um {ZEITPUNKT DER ÄNDERUNG, DIE DAS EREIGNIS VERURSACHT HAT} durch {ÄNDERUNG} ausgelöst.

Die {ÄNDERUNG} umfasste {BESCHREIBUNG ODER GRUND DER ÄNDERUNG, z. B. eine Änderung des Codes zum Update eines Systems}.

Ein Bug in diesem Code verursachte {BESCHREIBUNG DES PROBLEMS}.

Das Ereignis wurde von {ÜBERWACHUNGSSYSTEM} erkannt. Wir haben das Ereignis durch {DURCHGEFÜHRTE AKTIONEN ZUR PROBLEMLÖSUNG} behoben.

Dieser Vorfall mit {SCHWEREGRAD} betraf {X %} der Benutzer.

Aufgrund dieses Vorfalls gab es weitere Auswirkungen, wie {z. B. ANZAHL DER EINGEREICHTEN SUPPORTTICKETS, SOCIAL-MEDIA-ERWÄHNUNGEN, ANRUFE AN ACCOUNT MANAGER} in Bezug auf diesen 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 Uhr} am {MM/TT/JJ}, ({ZEITRAUM VOR DEN AUSWIRKUNGEN AUF KUNDEN, z. B. 10 Tage vor dem fraglichen Vorfall}), wurde eine Änderung an {PRODUKT ODER SERVICE} eingeführt, um {DIE ÄNDERUNGEN, DIE ZU DEM VORFALL GEFÜHRT HABEN}.

Diese Änderung führte zu {BESCHREIBUNG DER AUSWIRKUNGEN DER ÄNDERUNG}.

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:

{ANZAHL} Antworten wurden irrtümlich an {XX %} der Anfragen gesendet, über einen Zeitraum von {ZEITRAUM}.

Auswirkungen

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

Beispiel:

Unsere Benutzer erlebten den Vorfall {ZUSAMMENFASSUNG DES VORFALLS} am {MM/TT/JJ} von {XX:XX UTC bis XX:XX UTC} für die Dauer von {XX Std. XX Min.}.

Dieser Vorfall betraf {XX} Kunden (X % der Benutzer von {SYSTEM ODER SERVICE}), die folgende Symptome erlebten: {BESCHREIBUNG DER SYMPTOME}.

{ANZAHL DER SUPPORTTICKETS UND ANZAHL VON SOCIAL-MEDIA-BEITRÄGEN} wurden eingereicht.

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 {WARNMELDUNGSTYP} ausgelöst und {TEAM/PERSON} benachrichtigt wurde.

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

{BESCHREIBUNG DER VERBESSERUNG} wird vom {BESITZERTEAM DER VERBESSERUNG} umgesetzt, damit {ERWARTETE VERBESSERUNG}.

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 {BEREITSCHAFTSMITARBEITER} um {XX:XX UTC} in {SYSTEM, IN DEM INFORMATIONEN ZUM VORFALL ERFASST WERDEN} online.

Dieser Mitarbeiter hatte keine genaueren Kenntnisse von {BETROFFENES SYSTEM}. Daher wurde um {XX:XX UTC} eine zweite Warnmeldung an {ESKALATION AN BEREITSCHAFTSMITARBEITER} 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:

{BESCHREIBE DIE MASSNAHMEN, DIE DAS PROBLEM GEMILDERT HABEN, WARUM SIE DURCHGEFÜHRT WURDEN UND DAS ERGEBNIS}

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

Zeitlicher Ablauf

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 bei der Verarbeitung von Verbindungspools in führte zu Verbindungslecks bei Fehlerbedingungen. Außerdem war der Verbindungsstatus nicht mehr transparent.

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