Risposta moderna agli incidenti: dal rilevamento all'autopsia senza drammi

La convinzione più diffusa sugli incidenti di produzione è che ciò che conta davvero è la velocità di risposta: più velocemente il team reagisce, migliore sarà il risultato. Questa premessa sembra ragionevole finché non si osserva ciò che accade realmente nei primi minuti di una vera crisi: persone che duplicano gli sforzi, nessuno che coordina la comunicazione con le parti interessate, ingegneri che si scontrano a vicenda nei canali e decisioni critiche prese da chi ha gridato più forte. La velocità senza struttura non risolve gli incidenti, amplifica il caos.

Perché la maggior parte delle squadre improvvisa ancora

Quasi ogni team ha qualche runbook, qualche canale #incident su Slack e qualche vaga definizione di gravità. Il problema è che questi pezzi esistono isolatamente, senza costituire un processo coerente. Quando l'incidente accade realmente, nessuno sa chi è responsabile, chi parla con il cliente, chi documenta la sequenza temporale. Ogni persona agisce secondo il proprio istinto, che è diverso dall’istinto di chiunque lo circonda.

Questo non è un difetto di carattere. È un difetto di progettazione. Un processo di risposta agli incidenti non nasce naturalmente dalla buona volontà di ingegneri competenti. Deve essere deliberatamente progettato, documentato e, soprattutto, esercitato prima che sia veramente necessario. I team che testano il processo solo durante incidenti reali stanno imparando nel modo più costoso possibile.

L'anatomia di un incidente ben gestito

Un incidente strutturato inizia con la chiarezza della gravità. Non è sufficiente avere un SEV1, SEV2, SEV3 su carta: ogni livello deve avere criteri oggettivi – impatto finanziario, percentuale di utenti interessati, degrado dello SLA – e chiare implicazioni di risposta. SEV1 sveglia tutti alle tre del mattino. SEV3 può attendere l'orario lavorativo. Quando questi criteri non sono definiti, ciascun ingegnere in servizio decide autonomamente cosa è sufficientemente grave da provocare un'escalation.

Dalla dichiarazione di gravità, tre ruoli devono essere assegnati esplicitamente. L'Incident Commander, o IC, è colui che comanda la scena: non necessariamente la persona più tecnica nella stanza, ma colui che mantiene il processo, delega le indagini, prende decisioni quando c'è un vicolo cieco e determina quando l'incidente viene risolto. Il responsabile tecnico si concentra esclusivamente sulla diagnosi e sulla mitigazione, senza preoccuparsi della comunicazione o del coordinamento. Comms Lead si prende cura degli stakeholder interni ed esterni, alimentando pagine di stato e rispondendo ai messaggi dei leader che vogliono sapere cosa sta succedendo. Quando questi ruoli non sono chiari, il responsabile tecnico perde tempo a rispondere su Slack mentre il sistema è ancora in crash.

La trappola dell'eroe solitario di turno

Esiste una versione romanzata dell'incident Response in cui appare l'ingegnere più esperto, accede al terminale e, con una sequenza di comandi enigmatici, risolve tutto in venti minuti. Questo eroe esiste in alcune squadre, ed è esattamente il motivo per cui queste squadre hanno un problema serio.

L'eroe solitario crea dipendenza, accumula burnout e non trasferisce conoscenza. Quando va in vacanza, la squadra ha paura di qualsiasi avvertimento. Quando si dimette - e lo farà, perché gli eroi in servizio non durano a lungo - la squadra scopre che nessun altro sa come funziona l'infrastruttura critica. La risposta strutturata agli incidenti è, tra le altre cose, una strategia di distribuzione della conoscenza. Quando il processo esiste e i ruoli ruotano, più persone comprendono i sistemi, più persone si sentono capaci di rispondere e la dipendenza da una singola persona diminuisce.

Come costruire un processo che riduca l'MTTR senza distruggere il team

L’indicatore più importante per valutare lo stato del processo non è il numero di incidenti, ma l’MTTR, il tempo medio di ripristino. La riduzione dell’MTTR è una conseguenza di diverse decisioni di progettazione, non della pressione sul team affinché lavori più velocemente sotto stress.

La prima leva è la qualità degli alert. I team che dispongono di dozzine di avvisi rumorosi addestrano gli ingegneri a ignorare le notifiche, creando un rischio sistemico: quando arriva l'avviso che conta davvero, si perde nel rumore. Meno avvisi, più accuratezza, con un contesto sufficiente affinché l'ingegnere possa capire immediatamente cosa c'è che non va e dove guardare: questo riduce i primi minuti di disorientamento che costano molto MTTR.

La seconda leva è il runbook live. Non il documento creato una volta e dimenticato, ma una risorsa aggiornata dopo ogni incidente con la diagnostica che ha funzionato, i comandi che hanno aiutato, i falsi positivi da evitare. Il runbook non sostituisce il giudizio, ma elimina il tempo impiegato a reinventare soluzioni a problemi riscontrati in precedenza.

La terza leva è la pratica deliberata. Le esercitazioni antincendio – simulazioni di incidenti durante l’orario lavorativo, con scenari pianificati – fanno la differenza tra un team che conosce il processo a livello intellettuale e un team che può eseguirlo sotto pressione. La resistenza all'esecuzione di simulazioni di solito deriva dall'argomentazione secondo cui "abbiamo del vero lavoro da fare". Il costo di una squadra impreparata durante il SEV1 della domenica sera risponde chiaramente a questo argomento.

L'autopsia come sistema di apprendimento

La parte più sottovalutata della risposta agli incidenti è ciò che accade dopo il ripristino del sistema. L’autopsia irreprensibile – senza attribuire colpe individuali – esiste per una ragione tecnica, non solo etica: i sistemi complessi falliscono a causa di condizioni sistemiche, non a causa di un ingegnere che ha preso una decisione sbagliata alle due del mattino con informazioni incomplete. Incolpare le persone è una spiegazione che chiude la conversazione. Comprendere le condizioni che hanno reso possibile quel fallimento è ciò che impedisce il successivo.

Una buona autopsia ha una cronologia fattuale dell'incidente, un'analisi della causa principale che va oltre il sintomo immediato (cinque perché fino a raggiungere la condizione sistemica) e azioni correttive con un proprietario e una scadenza definiti. Ciò che distingue un’autopsia che genera apprendimento da una che è solo burocrazia è l’onestà delle domande: cosa non ha rilevato il sistema di monitoraggio? Quale decisione architettonica ha reso il raggio dell’esplosione così ampio? Il processo di distribuzione prevedeva delle barriere che avrebbero potuto impedirlo?