Processo di analisi retrospettiva degli imprevisti: monitora, documenta e migliora

PUNTI CHIAVE

• Le analisi retrospettive degli imprevisti aiutano i team a capire cosa è successo, perché è successo e cosa deve cambiare per evitare che i problemi si ripetano.

• Utilizzando Jira Service Management, Confluence e Jira insieme si crea un flusso di lavoro connesso per risposta, documentazione e follow-up.

• Un modello di analisi retrospettiva coerente rende più facile documentare e confrontare l'analisi degli imprevisti e usarle come punto di partenza per apprendere nel tempo.

• Trasformare le azioni correttive in ticket Jira con responsabili e scadenze aiuta i team a partire dalle lezioni apprese e farle diventare miglioramenti reali. 

Quando qualcosa non va per il verso giusto durante la fase di produzione, la correzione è solo l'inizio. È altrettanto importante capire perché è successo e assicurarsi che non succeda di nuovo allo stesso modo. 

Un'analisi retrospettiva degli imprevisti è un esame strutturato dell'imprevisto dall'inizio alla fine, che include cosa non ha funzionato, come ha reagito il team e cosa occorre cambiare andando avanti.

Con un modello di piano di risposta agli imprevisti che guida il processo, il tuo team può documentare ogni imprevisto in modo coerente, così che nulla di importante vada perso e che ogni analisi porti a miglioramenti reali.

Come funziona: gestione degli imprevisti e acquisizione delle analisi retrospettive

Una buona gestione degli imprevisti non significa solo intervenire per risolvere i problemi. Significa realizzare un sistema in cui ogni imprevisto contribuisca a migliorare i processi, gli strumenti e la preparazione per la volta successiva. Utilizzando Jira Service Management, Confluence e Jira insieme, il tuo team ottiene un flusso di lavoro connesso che copre l'intero ciclo di vita della risposta agli imprevisti, dal momento in cui viene attivato un avviso fino all'analisi retrospettiva e al lavoro di follow-up. 

Questo approccio mantiene una documentazione coerente tra gli imprevisti e stabilisce una chiara catena di responsabilità. I dettagli degli imprevisti non sono più sparsi nei messaggi Slack, nelle e-mail o nella memoria di qualcuno, ma si trovano in un unico ecosistema connesso dove possono essere esaminati, consultati e usati per agire. Questa coerenza significa anche che il modello del piano di risposta agli imprevisti rimane centrale nel processo anziché essere qualcosa che il team compila quando ne ha il tempo. 

Ecco come si articola ogni fase del processo:

Gestisci l'imprevisto in Jira Service Management

Jira Service Management è il punto di partenza della risposta agli imprevisti. Non appena arriva un ticket, registralo nel log di JSM, definisci il livello di gravità e assegna le persone che devono rispondere. 

Durante l'imprevisto, i team possono usare JSM per:

• Monitorare le azioni, le decisioni e le escalation in tempo reale.

• Mantenere un registro chiaro di chi è stato coinvolto e cosa è cambiato.

• Acquisire i dettagli che successivamente supporteranno l'analisi retrospettiva.

• Tenere informata la dirigenza senza interrompere chi risponde.

Poiché JSM si integra con Confluence e Jira, i dati raccolti durante l'imprevisto possono confluire direttamente nella documentazione dell'analisi retrospettiva e nel lavoro di follow-up. Per i team che utilizzano JSM come parte di una configurazione di software ITSM più ampia, i dati degli imprevisti contribuiscono anche al quadro più ampio della gestione dei servizi.

JSM supporta anche una solida comunicazione degli imprevisti durante l'intero processo di risposta aiutando i team a:

• Tenere aggiornati i clienti, i team di assistenza e gli stakeholder.

• Ridurre la confusione quando ci sono imprevisti attivi.

• Fornire visibilità su stato e impatto.

• Comunicare in modo più chiaro durante gli eventi dalla gravità elevata o gli scenari di gestione delle crisi.

Quando l'imprevisto sarà stato risolto, il team avrà già una documentazione dettagliata di come si è svolto, il che rende l'analisi retrospettiva più facile da documentare e più utile per miglioramenti futuri.

Acquisisci l'analisi retrospettiva in Confluence

Dopo la risoluzione, documenta l'imprevisto mentre i dettagli sono ancora freschi. L'ideale sarebbe entro 24-48 ore. Più aspetti, più il contesto si perde e meno utile diventa l'analisi retrospettiva. 

Crea una pagina Confluence dedicata utilizzando un modello dell'analisi retrospettiva degli imprevisti e lavora su ogni sezione: timeline, analisi della causa principale, valutazione dell'impatto e lezioni apprese. Il modello di risposta agli imprevisti incluso in questa pagina fornisce un framework completo che il tuo team può copiare e compilare per ogni nuovo imprevisto, così non dovrai capire cosa documentare ogni volta da zero.

