Utilizzo dell'analisi dei 5 motivi nei report sugli incidenti - Amazon CloudWatch
Cos'è l'analisi 5 Whys?Vantaggi della segnalazione degli incidentiScenari di esempio nei report sugli incidentiUtilizzo del flusso di lavoro guidato dei 5 perchéGestione di incidenti complessi con cause multipleLe migliori pratiche per un'analisi efficace dei 5 perché

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo dell'analisi dei 5 motivi nei report sugli incidenti

Quando si generano report sugli incidenti, CloudWatch le indagini possono eseguire un'analisi delle cause principali dei 5 motivi per identificare sistematicamente le cause alla base dei problemi operativi. Questo approccio strutturato migliora i report sugli incidenti con informazioni più approfondite e misure correttive attuabili.

Questa funzionalità utilizza Amazon Q per fornire una chat conversazionale. L'utente che ha effettuato l'accesso Console di gestione AWS deve disporre delle seguenti autorizzazioni:

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

È possibile aggiungere queste autorizzazioni direttamente o allegando la politica o la politica AIOpsOperatorAccessgestita all'utente AIOpsConsoleAdminPolicyo al ruolo.

Cos'è l'analisi 5 Whys?

The 5 Whys è una tecnica di analisi delle cause profonde che chiede ripetutamente il «perché», per passare dai sintomi incidenti alle cause fondamentali. Ogni risposta diventa la base per la domanda successiva, creando una catena logica che rivela la vera causa principale anziché limitarsi ai sintomi superficiali.

Durante la generazione di report sugli incidenti, CloudWatch le indagini utilizzano questo metodo per analizzare i risultati delle indagini e fornire un'analisi strutturata delle cause principali che va oltre i guasti tecnici immediati per identificare problemi di processo, configurazione o sistemici.

Vantaggi della segnalazione degli incidenti

L'inclusione dell'analisi dei 5 motivi nei report sugli incidenti offre diversi vantaggi:

  • Identificazione completa delle cause principali: va oltre le cause tecniche immediate per identificare i problemi di processo o di sistema sottostanti

  • Piani di riparazione attuabili: fornisce azioni specifiche e mirate per prevenire il ripetersi piuttosto che correzioni temporanee

  • Apprendimento organizzativo - Documenta la catena causale completa per riferimenti futuri e condivisione delle conoscenze del team

  • Analisi strutturata: garantisce un'indagine sistematica anziché una risoluzione di problemi ad hoc

Scenari di esempio nei report sugli incidenti

Incidente di connessione al database

Incidente iniziale: applicazione di e-commerce con 500 errori diffusi

  1. Perché 1: Perché gli utenti ricevono 500 errori? L'applicazione non può connettersi al database primario.

  2. Perché 2: Perché l'applicazione non riesce a connettersi al database? L'istanza del database ha esaurito le connessioni disponibili.

  3. Perché 3: Perché il database ha esaurito le connessioni? Un processo di elaborazione in batch ha aperto molte connessioni senza chiuderle correttamente.

  4. Perché 4: Perché il processo batch non ha chiuso correttamente le connessioni? La gestione degli errori del processo non include la pulizia della connessione in scenari di errore.

  5. Perché 5: Perché non è stata implementata la corretta gestione degli errori? Il processo di revisione del codice non include controlli specifici per i modelli di gestione delle risorse.

Causa principale: standard di revisione del codice inadeguati per la gestione delle risorse

Azioni consigliate: aggiornamento dell'elenco di controllo per la revisione del codice, implementazione del monitoraggio del pool di connessioni, aggiunta del rilevamento automatico delle perdite di risorse

Incidente di peggioramento delle prestazioni

Incidente iniziale: i tempi di risposta delle API sono aumentati da 200 ms a 5000 ms durante i picchi di traffico

  1. Perché 1: Perché i tempi di risposta sono aumentati? L'utilizzo della CPU ha raggiunto il 100% su tutte le istanze dell'applicazione.

  2. Perché 2: Perché la scalabilità automatica non ha aggiunto altre istanze? Il ridimensionamento automatico è stato attivato ma le nuove istanze non hanno superato i controlli di integrità.

  3. Perché 3: Perché le nuove istanze non hanno superato i controlli di integrità? Il processo di avvio dell'applicazione richiede 8 minuti, in più rispetto al timeout del controllo dello stato.

  4. Perché 4: Perché l'avvio richiede così tanto tempo? L'applicazione scarica file di configurazione di grandi dimensioni da S3 a ogni avvio.

  5. Perché 5: Perché questo ritardo di avvio non è stato considerato nella configurazione con scalabilità automatica? I test delle prestazioni sono stati eseguiti con istanze preriscaldate, non con avviamenti a freddo.

Causa principale: la metodologia di test delle prestazioni non riflette gli scenari di scalabilità automatica della produzione

