🥇Prepariamo il DRP — non dimenticare di considerare il meteoroide

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

DRP (disaster recovery plan) è una cosa che, in teoria, non servirà mai. Ma se dovesse accadere che castori migratori durante il periodo di accoppiamento rosicchino la principale fibra ottica o un junior admin faccia cadere il database di produzione, vuoi essere sicuro di avere un piano già pronto su cosa fare con tutto questo caos.

Mentre i clienti, in preda al panico, iniziano a riempire le linee di assistenza, il junior cerca cianuro, tu con aria saggia apri la busta rossa e inizi a mettere tutto in ordine.

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

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

A quali aziende potrebbe essere utile

È molto difficile tracciare un confine quando il reparto IT inizia ad avere bisogno di tali cose. Direi che un DRP è sicuramente necessario se:

Un'interruzione di server, applicazione o perdita di un database porterà a significative perdite aziendali in generale.
Hai un reparto IT completo. Intendo un reparto come un'unità aziendale a pieno titolo, con un proprio budget, non solo qualche impiegato stanco che stende reti, pulisce virus e ricarica stampanti.
Hai un budget reale, almeno per una parziale riserva in caso di emergenza.

Quando il reparto IT chiede per mesi almeno un paio di HDD per un server obsoleto per i backup, difficilmente riuscirai a organizzare un trasferimento completo del servizio caduto su risorse di riserva. Anche in questo caso, la documentazione non farà mai male.

La documentazione è importante

Inizia con la documentazione. Supponiamo che il tuo servizio funzioni su uno script Perl scritto tre generazioni fa, e nessuno sa come funziona. Il debito tecnico accumulato e la mancanza di documentazione finiranno per colpirti non solo al ginocchio, ma anche ad altre estremità, è solo una questione di tempo.

Una volta che hai una buona descrizione dei componenti del servizio, raccogli le statistiche sugli avvisi. È quasi certo che saranno del tutto tipici. Ad esempio, di tanto in tanto il disco si riempie, il che porta a un guasto del nodo fino alla sua pulizia manuale. Oppure il servizio clienti diventa inaccessibile perché qualcuno ha dimenticato di rinnovare il certificato, e non è riuscito o non ha voluto configurare Let's Encrypt.

Pensa come un sabotatore

La parte più difficile è prevedere quegli avvisi che non si sono mai verificati, ma che potrebbero potenzialmente mandare a terra completamente il tuo servizio. Qui di solito ci divertiamo a interpretare i cattivi con i colleghi. Prendi molto caffè e qualcosa di buono da mangiare e rinchiuditi in una sala riunioni. Assicurati solo che in quella sala riunioni siano rinchiusi anche gli ingegneri che hanno avviato il servizio in questione o che ci lavorano regolarmente. Poi inizia a disegnare su una lavagna o su carta tutti gli orrori possibili che potrebbero accadere al tuo servizio. Non è necessario dettagliare fino a ogni singolo addetto alle pulizie che scollega i cavi; basta considerare lo scenario "Violazione dell'integrità della rete locale".

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

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

Basta procedere per ogni categoria e vedere quali si applicano al tuo servizio. Ad esempio, il demone Nginx potrebbe smettere di funzionare e non riprendersi: questo è un guasto a livello di sistema operativo. Una situazione rare che rende il tuo web application non funzionante è un guasto del software. Durante questa fase, è importante lavorare sulla diagnosi del problema. Come distinguere un'interfaccia bloccata sulla virtualizzazione da un dispositivo Cisco guasto e un avviso sulla rete, ad esempio. Questo è importante per trovare rapidamente i responsabili e iniziare a sollecitarli finché l'incidente non è risolto.

Dopo aver annotato i problemi tipici, versiamo ancora caffè e cominciamo a considerare gli scenari più strani, quando alcuni parametri iniziano a discostarsi notevolmente dalla norma. Ad esempio:

Cosa succede se il tempo su un nodo attivo si sposta indietro di un minuto rispetto agli altri nel cluster?
E se il tempo si spostasse in avanti, e se fosse di 10 anni?
Cosa succede se durante la sincronizzazione un nodo del cluster perde improvvisamente la rete?
E cosa succede se due nodi non condividono la leadership a causa di un'isolamento temporaneo tra di loro nella rete?

In questa fase è molto utile un approccio al contrario. Prendete il membro più testardo del team con una fantasia malata e dategli il compito di organizzare in tempi brevissimi una diversione che mandi in tilt il servizio. Se sarà difficile diagnosticarla, tanto meglio. Non crederete a quali idee strane e geniali esprimono gli ingegneri se gli si dà l'idea di rompere qualcosa. E se promettete loro un banco di prova per farlo, sarà ancora meglio.

Che cos'è questo DRP?!

Quindi avete identificato il modello di minaccia. Avete tenuto conto anche dei residenti locali che tagliano i cavi in fibra ottica in cerca di rame, e del radar militare che fa cadere la linea radio rigorosamente il venerdì alle 16:46. Ora bisogna capire cosa fare con tutto questo.

