View a markdown version of this page

Verwendung der 5-Warum-Analyse in Vorfallberichten - Amazon CloudWatch

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwendung der 5-Warum-Analyse in Vorfallberichten

Bei der Erstellung von Vorfallberichten können die CloudWatch Ermittlungsbehörden eine Ursachenanalyse durchführen, um die zugrunde liegenden Ursachen betrieblicher Probleme systematisch zu ermitteln. Dieser strukturierte Ansatz erweitert Ihre Vorfallberichte um tiefere Einblicke und umsetzbare Abhilfemaßnahmen.

Diese Funktion verwendet Amazon Q, um einen Konversations-Chat bereitzustellen. Der Benutzer, der angemeldet ist, AWS-Managementkonsole muss über die folgenden Berechtigungen verfügen:

{ "Sid" : "AmazonQAccess", "Effect" : "Allow", "Action" : [ "q:StartConversation", "q:SendMessage", "q:GetConversation", "q:ListConversations", "q:UpdateConversation", "q:DeleteConversation", "q:PassRequest" ], "Resource" : "*" }

Sie können diese Berechtigungen direkt hinzufügen oder indem Sie entweder die oder die AIOpsOperatorAccess verwaltete Richtlinie an den Benutzer AIOpsConsoleAdminPolicy oder die Rolle anhängen.

Was ist eine 5-Warum-Analyse?

Bei der 5-Warum-Methode handelt es sich um eine Technik zur Ursachenanalyse, bei der wiederholt nach dem „Warum“ gefragt wird, um von den Symptomen des Vorfalls bis hin zu den grundlegenden Ursachen vorzudringen. Jede Antwort wird zur Grundlage für die nächste Frage, wodurch eine logische Kette entsteht, die die wahre Ursache und nicht nur oberflächliche Symptome aufdeckt.

Bei der Erstellung von Vorfallberichten verwenden die CloudWatch Untersuchungen diese Methode, um die Untersuchungsergebnisse zu analysieren und eine strukturierte Ursachenanalyse bereitzustellen, die über unmittelbare technische Ausfälle hinausgeht und Prozess-, Konfiguration- oder systemische Probleme identifiziert.

Vorteile der Meldung von Vorfällen

Die Aufnahme einer 5-Warum-Analyse in Vorfallberichte bietet mehrere Vorteile:

  • Umfassende Ursachenidentifikation — Geht über die unmittelbaren technischen Ursachen hinaus und identifiziert zugrundeliegende Prozess- oder Systemprobleme

  • Umsetzbare Behebungspläne — Bietet spezifische, gezielte Maßnahmen, um ein erneutes Auftreten zu verhindern, anstatt temporäre Lösungen zu finden

  • Organisatorisches Lernen — Dokumentiert die gesamte Kausalkette zum späteren Nachschlagen und Wissensaustausch im Team

  • Strukturierte Analyse — Sorgt für systematische Untersuchungen und nicht für spontane Problemlösungen

Beispielszenarien in Vorfallberichten

Vorfall mit einem Ausfall der Datenbankverbindung

Erster Vorfall: In der E-commerce Anwendung traten in der Regel 500 Fehler auf

  1. Grund 1: Warum erhalten Benutzer 500 Fehler? Die Anwendung kann keine Verbindung zur Primärdatenbank herstellen.

  2. Warum 2: Warum kann die Anwendung keine Verbindung zur Datenbank herstellen? Der Datenbankinstanz gingen die verfügbaren Verbindungen aus.

  3. Warum 3: Warum gingen der Datenbank die Verbindungen aus? Bei einer Stapelverarbeitung wurden viele Verbindungen geöffnet, ohne sie ordnungsgemäß zu schließen.

  4. Warum 4: Warum hat der Batch-Job Verbindungen nicht richtig geschlossen? Die Fehlerbehandlung des Jobs beinhaltet keine Verbindungsbereinigung in Fehlerszenarien.

  5. Warum 5: Warum wurde keine angemessene Fehlerbehandlung implementiert? Der Code-Review-Prozess beinhaltet keine spezifischen Prüfungen auf Muster im Ressourcenmanagement.

Hauptursache: Unangemessene Standards für die Codeüberprüfung für das Ressourcenmanagement

Empfohlene Maßnahmen: Aktualisieren Sie die Checkliste für die Codeüberprüfung, implementieren Sie die Überwachung des Verbindungspoolings, fügen Sie eine automatische Erkennung von Ressourcenlecks hinzu

