Alle 02:10 scatta un allarme. Un tecnico implementa una modifica alla configurazione, il servizio di test inizia a restituire errori e il responsabile di turno la annulla 40 minuti dopo. Durante la riunione di revisione, la prima domanda è: "Chi ha implementato la modifica?". Nel giro di pochi minuti la conversazione verte sul giudizio di una singola persona alle 2 del mattino, e nessuno si chiede perché la modifica sia arrivata in produzione senza un test canary, perché l'allarme abbia impiegato così tanto tempo ad arrivare o perché il manuale operativo fosse obsoleto.
Questo è uno scenario esemplificativo, non un caso reale di un cliente. È riconoscibile perché accade: un'analisi di un incidente che si concentra sull'ultima persona ad agire produce una narrazione ordinata ma con ben poco da imparare.
Questa guida è pensata per i responsabili dell'ingegneria e i coordinatori della formazione che desiderano migliorare le capacità di analisi delle prove relative agli incidenti e di individuazione di miglioramenti testabili. Spiega come distinguere le lacune di competenze dalle condizioni che le circondano, come progettare le esercitazioni, come condurre il debriefing e come misurare l'efficacia delle revisioni.
Cosa significa e cosa non significa "innocente".
Il libro di Google "Site Reliability Engineering" lo spiega chiaramente: affinché un'analisi post-mortem sia veramente imparziale, deve concentrarsi sull'identificazione delle cause che hanno contribuito all'incidente, senza accusare alcun individuo o team di comportamenti scorretti o inappropriati. Descrive anche il presupposto di base: tutti i soggetti coinvolti hanno agito con buone intenzioni e hanno fatto la cosa giusta con le informazioni a loro disposizione.Libro di Google SRE, "Postmortem Culture: Learning from Failure" (Cultura post-mortem: imparare dagli errori).)
L'assenza di colpevolizzazioni non significa assenza di conseguenze. Lo stesso capitolo prevede che le analisi post-mortem si concludano con azioni concrete, con priorità e responsabile. Un'indagine senza colpevolizzazioni richiede comunque l'individuazione di un responsabile, ma la responsabilità si sposta da "chi ha causato questo" a "chi renderà il sistema più sicuro e entro quando". Se le vostre revisioni saltano la seconda parte, avrete una piacevole conversazione, non un processo di apprendimento.
1. Identificare il comportamento e il suo contesto
Iniziate dal comportamento specifico che volete cambiare. "Le nostre analisi degli incidenti si concentrano sull'ultima persona ad agire" è osservabile. "La nostra cultura è fortemente orientata alla ricerca di colpevoli" non lo è.
Chiediti quindi se si tratta effettivamente di un problema di abilità. L'allenamento può risolvere solo alcune delle cause di una prestazione scadente. Prima di costruire qualsiasi cosa, distingui tre possibilità:
- Una competenza mancante. I revisori non sanno come ricostruire una cronologia degli eventi, distinguere un fattore scatenante da un fattore concomitante, o chiedersi "cosa ha fatto sembrare ragionevole quest'azione al momento dei fatti?".
- Incentivi. Le recensioni alimentano le discussioni sulle prestazioni, quindi le persone modellano i propri account per proteggersi.
- Gradienti di autorità e risposte passate. Un giovane ingegnere che ha sollevato una preoccupazione lo scorso trimestre e a cui è stato detto di smetterla di essere negativo, non la solleverà in questa riunione, per quanto ben preparato sia.
Solo il primo è un problema di formazione. Gli altri due sono condizioni. Se si insegna la competenza ma si lasciano inalterate le condizioni, le persone tenderanno a ripetere comportamenti che l'ambiente di lavoro penalizza. Considera la tua attuale interpretazione della causa come un'ipotesi e verificala con qualche conversazione con gli ingegneri e consultando documenti di revisione recenti prima di impegnarti in un programma.
2. Definire le condizioni operative per la pratica
La pratica è valida solo se il luogo di lavoro lo consente. Prima di iniziare le prove, concordate questi punti con chi si occupa delle revisioni:
- Responsabilità approvate. Chi facilita, chi definisce la tempistica, chi si occupa delle azioni di follow-up? È fondamentale esplicitare i ruoli, in modo che il facilitatore non si trovi ad assumere un ruolo di autorità improvvisato.
- Come i leader accolgono le preoccupazioni. Se un ingegnere afferma "lo strumento di distribuzione mi ha permesso di saltare la fase canary", cosa dovrebbe fare il responsabile? Decidere la risposta in anticipo, ad esempio: ringraziarlo, registrare l'accaduto come fattore determinante e assegnare un'azione.
- La risposta del supervisore. Le esercitazioni del personale richiedono una risposta corrispondente da parte dei supervisori. Se si addestrano gli ingegneri a esprimere la propria opinione durante le revisioni, ma i loro responsabili continuano a chiedere "di chi è la colpa?", l'addestramento sarà inutile.
Un breve briefing per i manager sul processo di valutazione è importante quanto la formazione per i partecipanti. È fondamentale includere una chiara spiegazione di come i documenti di valutazione vengono e non vengono utilizzati nella gestione delle prestazioni.
3. Progettare un percorso di apprendimento basato sul comportamento
Le linee guida del Carnegie Mellon Eberly Center sugli obiettivi di apprendimento sottolineano l'utile punto che obiettivi, valutazioni e strategie didattiche dovrebbero essere allineati tra loro (Centro Eberly, Obiettivi di apprendimentoSi tratta di linee guida di progettazione, non di prove relative a uno strumento o a un risultato specifico, ma è un buon test per questo programma: se l'obiettivo è analizzare le prove e concordare miglioramenti verificabili, allora le sole domande di richiamo mnemonico non possono costituire la valutazione.
La tassonomia di Bloom è utile in questo contesto per descrivere le esigenze cognitive del compito: analizzare, valutare, creare. Descrive ciò che il compito richiede a una persona. Non spiega perché lo fa o non lo fa, quindi non va utilizzata per diagnosticare la motivazione.
Un percorso fattibile si articola in tre fasi.
| Stage | Azione dello studente | Spedizione |
|---|---|---|
| Preparazione | Leggi la tua procedura di revisione degli incidenti e un breve glossario (fattore scatenante, fattore contribuente, mitigazione, azione da intraprendere). Una breve diagnosi verifica i prerequisiti. | Studio autonomo. Il test di verifica serve solo a confermare i prerequisiti, non a ripassare le competenze. |
| Fai pratica | Analizzare un caso di incidente predisposto e concordare miglioramenti verificabili. È richiesta una risposta motivata, non una scelta a risposta multipla. | Esercitazioni interattive o facilitate su casi di studio, con feedback sulla qualità dell'analisi dei fattori contribuenti e sul follow-up. |
| Revisione e trasferimento | Discutete una scelta ambigua, quindi completate un nuovo caso o una revisione reale sotto supervisione. | Coaching in diretta o revisione asincrona. Verificare l'applicazione delle competenze dopo che i partecipanti hanno avuto il tempo di utilizzarle sul lavoro. |
Il caso deve essere realistico e deve essere validato da un ingegnere esperto. Un caso tecnicamente errato induce i revisori a diffidare dell'esercizio.
4. Analizzare lo scenario e fare un debriefing.
Ecco come potrebbe svolgersi una sessione di pratica con lo scenario delle 02:10. Il pacchetto di prove contiene il registro di distribuzione, la cronologia degli avvisi, la policy di paging, la pull request e il runbook, tutti fittizi.
Sollecitare il partecipante. "Spiegate perché l'ingegnere ha imposto la modifica proprio in quel momento. Indicate le prove che avete utilizzato. Diteci di quali ulteriori informazioni o supporto avreste bisogno prima di poter essere certi della vostra decisione."
Una risposta debole suona così: "L'ingegnere avrebbe dovuto controllare la fase di precompilazione". Nomina una persona, non cita nulla e non propone alcun cambiamento.
Una risposta più incisiva potrebbe essere questa: "Il log di distribuzione mostra che la modifica è stata implementata direttamente perché il passaggio canary è facoltativo nello strumento. La pull request ha avuto un solo revisore che l'ha approvata dopo una finestra di 20 minuti. La pagina è stata visualizzata 18 minuti dopo l'inizio degli errori perché la soglia di avviso era impostata su una media di cinque minuti. Vorrei sapere quante altre modifiche questo mese hanno saltato il passaggio canary e se agli ingegneri di reperibilità è mai stato comunicato che questo passaggio è facoltativo. Azioni proposte: rendere il passaggio canary obbligatorio per questo livello di servizio, responsabile: team della piattaforma, verifica: tentare un'implementazione canary saltata nell'ambiente di staging e confermare che sia bloccata; ridurre la finestra di avviso, responsabile: responsabile di reperibilità, verifica: riprodurre gli errori della scorsa settimana rispetto alla nuova soglia."
Osservate cosa lo rende migliore. Si basa su dati concreti, identifica vincoli e incertezze e si conclude con azioni verificabili.
Ora passiamo al debriefing. Non limitatevi a dare un punteggio. Chiedete:
- Quali prove supportavano le analisi e quali erano le tue supposizioni?
- Quali delle tue azioni il team avrebbe effettivamente l'autorità di compiere?
- Cosa renderebbe più facile ripetere questo comportamento nella tua prossima vera esperienza lavorativa? Cosa lo renderebbe più difficile?
La terza domanda è la più importante. Mette in luce le condizioni descritte nella sezione 2. Se tre partecipanti affermano "il mio responsabile chiederà chi è stato", avete individuato un vincolo che la formazione non può eliminare.
5. Misurare il comportamento e dare seguito alle azioni intraprese.
La questione chiave è quali prove dimostrerebbero che gli studenti sono in grado di analizzare i dati relativi agli incidenti e concordare miglioramenti verificabili. Ecco una griglia di valutazione da cui partire. Si tratta di una proposta da adattare con un ingegnere esperto, non di uno standard di preparazione validato.
| Criterio | Prove osservabili | 0 | 1 | 2 |
|---|---|---|---|---|
| Esecuzione dell'attività | Analizza le prove e concorda i miglioramenti; registra l'azione e le prove a supporto di essa. | Assente o non supportato | Parziale, con omissioni rilevanti | Completato e giustificato in base a criteri concordati. |
| Ragionamento | Spiega i vincoli, le alternative e l'incertezza; i fattori che contribuiscono vanno oltre l'ultima azione | Assente o non supportato | Parziale, con omissioni rilevanti | Completo e giustificato |
| Confini | Utilizza procedure approvate; chiede aiuto quando mancano informazioni o l'autorità necessaria. | Assente o non supportato | Parziale, con omissioni rilevanti | Completo e giustificato |
Definisci separatamente gli errori critici, ad esempio indicando una persona come causa o proponendo un'azione senza che ne sia responsabile. Un punteggio totale elevato non deve mai nascondere un errore critico.
Per la misurazione vera e propria:
- Qualità dell'analisi dei fattori contribuenti. Confronta le recensioni scritte prima del programma con quelle scritte dopo, valutate secondo gli stessi criteri da qualcuno che non sa quali siano le une e quali le altre. Utilizza sia casi di follow-up inediti che casi reali.
- Seguire attraverso. Calcola la percentuale di azioni che hanno un responsabile, un test e sono state completate, rispetto al totale delle azioni segnalate. Indica il denominatore e l'intervallo di tempo.
- Abbinare l'osservazione alle modifiche del processo. Partecipa a una vera e propria riunione di revisione. Verifica cosa è successo in seguito alle azioni previste.
Fate attenzione al volume delle segnalazioni. Se dopo il programma vengono registrati più problemi e quasi incidenti, ciò potrebbe significare che la sicurezza è migliorata, che la fiducia è aumentata o che un nuovo strumento ha semplificato la registrazione. Una caduta potrebbe significare meno problemi o una minore propensione a parlare. Analizzate cosa è cambiato nello stesso periodo prima di attribuire qualsiasi variazione alla formazione ed evitate di dichiarare un effetto che non avete misurato.
Le linee guida di Eberly sopra riportate illustrano il concetto di allineamento; non dimostrano che questo approccio riduca gli incidenti. Conservate i vostri dati di base e di follow-up e considerateli come prove locali.
Quali vincoli possono persistere anche dopo il miglioramento delle competenze?
Siate sinceri con gli sponsor riguardo a questi aspetti:
- I documenti di revisione possono comunque influenzare le decisioni relative alle prestazioni.
- I team sottoposti a pressioni per rispettare le scadenze potrebbero tralasciare azioni costose ma sensate.
- Le azioni tra squadre diverse possono bloccarsi perché nessuno controlla il confine del campo.
- È probabile che gli ingegneri senior continuino a dominare la discussione.
Un'analisi più approfondita non elimina questi problemi. Pianifica modifiche di processo separate per affrontarli.
Metterlo in pratica con AhaSlides
AhaSlides supporta l'apprendimento adattivo, l'apprendimento interattivo e il passaggio tra lezioni dal vivo e lezioni autogestite. In questo percorso, ciò potrebbe significare una fase di preparazione autonoma, una sessione di studio di caso dal vivo o guidata con domande a risposta aperta in modo che tutti si impegnino in un'analisi prima della discussione di gruppo, e un'attività di follow-up dopo la sessione. Le specifiche funzioni di authoring, valutazione e reporting dovrebbero essere verificate in una dimostrazione con il proprio caso prima di farvi affidamento, e qualsiasi elemento che coinvolga IA, simulatori o integrazioni con i propri strumenti di gestione degli incidenti dovrebbe essere considerato esterno fino a quando non viene mostrato.
Passo successivo: Prendi la rubrica qui sopra e adattala con uno dei tuoi ingegneri senior, quindi crea il caso che utilizzerai. Se desideri vedere come potrebbe funzionare una versione dal vivo e autogestita di questo percorso, Prenota una demo del flusso di lavoro AhaSlides una volta che il caso e la griglia di valutazione sono stati redatti.
