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 video tutorial che gli ingegneri reperibili possono scansionare in pochi secondi.

Che cos'è un modello di runbook gratuito?

Un modello di runbook gratuito è una struttura riutilizzabile per la sequenza di passaggi che consente di portare a termine una specifica attività operativa: una distribuzione, un failover, una migrazione, un ripristino, una finestra di manutenzione programmata.

La parola runbook va presa alla lettera. Questo è un documento che viene eseguito, non letto. Rimane aperto su uno schermo mentre il lavoro si svolge, viene seguito in ordine e il suo valore risiede interamente in ciò che fa durante l'esecuzione, piuttosto che in ciò che dice quando viene archiviato.

Questo singolo fatto distingue un buon runbook da un buon documento di procedura, ed è l'elemento che manca alla maggior parte dei modelli. Producono una descrizione ben organizzata di cosa fare, il che è necessario e rappresenta circa la metà di ciò che un runbook deve essere.

L'altra metà è che un runbook è un modulo. Viene compilato mentre viene eseguito, perché la registrazione di ciò che è realmente accaduto è ciò che fa la differenza tra un'operazione a cui qualcuno può unirsi a metà strada e una che deve essere riavviata o indovinata.

Il formato segue questo principio. Un file Excel come modello di runbook gratuito è adatto alla tabella dei passaggi con le relative colonne dei risultati e dei timestamp, ed è ciò che la maggior parte dei team finisce per utilizzare. Una versione Word di un modello di runbook gratuito è adatta a runbook con un contesto pesante e molta prosa attorno ai passaggi, e un file Microsoft Word di modello di runbook gratuito è la stessa cosa sotto il suo nome più lungo. Un PDF di modello di runbook gratuito è una registrazione archiviata di un'esecuzione completata piuttosto che un documento di lavoro.

Runbook di distribuzione o runbook di incidenti?

Due documenti condividono lo stesso nome ma vengono utilizzati in modi opposti, quindi decidi quale stai scrivendo.

Un modello di runbook di distribuzione copre il lavoro pianificato. Un rilascio, una migrazione, un cutover, una finestra di manutenzione programmata. Viene eseguito dal primo passaggio fino alla fine, in ordine, in un momento noto a tutti, solitamente da più di una persona e spesso a cavallo di un cambio di turno. Il problema di progettazione è la sequenza, lo stato e il passaggio di consegne.

Un runbook di incidenti o di reperibilità copre il lavoro non pianificato. Qualcosa non va e qualcuno sta effettuando una diagnosi. Vi si accede in un punto imprevedibile, da chiunque sia disponibile, sotto pressione, e non viene letto in ordine. Il problema di progettazione è trovare rapidamente la sezione pertinente, il che lo rende più simile a un documento di consultazione che a uno script.

La maggior parte dei modelli pubblicati unisce le due cose e non serve bene nessuna delle due. Un runbook diagnostico forzato in una sequenza numerata non può essere iniziato a metà, e un runbook di distribuzione organizzato come una serie di sintomi perde l'ordine che lo rende sicuro.

Questa pagina riguarda principalmente il primo caso. Lavoro pianificato, eseguito in ordine, in cui i fallimenti costosi riguardano lo stato e il passaggio di consegne piuttosto che la diagnosi.

Come personalizzare questo modello in Trupeer

Passaggio 1: Apri la sezione Modelli

Vai alla sezione Modelli dalla navigazione principale.

Passaggio 2: Seleziona e apri un modello

Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.

Passaggio 3: Espandi la visualizzazione del modello

Se necessario, espandi la visualizzazione del modello per vedere chiaramente l'intero layout e i dettagli.

Passaggio 4: Modifica il modello

Fai clic su Modifica per iniziare a modificare 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

Passaggio 5: Salva il tuo modello personalizzato

Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.

Passaggio 6: Visualizza l'anteprima e perfeziona il modello

Quando vuoi vedere come appare il tuo modello personalizzato, apri l'Anteprima.

Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente se necessario, assicurandoti che il modello appaia esattamente come desideri.