La conservazione dell'analisi retrospettiva in Confluence offre diversi vantaggi pratici:

• Visibilità a livello di team: chiunque, dal team di progettazione alla dirigenza, può esaminare ciò che è successo senza bisogno di rintracciare la persona reperibile per avere un riassunto verbale.

• Identificazione dei pattern: quando ogni imprevisto viene documentato nello stesso formato, diventa molto più facile individuare i problemi ricorrenti e i punti deboli a livello di sistema nei vari trimestri.

• Documentazione senza colpe: un modello strutturato di risposta agli imprevisti mantiene il fulcro della conversazione sui sistemi e sui processi, senza puntare il dito su qualcuno, il che produce report più onesti e utili.

• Inserimento più rapido per i neoassunti: i nuovi membri del team possono esaminare le analisi retrospettive passate per capire come si comportano i sistemi quando sono sotto pressione e cosa ha già imparato il team dagli imprevisti precedenti.

Per una guida più approfondita su come condurre analisi retrospettive produttive, consulta il nostro manuale per le analisi retrospettive degli imprevisti.

Monitora i follow-up come ticket Jira

Un'analisi retrospettiva è utile solo quanto l'azione che genera. Ogni azione correttiva e problema ricorrente che si identifica durante l'analisi dovrebbe essere convertito in un ticket Jira con un responsabile chiaro e una scadenza. 

Questo è il passaggio che distingue i team che migliorano davvero da quelli che continuano a imbattersi negli stessi problemi. Quando le azioni correttive sono gestite come ticket tracciabili in Jira, i manager possono monitorare i progressi e i team possono ritenersi reciprocamente responsabili del completamento dei miglioramenti concordati. Questo passaggio, inoltre, aiuta nella definizione delle priorità. Quando il lavoro basato sugli imprevisti va di pari passo con il resto del backlog, è più facile valutarlo rispetto ad altre priorità piuttosto che lasciarlo finire silenziosamente in fondo all'elenco.

I giusti strumenti di gestione degli imprevisti collegano l'intero flusso di lavoro dall'inizio alla fine. Quando i sistemi di risposta, documentazione e follow-up sono integrati, il divario tra rilevare un problema ed evitare che si ripeta si riduce notevolmente.

Modello di risposta agli imprevisti

Di seguito è riportato un modello di piano di risposta agli imprevisti che il tuo team può copiare e adattare per ogni nuovo imprevisto. Illustra ogni fase di un'analisi retrospettiva, dal riepilogo iniziale e dalla timeline fino all'analisi della causa principale, alle lezioni apprese e alle azioni correttive. L'utilizzo di una struttura coerente per ogni imprevisto garantisce che nulla venga trascurato e che le analisi retrospettive siano facili da confrontare nel tempo.

Gli esempi nel modello sono un punto di partenza, non uno script da seguire alla lettera. Adatta il linguaggio e il livello di dettaglio per rispecchiare il modo in cui opera la tua organizzazione. L'obiettivo è documentare un contesto sufficiente perché chiunque legga l'analisi retrospettiva nei mesi successivi possa capire esattamente cosa è accaduto e cosa ha fatto il team al riguardo.

Riepilogo dell'imprevisto

Scrivi un riepilogo dell'imprevisto in poche frasi. Includi ciò che è successo, il perché, il livello di gravità dell'imprevisto e la durata dell'impatto.

ESEMPIO:

Nella fascia oraria {time range of incident, e.g. 15:45 and 16:35} del giorno {DATE}, {NUMBER} gli utenti hanno riscontrato {EVENT SYMPTOMS}. 

L'evento è stato attivato da {CHANGE} alle ore {TIME OF CHANGE THAT CAUSED THE EVENT}. 

{CHANGE} conteneva {DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system}. 

Un bug in questo codice ha causato {DESCRIPTION OF THE PROBLEM}. 

L'evento è stato rilevato da {MONITORING SYSTEM}. Il team ha iniziato a lavorare sull'evento intervenendo in questo modo: {RESOLUTION ACTIONS TAKEN}.

Questo imprevisto {SEVERITY LEVEL} ha interessato il {X%} degli utenti.

Si è avuto un ulteriore impatto, come notato dalle segnalazioni di {e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS} in relazione a questo imprevisto. 

Avvisaglie

Descrivi la successione di eventi che hanno portato all'imprevisto, ad esempio le modifiche precedenti che hanno introdotto bug non ancora rilevati.

ESEMPIO:

Alle ore {16:00} del giorno {MM/DD/YY}, ({AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}), è stata introdotta una modifica a {PRODUCT OR SERVICE}  al fine di {THE CHANGES THAT LED TO THE INCIDENT}. 

Questa modifica ha prodotto  {DESCRIPTION OF THE IMPACT OF THE CHANGE}.

Guasto

Descrivi in che modo la modifica implementata non ha avuto i risultati previsti. Se possibile, allega screenshot delle visualizzazioni dei dati pertinenti in cui è illustrato l'errore.

ESEMPIO:

{NUMBER} risposte sono state inviate per errore al {XX%} delle richieste. Questo è andato avanti per {TIME PERIOD}.

Impatto

Descrivi l'impatto che l'imprevisto ha avuto sugli utenti interni ed esterni. Includi quanti casi di assistenza sono stati aperti.

ESEMPIO:

Per {XXhrs XX minutes} nell'intervallo di tempo {XX:XX UTC and XX:XX UTC} del giorno {MM/DD/YY}, {SUMMARY OF INCIDENT} i nostri utenti hanno subito questo imprevisto.

Questo imprevisto ha interessato {XX} clienti (X% DI UTENTI DI {SYSTEM OR SERVICE}), che hanno riscontrato {DESCRIPTION OF SYMPTOMS}.

Sono stati inviati {XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS}.

Rilevamento

Quando il team ha rilevato l'imprevisto? Come se n'è accorto? In che modo è possibile migliorare il tempo di rilevamento? Rifletti: come avremmo potuto dimezzare questo tempo?

ESEMPIO:

L'imprevisto è stato rilevato quando {ALERT TYPE} è stato attivato e sono stati chiamati {TEAM/PERSON}. 

In seguito, è stato contattato {SECONDARY PERSON} perché {FIRST PERSON} non era responsabile del servizio di scrittura su disco e questo ha ritardato la risposta di {XX MINUTES/HOURS}.

{DESCRIBE THE IMPROVEMENT} verrà impostato da {TEAM OWNER OF THE IMPROVEMENT} in modo che {EXPECTED IMPROVEMENT}.

Risposta

Chi ha risposto all'imprevisto? Quando ha risposto e cosa ha fatto? Annota eventuali ostacoli o ritardi della risposta.

ESEMPIO:

Dopo essere stato contattato alle ore {XX:XX UTC}, {ON-CALL ENGINEER} si è collegato alle ore {XX:XX UTC} in {SYSTEM WHERE INCIDENT INFO IS CAPTURED}. 

Il tecnico non aveva conoscenze pregresse su {AFFECTED SYSTEM}, quindi è stato inviato un secondo avviso alle ore {XX:XX UTC} a {ESCALATIONS ON-CALL ENGINEER}, che è arrivato alle ore {XX:XX UTC}.

Ripristino

Descrivi in che modo è stato ripristinato il servizio ed è stato ritenuto concluso l'imprevisto. Esponi nei dettagli come hai ripristinato il corretto funzionamento del sistema e come sapevi quali passaggi seguire per farlo. 

A seconda dello scenario, considera queste domande: In che modo è possibile migliorare il tempo di mitigazione? e Come avremmo potuto dimezzare questo tempo?

ESEMPIO:

Abbiamo utilizzato un triplice approccio al ripristino del sistema: 

{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME} 

Esempio: incrementando la capacità di BuildEng EC3 ASG per aumentare il numero di nodi disponibili a supportare il carico di lavoro e ridurre le probabilità di pianificazione dei processi su nodi sovraccarichi

• Disattivazione del servizio automatico di scalabilità Escalator per impedire che il cluster si ridimensioni eccessivamente

• Ripristino del programma di pianificazione Build Engineering alla versione precedente.

Timeline

Descrivi nei dettagli la timeline dell'imprevisto. Consigliamo di utilizzare il fuso orario UTC come standard.

Includi eventuali eventi importanti precedenti all'evento, gli avvii delle attività, il primo impatto noto e le escalation. Annota le decisioni prese o le modifiche apportate e l'ora di fine dell'imprevisto, oltre agli eventuali eventi successivi all'impatto degni di nota. 

ESEMPIO:

Tutti gli orari sono UTC.

11:48 - Upgrade a K8S 1.9 del piano di controllo terminato 

12:46 - Upgrade alla V1.9 completato, incluse le istanze del servizio automatico di scalabilità cluster e del servizio di programmazione BuildEng 

14:20 - L'ingegnere della build segnala un problema a KITT Disturbed

14:27 - KITT Disturbed inizia a indagare sui guasti di una specifica istanza EC2 (ip-203-153-8-204) 

14:42 - KITT Disturbed isola il nodo 