Vorfall mit Leistungseinbußen

Erster Vorfall: Die API-Antwortzeiten wurden während der Datenverkehrsspitzen von 200 ms auf 5000 ms erhöht

  1. Grund 1: Warum haben sich die Antwortzeiten erhöht? Die CPU-Auslastung erreichte bei allen Anwendungsinstanzen 100%.

  2. Warum 2: Warum hat Auto Scaling keine weiteren Instanzen hinzugefügt? Auto Scaling wurde ausgelöst, aber neue Instanzen haben die Zustandsprüfungen nicht bestanden.

  3. Warum 3: Warum haben neue Instanzen die Zustandsprüfungen nicht bestanden? Der Startvorgang der Anwendung dauert 8 Minuten und ist damit länger als das Timeout bei der Systemdiagnose.

  4. Warum 4: Warum dauert der Start so lange? Die Anwendung lädt bei jedem Start große Konfigurationsdateien von S3 herunter.

  5. Warum 5: Warum wurde diese Startverzögerung bei der Auto-Scaling-Konfiguration nicht berücksichtigt? Die Leistungstests wurden mit vorgewärmten Instances durchgeführt, nicht mit Kaltstarts.

Hauptursache: Die Methodik der Leistungstests spiegelt nicht die Szenarien der automatischen Skalierung in der Produktion wider

Empfohlene Maßnahmen: Schließen Sie Kaltstarttests ein, optimieren Sie den Anwendungsstart, passen Sie die Timeouts für Integritätsprüfungen an und implementieren Sie das Konfigurations-Caching

Komplexer Vorfall mit Filialanalyse

Erster Vorfall: Bei OpenSearch serverlosen Kunden kam es 11 Stunden lang zu einer Beeinträchtigung der Verfügbarkeit um 48,3%

Hauptanalysekette:

  1. Grund 1: Warum kam es bei Kunden zu einer Verschlechterung des Serviceangebots? Die Serviceverfügbarkeit sank aufgrund einer falschen Ingester-Skalierung auf 48,3%.

  2. Warum 2: Warum war die Ingester-Skalierung falsch? CortexOperator Aufgrund einer Fehlberechnung der AZ-Balance wurde die Anzahl der Ingester von 223 auf 174 reduziert.

  3. Warum 3: Warum wurde der AZ-Saldo CortexOperator falsch berechnet? Der Code konnte nach dem Upgrade auf Version 1.17 keine neuen Kubernetes-Labelformate verarbeiten.

  4. Warum 4 (Zweig A — Technisch): Warum hat der Code keine neuen Labelformate verarbeitet? Der Code erwartete 'failure-domain.beta.kubernetes'. io/zone' Labels, aber Kubernetes 1.17 wurde in 'topology.kubernetes geändert. io/zone'.

  5. Warum 5 (Zweig A): Warum wurde keine Abwärtskompatibilität implementiert? Die Änderung des Labelformats wurde in den Upgrade-Hinweisen, die bei der Bereitstellungsplanung überprüft wurden, nicht dokumentiert.

Zweig B — Prozessanalyse:

  1. Warum 4 (Zweig B — Prozess): Warum wurde das beim Testen nicht erkannt? Bei den Integrationstests wurden vorkonfigurierte Cluster mit alten Labelformaten verwendet.

  2. Warum 5 (Zweig B): Warum beinhalteten die Tests keine Validierung des Labelformats? Die Einrichtung der Testumgebung entsprach nicht der Upgrade-Sequenz der Kubernetes-Produktionsversion.

Die Hauptursachen wurden identifiziert:

  • Technisch: Fehlende Abwärtskompatibilität für Änderungen am Kubernetes-Labelformat

  • Prozess: Die Testmethodik validiert nicht die Auswirkungen eines Versions-Upgrades

Integrierter Abhilfeplan: Implementieren Sie eine Logik zur Erkennung von Labelformaten, verbessern Sie die Upgrade-Testverfahren, fügen Sie eine automatische Kompatibilitätsüberprüfung hinzu und richten Sie einen Prozess zur Bewertung der Auswirkungen von Versionsänderungen ein.

Verwenden Sie den angeleiteten „5 Warum“ -Workflow

CloudWatch Investigations bietet einen geführten 5-Warum-Analyse-Workflow, der Ihnen hilft, fehlende Fakten zu beheben und Ihre Vorfallberichte zu verbessern. Diese Funktion wird als Workflow-Vorschlag angezeigt, wenn das System Möglichkeiten zur Verbesserung der Ursachenanalyse identifiziert.