Con un modello di runbook puoi:

• Risparmiare ore nella scrittura: Salta la pagina bianca con una struttura creata appositamente per le procedure operative.

• Ridurre l'MTTR: Runbook chiari aiutano gli ingegneri reperibili a risolvere gli incidenti più velocemente.

• Rimanere in linea con il brand: Applica il tuo logo, i tuoi caratteri e i tuoi colori utilizzando il kit del brand di Trupeer.

• Formare nuovi ingegneri: Associa i runbook a video tutorial per inserire più rapidamente il personale operativo.

• Standardizzare tra i team: Utilizza lo stesso formato di runbook per ogni tipo di incidente.

• Raggiungere team globali: Traduci i runbook in oltre 65 lingue con un solo clic.

Scrivi il runbook in modo che possa essere consegnato a metà

Ecco il vincolo di progettazione su cui vale la pena costruire. Ad un certo punto durante l'esecuzione, la persona che esegue il runbook smetterà di essere la persona che lo ha avviato.

Un turno finisce. Qualcuno viene chiamato altrove. Una finestra temporale dura più del previsto. In qualsiasi operazione che duri più di qualche ora, questo è normale piuttosto che eccezionale, ed è il momento in cui i runbook falliscono in modo costoso.

La domanda su cui progettare è precisa. Una seconda persona può riprendere questo processo al passaggio trentasette, senza briefing verbale, e procedere in sicurezza?

Rispondere di sì richiede quattro cose che la maggior parte dei modelli non ha.

Un risultato effettivo registrato per passaggio, non solo uno previsto. Una spunta significa che qualcuno ha fatto clic su qualcosa. Non dice alla persona successiva cosa è successo.

Un timestamp per passaggio, perché quanto tempo fa è stato eseguito un passaggio è spesso il dato diagnostico più utile disponibile.

Un'indicazione esplicita di quali passaggi possono essere rieseguiti in sicurezza. La prima domanda di chi subentra è se il passaggio precedente sia effettivamente terminato. Se il passaggio può essere ripetuto in sicurezza, quella domanda cessa di avere importanza, il che vale molto di più del costo per registrarlo.

Un punto di non ritorno dichiarato. Oltre il quale il rollback non è più disponibile. Qualcuno che arriva a metà esecuzione deve sapere da quale parte di quella linea si trova prima di toccare qualsiasi cosa.

Aggiungi queste quattro cose e il passaggio di consegne verbale smette di essere il meccanismo principale. Il documento stesso diventa il passaggio di consegne, che è l'unica versione che sopravvive quando qualcuno è stanco, di fretta o non disponibile.

Cosa deve contenere un modello di runbook

Nove componenti. I quattro centrali sono quelli che distinguono un runbook da una procedura.

L'ultimo merita attenzione. I passaggi di verifica scritti come "conferma che il sito sia attivo" passano anche quando il sito è attivo ma non funzionante, che è il fallimento descritto di seguito.

Modello di runbook gratuito: la struttura da copiare

Compilato con un esempio reale anziché con segnaposto. Questo è un estratto dalla migrazione di un sistema di gestione degli ordini.

Copia da qui.

Intestazione e finestra temporale. Nome dell'esecuzione, data, finestra pianificata, termine ultimo per l'annullamento e versione di questo runbook.

Migrazione gestione ordini. Sabato 14 giugno. Finestra dalle 06:00 alle 20:00. Termine ultimo per l'annullamento 16:00, dopodiché effettueremo il rollback indipendentemente dai progressi. Runbook v9.

Ruoli per questa esecuzione. Con i numeri di telefono direttamente sul documento.

In esecuzione: K Ferreira dalle 06:00 alle 14:00, poi D Attwood dalle 14:00 alle 20:00. Punto di no ritorno approvato da: Responsabile Engineering, 07700 900xxx. Escalation: lead della piattaforma di reperibilità, 07700 900xxx. Contatto aziendale per la decisione di procedere: Direttore Commerciale.

