Close

Der Weg zu einem besseren Vorfallmanagement beginnt hier

Vorlage: Nachbearbeitung und Störungsanalyse

Eine klare Dokumentation ist der Schlüssel zu effektiven Post-Mortem-Analysen von Vorfällen. Viele Teams verwenden eine umfangreiche Vorlage, um während jeder Post-Mortem-Analyse konsistente Details zu sammeln.


Unten findest du eine Beispielvorlage für Post-Mortem-Analysen von Vorfällen, die auf der in unserem Handbuch für Vorfälle beschriebenen Post-Mortem-Analyse basiert. Du kannst sie kopieren und zur Dokumentation deiner eigenen Post-Mortem-Analysen nutzen.

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 am erlebten Benutzer .

Das Ereignis wurde um durch <ÄNDERUNG> ausgelöst.

Die <ÄNDERUNG> umfasste .

Ein Bug in diesem Code verursachte .

Das Ereignis wurde von <ÜBERWACHUNGSSYSTEM> erkannt. Wir haben das Ereignis durch behoben.

Dieser Vorfall mit betraf der Benutzer.

Aufgrund dieses Vorfalls gab es weitere Auswirkungen, wie 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 , (), wurde eine Änderung an eingeführt, um .

Diese Änderung führte zu .

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:

Antworten wurden irrtümlich an der Anfragen gesendet, über einen Zeitraum von .

Auswirkungen

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

Beispiel:

Unsere Benutzer erlebten den Vorfall am von für die Dauer von .

Dieser Vorfall betraf Kunden (x % der Benutzer von ), die folgende Symptome erlebten: .

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 ausgelöst und benachrichtigt wurde.

Als nächstes wurde benachrichtigt, da nicht über die notwendige Berechtigung für den Service verfügte, was die Reaktion um verzögerte.

wird vom umgesetzt, damit .

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 ging um in online.

Dieser Mitarbeiter hatte keine genaueren Kenntnisse von . Daher wurde um eine zweite Warnmeldung an gesendet, der um 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:

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
Weiter geht's
Blameless