Il vostro compito è scrivere quelle famose buste rosse che verranno aperte in caso di emergenza. Calcolate subito che quando (non se!) tutto andrà storto, accanto ci sarà solo il tirocinante più inesperto, la cui mano tremerà forte per la paura di quanto sta succedendo. Osservate 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 accanto a loro, spesso tutti afferrano disperatamente qualsiasi cosa. Per questo sulla parete c'è un'istruzione chiara con punti del tipo 'aprire il pacchetto di questo' e 'iniezione endovenosa di tot unità del farmaco'.

In una situazione di emergenza è difficile pensare! Devono esserci istruzioni semplici da elaborare a livello istintivo.

Un buon DRP è composto da diversi blocchi semplici:

Chi avvisare all'inizio dell'emergenza. Questo è importante per massimizzare la parallelizzazione del processo di risoluzione.
Come diagnosticare correttamente - eseguiamo il tracciamento, controlliamo lo stato di systemctl servicename e così via.
Quanto tempo dedicare a ciascuna fase. Se non riuscite a riparare a mano entro il tempo SLA, la macchina virtuale viene distrutta e ripristinata dal backup di ieri.
Come assicurarsi che l'emergenza sia conclusa.

Ricordate che il DRP inizia quando il servizio ha completamente smesso di funzionare e termina con il ripristino della operatività, anche se con una ridotta efficienza. La semplice perdita di risorse non dovrebbe attivare il DRP. E sì, potete includere una tazza di tè nel DRP. Sul serio. Secondo le statistiche, molti incidenti sgradevoli diventano catastrofici perché il personale, in preda al panico, cerca di riparare qualcosa, uccidendo nel processo l'unico nodo vivo con i dati o finendo definitivamente di danneggiare il cluster. Di solito, 5 minuti per una tazza di tè vi daranno un po' di tempo per rilassarvi e analizzare la situazione.

Non confuse il DRP con il passaporto del sistema! Non sovraccaricatevi di informazioni inutili. Offrite semplicemente la possibilità di navigare rapidamente e comodamente tra le sezioni necessarie della documentazione tramite hyperlink e di leggere in formato espanso le parti rilevanti dell'architettura del servizio. E nel DRP, solo indicazioni dirette su dove e come collegarsi con comandi specifici per il copia-incolla.

Come testare correttamente

Assicuratevi che ogni dipendente responsabile sia in grado di eseguire tutti i punti. Nel momento cruciale, potrebbe succedere che l'ingegnere non abbia i diritti di accesso al sistema necessario, non abbia le password per l'account richiesto o non abbia idea di cosa significhi “Collegati alla console di gestione del servizio tramite proxy nella sede centrale”. Ogni punto deve essere estremamente semplice.

Sbagliato — "Accedete alla virtualizzazione e riavviate il nodo morto"
Esatto — "Collegatevi tramite l'interfaccia web a virt.example.com, nella sezione nodi eseguite il riavvio del nodo che genera l'errore".

Evitate ambiguità. Ricordate il tirocinante spaventato.

Testate obbligatoriamente il DRP. Non è solo un piano da completare — è ciò che permetterà a voi e ai vostri clienti di uscire rapidamente da una situazione critica. È ottimale farlo diverse volte:

Un esperto e alcuni tirocinanti lavorano su un banco di prova che simula al meglio il servizio reale. L'esperto rompe il servizio in vari modi e offre ai tirocinanti la possibilità 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 ampliato e semplificato nei punti poco chiari.
Test delle operazioni su un servizio reale. In realtà, non sarà mai possibile creare una copia perfetta di un servizio autentico. Pertanto, un paio di volte all'anno è necessario disattivare pianificatamente alcune server, interrompere le connessioni e causare altre emergenze dalla lista delle minacce, per valutare l'ordine di ripristino. Meglio un'interruzione programmata di 10 minuti nel cuore della notte piuttosto che un guasto improvviso per alcune ore in un periodo di carico massimo con perdita di dati.
Risoluzione reale di un'emergenza. Sì, anche questo è parte del testing. Se si verifica un'emergenza che non era nella lista delle minacce, è necessario aggiornare e rivedere il DRP sulla base dei risultati delle sue indagini.

Punti chiave

Se qualcosa può andare storto, non solo andrà storto, ma lo farà nel modo più catastrofico possibile.
Assicurati di avere risorse per il ripristino del carico in caso di emergenza.
Assicurati di avere backup, che vengano creati automaticamente e controllati regolarmente per la loro coerenza.
Pensa a scenari di minacce standard.
Dai la possibilità agli ingegneri di pensare a varianti non standard per compromettere il servizio.
Il DRP deve essere una semplice e chiara istruzione. Tutta la diagnostica complessa deve avvenire solo dopo che il servizio è stato ripristinato per i clienti. Anche se solo su capacità di riserva.
Indica i numeri di telefono e i contatti chiave nel DRP.
Testa regolarmente i dipendenti sulla comprensione del DRP.
Esegui emergenze programmate in produzione. I test non possono sostituire tutto.