Erfahrung mit interaktiver Analyse

Die 5-Warum-Analyse bei CloudWatch Ermittlungen verwendet einen interaktiven, chatbasierten Ansatz, der Sie durch den Ermittlungsprozess führt. Diese Konversationsmethode trägt dazu bei, eine umfassende Analyse sicherzustellen und gleichzeitig den logischen Fluss zwischen den Fragen aufrechtzuerhalten.

Hauptmerkmale des interaktiven Erlebnisses:

  • Fact-based Initialisierung — Das System präsentiert im Voraus relevante Fakten aus Ihrer Untersuchung und verwendet sie, um offensichtliche Antworten vorab auszufüllen und deutlich auf faktenbasierte und auf Schlussfolgerungen beruhende Vorschläge hinzuweisen

  • Geführte Sondierung — Für jede „Warum“ -Frage schlägt das System Antworten auf der Grundlage der verfügbaren Fakten vor, fordert spezifischen zusätzlichen Kontext an und leitet Sie an, wichtige Aspekte zu berücksichtigen, bevor Sie fortfahren

  • Filialmanagement — Wenn mehrere Faktoren identifiziert werden, die dazu beitragen, bietet das System klare Filialoptionen, erklärt die Beziehungen zwischen den Filialen und hilft bei der Priorisierung paralleler Untersuchungen

  • Progressive Validierung — Für jede Antwort formuliert das System die Antworten aus Gründen der Klarheit neu, sucht nach Bestätigung, hebt wichtige Erkenntnisse hervor und verknüpft die Ergebnisse mit einem breiteren Kontext

Dieser Ansatz stellt sicher, dass Sie alle relevanten Informationen erfassen und sich gleichzeitig auf die wichtigsten kausalen Zusammenhänge konzentrieren.

Zugriff auf den geführten Arbeitsablauf:

  1. Lesen Sie während der Erstellung des Vorfallberichts den Abschnitt Fakten, die Aufmerksamkeit erfordern, im rechten Bereich.

  2. Suchen Sie unter Vorgeschlagener Arbeitsablauf nach dem Vorschlag zur Guided 5-Whys-Analyse.

  3. Wählen Sie Guide me aus, um den interaktiven 5-Warum-Prozess zu starten.

  4. Folgen Sie den Anweisungen, um jede „Warum“ -Frage systematisch zu beantworten und eine vollständige Kausalkette von den Symptomen bis zur eigentlichen Ursache aufzubauen.

Der geführte Arbeitsablauf hilft Ihnen dabei, umfassende Informationen zur Grundursache zu erfassen, indem er Sie Schritt für Schritt durch die 5-Whys-Methode führt. Die Analyseergebnisse werden automatisch in Ihren Vorfallbericht aufgenommen und bieten so eine strukturierte Dokumentation für Überprüfungen nach einem Vorfall und für organisatorisches Lernen.

Sie können auch über die Chat-Oberfläche eine 5-Warum-Analyse anfordern, indem Sie Fragen wie „Führen Sie eine 5-Warum-Analyse für diesen Vorfall durch“ oder „Was ist die Ursache mithilfe der 5-Warum-Methode?“ stellen.

Umgang mit komplexen Vorfällen mit mehreren Ursachen

Bei einigen Vorfällen spielen mehrere Faktoren eine Rolle, weshalb parallele Analysepfade erforderlich sind. CloudWatch Untersuchungen unterstützen die Filialanalyse, um sicherzustellen, dass alle wichtigen Ursachen identifiziert und behoben werden.

Wenn eine Filialanalyse erforderlich ist:

  • Es traten mehrere unabhängige Fehler gleichzeitig auf

  • Verschiedene Systemkomponenten trugen zur gleichen Kundenwirkung bei

  • Sowohl technische Fehler als auch Prozessfehler spielten eine wichtige Rolle

  • Durch kaskadierende Fehler entstanden mehrere Kausalketten

Prozess der Filialanalyse:

  1. Identifizierung von Filialen — Das System identifiziert Punkte, an denen mehrere Ursachen zusammenlaufen oder divergieren

  2. Parallele Untersuchung — Jeder Zweig wird nach der vollständigen 5-Whys-Methode analysiert

  3. Verbindungsübersicht — Die Beziehungen zwischen den Filialen werden dokumentiert, um zu zeigen, wie sie interagieren

  4. Integrierte Problemlösung — In den Sanierungsplänen werden alle identifizierten Grundursachen und deren Wechselwirkungen berücksichtigt

