Prima o poi ogni sistema si ferma. Un certificato scade, un disco si riempie, un rilascio introduce un errore, un fornitore ha un problema. La differenza tra un team maturo e uno improvvisato non sta nel numero di guasti, ma nel modo in cui li affronta: quanto rapidamente se ne accorge, quanto ordinatamente reagisce e quanto impara dopo.
Durante il guasto: l'ordine conta più della velocità
Nei primi minuti di un disservizio l'istinto spinge tutti a mettere le mani ovunque. Il risultato è spesso caos: tre persone modificano la stessa configurazione, nessuno sa cosa è stato già provato, gli utenti non ricevono notizie. Qualche regola semplice cambia completamente la situazione.
1. Dichiarare l'incidente
Il primo passo è riconoscere che c'è un problema e dirlo apertamente, in un canale dedicato. Aspettare di essere sicuri che sia grave fa solo perdere tempo. Dichiarare un incidente che poi si rivela piccolo non costa nulla.
2. Assegnare i ruoli
Anche in un team piccolo conviene distinguere almeno tre funzioni, che possono coincidere se le persone sono poche:
- chi coordina: non tocca i sistemi, ma tiene il quadro, decide le priorità e assegna i compiti;
- chi interviene: indaga e applica le correzioni, comunicando al coordinatore cosa sta per fare;
- chi comunica: aggiorna utenti, clienti e responsabili a intervalli regolari.
Separare il coordinamento dall'intervento tecnico è il cambiamento con il maggiore impatto: chi è immerso nei log non riesce anche a pensare al quadro generale.
3. Ripristinare prima di capire
L'obiettivo immediato è far tornare il servizio, non trovare la causa. Se il problema è comparso dopo un rilascio, si torna alla versione precedente anche senza sapere perché la nuova non funziona. Se un server è in difficoltà, si sposta il traffico altrove. La diagnosi approfondita viene dopo, con calma e con i dati raccolti.
4. Annotare tutto
Un registro cronologico, anche scritto in fretta nel canale dell'incidente, è prezioso: orario di ogni osservazione, ipotesi, azioni e loro effetti. Serve durante il guasto, per non ripetere tentativi già fatti, e dopo, per ricostruire cosa è successo.
5. Comunicare con regolarità
Gli utenti tollerano un disservizio molto meglio se sanno che qualcuno se ne sta occupando. Un aggiornamento ogni mezz'ora, anche solo per dire «stiamo ancora lavorando, prossimo aggiornamento alle 15», vale più di un lungo silenzio seguito da una spiegazione perfetta. Una pagina di stato ospitata fuori dalla propria infrastruttura resta raggiungibile anche quando il servizio principale è fermo.
Classificare la gravità
Stabilire in anticipo dei livelli di gravità evita discussioni nel momento sbagliato.
| Livello | Esempio | Risposta |
|---|---|---|
| Critico | Servizio principale irraggiungibile per tutti | Intervento immediato a qualsiasi ora |
| Alto | Funzione importante non disponibile o molto lenta | Intervento immediato in orario esteso |
| Medio | Problema limitato con alternativa disponibile | Intervento nel normale orario di lavoro |
| Basso | Difetto minore senza impatto rilevante | Pianificato tra le attività ordinarie |
Dopo il guasto: il postmortem
Quando il servizio è tornato e la tensione è calata, arriva la parte più importante: capire perché è successo e cosa cambiare. Il documento che raccoglie questa analisi si chiama postmortem.
Senza colpe
Il principio fondamentale è che il postmortem sia senza colpe (blameless). Non si cerca chi ha sbagliato, ma perché il sistema ha permesso che un errore umano, inevitabile, causasse un danno. Se una persona ha cancellato il database di produzione credendo di essere su quello di test, la domanda giusta non è «chi è stato?», ma «perché i due ambienti erano così facili da confondere, e perché la cancellazione non chiedeva conferma?».
Questo approccio non è indulgenza. È l'unico modo per ottenere informazioni sincere: se raccontare un errore porta a una punizione, le persone smettono di raccontarli, e gli stessi problemi si ripetono.
Cosa contiene
Un buon postmortem è breve e concreto:
- Riepilogo: cosa è successo, per quanto tempo, chi ne è stato colpito.
- Cronologia: i momenti chiave, dal primo segnale al ripristino completo.
- Cause: la catena di eventi e condizioni che ha portato al guasto. Raramente c'è una causa sola.
- Cosa ha funzionato e cosa no: nella rilevazione, nella risposta, nella comunicazione.
- Azioni correttive: ciascuna con un responsabile e una scadenza.
Azioni che cambiano davvero le cose
Le azioni correttive più efficaci modificano il sistema, non il comportamento delle persone. «Fare più attenzione» non è un'azione. «Aggiungere un avviso quando un certificato scade entro quindici giorni» lo è. Lo stesso vale per «automatizzare il rinnovo», «aggiungere una conferma alle operazioni distruttive», «separare le credenziali di test e produzione».
Nel mio lavoro la misura della qualità di un postmortem è semplice: dopo qualche mese, quante delle azioni indicate sono state davvero completate? Un documento perfetto le cui azioni restano in sospeso non ha migliorato nulla.
In sintesi
- Dichiara subito l'incidente e separa chi coordina da chi interviene e da chi comunica.
- Ripristina il servizio prima di cercare la causa, anche tornando alla versione precedente.
- Tieni un registro cronologico e aggiorna gli utenti a intervalli regolari.
- Scrivi un postmortem senza colpe che analizzi perché il sistema ha permesso l'errore.
- Definisci azioni correttive concrete, con responsabile e scadenza, e verifica che vengano completate.
