Anche durante un disastro, c'è sempre tempo per una tazza di tè.
DRP (piano di ripristino di emergenza) è una cosa che idealmente non sarà mai necessaria. Ma se improvvisamente i castori che migrano durante la stagione degli amori rosicchiano la fibra ottica principale o un amministratore junior lascia cadere una base produttiva, vuoi sicuramente essere sicuro di avere un piano prestabilito su cosa fare con tutta questa disgrazia.
Mentre i clienti in preda al panico iniziano a chiamare il supporto tecnico, un junior cerca cianuro, tu apri saggiamente la busta rossa e inizi a mettere tutto in ordine.
In questo post, voglio condividere consigli su come scrivere un DRP e cosa dovrebbe contenere. Vedremo anche quanto segue:
- Impara a pensare come un cattivo.
- Analizziamo i benefici di una tazza di tè durante l'apocalisse.
- Pensa a una comoda struttura DRP
- Vediamo come testarlo
Quali aziende potrebbero trarne vantaggio?
È molto difficile tracciare una linea quando il reparto IT inizia ad aver bisogno di queste cose. Direi che avrai sicuramente bisogno di DRP se:
- L'arresto di un server, di un'applicazione o la perdita di un database comporterà perdite significative per l'azienda nel suo insieme.
- Hai un dipartimento IT a tutti gli effetti. Voglio dire, un dipartimento come unità a tutti gli effetti dell'azienda, con il proprio budget, e non solo pochi dipendenti stanchi che creano una rete, puliscono virus e ricaricano stampanti.
- Hai un budget realistico per il licenziamento almeno parziale in caso di emergenza.
Quando il reparto IT chiede da mesi almeno un paio di HDD per un vecchio server per i backup, è improbabile che tu possa organizzare un vero e proprio trasferimento del servizio caduto in capacità di riserva. Anche se la documentazione non sarà superflua neanche qui.
La documentazione è importante
Inizia con la documentazione. Diciamo che il tuo servizio viene eseguito su uno script Perl che è stato scritto tre generazioni di amministratori fa e nessuno sa come funziona. Il debito tecnico accumulato e la mancanza di documentazione ti spareranno inevitabilmente non solo al ginocchio, ma anche ad altri arti, è piuttosto una questione di tempo.
Una volta che hai una buona descrizione dei componenti del servizio a portata di mano, aumenta le statistiche sugli arresti anomali. Quasi certamente saranno del tutto tipici. Ad esempio, di tanto in tanto si ha un disco pieno, il che causa il fallimento del nodo fino a quando non viene pulito manualmente. Oppure il servizio client diventa non disponibile a causa del fatto che qualcuno ha nuovamente dimenticato di rinnovare il certificato e Let's Encrypt non può essere configurato o non lo desidera.
Pensieri come un sabotatore
La parte più difficile è prevedere quegli incidenti mai accaduti prima, ma che potenzialmente potrebbero rovinare completamente il tuo servizio. Qui di solito interpretiamo i cattivi con i colleghi. Prendi molto caffè e qualcosa di gustoso e chiuditi nella sala riunioni. Assicurati solo che nella stessa riunione hai bloccato quegli ingegneri che hanno sollevato il servizio di destinazione o ci lavorano regolarmente. Quindi, alla lavagna o su carta, inizi a disegnare tutti i possibili orrori che possono accadere al tuo servizio. Non è necessario dettagliare fino a una specifica donna delle pulizie e tirare fuori i cavi, è sufficiente considerare lo scenario "Violazione dell'integrità della rete locale".
Di solito, le emergenze più tipiche rientrano nei seguenti tipi:
- Errore di rete
- Errore del servizio del sistema operativo
- Errore dell'applicazione
- cedimento del ferro
- Errore di virtualizzazione
Basta passare attraverso ogni vista e vedere cosa si applica al tuo servizio. Ad esempio, il demone Nginx potrebbe cadere e non alzarsi: questo è un errore da parte del sistema operativo. Una rara situazione che porta la tua applicazione web in uno stato non funzionante è un errore del software. Durante lo sviluppo di questa fase, è importante elaborare la diagnosi del problema. Come distinguere un'interfaccia bloccata sulla virtualizzazione da un Cisco caduto e un arresto anomalo della rete, ad esempio. Questo è importante per trovare rapidamente i responsabili e iniziare a tirare la coda fino a quando l'incidente non sarà risolto.
Dopo aver annotato i problemi tipici, versiamo altro caffè e iniziamo a considerare gli scenari più strani, quando alcuni parametri iniziano ad andare oltre la norma. Per esempio:
- Cosa succede se l'ora sul nodo attivo torna indietro di un minuto rispetto agli altri nel cluster?
- E se il tempo avanza, e se di 10 anni?
- Cosa succede se un nodo del cluster perde improvvisamente la rete durante la sincronizzazione?
- E cosa succede se due nodi non condividono la leadership a causa del temporaneo isolamento reciproco sulla rete?
In questa fase, l'approccio inverso aiuta molto. Prendi il membro più testardo della squadra con un'immaginazione malata e affidagli il compito di organizzare un diversivo nel più breve tempo possibile, che metterà giù il servizio. Se è difficile da diagnosticare, ancora meglio. Non crederai alle idee strane e fantastiche che escogitano gli ingegneri quando hanno l'idea di rompere qualcosa. E se prometti loro un banco di prova per questo, va molto bene.
Cos'è questo tuo DRP?!
Quindi hai definito il modello di minaccia. Hanno anche preso in considerazione i residenti locali che tagliano i cavi in fibra ottica alla ricerca di rame e un radar militare che fa cadere una linea di trasmissione radio rigorosamente il venerdì alle 16:46. Ora dobbiamo capire cosa fare con tutto questo.
Il tuo compito è scrivere le stesse buste rosse che verranno aperte in caso di emergenza. Aspettati subito che quando (non se!) Tutto sarà incasinato, nelle vicinanze ci sarà solo il tirocinante più inesperto, le cui mani tremeranno violentemente per l'orrore di quanto sta accadendo. Guarda come vengono implementati i segnali di emergenza negli studi medici. Ad esempio, cosa fare con lo shock anafilattico. Il personale medico conosce a memoria tutti i protocolli, ma quando una persona vicina inizia a morire, molto spesso tutti si aggrappano impotenti a tutto. Per fare ciò, una chiara istruzione è appesa al muro con articoli come "apri il pacchetto di tale e tale" e "inietta tante unità del farmaco per via endovenosa".
È difficile pensare in caso di emergenza! Dovrebbero esserci semplici istruzioni per l'analisi spinale.
Un buon DRP è costituito da pochi semplici blocchi:
- A chi notificare l'inizio dell'incidente. Questo è importante per parallelizzare il più possibile il processo di eliminazione.
- Come diagnosticare correttamente: tracciamo, guardiamo in systemctl status servicename e così via.
- Quanto tempo può essere dedicato a ciascuna fase. Se non hai tempo per aggiustarlo con le tue mani durante il tempo SLA, la macchina virtuale viene uccisa e spostata dal backup di ieri.
- Come assicurarsi che l'incidente sia finito.
Ricorda che DRP inizia quando il servizio è completamente fallito e si completa con il ripristino, anche con efficienza ridotta. La semplice perdita di una prenotazione non dovrebbe attivare DRP. Puoi anche prescrivere una tazza di tè in DRP. Sul serio. Secondo le statistiche, molti incidenti passano da spiacevoli a catastrofici a causa del fatto che il personale in preda al panico si precipita a riparare qualcosa, uccidendo contemporaneamente l'unico nodo live con i dati o infine terminando il cluster. Di norma, 5 minuti per una tazza di tè ti daranno un po' di tempo per calmarti e analizzare cosa sta succedendo.
Non confondere DRP e passaporto di sistema! Non sovraccaricarlo con dati non necessari. Basta dare l'opportunità di accedere rapidamente e comodamente alla sezione richiesta della documentazione tramite collegamenti ipertestuali e leggere in un formato esteso le sezioni necessarie dell'architettura del servizio. E nello stesso DRP ci sono solo istruzioni dirette su dove e come connettersi con comandi specifici per il copia-incolla.
Come testare correttamente
Assicurati che qualsiasi dipendente responsabile sia in grado di completare tutti gli elementi. Nel momento più cruciale, potrebbe risultare che l'ingegnere non ha i diritti di accesso al sistema richiesto, non ci sono password per l'account richiesto o non ha idea di cosa "Connettiti alla console di gestione del servizio tramite un proxy al sede centrale” significa. Ogni elemento dovrebbe essere il più semplice possibile.
Неправильно - "Vai alla virtualizzazione e riavvia il nodo morto"
Correttamente - "Connettiti tramite l'interfaccia web a virt.example.com, nella sezione del nodo, ricarica il nodo che sta causando l'errore."
Evita l'ambiguità. Ricorda lo stagista spaventato.
Assicurati di testare DRP. Questo non è solo un piano per lo spettacolo: è qualcosa che consentirà a te e ai tuoi clienti di uscire rapidamente da una situazione critica. È meglio farlo più volte:
- Un esperto e diversi stagisti lavorano su un banco di prova che imita il più possibile un servizio reale. 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 aver formato i tirocinanti, DRP viene integrato e semplificato in luoghi oscuri.
- Test su un servizio reale. In effetti, non puoi mai creare una copia perfetta di un servizio reale. Pertanto, un paio di volte all'anno è necessario spegnere parte dei server in modo pianificato, interrompere le connessioni e organizzare altri incidenti dall'elenco delle minacce per valutare l'ordine di ripristino. È meglio avere un'interruzione pianificata di 10 minuti nel cuore della notte piuttosto che un guasto improvviso per diverse ore al carico di picco con perdita di dati.
- Eliminazione reale dell'incidente. Sì, anche questo fa parte del test. Se si verifica un incidente che non era nell'elenco delle minacce, è necessario integrare e finalizzare il DRP sulla base dei risultati della sua indagine.
Punti chiave
- Se le stronzate possono accadere, non accadranno e basta, ma lo faranno nello scenario più catastrofico.
- Assicurati di disporre delle risorse per il failover.
- Assicurati di disporre di backup, vengono creati automaticamente e controllati regolarmente per verificarne la coerenza.
- Considera i tipici scenari di minaccia.
- Offri agli ingegneri l'opportunità di proporre opzioni non standard per mettere il servizio.
- DRP dovrebbe essere istruzioni semplici e stupide. Tutta la diagnostica complessa solo dopo che i clienti hanno ripristinato il servizio. Anche se è in standby.
- Elenca i numeri di telefono e i contatti chiave in DRP.
- Testare regolarmente i dipendenti per la comprensione del DRP.
- Organizzare gli incidenti pianificati sul prodotto. I supporti non possono sostituire tutto.
Fonte: habr.com