Precondizioni. Tutte confermate prima del passaggio uno.

Backup completo del database eseguito e ripristino testato sull'istanza di standby. Blocco del codice in vigore da giovedì. Entrambi gli esecutori hanno l'accesso in produzione verificato oggi, non presunto. Rollback provato in staging il 7 giugno.

Riga di stato. Aggiornata man mano che procedi, mantenuta in alto.

Attualmente al passaggio 37. In esecuzione dalle 13:48. Esecutore: K Ferreira. Punto di no ritorno non ancora superato.

Tabella dei passaggi.

Rollback. Disponibile fino al passaggio 37 incluso. Ripristino dal backup pre-esecuzione, reindirizzamento del DNS, riavvio dei worker di ricezione. Provato in staging il 7 giugno da D Attwood.

Sezione passaggio di consegne. Compilata prima che chiunque se ne vada.

Completato fino al passaggio 35. Il passaggio 34 è fallito silenziosamente al primo tentativo con una discrepanza nel conteggio ed è stato rieseguito con successo, ora i conteggi corrispondono a 84.120. Monitorare nuovamente il conteggio dell'indice dopo il passaggio 36, poiché è già fallito una volta. Nulla in corso. Punto di no ritorno non superato, rollback ancora disponibile.

Verifica. Abbastanza specifica da poter fallire.

Il sito si carica. Il conteggio dei prodotti sulle pagine delle categorie somma a 84.120. Dieci ordini campione effettuati dall'inizio alla fine. Cronologia degli ordini visibile per cinque account noti. Il report di riconciliazione dei pagamenti viene eseguito e corrisponde.

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 suo sistema di gestione degli ordini durante una finestra pianificata di quattordici ore di sabato.

Il runbook conteneva sessantuno passaggi. Era stato revisionato, testato in staging ed era un documento davvero accurato. La sua tabella dei passaggi aveva tre colonne: numero del passaggio, azione e una casella di controllo.

Il primo ingegnere ha eseguito i passaggi da uno a trentasette, ha effettuato il passaggio di consegne verbalmente in circa dieci minuti al cambio turno ed è andato a casa dopo una lunga giornata.

Il passaggio trentaquattro consisteva nella reindicizzazione del catalogo prodotti, un'operazione che richiedeva circa quaranta minuti. L'aveva avviata, non aveva visto errori e l'aveva contrassegnata come completata. In realtà era fallita a circa l'ottanta percento senza segnalare nulla.

La seconda ingegnere è arrivata trovando un elenco di sessantuno passaggi con spunte sui primi trentasette. Non c'era alcuna registrazione di ciò che ogni passaggio avesse prodotto, nessun timestamp e nessuna indicazione di quali passaggi potessero essere ripetuti in sicurezza. Tutto ciò che precedeva il passaggio trentotto era, per quanto riguardava il documento, semplicemente fatto.

Ha continuato. Il catalogo era parzialmente indicizzato, il che significava che circa il dodici percento dei prodotti era invisibile sul sito al momento della riapertura.

Lo smoke test finale ha confermato che il sito si caricava. Non ha confrontato il conteggio dei prodotti con quello del catalogo, quindi è passato.

Nessuno se n'è accorto fino a lunedì mattina, trentuno ore dopo, durante il fine settimana di vendite più intenso del trimestre. Le perdite stimati sugli ordini rispetto allo stesso fine settimana dell'anno precedente sono state di circa duecentoquarantamila sterline.

Non potevano effettuare il rollback. Il punto di no ritorno era stato superato al passaggio quarantuno e, sebbene tutti i soggetti coinvolti lo sapessero in linea di principio, era registrato in un paragrafo a pagina uno anziché nel passaggio esatto in cui era avvenuto.

La riscrittura non ha aggiunto passaggi. Ha aggiunto colonne. Risultato effettivo, timestamp e un'indicazione di sicurezza per la riesecuzione su ogni passaggio. Una riga di stato in alto. Il punto di no ritorno è stato spostato dall'introduzione al passaggio stesso, in grassetto. E una sezione di passaggio di consegne che deve essere completata prima che chiunque se ne vada, che ha trasformato una conversazione di dieci minuti in quattro righe scritte.

