Home / Blog / Guida al runbook

Operazioni

Cos'è un runbook e come scriverne uno che il team userà davvero?

Un runbook è una guida passo passo per un'attività ricorrente o un incidente. Scopri la differenza con una SOP, cosa includere e come mantenerlo utile nel tempo.

5 ottobre 2026 · 6 min di lettura

Sono le 2 di notte, qualcosa si è rotto e l'unica persona che conosce la soluzione è su un aereo. Che si tratti di un pagamento fallito, di un server fermo o di una coda di ordini bloccata, l'ora successiva dipende da una cosa: la conoscenza è scritta o è solo nella testa di qualcuno? Il runbook è il modo per metterla per iscritto. Questa guida spiega cos'è un runbook, in cosa differisce da una SOP e come scriverne uno che le persone aprono davvero quando sono sotto pressione.

Cos'è un runbook?

Un runbook è una guida breve e pratica per gestire una situazione specifica: un'attività ricorrente, un guasto noto o un incidente. Dice a chi è di turno cosa ha innescato la situazione, chi ne è responsabile, cosa fare esattamente, come tornare indietro se le cose peggiorano e chi chiamare. Il test di un buon runbook è semplice: un collega competente che non ha mai fatto questa attività potrebbe seguirlo da solo, di notte, senza chiamarti?

Runbook e SOP: qual è la differenza?

I due si sovrappongono e molti team usano i termini come sinonimi. Una distinzione utile:

• Una SOP (procedura operativa standard) descrive come deve essere sempre svolto il lavoro di routine, ad esempio inserire un fornitore o chiudere il mese. Riguarda coerenza e conformità e di solito si legge in anticipo.
• Un runbook descrive come rispondere a un evento specifico o eseguire una determinata attività operativa, spesso sotto pressione di tempo. Riguarda rapidità e sicurezza e si legge sul momento.

Una SOP può essere approfondita e un po' formale. Un runbook deve essere diretto: frasi brevi, comandi esatti, nessun saggio introduttivo. Rimanda dal runbook alla SOP quando qualcuno ha bisogno del «perché».

Quando conviene scrivere un runbook?

Non si può documentare tutto, quindi parti da dove fa male. Scrivi un runbook quando:

• Un'attività è ripetuta e sbagliare costa caro, come l'esportazione mensile delle paghe o un rilascio.
• Un incidente è accaduto due volte. La seconda volta è il segnale.
• Solo una persona sa fare qualcosa. È un rischio, non una risorsa.
• Un'attività è rara ma critica, come il ripristino da backup. Nessuno ricorda le procedure rare.
• I nuovi arrivati fanno sempre le stesse domande.

Cosa deve contenere un runbook?

Mantieni le stesse cinque parti in ogni runbook, così tutti sanno sempre dove guardare.

• Innesco. Quando usare questo runbook: l'allarme, il sintomo o la data sul calendario. «Tasso di errore del checkout sopra il 5% per dieci minuti» è un innesco. «Quando le cose vanno male» no.
• Responsabile. Una persona o un ruolo indicato per nome, incaricato di mantenerlo accurato, più la data dell'ultima revisione.
• Passaggi. Un elenco numerato, un'azione per passaggio, nell'ordine in cui vanno eseguiti, ciascuno con il risultato atteso, così chi legge sa che ha funzionato.
• Rollback. Come tornare allo stato precedente se un passaggio fallisce o peggiora le cose. Scrivilo prima di averne bisogno.
• Escalation. Chi contattare se i passaggi non risolvono, in quale ordine, come e dopo quanti minuti di tentativi.

Come scrivere passaggi che le persone seguano?

Un'azione per passaggio

«Riavvia il servizio e controlla i log» sono due passaggi. Separali, così una persona sotto stress non ne salta metà.

Sii preciso

Indica il comando reale, il percorso esatto del menu o il link vero. «Apri il pannello di amministrazione» costringe a indovinare. Alle 2 di notte, copia e incolla batte l'interpretazione.

