🥇Prepariamo il DRP — non dimenticate di considerare un meteorite

Anche durante una catastrofe c'è sempre tempo per una tazza di tè

DRP (disaster recovery plan) è qualcosa di cui idealmente non avresti mai bisogno. Ma se, per caso, i castori in periodo di accoppiamento rosicchiano la fibra ottica principale o un junior admin elimina un database di produzione, vuoi essere sicuro di avere un piano già preparato su come gestire tutto questo disastro.

Mentre i clienti, in preda al panico, cominciano a intasare il supporto, il junior cerca il cianuro, tu, con aria saggia, apri la busta rossa e inizi a sistemare tutto.

In questo post voglio condividere dei consigli su come scrivere un DRP e cosa dovrebbe contenere. Inoltre, esamineremo le seguenti cose:

Impareremo a pensare come un cattivo.
Discuteremo l'importanza di una tazza di tè durante l'apocalisse.
Pianificheremo una struttura comoda per il DRP
Vedremo come testarlo

Per quali aziende può essere utile

È molto difficile tracciare un confine quando il reparto IT inizia ad avere bisogno di cose del genere. Direi che un DRP ti serve sicuramente se:

L'arresto di un server, di un'applicazione o la perdita di un database può portare a significative perdite aziendali nel complesso.
Hai un reparto IT completo. In altre parole, un'unità aziendale con il proprio budget, non solo alcuni dipendenti stanchi che si occupano di cablare la rete, rimuovere virus e rifornire le stampanti.
Hai un budget reale, anche solo per una parziale riserva in caso di emergenza.

Quando il reparto IT chiede da mesi almeno un paio di HDD per un server datato per i backup, sarà difficile organizzare un vero trasferimento del servizio in crash su potenzialità di riserva. Anche in questo caso, avere della documentazione non guasta.

La documentazione è importante

Inizia dalla documentazione. Supponiamo che il tuo servizio funzioni su uno script Perl scritto tre generazioni di amministratori fa, e nessuno sa come funziona. Il debito tecnico accumulato e l'assenza di documentazione colpiranno inesorabilmente non solo il tuo ginocchio, ma anche altre estremità, è solo una questione di tempo.

Dopo aver ottenuto una buona descrizione dei componenti del servizio, raccogli le statistiche sugli incidenti. Quasi sicuramente saranno del tutto tipiche. Ad esempio, potrebbe capitare che di tanto in tanto il disco si riempi, causando il malfunzionamento del nodo fino alla sua pulizia manuale. Oppure il servizio ai clienti diventa inaccessibile perché qualcuno ha di nuovo dimenticato di rinnovare il certificato e non è riuscito o non ha voluto configurare Let’s Encrypt.

Pensa come un sabotatore

La parte più difficile consiste nel prevedere quegli incidenti che non si sono mai verificati, ma che potrebbero compromettere completamente il tuo servizio. Qui di solito giochiamo con i colleghi a fare i cattivi. Prendi tanto caffè e qualche dolcetto e rinchiuditi in una sala riunioni. Assicurati solo di chiudere dentro anche quegli ingegneri che hanno messo in funzione il servizio target o che lavorano regolarmente con esso. Poi, su una lavagna o su carta, cominci a disegnare tutti gli orrori che potrebbero accadere al tuo servizio. Non è necessario dettagliare fino al punto di specificare la signora delle pulizie e il distacco dei cavi; basta esaminare lo scenario "Interruzione dell'integrità della rete locale".

Di solito, la maggior parte delle situazioni di emergenza tipiche rientra nelle seguenti categorie:

Guasto di rete
Guasto dei servizi di sistema operativo
Guasto dell'applicazione
Guasto dell'hardware
Guasto della virtualizzazione

Basta seguire ogni categoria e vedere cosa si applica al tuo servizio. Ad esempio, potrebbe verificarsi un arresto anomalo di Nginx che non si riavvia: questo è un problema legato al sistema operativo. Si tratta di una situazione rara che può portare la tua applicazione web in uno stato di inattività: un errore software. Durante questa fase è fondamentale diagnosticare il problema. Come distinguere un'interfaccia bloccata in virtualizzazione da un crash di una rete o di un dispositivo di rete, per esempio. È importante per identificare rapidamente i responsabili e iniziare a contattarli, prima che l'incidente venga risolto.

Dopo aver annotato i problemi comuni, prendiamo un'altra tazza di caffè e cominciamo a esaminare gli scenari più strani in cui alcuni parametri iniziano a discostarsi notevolmente dalla norma. Per esempio:

Cosa succede se l'orario su un nodo attivo viene spostato indietro di un minuto rispetto agli altri nel cluster?
E se l'orario viene spostato in avanti, cosa succede se di 10 anni?
Cosa accade se durante la sincronizzazione un nodo del cluster perde improvvisamente la rete?
E cosa succede se due nodi non riescono a spartire la leadership a causa di un'isolamento temporanea nella rete?

In questa fase, l'approccio migliore è quello inverso. Prendi il membro più esuberante del tuo team, dotato di una fantasia fuori dal comune, e assegna a lui il compito di creare entro brevi termini un sabotaggio che comprometta il servizio. Se sarà difficile da diagnosticare, ancora meglio. Non puoi immaginare le idee strane e geniali che gli ingegneri propongono quando gli dai l'idea di rompere qualcosa. E se prometti loro anche un banco di prova per farlo, ancora meglio.

Che cos'è questo DRP?!

