View a markdown version of this page

Utilizzo dell'analisi di 5 Whys nei report sugli incidenti - Amazon CloudWatch
Che cos'è l'analisi di 5 Whys?Vantaggi della segnalazione degli incidentiScenari di esempio nelle segnalazioni di incidentiUtilizzo del flusso di lavoro guidato «5 Whys»Gestione di incidenti complessi con cause multipleLe migliori pratiche per un'efficace analisi 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 di 5 Whys nei report sugli incidenti

Quando si generano i report sugli incidenti, CloudWatch le indagini possono eseguire un'analisi delle cause principali dei 5 Whys per identificare sistematicamente le cause alla base dei problemi operativi. Questo approccio strutturato migliora le segnalazioni degli 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 policy o la policy AIOpsOperatorAccess gestita all'utente AIOpsConsoleAdminPolicy o al ruolo.

Che cos'è l'analisi di 5 Whys?

L'analisi dei 5 perché è una tecnica di analisi delle cause principali che chiede ripetutamente il «perché» per passare dai sintomi accidentali alle cause fondamentali. Ogni risposta diventa la base per la domanda successiva, creando una catena logica che rivela la vera causa principale e non solo i sintomi superficiali.

Durante la generazione del rapporto sugli incidenti, CloudWatch Investigations utilizza 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 di 5 Whys nei report sugli incidenti offre diversi vantaggi:

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

  • Piani di risoluzione attuabili: forniscono azioni specifiche e mirate per prevenire le recidive piuttosto che soluzioni temporanee

  • Apprendimento organizzativo: documenta l'intera catena causale per riferimenti futuri e condivisione delle conoscenze tra i team

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

Scenari di esempio nelle segnalazioni di incidenti

Incidente di errore di connessione al database

Incidente iniziale: E-commerce applicazione 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 job non include la pulizia della connessione negli scenari di errore.

  5. Perché 5: Perché non è stata implementata una 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 della checklist per la revisione del codice, implementazione del monitoraggio del pool di connessioni, aggiunta del rilevamento automatico delle perdite di risorse

Incidente di degrado delle prestazioni

Incidente iniziale: i tempi di risposta dell'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% in tutte le istanze dell'applicazione.

  2. Perché 2: Perché il ridimensionamento automatico 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 sanitari? Il processo di avvio dell'applicazione richiede 8 minuti, più del timeout del controllo di integrità.

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

  5. Perché 5: Perché questo ritardo di avvio non è stato preso in considerazione 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: includete test con avvio a freddo, ottimizzazione dell'avvio delle applicazioni, regolazione dei timeout dei controlli di integrità, implementazione della memorizzazione nella cache di configurazione

Incidente complesso con analisi delle filiali

Incidente iniziale: i clienti OpenSearch serverless hanno subito una riduzione 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 ridimensionamento dell'ingester.

  2. Perché 2: Perché il ridimensionamento di Ingester non era corretto? CortexOperator ha ridotto gli ingester da 223 a 174 a causa di un errore di calcolo del saldo AZ.

  3. Perché 3: Perché ho calcolato CortexOperator male il saldo AZ? 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 i nuovi formati di etichette? Il codice prevedeva «failure-domain.beta.kubernetes». io/zone' etichette ma Kubernetes 1.17 è cambiato in «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 dell'implementazione.

Filiale B - Analisi del processo:

  1. Perché 4 (Filiale B - Processo): perché non è stato preso in considerazione durante i 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 produzione di Kubernetes.

Cause principali identificate:

  • Tecnico: manca la 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 riparazione integrato: implementa la logica di rilevamento del formato delle etichette, migliora le procedure di test di aggiornamento, aggiungi la convalida automatica della compatibilità e stabilisci un processo di valutazione dell'impatto delle modifiche alla versione.

Utilizzo del flusso di lavoro guidato «5 Whys»

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

Esperienza di analisi interattiva

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

Caratteristiche principali dell'esperienza interattiva:

  • Fact-based inizializzazione: il sistema presenta in anticipo i fatti pertinenti dell'indagine, utilizzandoli per precompilare le risposte ovvie e indicando chiaramente i suggerimenti basati sui fatti rispetto a quelli basati sull'inferenza

  • Sondaggio guidato: per ogni domanda sul perché, il sistema suggerisce risposte in base ai fatti 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 disponibili per le filiali, spiega le relazioni tra le filiali e aiuta a stabilire le priorità delle indagini parallele

  • Convalida progressiva: per ogni risposta, il sistema riformula le risposte per renderle più chiare, 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 l'attenzione sulle relazioni causali più critiche.

Accesso al flusso di lavoro guidato:

  1. Durante la generazione del rapporto sugli incidenti, consulta la sezione Fatti a cui prestare attenzione nel pannello di destra.

  2. Cerca il suggerimento per l'analisi guidata dei 5 motivi nella sezione Flusso di lavoro consigliato.

  3. Scegli Guide me per avviare il processo interattivo dei 5 perché.

  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 ti aiuta ad acquisire informazioni complete sulla causa principale guidandoti attraverso ogni fase della metodologia dei 5 perché. I risultati dell'analisi vengono automaticamente incorporati nel rapporto sull'incidente, fornendo una documentazione strutturata per le revisioni successive all'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 perché?»

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 assicurarsi che tutte le cause significative siano identificate e affrontate.

Quando è necessaria un'analisi delle filiali:

  • Si sono verificati contemporaneamente più guasti indipendenti

  • Componenti di sistema diversi hanno contribuito allo stesso impatto sul cliente

  • I guasti tecnici e di processo hanno avuto un ruolo significativo

  • I guasti 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 dei 5 Whys

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

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

Questo approccio completo garantisce che gli incidenti complessi ricevano un'analisi approfondita e che tutti i fattori che contribuiscono siano affrontati nel piano di riparazione finale.

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

Per massimizzare l'efficacia dell'analisi di 5 Whys nei report sugli incidenti, seguite queste best practice derivate dall'esperienza operativa:

Linee guida per la formulazione delle domande

  • Inizia dall'impatto sul cliente: inizia ogni analisi con il problema che riguarda il cliente per mantenere l'attenzione sull'impatto aziendale

  • Aumenta progressivamente la profondità tecnica: passa dall'impatto aziendale ai dettagli tecnici man mano che avanzi nelle 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 cronologici specifici per convalidare ogni risposta

Convalida dell'analisi

Convalida la tua analisi dei 5 Whys 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 le recidive

  • Azionabilità: la causa principale identificata porta ad azioni correttive specifiche e implementabili

Le insidie più comuni da evitare

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

  • Blame-focused analisi - Concentratevi sui guasti del sistema e del processo piuttosto che sulle singole azioni

  • Single-path pensiero: considera molteplici fattori che contribuiscono e utilizza l'analisi delle filiali quando appropriato

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

Integrazione con le sezioni relative ai rapporti sugli incidenti

L'analisi dei 5 motivi si integra con altre sezioni del rapporto sugli incidenti 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

  • Lezioni apprese e fondamenti: le cause principali identificate attraverso l'analisi dei 5 Whys sono alla base delle lezioni apprese e delle sezioni relative alle azioni correttive

Questa integrazione garantisce la coerenza nella segnalazione degli incidenti e fornisce alle parti interessate una narrazione completa e coerente, dai sintomi iniziali alla causa principale fino ai piani di risoluzione.