Alla migrazione successiva, il cambio di turno è avvenuto alla nona ora. Il passaggio di consegne è durato quattro minuti. L'ingegnere subentrante ha rieseguito tre passaggi di cui non era sicura, proprio perché erano contrassegnati come sicuri da rieseguire, e l'esecuzione è terminata entro la finestra temporale.

Rieseguire tre passaggi per precauzione costa pochi minuti. Non poterlo fare è ciò che costa un intero fine settimana.

Come scrivere un runbook in sei passaggi

1. Scrivi i passaggi eseguendo l'attività, non a memoria. Un runbook scritto alla scrivania contiene i passaggi che l'autore ricorda e omette quelli che le sue mani compiono automaticamente.

2. Assegna a ogni passaggio un risultato previsto. Ciò che vedrai che significa che ha funzionato. Un passaggio senza un risultato previsto non può essere verificato da nessuno tranne che dal suo autore.

3. Contrassegna ogni passaggio come sicuro da rieseguire o meno. Trattato di seguito. Questa è la colonna più economica da aggiungere e la più preziosa durante un passaggio di consegne.

4. Metti il punto di no ritorno in corrispondenza del passaggio, in grassetto. Non nell'introduzione, dove verrebbe letto solo una volta da qualcuno che non è la persona che ha bisogno di vederlo.

5. Aggiungi le colonne che compilerai durante l'esecuzione. Risultato effettivo e timestamp. Se non sono sul documento, non verranno registrati da nessuna parte.

6. Provalo, incluso il rollback. Un piano di rollback solo scritto su carta è una supposizione. Provalo in staging con la persona che lo eseguirà, non con quella che lo ha scritto.

Il passaggio uno è quello che distingue i runbook utili da quelli plausibili. Scrivere durante l'esecuzione cattura il clic non documentato, la credenziale che era già negli appunti e la scheda che doveva rimanere aperta.

Contrassegnare i passaggi come sicuri da rieseguire e il punto di no ritorno

Questi due contrassegni svolgono la maggior parte del lavoro in un passaggio di consegne e nessuno dei due appare in un modello tipico.

Sicuro da rieseguire. Per ogni passaggio, stabilire se può essere eseguito due volte senza causare danni. Riavviare un servizio interrotto, rieseguire un indice, riapplicare una configurazione già applicata: di solito sì. Inviare un'e-mail a un cliente, incrementare un contatore, migrare righe in una tabella che non deduplica: di solito no.

Il valore sta nel fatto che elimina la domanda a cui chi subentra non sa rispondere: "Il passaggio precedente è terminato?". Se la risposta non ha importanza, perché ripeterlo è innocuo, nessuno deve accertarsene sotto pressione con informazioni incomplete.

Laddove un passaggio non sia sicuro da rieseguire, indica cosa controllare prima. "No, verifica il conteggio delle righe prima di ripetere" è molto più utile di un semplice "No", perché la persona che legge ha già deciso che deve fare qualcosa.

Il punto di no ritorno. Ogni esecuzione che modifica lo stato ne ha uno. È il passaggio dopo il quale il rollback non è più disponibile, o non è più economico rispetto al procedere avanti.

Contrassegnalo in corrispondenza del passaggio, visivamente distinto, in modo che chiunque scorra la pagina possa vedere da quale parte si trova. Specifica chi ne autorizza il superamento e registra l'ora in cui è stato superato nella colonna del risultato effettivo. Molte esecuzioni ne hanno più di uno: in tal caso, contrassegna ciascuno e indica cosa preclude.

Il motivo per registrare il superamento del punto, invece di contrassegnare solo il passaggio, è che dopo un incidente viene sempre chiesto quando la decisione è diventata irreversibile e nessuno lo ricorda.

Varianti dei modelli di runbook

La struttura rimane la stessa, ma cambia l'enfasi.