Azioni consigliate: includere test di avvio a freddo, ottimizzazione dell'avvio delle applicazioni, regolazione dei timeout dei controlli di integrità, implementazione della memorizzazione nella cache della configurazione

Incidente complesso con analisi delle filiali

Incidente iniziale: i clienti OpenSearch serverless hanno subito un calo della disponibilità del 48,3% per 11 ore

Catena di analisi principale:

  1. Perché 1: Perché i clienti hanno subito un peggioramento del servizio? La disponibilità del servizio è scesa al 48,3% a causa di un errato dimensionamento degli ingester.

  2. Perché 2: Perché l'ingester scaling non era corretto? CortexOperator ha ridotto il numero di ingestioni da 223 a 174 a causa di un errore di calcolo del saldo AZ.

  3. Perché 3: Perché il saldo AZ è stato calcolato CortexOperator male? Il codice non è stato in grado di elaborare nuovi formati di etichette Kubernetes dopo l'aggiornamento alla versione 1.17.

  4. Perché 4 (Branch A - Technical): Perché il codice non gestiva nuovi formati di etichette? Il codice prevedeva «failure-domain.beta.kubernetes». io/zone' labels but Kubernetes 1.17 changed to 'topology.kubernetes.io/zone'.

  5. Perché 5 (Branch A): Perché non è stata implementata la compatibilità con le versioni precedenti? La modifica del formato dell'etichetta non è stata documentata nelle note di aggiornamento esaminate durante la pianificazione della distribuzione.

Filiale B - Analisi del processo:

  1. Perché 4 (Filiale B - Processo): Perché non è stato rilevato nei test? I test di integrazione hanno utilizzato cluster preconfigurati con vecchi formati di etichette.

  2. Perché 5 (Branch B): Perché i test non includevano la convalida del formato delle etichette? La configurazione dell'ambiente di test non rispecchiava la sequenza di aggiornamento della versione di Kubernetes di produzione.

Cause principali identificate:

  • Tecnico: mancata compatibilità con le versioni precedenti per le modifiche al formato delle etichette Kubernetes

  • Processo: la metodologia di test non convalida gli impatti dell'aggiornamento della versione

Piano di correzione integrato: implementazione della logica di rilevamento del formato delle etichette, miglioramento delle procedure di test degli aggiornamenti, aggiunta della convalida automatica della compatibilità e definizione del processo di valutazione dell'impatto delle modifiche alle versioni.

Utilizzo del flusso di lavoro guidato dei 5 perché

CloudWatch investigations fornisce un flusso di lavoro guidato per l'analisi dei 5 motivi per aiutarvi a risolvere i fatti mancanti e a rafforzare le segnalazioni sugli incidenti. Questa funzionalità viene visualizzata come flusso di lavoro consigliato quando il sistema identifica le opportunità per migliorare l'analisi delle cause alla radice.

Esperienza di analisi interattiva

L'analisi dei 5 perché nelle CloudWatch indagini utilizza un approccio interattivo basato su chat che guida l'utente attraverso il processo di indagine. Questo metodo conversazionale aiuta a garantire un'analisi completa mantenendo al contempo il flusso logico tra le domande.

Caratteristiche principali dell'esperienza interattiva:

  • Inizializzazione basata sui fatti: il sistema presenta fin dall'inizio i fatti rilevanti dell'indagine, utilizzandoli per precompilare risposte ovvie e indicando chiaramente i suggerimenti basati sui fatti anziché quelli basati sull'inferenza

  • Indagine guidata: per ogni domanda sul «perché», il sistema suggerisce risposte in base ai dati disponibili, richiede un contesto aggiuntivo specifico e guida l'utente a considerare aspetti importanti prima di procedere

  • Gestione delle filiali - Quando vengono identificati più fattori che contribuiscono, il sistema presenta chiaramente le opzioni delle filiali, spiega le relazioni tra le filiali e aiuta a dare priorità alle indagini parallele

  • Convalida progressiva: per ogni risposta, il sistema riformula le risposte per motivi di chiarezza, cerca conferme, evidenzia le informazioni chiave e collega i risultati a un contesto più ampio

Questo approccio garantisce l'acquisizione di tutte le informazioni pertinenti mantenendo al contempo l'attenzione sulle relazioni causali più critiche.

Accesso al flusso di lavoro guidato:

  1. Durante la generazione del rapporto sugli incidenti, consulta la sezione I fatti richiedono attenzione nel pannello di destra.

  2. Cerca il suggerimento relativo all'analisi Guided 5-Whys nella sezione Flusso di lavoro consigliato.

  3. Scegli Guide me per avviare il processo interattivo 5 Whys.

  4. Segui le istruzioni guidate per risolvere sistematicamente ogni domanda sul «perché», costruendo una catena causale completa dai sintomi alla causa principale.