14:49 - BuildEng segnala che il problema interessa più di un solo nodo. 86 istanze del problema mostrano che gli errori sono più sistemici 

15:00 - KITT Disturbed suggerisce di passare allo scheduler standard 

15:34 - BuildEng segnala che 200 pod hanno avuto esito negativo 

16:00 - BuildEng blocca tutte le build non riuscite con report OutOfCPU 

16:13 - BuildEng segnala che gli errori sono costantemente ricorrenti con le nuove build e non sono stati solo transitori. 

16:30 - KITT riconosce gli errori come imprevisto e li gestisce di conseguenza. 

16:36 - KITT disattiva il servizio automatico di scalabilità Escalator per evitare che esso rimuova risorse di elaborazione per limitare il problema.

16:40 - KITT conferma che ASG è stabile, il carico del cluster è normale e l'impatto sui clienti è risolto.

MODELLO:

XX:XX UTC - ATTIVITÀ RELATIVA ALL'IMPREVISTO; AZIONI INTRAPRESE

XX:XX UTC - ATTIVITÀ RELATIVA ALL'IMPREVISTO; AZIONI INTRAPRESE

XX:XX UTC - ATTIVITÀ RELATIVA ALL'IMPREVISTO; AZIONI INTRAPRESE

Identificazione della causa primaria: I cinque perché

I 5 perché sono una tecnica di identificazione della causa primaria. Ecco come puoi usarla:

• Inizia con una descrizione dell'impatto e chiediti perché si è verificato. 

• Prendi nota dell'impatto.  

• Chiediti perché è successo e perché ha avuto l'impatto che ne è derivato. 

• Continua a chiederti perché fino ad arrivare alla causa primaria.

Elenca i "perché" nella documentazione dell'analisi retrospettiva.

ESEMPIO:

1. L'applicazione ha avuto un'interruzione perché il database era bloccato

2. Il database è bloccato perché c'erano troppe scritture al suo interno

3. Perché abbiamo introdotto una modifica al servizio e non ci aspettavamo scritture elevate

4. Perché non abbiamo un processo di sviluppo stabilito per le modifiche ai test di carico

5. Perché non abbiamo mai ritenuto necessario eseguire il test di carico fino a quando non abbiamo raggiunto questo livello di scala.

Causa radice

Annota la causa primaria definitiva dell'imprevisto, ovvero ciò che deve cambiare per impedire che questa categoria di imprevisto si ripresenti.

ESEMPIO:

Un bug in

Controllo del backlog

Rivedi il backlog di progettazione per verificare se c'era del lavoro non pianificato che avrebbe potuto impedire questo imprevisto o almeno ridurne l'impatto. 

Una valutazione onesta del backlog aiuta a chiarire le passate decisioni in merito a priorità e rischi.

ESEMPIO:

Nessun elemento specifico nel backlog che avrebbe potuto migliorare questo servizio. C'è una nota sui miglioramenti della tipizzazione del flusso e questi erano task noti in via di sviluppo con propri flussi di lavoro.  

Sono stati inviati dei ticket relativi al miglioramento dei test di integrazione che finora non hanno avuto successo.

Ricorrenza

Ora che conosci la causa primaria, puoi esaminare gli imprevisti passati e verificare se hanno la stessa causa primaria? Se la risposta è sì, annota la mitigazione tentata per questi imprevisti e chiedi perché l'imprevisto si è verificato di nuovo.

ESEMPIO:

Questa stessa causa primaria ha causato gli imprevisti HOT-13432, HOT-14932 e HOT-19452.

Lezioni apprese

Discuti di cosa è andato bene nel processo di risposta agli imprevisti, di cosa poteva essere migliorato e delle opportunità di miglioramento.

ESEMPIO:

• Occorre un test unitario per verificare che il limitatore di velocità del lavoro sia stato sottoposto a corretta manutenzione

• I carichi di lavoro delle operazioni di massa atipiche rispetto al normale funzionamento dovrebbero essere rivisti

• Le operazioni di massa devono iniziare progressivamente ed essere monitorate, aumentandole quando le metriche del servizio sembrano mantenersi su valori nominali

Azioni correttive

Descrivi l'azione correttiva stabilita per impedire che questa categoria di imprevisti si verifichi in futuro. Annota chi è il responsabile, quando deve completare il lavoro e dove tale lavoro viene monitorato.

ESEMPIO:

1. Posto temporaneamente in atto un limite di velocità del servizio automatico di scalabilità per limitare gli errori

2. Test unitario e reintroduzione della limitazione di velocità del lavoro

3. Introduzione di un meccanismo secondario per raccogliere le informazioni di velocità distribuite sul cluster per guidare gli effetti di scalabilità