Modello di runbook di distribuzione. L'esempio sopra riportato. Sequenziale, pianificato, che spesso copre più turni, ed è la variante in cui la progettazione del passaggio di consegne conta di più.

Runbook di disaster recovery. Eseguito raramente e nelle peggiori condizioni, per cui decade in modo invisibile tra un utilizzo e l'altro. Il requisito distintivo è la prova programmata, poiché un runbook di DR che non è stato eseguito per un anno deve essere considerato errato.

Runbook di incidenti e reperibilità. Vi si accede in un punto imprevedibile piuttosto che essere eseguito in ordine. Organizzalo per sintomo anziché per sequenza, mantieni ogni voce breve e inserisci collegamenti a materiale più approfondito anziché contenerlo.

Runbook di manutenzione programmata. Ripetuto regolarmente, il che lo rende l'unica variante che migliora concretamente con l'uso, a condizione che qualcuno lo aggiorni durante l'esecuzione anziché ripromettersi di farlo in seguito.

Runbook di onboarding e offboarding. Spesso il primo runbook scritto da un team, poiché la sequenza è stabile e il costo di un passaggio saltato, in particolare nell'offboarding, è un problema di sicurezza piuttosto che un inconveniente.

Per tutto ciò che riguarda sistemi regolamentati, transazioni finanziarie o controlli di sicurezza, un runbook di solito si inserisce in un processo di gestione dei cambiamenti (change management) con i propri requisiti di approvazione e conservazione dei registri, che prevalgono su qualsiasi cosa descritta in questa pagina.

Runbook, istruzione di lavoro o SOP?

Tre documenti che si sovrappongono e che vale la pena distinguere, poiché una scelta errata produce il contenuto corretto ma in una forma inutilizzabile.

Una procedura operativa standard (SOP) copre un processo a livello di chi fa cosa e in quale ordine, solitamente coinvolgendo più ruoli e spesso estendendosi su più giorni. Viene letta per comprenderne il funzionamento generale.

Un'istruzione di lavoro descrive in dettaglio una singola attività per la persona che la esegue, ed è scritta per essere seguita da qualcuno che potrebbe non avere familiarità con essa. Il modello di istruzioni di lavoro copre questo tipo di documento.

Un runbook è un'istruzione di lavoro che funge anche da registro di esecuzione. Viene seguito e compilato contemporaneamente, solitamente copre diverse attività in un ordine definito e le sue colonne esistono per lasciare una traccia.

Se il tuo documento viene letto prima del lavoro e archiviato dopo, è una procedura. Se è aperto durante il lavoro ed è diverso alla fine rispetto all'inizio, è un runbook.

Mantenere i runbook aggiornati

I runbook decadono più velocemente della maggior parte della documentazione perché descrivono sistemi che cambiano, e il decadimento è invisibile fino al momento dell'esecuzione che fallisce.

Il meccanismo che funziona davvero è l'aggiornamento durante l'esecuzione anziché dopo. Chiunque esegua il runbook ha il documento aperto, ha appena scoperto che il passaggio dodici ora richiede una conferma extra, ed è l'unica persona che può registrarlo sul momento in modo economico. Dieci secondi in quel momento, o un'ora di confusione alla prossima esecuzione.

Rendi questa pratica legittima dichiarandolo esplicitamente in cima al documento, e considerando un runbook rimasto invariato dopo un'esecuzione reale come leggermente sospetto piuttosto che come un segno di qualità.

L'automazione è l'altra strada, ed è bene essere realisti al riguardo. Automatizzare un passaggio di runbook elimina contemporaneamente l'errore umano e il problema della documentazione, il che è indubbiamente preferibile ove applicabile. Ciò che non elimina è la necessità del documento di supporto, perché qualcuno deve comunque sapere cosa fare quando l'automazione fallisce, e quella persona sarà meno allenata di prima. Automatizza i passaggi, mantieni il runbook e assicurati che copra il fallimento della parte automatizzata.

Cosa non può risolvere un modello di runbook gratuito

