Runbook incidente: le informazioni che mancano sempre quando serve

Un alert dice che qualcosa non funziona. Raramente dice chi chiamare, quale servizio aziendale è coinvolto e quali azioni sono sicure. Quando queste risposte dipendono dalla memoria di una sola persona, i primi minuti dell'incidente diventano ricerca di informazioni.

Un runbook utile non deve documentare ogni possibilità. Deve permettere a una persona autorizzata di orientarsi, raccogliere evidenze e scegliere il passo successivo senza aumentare il danno.

Parti da un evento riconoscibile

“Problema sul server” è troppo generico. Meglio: “Il gestionale non risponde da due postazioni e il monitor applicativo fallisce”. Indica come verificare il sintomo, quali falsi positivi escludere e quale perimetro controllare.

Se il problema riguarda un singolo utente, il percorso può essere diverso da un'indisponibilità generale. Questa distinzione evita di riavviare infrastruttura condivisa per correggere un problema locale.

Le informazioni minime

Un documento breve dovrebbe contenere:

• servizio, proprietario e impatto sul lavoro;
• dipendenze essenziali e collegamento all'inventario aggiornato;
• controlli iniziali in sola lettura e risultato atteso;
• percorso autorizzato per ottenere gli accessi, senza password nel documento;
• condizioni che richiedono escalation immediata;
• azioni consentite, rischi e prerequisiti;
• percorso di recupero e verifica finale;
• responsabile, versione e data dell'ultima prova.

Conserva una copia di emergenza accessibile anche se autenticazione, rete o repository principale non funzionano. La disponibilità del runbook fa parte del piano, non è un dettaglio editoriale.

Un esempio compilabile

Per un servizio web interno, la prima parte potrebbe essere questa:

Evento: applicazione indisponibile da più postazioni
Impatto: inserimento ordini bloccato
Primo controllo: verificare monitor applicativo e connettività autorizzata
Evidenze: ora, utenti coinvolti, messaggio di errore, ultimo deploy
Escalation: referente applicativo e referente infrastruttura
Stop: nessun riavvio del database senza decisione del responsabile
Chiusura: accesso e operazione di prova validati dal referente utenti

È una struttura dimostrativa: nomi, controlli e soglie devono essere adattati. Non basta scrivere “controllare i log”: indica quale sorgente aprire, quale intervallo temporale osservare e quali informazioni raccogliere, evitando esportazioni indiscriminate di dati personali.

Non confondere diagnosi e intervento

Separa le verifiche in sola lettura dalle modifiche. Prima di un'azione distruttiva, documenta chi può autorizzarla e quali evidenze preservare.

Un riavvio può cancellare informazioni utili e peggiorare un incidente di sicurezza. Se emergono indizi di compromissione, il runbook deve indirizzare al percorso di incident response concordato, non incoraggiare pulizie improvvisate.

Anche la comunicazione va prevista: chi informa gli utenti, con quale frequenza e attraverso quale canale alternativo? “Stiamo lavorando” è meno utile di una comunicazione che distingue impatto confermato, attività in corso e prossimo aggiornamento.

Come provarlo senza un incidente vero

Organizza una simulazione da tavolo: una seconda persona legge il runbook e descrive ogni passo. Blocca la prova quando manca un accesso, un riferimento è ambiguo o un risultato atteso non è definito.

Se il contesto lo consente, esegui successivamente una prova tecnica isolata e autorizzata. Misura tempo per trovare il documento, tempo per orientarsi ed escalation corretta. Non usare la produzione come laboratorio senza un piano di change.

La chiusura non è “alert verde”

Il servizio è recuperato quando funziona per gli utenti e non restano condizioni critiche non gestite. Registra orari, azioni, validazione e attività successive. Il post-incidente deve aggiornare il runbook: altrimenti il prossimo turno ripeterà la stessa ricerca.

Hai un'attività critica che oggi si gestisce soltanto chiamando la persona giusta? Scopri Procedure Sprint 30: possiamo partire da quella procedura e renderne verificabili accessi, responsabilità e criteri di riuscita.