Gestione degli imprevisti per i team high velocity
Modello dell'analisi retrospettiva degli imprevisti
Una documentazione chiara è la chiave di un'analisi retrospettiva degli imprevisti efficace. Molti team usano un modello completo per raccogliere dettagli coerenti durante le revisioni delle analisi retrospettive.
Di seguito è riportato un esempio di un modello di analisi retrospettiva degli imprevisti basato sull'analisi descritta nel nostro Manuale degli imprevisti. Puoi copiare e incollare questi contenuti per documentare le tue analisi retrospettive.
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:
Tra le ore {intervallo temporale dell'imprevisto, ad es. tra le ore 15:45 e le ore 16:35} il giorno {DATA}, {NUMERO} utenti hanno riscontrato {SINTOMI EVENTO}.
L'evento è stato attivato da {MODIFICA} alle ore {ORA DELLA MODIFICA CHE HA CAUSATO L'EVENTO}.
La {MODIFICA} conteneva {DESCRIZIONE O RAGIONE DELLA MODIFICA, ad esempio una modifica del codice per l'aggiornamento di un sistema}.
Un bug in questo codice ha causato {DESCRIZIONE DEL PROBLEMA}.
L'evento è stato rilevato da {SISTEMA DI MONITORAGGIO}. Il team ha iniziato a lavorare all'evento mediante {AZIONI RISOLUTIVE INTRAPRESE}.
Questo imprevisto {LIVELLO DI GRAVITÀ} ha interessato il {X%} degli utenti.
Si è verificato un ulteriore impatto, come registrato da {ad es. NUMERO DI TICKET DI ASSISTENZA INVIATI, MENZIONI SUI SOCIAL MEDIA, CHIAMATE AGLI ACCOUNT MANAGER} effettuati 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 {GG/MM/AA}, ({INTERVALLO DI TEMPO PRIMA DELL'IMPATTO SUI CLIENTI, ad es. 10 giorni prima dell'imprevisto in questione}), è stata apportata una modifica a {PRODOTTO O SERVIZIO} per {MODIFICHE CHE HANNO PORTATO ALL'IMPREVISTO}.
Questa modifica ha causato {DESCRIZIONE DELL'IMPATTO DELLA MODIFICA}.
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:
{NUMERO} risposte sono state inviate per errore al {XX%} delle richieste. Questa situazione è andata avanti per {INTERVALLO DI TEMPO}.
Impatto
Descrivi l'impatto che l'imprevisto ha avuto sugli utenti interni ed esterni. Includi quanti casi di assistenza sono stati aperti.
ESEMPIO:
Per {XX ore XX minuti} tra le ore {XX:XX UTC e le ore XX:XX UTC} il giorno {GG/MM/AA}, i nostri utenti hanno riscontrato l'imprevisto {RIEPILOGO DELL'IMPREVISTO}.
Questo imprevisto ha interessato {XX} clienti (X% DEGLI UTENTI DEL {SISTEMA O DEL SERVIZIO}) che hanno riscontrato {DESCRIZIONE DEI SINTOMI}.
Sono stati inviati {XX NUMERO DI TICKET DI ASSISTENZA E XX NUMERO DI POST SUI SOCIAL MEDIA}.
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:
Questo imprevisto è stato rilevato quando {TIPO DI AVVISO} è stato attivato e {TEAM/PERSONA} è stato contattato.
Successivamente, è stato contattato {PERSONA SECONDARIA} perché {PRIMA PERSONA} non era responsabile del servizio di scrittura su disco, ritardando la risposta di {XX MINUTI/ORE}.
Verrà configurato un {DESCRIZIONE DEL MIGLIORAMENTO} da parte di {TEAM RESPONSABILE DEL MIGLIORAMENTO} per {MIGLIORAMENTO PREVISTO}.
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}, {TECNICO REPERIBILE SU CHIAMATA} si è collegato alle ore {XX:XX UTC} al {SISTEMA IN CUI VENGONO ACQUISITE LE INFORMAZIONI SULL'IMPREVISTO}.
Questo tecnico non aveva nessuna conoscenza pregressa di {SISTEMA INTERESSATO}, per cui è stato inviato un secondo avviso alle ore {XX:XX UTC} a {TECNICO REPERIBILE SU CHIAMATA DI ESCALATION}, 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:
{DESCRIVERE L'AZIONE CHE HA MITIGATO IL PROBLEMA, PERCHÉ È STATA INTRAPRESA E IL RISULTATO}
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:
- L'applicazione ha avuto un'interruzione perché il database era bloccato
- Il database è bloccato perché c'erano troppe scritture al suo interno
- Perché abbiamo introdotto una modifica al servizio e non ci aspettavamo scritture elevate
- Perché non abbiamo un processo di sviluppo stabilito per le modifiche ai test di carico
- 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:
A 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:
- Posto temporaneamente in atto un limite di velocità del servizio automatico di scalabilità per limitare gli errori
- Test unitario e reintroduzione della limitazione di velocità del lavoro
- Introduzione di un meccanismo secondario per raccogliere le informazioni di velocità distribuite sul cluster per guidare gli effetti di scalabilità
Scopri di più sulla comunicazione degli imprevisti con Statuspage
In questo tutorial ti mostreremo come utilizzare i modelli di imprevisto per comunicare in modo efficace durante le interruzioni. Puoi adattarlo a molti tipi di interruzione del servizio.
Segui il tutorialL'importanza del processo di analisi retrospettiva degli imprevisti
L'analisi retrospettiva degli imprevisti, nota anche come revisione post-imprevisto, è il modo migliore per esaminare ciò che è avvenuto durante un imprevisto e fissare le lezioni apprese.
Leggi l'articolo