Analisi delle Cause Radice
Andare oltre i sintomi per trovare le cause sistemiche.
1Perché le Cause Radice Contano
La maggior parte della risoluzione dei problemi affronta i sintomi, non le cause.
Il deploy è fallito? Ripristina e ridistribuisci. Bug in produzione? Applicagli una hotfix. La build è lenta? Aggiungi più server di build.
Queste correzioni affrontano il dolore immediato. Il problema scompare... finché non ritorna. Perché non hai risolto ciò che lo ha causato.
L'analisi delle cause radice significa chiedere "perché?" finché non trovi la causa sistemica—la cosa che, se risolta, impedirebbe al problema di ripresentarsi.
Il deploy non è fallito a causa di un problema casuale. È fallito perché la suite di test è instabile. La suite di test è instabile perché i test condividono lo stato. I test condividono lo stato perché il framework di testing non era stato compreso quando è stato configurato.
Risolvi il sintomo immediato (riprova il deploy) e riproverai di nuovo domani. Risolvi la causa radice (correggi la comprensione del framework di test) e i deploy smettono di fallire.
L'analisi delle cause radice richiede più tempo inizialmente. Ma fa risparmiare esponenzialmente più tempo prevenendo le ricorrenze.
Il Pericolo delle Soluzioni Rapide
Ogni soluzione rapida che non affronta le cause radice crea uno schema: il problema si ripresenta, lo risolvi di nuovo, diventa 'normale'. Alla fine hai un sistema tenuto insieme da soluzioni temporanee, dove i problemi reali sono invisibili sotto strati di patch.
2I Cinque Perché
I Cinque Perché è la tecnica più semplice per le cause radice: continua a chiedere "perché?" finché non raggiungi una causa radice, di solito intorno a cinque iterazioni.
Esempio:
Problema: La produzione è stata inattiva per 2 ore.
- Perché? È stata distribuita una configurazione errata.
- Perché? La modifica della configurazione non è stata testata.
- Perché? Non abbiamo test per le modifiche di configurazione.
- Perché? La configurazione è gestita separatamente dal codice.
- Perché? Il team infrastruttura l'ha configurata prima che il team di sviluppo adottasse GitOps.
Causa radice: Separazione storica della configurazione dal codice nella pipeline di deployment.
Contromisura: Spostare la configurazione nello stesso repository e pipeline CI/CD del codice applicativo.
Insidie dei Cinque Perché:
- Fermarsi troppo presto: "Errore umano" non è mai una causa radice. Perché è avvenuto l'errore? Quale sistema lo ha permesso?
- A filo singolo: I problemi reali hanno spesso cause multiple. I Cinque Perché possono perdere catene causali parallele.
- Guidato dalle opinioni: Senza dati, potresti chiedere "perché?" e ottenere speculazioni invece di fatti.
- Ricerca di colpevoli: Se i Cinque Perché degenerano in "chi ha sbagliato?", vengono usati male.
I Cinque Perché funzionano meglio come punto di partenza, integrati con dati e prospettive multiple.
3Diagrammi di Ishikawa (a Lisca di Pesce)
Il diagramma di Ishikawa, chiamato anche a lisca di pesce o diagramma causa-effetto, aiuta a esplorare simultaneamente categorie di cause multiple.
Il problema è la "testa" del pesce. Le categorie principali di cause sono le "lisce". Le sotto-cause si diramano da ogni lisca.
Categorie comuni (le 6 M):
- Manpower: Persone, competenze, formazione
- Method: Processi, procedure
- Machine: Strumenti, attrezzature, sistemi
- Material: Input, dati, dipendenze
- Measurement: Metriche, monitoraggio, feedback
- Mother Nature (Environment): Fattori esterni, contesto
Per il software, potresti adattare:
- People: Competenze, comunicazione, struttura del team
- Process: Workflow, passaggi di consegne, policy
- Technology: Strumenti, infrastruttura, architettura
- Data: Input, stato, dipendenze
- Measurement: Visibilità, monitoraggio, alerting
- Environment: Servizi esterni, carico, contesto
Il diagramma aiuta i team a fare brainstorming sulle cause in modo sistematico piuttosto che ancorarsi alla prima idea. Rivela che i problemi hanno solitamente cause contribuenti multiple.
Combina le Tecniche
Usa i Cinque Perché per scavare in profondità su ogni ramo della lisca di pesce. La lisca di pesce assicura che tu esplori in ampiezza; i Cinque Perché assicurano che tu esplori in profondità. Insieme sono potenti.
Incidente: Fallimento del deploy ha causato un'interruzione di 2 ore. I Cinque Perché hanno portato a: configurazione non testata → configurazione gestita separatamente → decisione architetturale storica. La lisca di pesce ha rivelato: anche nessun runbook di deploy (Process), nessun processo canary (Method). Affrontati tutti e tre.
Incidente: Fallimento del deploy ha causato un'interruzione di 2 ore. Conclusione del post-mortem: 'Lo sviluppatore avrebbe dovuto essere più attento.' Azione: 'Essere più attenti la prossima volta.' Il problema si ripresenta due settimane dopo con uno sviluppatore diverso.
- Risolvere i sintomi senza le cause radice porta a problemi ricorrenti
- I Cinque Perché scavano in profondità chiedendo 'perché?' ripetutamente
- L'errore umano non è mai una causa radice—chiedi quale sistema lo ha permesso
- I diagrammi a lisca di pesce aiutano a esplorare categorie di cause multiple
- Usa dati, non speculazioni, per validare le catene causali
- •Fermarsi a 'errore umano' o 'mancanza di attenzione'
- •Usare i Cinque Perché senza dati per validare le ipotesi
- •Trovare una causa e fermarsi (i problemi hanno spesso cause multiple)
- •Trasformare l'analisi delle cause radice in assegnazione di colpe