Descrivi com'è il successo

Dopo ogni passaggio chiave scrivi cosa dovrebbe vedere chi legge: «La pagina di stato mostra In esecuzione.» Se non è così, sa che deve fermarsi ed effettuare l'escalation invece di proseguire alla cieca.

Un breve esempio

Ecco lo schema di un runbook per una coda di ordini bloccata:

• Innesco: più di 50 ordini in attesa da oltre 15 minuti.
• Responsabile: la responsabile operations; ultima revisione a settembre.
• Passaggi: controllare la pagina di stato del gestore dei pagamenti; riavviare il worker della coda; verificare che il numero di ordini in attesa scenda entro cinque minuti.
• Rollback: se il riavvio crea ordini duplicati, mettere in pausa il worker e seguire la guida alla pulizia dei duplicati.
• Escalation: se la coda non si muove dopo 20 minuti, chiamare l'ingegnere reperibile, poi la direzione operativa.

Come si testa un runbook?

Un runbook non testato è un'ipotesi. Dallo a qualcuno che non l'ha scritto e chiedigli di seguirlo, idealmente in un ambiente sicuro o durante un'esercitazione, mentre tu osservi in silenzio. Ogni punto in cui esita, fa una domanda o improvvisa è una lacuna da colmare. Fai queste esercitazioni una o due volte l'anno per i runbook critici. Dopo ogni incidente reale, aggiungi una domanda alla revisione: il runbook ha aiutato e cosa lo avrebbe migliorato?

Come si tiene aggiornato un runbook?

• Assegna a ogni runbook un responsabile e una data di revisione. Trimestrale per quelli critici, due volte l'anno per gli altri.
• Aggiornalo dopo ogni utilizzo. Chi l'ha appena seguito sa meglio di chiunque cosa era sbagliato o mancava, quindi rendi la correzione parte della chiusura dell'incidente.
• Collegalo al cambiamento. Quando cambia un sistema, uno strumento o un fornitore, l'aggiornamento dei runbook correlati rientra nella stessa checklist.
• Fa' in modo che si trovi. Un runbook perfetto in una cartella dimenticata è inutile. Conservali in un unico posto, con nomi chiari e, se possibile, collegati dall'allarme stesso.

Dove conservare i runbook?

Per iniziare bastano un documento condiviso o una wiki. Più dello strumento conta che i runbook stiano vicini al lavoro. Se già monitori operazioni, attività e KPI in FulcrumGrid Command Center, puoi collegare ogni runbook al progetto o alla metrica che protegge e assegnare le date di revisione ai responsabili come a qualsiasi altra attività, così non scadono in silenzio. Ma parti da ciò che il tuo team aprirà davvero.

Scegli l'incidente che ha fatto più male lo scorso trimestre, scrivi il suo runbook questa settimana e provalo con una persona nuova. Un solo buon runbook farà più per il tuo team di un raccoglitore pieno di runbook mai testati.

Domande frequenti

Un runbook è la stessa cosa di un playbook?

I termini si sovrappongono. Molti team usano il runbook per azioni tecniche o operative esatte, passo passo, e il playbook per una strategia più ampia, come gestire un incidente grave o un'escalation di un cliente, che può rimandare a più runbook.

Quanto deve essere lungo un runbook?

Il più breve possibile, idealmente una o due pagine. Se serve di più, dividilo in runbook più piccoli o rimanda a materiale di contesto invece di seppellire i passaggi.

Chi deve scrivere il runbook?

Chi svolge l'attività oggi dovrebbe stendere la bozza, perché conosce i dettagli. Poi qualcuno che non l'ha mai fatta dovrebbe testarlo e correggerlo, perché individua le ipotesi mancanti.

Ogni quanto vanno rivisti i runbook?

Rivedi quelli critici ogni trimestre e gli altri due volte l'anno. Aggiorna qualsiasi runbook subito dopo l'uso in un incidente reale o quando cambia il sistema che copre.

← Torna al blog