Quindi hai identificato il modello di minacce. Hai considerato anche i locali che tagliano i cavi in fibra ottica in cerca di rame, e il radar militare che interrompe la linea radio ogni venerdì alle 16:46. Ora devi capire cosa fare con tutto questo.

Il tuo compito è scrivere le famose buste rosse che saranno aperte in caso di emergenza. Calcola subito che quando (non se!) tutto andrà storto, accanto ci sarà solo il tirocinante più inesperto, i cui eventi tremano dal terrore di ciò che sta accadendo. Guarda come sono realizzati i cartelli di emergenza negli ambulatori medici. Ad esempio, cosa fare in caso di shock anafilattico. Il personale medico conosce a memoria tutti i protocolli, ma quando una persona inizia a morire, molto spesso afferrano tutto ciò che capita. Per questo, sulla parete è appesa una chiara istruzione con punti del tipo «aprire la confezione di...» e «iniettare per via intravenosa tot unità del farmaco».

In caso di emergenza è difficile pensare! Devono esserci istruzioni semplici per la lettura automatica.

Un buon DRP è composto da diversi blocchi semplici:

Chi avvisare all'inizio dell'emergenza. Questo è importante per massimizzare il processo di risoluzione.
Come diagnosticare correttamente — eseguiamo il tracing, controlliamo lo stato del servizio con `systemctl status servicename` e così via.
Quanto tempo si può dedicare a ciascuna fase. Se non riesci a riparare manualmente entro il tempo SLA, la macchina virtuale viene distrutta e ripristinata dalla copia di sicurezza di ieri.
Come verificare che l'incidente sia stato risolto.

Ricorda che il DRP inizia nel momento in cui il servizio ha completamente fallito e termina con il ripristino della funzionalità, anche se con ridotta efficienza. La semplice perdita di un backup non dovrebbe attivare il DRP. E puoi anche annotare nel DRP di prendere una tazza di tè. Seriamente. Statisticamente, molte emergenze diventano catastrofiche semplicemente perché il personale, in preda al panico, tenta di riparare qualcosa, uccidendo nel processo l'unico nodo vivo con i dati o compromettere definitivamente il cluster. In genere, 5 minuti per una tazza di tè ti daranno un po' di tempo per calmarti e analizzare ciò che sta accadendo.

Non confondere il DRP con il passaporto del sistema! Non sovraccaricarlo con informazioni superflue. Consenti semplicemente una navigazione rapida e comoda tramite i collegamenti ipertestuali per accedere alla sezione desiderata della documentazione e leggere in modo dettagliato riguardo le aree specifiche dell'architettura del servizio. Nel DRP dovrebbero esserci solo istruzioni chiare su dove e come connettersi, con comandi specifici per il copia e incolla.

Come testare correttamente

Assicurati che ogni dipendente responsabile sia in grado di completare tutti i punti. Nel momento più critico, potrebbe accadere che l'ingegnere non abbia i diritti per accedere al sistema necessario, che manchino le password per l'account richiesto o che non sappia cosa significhi "Connettiti alla console di gestione del servizio tramite proxy presso la sede centrale". Ogni punto dovrebbe essere estremamente semplice.

Sbagliato — «Accedi alla virtualizzazione e riavvia il nodo morto»
Esatto — «Connettiti tramite interfaccia web a virt.example.com, nella sezione nodi esegui il riavvio del nodo che genera l'errore».

Evita ambiguità. Ricorda lo stagista spaventato.

Testare sempre il DRP. Non è solo un piano da spuntare: è ciò che permetterà a voi e ai vostri clienti di uscire rapidamente da una situazione critica. È ottimale farlo più volte.

Un esperto e alcuni tirocinanti lavorano su un ambiente di test che imita il servizio reale il più possibile. L'esperto interrompe il servizio in vari modi e consente ai tirocinanti di ripristinarlo secondo il DRP. Tutti i problemi, le ambiguità nella documentazione e gli errori vengono registrati. Dopo la formazione dei tirocinanti, il DRP viene integrato e semplificato nei punti poco chiari.
Testare su un servizio reale. In realtà, non si può mai creare una copia perfetta del servizio reale. Pertanto, un paio di volte all'anno è necessario spegnere programmativamente alcuni server, interrompere le connessioni e simulare altre emergenze dall'elenco delle minacce per valutare l'ordine di ripristino. È meglio un'emergenza programmata di 10 minuti nel bel mezzo della notte che un guasto improvviso di alcune ore durante i picchi di carico con perdita di dati.
Reale risoluzioni delle emergenze. Sì, anche questo fa parte del testing. Se si verifica un'emergenza non prevista nella lista delle minacce, è necessario aggiornare e rielaborare il DRP sulla base dei risultati della sua indagine.

Punti chiave

Se qualcosa può andare storto, non solo andrà storto, ma lo farà secondo uno scenario altamente catastrofico.
Assicurati di avere risorse per il failover.
Verifica di avere backup, che vengano creati automaticamente e controllati regolarmente per coerenza.
Pensa a scenari di minacce comuni.
Dai la possibilità agli ingegneri di elaborare varianti non standard per interrompere il servizio.
Il DRP deve essere una semplice e diretta istruzione. Tutta la diagnostica complessa deve avvenire solo dopo che i clienti hanno riottenuto il servizio, anche se su risorse di riserva.
Indica numeri di telefono e contatti chiave nel DRP.
Testa regolarmente i dipendenti sulla comprensione del DRP.
Organizza emergenze pianificate in produzione. I test non possono sostituire tutto.