Un runbook scritto a memoria. Nessun modello fa emergere i passaggi che l'autore compie senza pensare. Solo la scrittura durante l'esecuzione lo fa.

Un rollback non testato. Un piano di rollback che non è mai stato eseguito è solo un'ipotesi, e il bel mezzo di una migrazione fallita è il posto peggiore per testarlo.

Una checklist spacciata per runbook. La maggior parte di ciò che circola come download gratuito di modelli di runbook è solo una procedura numerata con caselle di controllo, che è un documento diverso e più debole.

Una verifica che non può fallire. "Conferma che il sito sia attivo" passa anche quando il sito è attivo ma presenta errori. Ogni passaggio di verifica dovrebbe essere abbastanza specifico da poterne immaginare il fallimento.

Una finestra temporale senza un termine ultimo per l'annullamento. Senza di esso, un'esecuzione che sta andando male prosegue, perché interrompere sembra sempre più costoso rispetto al passaggio successivo. Stabilisci il termine ultimo prima di iniziare, quando nessuno è ancora emotivamente coinvolto.

Mostra l'esecuzione anziché descriverla

I runbook vengono eseguiti da persone che li utilizzano raramente. Una migrazione avviene due volte l'anno. Un test di DR avviene annualmente. La persona che lo esegue lo ha fatto una volta in precedenza, o forse mai.

Questo è esattamente il caso in cui la procedura scritta funziona peggio, perché il lettore deve ricostruire una sequenza di schermate e stati della console partendo dal testo, e lo scarto tra ciò che l'autore intendeva e ciò che il lettore immagina è il luogo in cui si nasconde il passaggio non documentato.

Trupeer AI colma questo divario. Qualcuno esegue il processo una volta, in staging, mentre registra, e l'output è una guida scritta passo dopo passo con screenshot già catturati e posizionati, insieme a un video, il tutto personalizzato con il tuo brand. La versione scritta diventa il runbook. Il video è ciò che la persona che esegue il processo guarda il giorno prima, ovvero la preparazione che attualmente nessuno ha il tempo di produrre.

Registralo. Personalizzalo con il tuo brand. Traducilo. Usa Trupeer.

Da ciò derivano due aspetti particolarmente importanti per i runbook. La prova pratica produce la documentazione come sottoprodotto anziché come attività aggiuntiva, che è l'unica documentazione che viene effettivamente realizzata con costanza. E quando l'infrastruttura cambia, registrare nuovamente la prova è più veloce che modificare gli screenshot, quindi è più probabile che il runbook sia aggiornato nel momento in cui serve.

Il materiale viene inserito nella tua knowledge base e funge anche da formazione per chiunque sia il prossimo di turno. Le prove di verifica e i controlli di qualità relativi all'esecuzione appartengono al piano di QA. La coerenza con gli altri documenti è solo questione di impostare il kit del brand una volta sola, e la configurazione è descritta nella guida alla configurazione dei modelli di documento.

Domande Frequenti

Esiste una versione Excel di un modello di runbook gratuito?

Excel è lo strumento che la maggior parte dei team finisce per utilizzare ed è molto adatto a questo documento, poiché il cuore di un runbook è una tabella da compilare durante il lavoro. Un file Excel per modello di runbook gestisce in modo naturale le colonne del passaggio, del risultato previsto, del risultato effettivo, del timestamp e della sicurezza di riesecuzione, e consente a più persone di visualizzare lo stesso foglio durante un'esecuzione.

Due impostazioni pratiche: blocca la riga di intestazione e inserisci la riga di stato nelle prime due righe sopra di essa, in modo che rimanga visibile durante lo scorrimento. Un file Excel di modello di runbook gratuito in cui il passaggio corrente scompare alla vista perde la maggior parte del suo valore per il passaggio di consegne.

Esiste una versione Word di un modello di runbook gratuito?

Word è adatto a runbook con un contesto sostanziale attorno ai passaggi: note sull'architettura, cronologia delle decisioni, dettagli sull'escalation. Costruisci il file Word del modello di runbook gratuito inserendo prima le sezioni narrative e successivamente la tabella dei passaggi.