Il flusso di lavoro guidato aiuta ad acquisire informazioni complete sulla causa principale illustrandoti ogni fase della metodologia dei 5 perché. I risultati dell'analisi vengono incorporati automaticamente nel rapporto sull'incidente, che fornisce una documentazione strutturata per le revisioni post-incidente e l'apprendimento organizzativo.

Puoi anche richiedere un'analisi dei 5 perché tramite l'interfaccia di chat ponendo domande come «Esegui un'analisi dei 5 perché per questo incidente» o «Qual è la causa principale utilizzando la metodologia 5 Whys?»

Gestione di incidenti complessi con cause multiple

Alcuni incidenti coinvolgono molteplici fattori che richiedono percorsi di analisi paralleli. CloudWatch le indagini supportano l'analisi delle filiali per garantire che tutte le cause significative siano identificate e affrontate.

Quando è necessaria l'analisi delle filiali:

  • Si sono verificati più guasti indipendenti contemporaneamente

  • Componenti di sistema diversi hanno contribuito allo stesso impatto sui clienti

  • Sia i guasti tecnici che quelli di processo hanno avuto un ruolo significativo

  • Gli errori a cascata hanno creato molteplici catene causali

Processo di analisi delle filiali:

  1. Identificazione delle filiali - Il sistema identifica i punti in cui più cause convergono o divergono

  2. Indagine parallela: ogni filiale viene analizzata utilizzando la metodologia completa 5 Whys

  3. Mappatura delle connessioni: le relazioni tra le filiali vengono documentate per mostrare come interagiscono

  4. Risoluzione integrata: i piani di riparazione affrontano tutte le cause principali identificate e le relative interazioni

Questo approccio globale garantisce che gli incidenti complessi ricevano un'analisi approfondita e che tutti i fattori che vi contribuiscono siano presi in considerazione nel piano di riparazione finale.

Le migliori pratiche per un'analisi efficace dei 5 perché

Per massimizzare l'efficacia dell'analisi dei 5 motivi nelle segnalazioni degli incidenti, segui queste best practice derivate dall'esperienza operativa:

Linee guida per la formulazione delle domande

  • Iniziate con l'impatto sui clienti: iniziate ogni analisi con il problema relativo al cliente per mantenere l'attenzione sull'impatto aziendale

  • Aumenta progressivamente la profondità tecnica: passa dall'impatto aziendale ai dettagli tecnici man mano che avanzi con le domande

  • Mantieni la continuità logica: assicurati che ogni risposta porti naturalmente alla domanda successiva senza lacune logiche

  • Includi prove a sostegno: fai riferimento a metriche, registri o eventi temporali specifici per convalidare ogni risposta

Convalida dell'analisi

Convalida l'analisi dei 5 perché utilizzando questi criteri:

  • Flusso logico: chiara progressione dai sintomi alla causa principale senza passaggi mancanti

  • Precisione tecnica: terminologia corretta, descrizioni accurate del comportamento del sistema e interazioni valide tra i componenti

  • Completezza: l'analisi spiega tutti i sintomi osservati e raggiunge una causa fondamentale che, se affrontata, impedirebbe la recidiva

  • Agibilità: la causa principale identificata porta a azioni correttive specifiche e implementabili

Insidie comuni da evitare

  • Fermatevi ai sintomi: non concludete l'analisi al primo guasto tecnico; continuate fino a individuare le cause sistemiche o di processo

  • Analisi incentrata sulla colpa: concentratevi sugli errori del sistema e dei processi piuttosto che sulle singole azioni

  • Pensiero basato su un unico percorso: prendi in considerazione molteplici fattori che contribuiscono e utilizza l'analisi delle filiali, se del caso

  • Prove insufficienti: assicurati che ogni risposta sia supportata da dati concreti derivanti dalla tua indagine

Integrazione con le sezioni relative ai report sugli incidenti

L'analisi dei 5 motivi si integra con altre sezioni del rapporto sull'incidente per fornire una documentazione completa:

  • Correlazione temporale: ogni domanda sul «perché» può fare riferimento a eventi temporali specifici, fornendo un contesto temporale per le relazioni causali

  • Convalida delle metriche: le risposte sono supportate da metriche e grafici che dimostrano i comportamenti tecnici descritti

  • Allineamento della valutazione dell'impatto: il primo «perché» si collega direttamente alle metriche di impatto sui clienti documentate nella sezione sulla valutazione dell'impatto

  • Nozioni di base sulle lezioni apprese - Le cause principali identificate attraverso l'analisi di 5 Perché sono alla base delle lezioni apprese e delle azioni correttive

Questa integrazione garantisce la coerenza in tutta la segnalazione dell'incidente e fornisce alle parti interessate una narrazione completa e coerente dai sintomi iniziali alla causa principale fino ai piani di riparazione.