Dieser umfassende Ansatz stellt sicher, dass komplexe Vorfälle gründlich analysiert werden und dass alle Faktoren, die dazu beitragen, im endgültigen Sanierungsplan berücksichtigt werden.

Bewährte Methoden für eine effektive 5-Warum-Analyse

Um die Effektivität der 5-Warum-Analyse in Ihren Vorfallberichten zu maximieren, sollten Sie sich an die folgenden Best Practices halten, die sich aus Betriebserfahrungen ergeben haben:

Richtlinien für die Formulierung von Fragen

  • Beginnen Sie mit den Auswirkungen auf den Kunden — Beginnen Sie jede Analyse mit dem Problem, mit dem der Kunde konfrontiert ist, um die Auswirkungen auf das Geschäft nicht aus den Augen zu verlieren

  • Erhöhen Sie schrittweise die technische Tiefe — Gehen Sie von den Auswirkungen auf das Geschäft zu den technischen Details über, während Sie die Fragen beantworten

  • Sorgen Sie für logische Kontinuität — Stellen Sie sicher, dass jede Antwort auf natürliche Weise ohne logische Lücken zur nächsten Frage führt

  • Fügen Sie unterstützende Beweise hinzu — Verweisen Sie auf bestimmte Kennzahlen, Protokolle oder Ereignisse im Zeitverlauf, um jede Antwort zu validieren

Validierung der Analyse

Validieren Sie Ihre 5-Warum-Analyse anhand dieser Kriterien:

  • Logischer Ablauf — Klare Progression von den Symptomen zur eigentlichen Ursache, ohne dass Schritte fehlen

  • Technische Genauigkeit — Korrekte Terminologie, genaue Beschreibungen des Systemverhaltens und gültige Interaktionen zwischen den Komponenten

  • Vollständigkeit — Die Analyse erklärt alle beobachteten Symptome und ermittelt eine grundlegende Ursache, die, wenn sie behoben wird, ein erneutes Auftreten verhindern würde

  • Umsetzbarkeit — Die identifizierte Grundursache führt zu spezifischen, umsetzbaren Abhilfemaßnahmen

Häufige Fallstricke, die es zu vermeiden gilt

  • Beenden Sie bei den Symptomen — Schließen Sie die Analyse nicht beim ersten technischen Ausfall ab, sondern fahren Sie fort, bis Sie systemische oder prozessbedingte Ursachen gefunden haben

  • Blame-focused Analyse — Konzentrieren Sie sich auf System- und Prozessfehler und nicht auf einzelne Maßnahmen

  • Single-path Denken — Berücksichtigen Sie mehrere Faktoren, die dazu beitragen, und verwenden Sie gegebenenfalls Branchenanalysen

  • Unzureichende Beweise — Stellen Sie sicher, dass jede Antwort durch konkrete Daten aus Ihrer Untersuchung gestützt wird

Integration in Abschnitte mit Berichten über Vorfälle

Die 5-Warum-Analyse lässt sich in andere Abschnitte Ihres Vorfallberichts integrieren, um eine umfassende Dokumentation bereitzustellen:

  • Zeitliche Korrelation — Jede „Warum“ -Frage kann sich auf bestimmte Ereignisse im Zeitverlauf beziehen und liefert so den zeitlichen Kontext für kausale Zusammenhänge

  • Überprüfung der Kennzahlen — Die Antworten werden durch Kennzahlen und Grafiken unterstützt, die das beschriebene technische Verhalten veranschaulichen

  • Ausrichtung der Folgenabschätzung — Das erste „Warum“ bezieht sich direkt auf die Kennzahlen zur Kundenauswirkung, die im Abschnitt zur Folgenabschätzung dokumentiert sind

  • Grundlage der gewonnenen Erkenntnisse — Die durch die Fünf-Warum-Analyse identifizierten Grundursachen fließen direkt in die Abschnitte „Gelernte Erkenntnisse“ und „Abhilfemaßnahmen“ ein

Diese Integration gewährleistet die Konsistenz Ihres gesamten Vorfallberichts und bietet allen Beteiligten eine vollständige, kohärente Darstellung von den ersten Symptomen über die Grundursache bis hin zu den Plänen zur Problembehebung.