Il limite sta nella compilazione durante un'esecuzione. Una tabella Word è più lenta da aggiornare rispetto alla cella di un foglio di calcolo e, durante una migrazione live, questo attrito è sufficiente a scoraggiare le persone dal registrare i risultati reali. Molti team mantengono il contesto in un documento Word di modello di runbook e la tabella dei passaggi in un foglio di calcolo collegato.

Esiste una versione Microsoft Word di un modello di runbook gratuito?

Sì, e si applica lo stesso compromesso. Un file Microsoft Word di modello di runbook gratuito è la scelta giusta quando il runbook viene esaminato e approvato come parte di un processo di modifica, poiché i documenti si adattano ai flussi di lavoro di approvazione meglio dei fogli di calcolo.

Se scegli questa strada, aggiungi comunque le colonne del risultato effettivo e del timestamp. Un runbook approvato senza di esse verrà eseguito senza di esse, e la registrazione di cui avevi bisogno non esisterà.

Esiste un modello di runbook di distribuzione?

Un modello di runbook di distribuzione è la variante sequenziale trattata in questa pagina: lavoro pianificato, eseguito in ordine, che solitamente copre un intero turno.

Quattro elementi distinguono un buon modello da uno generico. Un punto di no ritorno evidenziato in corrispondenza del passaggio stesso anziché nell'introduzione. Un'indicazione di sicurezza per la riesecuzione su ogni passaggio. Colonne per il risultato effettivo e il timestamp. E una sezione per il passaggio di consegne da completare prima che chiunque se ne vada. Quasi nessun modello pubblicato possiede questi quattro elementi.

Esiste un modello di runbook gratuito in formato PDF?

Il PDF rappresenta l'archivio piuttosto che il documento di lavoro. Una volta completata un'esecuzione, esporta il runbook compilato come PDF e allegalo al registro delle modifiche, poiché un runbook completato con timestamp e risultati reali è la migliore prova di ciò che è accaduto che potrai mai avere.

Non eseguire le operazioni direttamente da un PDF. Il documento deve essere compilato durante l'esecuzione, e qualsiasi file in cui non sia possibile digitare non consentirà di registrare nulla.

Esiste un download gratuito di modelli di runbook che valga la pena utilizzare?

La tabella in sé richiede dieci secondi per essere creata, quindi un download gratuito di un modello di runbook offre ben poco risparmio, e la maggior parte di quelli pubblicati online sono semplici documenti di procedura con l'etichetta di runbook.

Controlla una cosa prima di adottarne uno. Verifica se la tabella dei passaggi ha una colonna per indicare cosa è realmente accaduto. Se ha solo una casella di controllo, hai davanti una semplice checklist, e l'intera tesi di questa pagina è che la differenza tra queste due tipologie di documento è proprio ciò da cui dipende il successo di un passaggio di consegne.

Quanto deve essere lungo un runbook?

Tanto quanto l'esecuzione stessa, che per una migrazione importante conta realmente decine di passaggi. La lunghezza non è il problema dei runbook.

L'aspetto da controllare è la dimensione del singolo passaggio. Un passaggio dovrebbe essere un'unica azione con un unico risultato osservabile. I passaggi che raggruppano diverse azioni non possono essere consegnati a metà, perché la persona successiva non può sapere quanto di quel blocco sia stato effettivamente eseguito, ed è proprio questa la situazione che il documento esiste per evitare.

Chi dovrebbe scrivere il runbook?

Chiunque dovrà eseguirlo, scrivendolo mentre lo esegue su un ambiente non di produzione. Un runbook scritto da un progettista ed eseguito da un ingegnere mancherà proprio dei passaggi che il progettista non compie personalmente.

Successivamente, fai eseguire la bozza a una seconda persona in staging senza l'aiuto dell'autore. Ogni domanda che dovrà porre rappresenta un difetto, e la soluzione è scriverla nel documento anziché rispondere a voce.