Usa questo modello
Un ottimo runbook fa la differenza tra un turno di reperibilità tranquillo e un disastro alle 3 del mattino. Con Trupeer, puoi risparmiare ore nella stesura dei runbook IT partendo da un modello di runbook gratuito, personalizzandolo con le tue linee guida del brand e trasformando lunghi runbook in walkthrough video che i tecnici reperibili possono consultare in pochi secondi.
Che cos'è un modello di runbook gratuito?
Un modello di runbook gratuito è una struttura riutilizzabile per la sequenza di passaggi necessaria a completare una specifica attività operativa: un deployment, un failover, una migrazione, un ripristino, una finestra di manutenzione programmata. Per i sistemi SAP, il nostro generatore di runbook SAP crea questi documenti a partire da una registrazione dell'attività.
La parola runbook va presa alla lettera. È un documento che viene eseguito ("run"), non semplicemente letto. Rimane aperto sullo schermo mentre si lavora, viene seguito punto per punto e il suo valore risiede interamente in ciò che consente di fare durante l'esecuzione, piuttosto che in ciò che descrive una volta archiviato.
Questo singolo aspetto distingue un buon runbook da un buon documento di procedura, ed è l'elemento che manca nella maggior parte dei modelli. Essi generano una descrizione ben organizzata di cosa fare: cosa necessaria, ma che costituisce solo circa la metà di ciò che un runbook deve essere.
L'altra metà è che un runbook è un modulo. Va compilato durante l'esecuzione, perché la registrazione di ciò che è effettivamente accaduto fa la differenza tra un'operazione a cui qualcuno può subentrare a metà percorso e una che deve essere riavviata o gestita tirando a indovinare.
Il formato segue questa logica. Un modello di runbook gratuito in formato Excel è ideale per la tabella dei passaggi, con le relative colonne per esito e timestamp, ed è la scelta finale della maggior parte dei team. Un modello di runbook gratuito in formato Word è adatto a runbook ricchi di contesto e spiegazioni discorsive attorno ai passaggi; il file modello di runbook gratuito per Microsoft Word è esattamente la stessa cosa con un nome più esteso. Un modello di runbook gratuito in PDF rappresenta invece l'archivio storico di un'esecuzione completata, piuttosto che un documento di lavoro attivo.
Runbook di deployment o runbook per gli incidenti?
Due documenti condividono lo stesso nome ma vengono usati in modi opposti, quindi è fondamentale stabilire quale stai scrivendo.
Un modello di runbook di deployment copre le attività pianificate. Un rilascio, una migrazione, un cutover, una finestra di manutenzione programmata. Viene eseguito dal primo all'ultimo passaggio, in ordine sequenziale, a un orario concordato, di solito da più persone e spesso a cavallo di un cambio turno. Le problematiche progettuali chiave sono sequenza, stato e passaggio di consegne (handover).
Un runbook per la gestione di incidenti o reperibilità copre il lavoro non pianificato. C'è un problema e qualcuno deve diagnosticarlo. Vi si accede da un punto imprevedibile, da parte di chiunque sia disponibile, sotto pressione, e non viene letto dall'inizio alla fine. L'obiettivo progettuale è trovare rapidamente la sezione pertinente, rendendolo più simile a un documento di consultazione che a uno script.
La maggior parte dei modelli disponibili fonde le due cose, senza soddisfare nessuna delle due esigenze. Un runbook diagnostico forzato in una sequenza numerata non consente l'accesso a metà percorso, e un runbook di deployment organizzato per sintomi perde la sequenzialità che lo rende sicuro.
Questa pagina è dedicata principalmente al primo tipo: attività pianificate, eseguite in sequenza, dove i fallimenti più costosi dipendono dallo stato e dal passaggio di consegne piuttosto che dalla diagnosi.
Come personalizzare questo modello in Trupeer
Passo 1: Apri la sezione Modelli
Accedi alla sezione Modelli dal menu di navigazione principale.
Passo 2: Seleziona e apri un modello
Fai clic sul modello con cui desideri lavorare per aprirlo.
Passo 3: Espandi la visualizzazione del modello
Se necessario, espandi la visualizzazione del modello per esaminare chiaramente l'intero layout e i dettagli.
Passo 4: Modifica il modello
Fai clic su Modifica per iniziare a personalizzare il modello selezionato.
All'interno dell'editor puoi:
Aggiungere nuove sezioni
Definire o aggiornare le regole di formattazione
Aggiungere un logo e regolarne la posizione e le relative impostazioni
Passo 5: Salva il modello personalizzato
Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato tra i tuoi contenuti.
Passo 6: Visualizza l'anteprima e perfeziona il modello
Quando vuoi controllare l'aspetto del modello personalizzato, apri l'Anteprima.
Dalla schermata di anteprima puoi continuare a effettuare modifiche dirette, se necessario, assicurandoti che il modello appaia esattamente come desideri.
Con un modello di runbook puoi:
Risparmiare ore di scrittura: Dimentica la pagina bianca grazie a una struttura studiata per le procedure operative.
Ridurre l'MTTR: Runbook chiari aiutano i tecnici reperibili a risolvere gli incidenti più rapidamente.
Rispettare l'identità del brand: Applica logo, font e colori aziendali usando il brand kit di Trupeer.
Formare nuovi tecnici: Abbina ai runbook walkthrough video per velocizzare l'onboarding del team operativo.
Uniformare le procedure tra i team: Utilizza lo stesso formato di runbook per ogni tipologia di incidente.
Coinvolgere team globali: Traduci i runbook in oltre 65 lingue con un solo clic.
Scrivi il runbook prevedendo il passaggio di consegne a metà percorso
Ecco il vincolo progettuale attorno a cui costruire tutto: a un certo punto dell'esecuzione, la persona che sta seguendo il runbook non sarà più quella che l'ha iniziato.
Un turno finisce. Qualcuno viene chiamato altrove. Una finestra operativa dura più del previsto. In qualsiasi operazione che si protrae per più di qualche ora, questo è normale e non eccezionale, ed è il momento esatto in cui i runbook falliscono con costi elevatissimi.
La domanda attorno a cui progettare è precisa: una seconda persona può subentrare al passaggio trentasette, senza alcun briefing a voce, e procedere in sicurezza?
Poter rispondere "sì" richiede quattro elementi che la maggior parte dei modelli non prevede.
La registrazione dell'esito effettivo per ogni passaggio, non solo di quello previsto. Una spunta indica solo che qualcuno ha fatto un clic; non dice a chi subentra cosa sia realmente accaduto.
Un timestamp per ogni passaggio, perché sapere quanto tempo fa è stato eseguito un passaggio è spesso l'informazione diagnostica più preziosa.
L'indicazione esplicita di quali passaggi siano rieseguibili in sicurezza. La prima domanda di chi subentra è se il passaggio precedente sia stato effettivamente completato. Se il passaggio può essere ripetuto in sicurezza, il dubbio non è più bloccante: un vantaggio inestimabile a fronte di uno sforzo minimo di registrazione.
Un punto di non ritorno dichiarato, superato il quale il rollback non è più possibile. Chi arriva a metà dell'esecuzione deve sapere da che parte di quella linea si trova prima di toccare qualsiasi cosa.
Aggiungendo questi quattro elementi, il passaggio di consegne verbale cessa di essere il meccanismo critico. È il documento stesso a diventare il passaggio di consegne: l'unica versione affidabile quando qualcuno è stanco, di fretta o non reperibile.
Cosa deve contenere un modello di runbook
Nove componenti. I quattro centrali sono quelli che distinguono un runbook da una semplice procedura.
Componente | A cosa serve |
|---|---|
Obiettivo e finestra temporale | Cosa realizza l'esecuzione, la finestra pianificata e il limite massimo oltre il quale annullare. |
Ruoli per questa sessione | Chi esegue, chi approva il punto di non ritorno, a chi fare escalation, con recapiti presenti sul documento e non altrove. |
Precondizioni | Cosa deve essere verificato prima del passaggio 1. Accessi, backup eseguiti e verificati, freeze operativo attivo, personale disponibile. |
Riga di stato | Passaggio corrente, chi lo sta eseguendo e da quando. Aggiornata in tempo reale, in cima al documento. |
Tabella dei passaggi | Passaggio, azione, esito previsto, esito effettivo, timestamp, rieseguibile in sicurezza. |
Punto di non ritorno | Evidenziato esattamente nel passaggio in cui si verifica, non citato solo nell'introduzione. |
Rollback | Definito per singola fase ove possibile, con la conferma dell'avvenuta prova pratica piuttosto che della sola redazione teorica. |
Sezione di passaggio consegne | Compilata prima che qualcuno lasci il turno. Cosa è fatto, cosa è in corso, cosa monitorare. |
Verifica | Come confermare che l'esecuzione sia effettivamente riuscita, con criteri sufficientemente specifici da poter fallire. |
L'ultimo punto merita particolare attenzione. Passaggi di verifica formulati come "verificare che il sito sia online" risultano superati anche quando il sito è online ma non funzionante: esattamente l'errore descritto di seguito.
Modello di runbook gratuito: la struttura da copiare
Compilato con un esempio reale anziché con segnaposto. Questo è un estratto da una migrazione di un sistema di gestione degli ordini.
Copia da qui.
Intestazione e finestra operativa. Nome dell'esecuzione, data, finestra pianificata, termine ultimo per l'annullamento e versione del runbook.
Migrazione gestione ordini. Sabato 14 giugno. Finestra 06:00 - 20:00. Termine ultimo per l'annullamento: 16:00, orario oltre il quale si effettua il rollback indipendentemente dallo stato di avanzamento. Runbook v9.
Ruoli per questa sessione. Con recapiti telefonici indicati sul documento.
Esecuzione: K Ferreira 06:00 - 14:00, poi D Attwood 14:00 - 20:00. Approvazione punto di non ritorno: Responsabile Engineering, 07700 900xxx. Escalation: Lead piattaforma on-call, 07700 900xxx. Referente di business per l'approvazione finale (decisione di go): Direttore Commerciale.
Precondizioni. Tutte da confermare prima del passaggio 1.
Backup completo del database eseguito e ripristino testato sull'istanza di standby. Code freeze attivo da giovedì. Accessi di produzione di entrambi gli esecutori verificati oggi (non presunti). Rollback provato in ambiente di staging il 7 giugno.
Riga di stato. Aggiornata man mano, posizionata in alto.
Attualmente al passaggio 37. In esecuzione dalle 13:48. Esecutore: K Ferreira. Punto di non ritorno non ancora superato.
Tabella dei passaggi.
# | Azione | Esito previsto | Esito effettivo | Ora | Rieseguibile in sicurezza |
|---|---|---|---|---|---|
33 | Arrestare i worker di acquisizione ordini | La profondità della coda smette di crescere, nessun consumer elencato | Confermato, 4 consumer arrestati | 13:12 | Sì |
34 | Reindicizzare il catalogo prodotti | Il job di indicizzazione risulta completato, il conteggio degli elementi indicizzati corrisponde a quello del catalogo (84.120) | Job segnalato come completato, conteggio 67.400, mancata corrispondenza | 13:48 | Sì |
35 | Verificare la corrispondenza tra conteggio indice e catalogo | I conteggi coincidono | Non coincidono, vedere passaggio 34, in riesecuzione | 14:05 | Sì |
36 | Deviare il traffico di lettura sul nuovo cluster | Il grafico del traffico mostra che il nuovo cluster riceve le letture | Sì | ||
37 | Migrare le tabelle dello storico ordini | I conteggi delle righe corrispondono alla sorgente con tolleranza zero | No, una migrazione parziale richiede prima un intervento di pulizia | ||
38 | PUNTO DI NON RITORNO. Rollback non più disponibile oltre questo passaggio. Spostare le scritture sul nuovo cluster | Le scritture compaiono esclusivamente sul nuovo cluster | No |
Rollback. Possibile fino al passaggio 37 incluso. Ripristino dal backup pre-esecuzione, reindirizzamento DNS, riavvio dei worker di acquisizione. Procedura testata in staging il 7 giugno da D Attwood.
Sezione di passaggio consegne. Da compilare prima che chiunque lasci la postazione.
Completato fino al passaggio 35. Il passaggio 34 ha fallito silenziosamente al primo tentativo con un disallineamento nel conteggio ed è stato rieseguito con successo; ora i conteggi coincidono a 84.120. Verificare nuovamente il conteggio dell'indice dopo il passaggio 36, dato che si è verificato un errore in precedenza. Nessuna attività pendente in corso. Punto di non ritorno non superato, rollback ancora disponibile.
Verifica. Con criteri sufficientemente specifici da poter evidenziare errori.
Il sito si carica. Il totale dei prodotti sulle pagine di categoria ammonta a 84.120. Effettuati dieci ordini di test end-to-end. Cronologia ordini visibile per cinque account noti. Il report di riconciliazione dei pagamenti viene eseguito e i dati quadrano.
Copia fino a qui.
Esempio di runbook: sessantuno passaggi e un passaggio di consegne di dieci minuti
Tamworth Retail Group, un rivenditore online, ha migrato il proprio sistema di gestione degli ordini durante una finestra programmata di quattordici ore di sabato.
Il runbook contava sessantuno passaggi. Era stato revisionato, provato in ambiente di staging ed era un documento redatto con grande cura. La tabella operativa contava tre colonne: numero del passaggio, azione e una casella di spunta.
Il primo tecnico ha eseguito i passaggi dall'uno al trentasette, ha effettuato il passaggio di consegne verbalmente in una decina di minuti al cambio turno ed è tornato a casa dopo una lunga giornata.
Il passaggio trentaquattro consisteva nella reindicizzazione del catalogo prodotti, un'operazione da circa quaranta minuti. Il tecnico l'ha avviata, non ha notato errori e ha spuntato la casella. In realtà il processo si era bloccato a circa l'ottanta percento senza restituire alcun messaggio di errore.
La seconda tecnica si è trovata davanti a un elenco di sessantuno passaggi con spunte sui primi trentasette. Non c'era traccia dell'esito prodotto da alcun passaggio, nessun timestamp e nessuna indicazione su quali operazioni potessero essere ripetute in sicurezza. Tutto ciò che precedeva il passaggio trentotto era, secondo il documento, semplicemente completato.
Ha quindi proseguito. Il catalogo era indicizzato solo in parte, il che significava che circa il dodici percento dei prodotti è risultato invisibile sul sito alla riapertura.
Lo smoke test finale ha confermato che il sito era raggiungibile. Non confrontando il numero di prodotti visibili con quello presente a catalogo, il test è risultato superato con successo.
Nessuno se ne è accorto fino a lunedì mattina, trentuno ore dopo, nel bel mezzo del fine settimana di vendite più intenso del trimestre. La stima delle vendite perse rispetto allo stesso weekend dell'anno precedente è stata di circa duecentoquarantamila sterline.
Non è stato possibile eseguire il rollback. Il punto di non ritorno era stato superato al passaggio quarantuno e, sebbene tutti i soggetti coinvolti lo sapessero in linea teorica, l'avvertenza era annotata in un paragrafo a pagina uno anziché in corrispondenza del passaggio critico.
La riscrittura del documento non ha aggiunto passaggi. Ha aggiunto colonne: esito effettivo, timestamp e l'indicazione di rieseguibilità in sicurezza per ogni voce. Una riga di stato in cima. Il punto di non ritorno è stato spostato dall'introduzione direttamente al passaggio interessato, in grassetto. È stata infine introdotta una sezione per il passaggio di consegne da compilare obbligatoriamente prima di lasciare la postazione, trasformando un colloquio verbale di dieci minuti in quattro righe scritte.
Alla migrazione successiva, il cambio turno è avvenuto alla nona ora. Il passaggio di consegne ha richiesto quattro minuti. La tecnica subentrante ha ripetuto tre passaggi su cui nutriva dubbi, proprio perché contrassegnati come rieseguibili in sicurezza, e l'intera operazione si è conclusa entro la finestra prevista.
Ripetere tre passaggi per precauzione costa pochi minuti. Non poterlo fare costa un intero fine settimana.
Come scrivere un runbook in sei passaggi
Scrivi i passaggi eseguendo l'attività, non a memoria. Un runbook redatto alla scrivania contiene i passaggi che l'autore ricorda e omette quelli che le sue mani compiono in automatico.
Assegna a ogni passaggio un esito previsto. Ciò che attesta visivamente la riuscita dell'operazione. Un passaggio senza un esito atteso esplicito non può essere verificato da nessun altro se non dal suo autore.
Contrassegna ogni passaggio come rieseguibile in sicurezza o meno. Come descritto sotto, questa è la colonna più economica da aggiungere e la più preziosa durante un passaggio di consegne.
Colloca il punto di non ritorno in corrispondenza del passaggio specifico, in grassetto. Non nell'introduzione, dove verrebbe letto una sola volta da qualcuno diverso da chi ne ha davvero bisogno.
Aggiungi le colonne da compilare durante l'esecuzione. Esito effettivo e timestamp. Se non sono previsti nel documento, non verranno registrati da nessuna parte.
Effettua una prova pratica, compreso il rollback. Un piano di rollback solo scritto su carta è una semplice ipotesi. Fai le prove in staging con chi dovrà effettivamente eseguirlo, non con chi lo ha scritto.
Il primo punto è quello che distingue i runbook utili da quelli solo apparentemente validi. Scrivere mentre si opera permette di intercettare il clic non documentato, la credenziale che era già negli appunti e la scheda del browser che doveva restare aperta.
Contrassegnare i passaggi rieseguibili in sicurezza e il punto di non ritorno
Questi due indicatori svolgono la maggior parte del lavoro durante un passaggio di consegne, eppure nessuno dei due compare nei modelli convenzionali.
Rieseguibile in sicurezza. Per ciascun passaggio, stabilire se possa essere eseguito due volte senza provocare danni. Riavviare un servizio arrestato, rieseguire un'indicizzazione, riapplicare una configurazione già attiva: di solito sì. Inviare un'email a un cliente, incrementare un contatore, migrare record in una tabella priva di deduplicazione: di solito no.
Il valore sta nell'eliminare l'interrogativo a cui chi subentra non può rispondere: "Il passaggio precedente è terminato davvero?". Se la risposta è irrilevante perché ripeterlo è innocuo, nessuno dovrà tentare di accertarlo sotto stress e con informazioni parziali.
Quando un passaggio non è rieseguibile in sicurezza, specifica cosa controllare prima. L'indicazione "No, verificare il conteggio delle righe prima di ripetere" è infinitamente più utile di un semplice "No", perché chi legge ha già deciso che deve intervenire.
Il punto di non ritorno. Ogni operazione che altera lo stato di un sistema ne ha uno. È il punto oltre il quale il rollback non è più possibile, o non è più economicamente conveniente rispetto all'andare avanti.
Evidenzialo sul passaggio stesso in modo visivamente netto, affinché chi scorre il documento capisca subito da che parte si trova. Specifica chi è autorizzato ad approvarne il superamento e annota l'ora del passaggio nella colonna dell'esito effettivo. Molte operazioni ne hanno più di uno: in tal caso, contrassegnali singolarmente indicando quali opzioni precludono.
La ragione per cui registrare l'avvenuto superamento (e non solo evidenziare il passaggio) è che, a seguito di un incidente, la domanda su quando la decisione sia diventata irreversibile verrà puntualmente posta, e nessuno la ricorderà con precisione.
Varianti del modello di runbook
La struttura di base rimane valida, ma cambia la priorità degli elementi.
Modello di runbook di deployment. L'esempio descritto sopra. Sequenziale, pianificato, articolato spesso su più turni: la tipologia in cui la gestione del passaggio di consegne è più critica.
Runbook di disaster recovery. Eseguito raramente e nelle condizioni peggiori possibili, tende a diventare obsoleto silenziosamente tra un utilizzo e l'altro. Il requisito cardine è la simulazione programmata: un runbook di DR non testato da un anno va considerato inaffidabile per definizione.
Runbook per incidenti e reperibilità (on-call). Utilizzato a partire da punti non prevedibili anziché dall'inizio alla fine. Va strutturato per sintomi anziché per sequenza temporale, mantenendo ogni voce sintetica e rimandando a documentazione di dettaglio tramite link piuttosto che includendola per intero.
Runbook per manutenzione programmata. Ripetuto regolarmente, è l'unica variante che migliora sul campo col tempo, a patto che qualcuno lo aggiorni durante l'esecuzione stessa anziché rimandare l'aggiornamento a dopo.
Runbook di onboarding e offboarding. Spesso il primo a essere redatto in un team: la sequenza è stabile e il costo di un passaggio saltato (specie nell'offboarding) si traduce in una falla di sicurezza anziché in un semplice disagio.
Per tutto ciò che riguarda sistemi regolamentati, transazioni finanziarie o controlli legati alla sicurezza, il runbook si inserisce solitamente in un processo formale di change management con specifici requisiti di approvazione e tracciamento, che hanno la precedenza su quanto riportato in questa pagina.
Runbook, istruzione di lavoro o SOP?
Tre tipologie documentali affini che è fondamentale non confondere, poiché una scelta errata produce contenuti corretti ma inutilizzabili nella pratica.
Una procedura operativa standard (SOP) descrive un processo a livello macro definendo chi fa cosa e in quale ordine, coinvolgendo solitamente ruoli differenti e spesso estendendosi su più giorni. La si consulta per comprendere il flusso complessivo.
Un'istruzione operativa (work instruction) approfondisce nel dettaglio una singola attività a beneficio di chi la esegue sul campo, ed è redatta per guidare anche personale privo di esperienza pregressa. Il modello di istruzioni operative è dedicato specificamente a questa tipologia.
Un runbook è un'istruzione operativa che funge contemporaneamente da registro delle operazioni. Viene seguito e compilato nello stesso momento, copre generalmente più attività in ordine tassativo e dispone di colonne create appositamente per documentare l'avanzamento.
Se il documento viene letto prima dell'intervento e archiviato al termine, si tratta di una procedura. Se invece resta aperto durante le operazioni e risulta modificato al termine rispetto all'inizio, è a tutti gli effetti un runbook.
Mantenere aggiornati i runbook
I runbook si degradano più in fretta di qualsiasi altra documentazione perché descrivono sistemi in continua evoluzione, e la loro obsolescenza resta invisibile fino al momento dell'errore operativo.
L'unica strategia efficace è aggiornarli contestualmente all'esecuzione, non a posteriori. Chi sta eseguendo il runbook ha il documento sotto gli occhi, si è appena accorto che il passaggio dodici richiede un'ulteriore conferma ed è l'unico che può annotarlo senza sforzo. Bastano dieci secondi subito per evitare un'ora di disorientamento al ciclo successivo.
Rendi ufficiale questa prassi indicandola chiaramente in cima al documento, e considera un runbook privo di modifiche dopo un'esecuzione reale come un segnale sospetto, non come una prova di perfezione.
L'automazione rappresenta la seconda strada, ma va valutata con realismo. Automatizzare un'azione elimina contemporaneamente l'errore umano e la necessità di documentazione: un traguardo eccellente, dove applicabile. Ciò che non elimina è l'utilità del documento di contesto, poiché qualcuno dovrà comunque sapere cosa fare qualora l'automazione fallisca, e quel qualcuno avrà meno manualità operativa rispetto al passato. Automatizza le singole operazioni, conserva il runbook e assicurati che contempli il fallimento della procedura automatizzata.
Cosa non può risolvere un modello di runbook gratuito
Un runbook redatto a memoria. Nessun template può fare emergere i passaggi che l'autore compie in automatico senza riflettere. Solo la redazione contestuale all'esecuzione pratica ci riesce.
Un rollback mai collaudato. Una procedura di ripristino mai eseguita è una mera supposizione, e il pieno di una migrazione compromessa è il contesto peggiore per metterla alla prova.
Una semplice checklist spacciata per runbook. Gran parte del materiale scaricabile gratuitamente come modello di runbook non è altro che una procedura numerata con caselle di controllo: un documento fondamentalmente diverso e molto più limitato.
Verifiche strutturate in modo tale da non poter fallire. Il controllo "accertarsi che il sito sia attivo" risulta superato anche se il portale è raggiungibile ma non funzionante. Ciascun passaggio di verifica deve essere formulato con parametri talmente precisi da renderne plausibile il fallimento.
Una finestra priva di orario limite per l'annullamento. Senza una scadenza tassativa, un intervento problematico viene portato avanti a oltranza, poiché interrompersi appare psicologicamente più oneroso che tentare l'azione successiva. Definisci il limite temporale prima di cominciare, in assenza di condizionamenti emotivi.
Mostra l'operazione anziché descriverla
I runbook vengono eseguiti da persone che li utilizzano di rado. Una migrazione ha luogo due volte l'anno; un test di disaster recovery avviene con frequenza annuale. Chi se ne occupa l'ha fatto forse una volta soltanto, o mai prima d'ora.
È lo scenario in cui le procedure scritte risultano meno efficaci: chi legge è costretto a ricostruire schermate e stati della console a partire da un testo descrittivo. Il disallineamento tra l'intenzione di chi scrive e la rappresentazione mentale di chi legge è il luogo esatto in cui si annidano i passaggi omessi.
L'AI di Trupeer azzera questa distanza. Basta eseguire la procedura una volta in ambiente di staging registrando la sessione: l'output sarà una guida dettagliata passaggio per passaggio con schermate già acquisite e posizionate, affiancata da un video allineato all'identità visiva del tuo brand. Il testo diventa il runbook operativo; il video offre a chi deve eseguire l'attività il materiale di preparazione ideale da visionare il giorno prima, una risorsa che attualmente nessuno ha il tempo di produrre da zero.
Registra. Personalizza con il tuo brand. Traduci. Trasforma con Trupeer.
Ne derivano due vantaggi fondamentali per i runbook. La prova pratica genera la documentazione come naturale sottoprodotto anziché come compito accessorio: l'unico modo per garantire che venga realmente prodotta. E al mutare dell'infrastruttura, registrare nuovamente la prova è molto più rapido che ritagliare e sostituire screenshot: il runbook ha così molte più probabilità di rimanere aggiornato quando serve davvero.
I contenuti confluiscono nella tua knowledge base e possono essere impiegati per la formazione di chi coprirà il turno successivo. Riscontri di verifica e criteri di controllo qualità della sessione trovano posto nel piano di QA. L'omogeneità visiva con gli altri documenti aziendali si ottiene configurando una sola volta il brand kit, mentre l'impostazione iniziale è dettagliata nella guida alla configurazione dei modelli di documento.
Domande frequenti
Esiste un modello di runbook gratuito in formato Excel?
Excel rappresenta la soluzione scelta dalla maggior parte dei team e si adatta perfettamente allo scopo, dato che il nucleo di un runbook è una matrice da compilare in tempo reale. Un modello di runbook in Excel accoglie in modo naturale i campi per passaggio, esito atteso, esito effettivo, timestamp e rieseguibilità in sicurezza, permettendo inoltre a più operatori di monitorare lo stesso foglio durante l'esecuzione.
Due accorgimenti pratici: bloccare la riga di intestazione e inserire la riga di stato nelle prime due righe in alto, così che rimanga visibile durante lo scorrimento. Un modello di runbook in Excel in cui il passaggio corrente scompare scorrendo la pagina perde gran parte della sua utilità nel passaggio di consegne.
Esiste un modello di runbook gratuito in formato Word?
Word è indicato per runbook che richiedono un ampio inquadramento attorno ai singoli passaggi: note architetturali, decisioni pregresse, dettagli per le escalation. Struttura il file Word del modello gratuito anteponendo le sezioni descrittive alla tabella dei passaggi operativi.
Il punto critico resta la compilazione in corso d'opera. Aggiornare una tabella in Word è meno fluido che compilare le celle di un foglio di calcolo, e durante una migrazione critica questo attrito finisce per scoraggiare la registrazione degli esiti effettivi. Molti team scelgono di mantenere la parte contestuale in un documento Word, rimandando a un foglio di calcolo collegato per la tabella delle azioni.
Esiste un modello di runbook gratuito per Microsoft Word?
Sì, con i medesimi pro e contro. Il file per Microsoft Word rappresenta l'opzione ideale se il runbook deve essere sottoposto a revisione e approvazione formale nell'ambito di una procedura di Change Management, poiché i documenti di testo si integrano meglio nei flussi di approvazione rispetto ai fogli di calcolo.
Se scegli questa impostazione, abbi cura di inserire comunque le colonne per l'esito effettivo e il timestamp. Un runbook approvato senza questi campi verrà eseguito senza compilarli, privandoti delle registrazioni indispensabili.
Esiste un modello di runbook per il deployment?
Il modello di runbook per il deployment coincide con la versione sequenziale descritta in questa pagina: attività pianificate, condotte passo dopo passo, che coprono frequentemente più turni di lavoro.
Quattro elementi distinguono un modello di qualità da uno generico: l'indicazione del punto di non ritorno posizionata sul passaggio critico anziché nell'introduzione; la segnalazione di rieseguibilità sicura per ciascuna azione; le colonne dedicate a esito effettivo e timestamp; una sezione di passaggio consegne da compilare prima di lasciare la postazione. Caratteristiche pressoché assenti nella quasi totalità dei modelli diffusi in rete.
Esiste un modello di runbook gratuito in formato PDF?
Il PDF risponde a scopi di archiviazione, non di operatività diretta. A sessione conclusa, esporta il runbook compilato in PDF e allegalo al ticket di change: un runbook ultimato e corredato di orari ed esiti effettivi costituisce la documentazione storica più accurata che si possa ottenere.
Non eseguire l'attività direttamente da un documento PDF: il runbook richiede l'inserimento continuo di dati durante le operazioni, e qualsiasi strumento che impedisca la digitazione immediata porterà all'omissione dei dati di esecuzione.
I modelli gratuiti di runbook scaricabili online sono validi?
Impostare la tabella richiede una decina di minuti: ricorrere a un file pronto da scaricare offre un risparmio trascurabile, considerando inoltre che la maggioranza dei documenti disponibili sono semplici procedure denominate impropriamente runbook.
Prima di adottarne uno, fai una verifica fondamentale: accertati che la tabella operativa contenga una colonna in cui annotare l'esito reale delle operazioni. La presenza della sola casella di spunta indica una semplice checklist, e la tesi centrale di questa pagina è che la differenza tra questi due strumenti sia proprio l'elemento da cui dipende la riuscita di un passaggio di consegne.
Quanto deve essere lungo un runbook?
Tanto quanto l'operazione richiede: per una migrazione di una certa entità sono necessarie diverse decine di passaggi. L'estensione complessiva non rappresenta un problema.
L'aspetto cruciale da presidiare è la granularità delle azioni: ogni passaggio deve corrispondere a una singola azione con un esito chiaramente verificabile. Raggruppare più operazioni all'interno della stessa voce impedisce un passaggio di consegne parziale, poiché chi subentra non avrà modo di stabilire quali tra i compiti aggregati siano stati effettivamente eseguiti: l'esatta criticità che il documento ha lo scopo di evitare.
Chi deve redigere il runbook?
Le stesse persone chiamate a eseguirlo sul campo, redigendolo mentre completano la procedura in un ambiente non di produzione. Un runbook steso da un architect ed eseguito da un tecnico operativo risulterà privo esattamente di quei passaggi che l'architect non compie di persona.
Fai poi testare la bozza in staging da una seconda persona, senza l'assistenza dell'autore. Qualsiasi dubbio o richiesta di chiarimento evidenzia una lacuna: la soluzione consiste nell'integrarla per iscritto nel testo anziché limitarsi a rispondere a voce.
