Test di disaster recovery
Dopo aver predisposto un piano di disaster recovery(DR), testatelo regolarmente. Si può evitare di trovare difetti quando si affronta un vero e proprio disastro. I test aiutano a garantire che il piano funzioni e raggiunga i risultati desiderati. Se il piano non funziona durante il test, è possibile apportare le modifiche necessarie. I test regolari aiutano a garantire che qualsiasi cambiamento nell'ambiente di lavoro venga catturato e che, se necessario, vengano apportate delle modifiche.
Per verificare il vostro piano, utilizzate diversi tipi di test di disaster recovery:
- Prova a secco DR
- Simulazione DR
- Commutazione
Prova a secco DR
Un test a secco è un'esercitazione su carta del vostro piano di DR. Quando si esegue un test a secco, non si esegue alcun recupero, ma si controlla che non ci siano buchi evidenti nel piano. Ad esempio, il test a secco aiuta a garantire che:
- avete il giusto personale coinvolto
- i backup sono presenti e disponibili
- i canali di comunicazione tra il personale funzionano
- non ci sono passi mancanti nei runbook DR
- i passaggi di consegne tra i team funzionano in modo efficiente
Un test DR dry richiede lo stesso impegno in termini di competenze e persone di qualsiasi altro test. Poiché non vengono eseguite azioni di recupero effettive, questo tipo di test è più veloce e viene normalmente eseguito con una frequenza maggiore rispetto agli altri tipi di test. Potete scegliere se eseguire il piano nella sua interezza o se testare singole parti e servizi al suo interno.
Simulazione DR
La simulazione di DR è un modo per verificare o controllare i runbook di emergenza e verificare gli obiettivi di tempo di ripristinoNella pianificazione del disaster recovery, la durata del tempo necessario per ripristinare un processo aziendale dopo un disastro. (RTO) e di punto di ripristino(RPONella pianificazione del disaster recovery, il momento in cui i dati vengono ripristinati, misurato in termini di tempo (secondi, minuti, ore) a partire dall'istanza recuperata fino al punto in cui si è verificato il disastro. ) forniti dalla soluzione, simulando le condizioni di un'emergenza reale e ripristinando i dati.
Una simulazione di DR richiede un'attenta pianificazione, poiché si introducono potenziali interruzioni nella replica dei dati dalla regione primaria, evitando al contempo l'impatto sui carichi di lavoro di produzione. Mentre si sta testando l'ambiente di DR, questo potrebbe essere temporaneamente non disponibile per scopi di disaster recovery effettivi. Questo rischio dipende dai servizi cloud specifici e dalle modalità di distribuzione. Alcuni servizi possono consentire il test e la disponibilità simultanea, altri no.
Una simulazione DR crea una copia temporanea dell'ambiente di produzione nell'area DR designata per il test e la convalida. Al termine della simulazione, l'ambiente di test viene cancellato o resettato e tutte le modifiche apportate durante il test vengono eliminate, mentre l'ambiente primario di produzione continua a funzionare normalmente.
Commutazione
Lo switch-over comporta il passaggio dell'ambiente di produzione da una regione all'altra. Questo metodo aiuta a verificare e controllare la capacità di gestire e sostenere le operazioni di produzione per un lungo periodo in una regione alternativa. Le operazioni di produzione vengono interrotte con grazia nella prima regione, passate alla seconda regione e riavviate dopo l'eventuale ripristino dei dati.
Dopo aver verificato che la seconda regione funziona come previsto, è possibile riprendere le attività di produzione e configurare la replica dei dati per rendere la regione originale la nuova regione secondaria. L'ambiente di produzione continua a funzionare da questo sito finché non si decide di tornare indietro.
Frequenza dei test DR
La frequenza dei test del piano di DR dipende da molti fattori, tra cui quelli imposti dagli standard di conformità alle normative. Se la conformità non è un problema, puntate a condurre un test DR completo almeno una volta all'anno e documentate i risultati per la revisione da parte degli auditor. È buona norma eseguire test su scala ridotta nel corso dell'anno per garantire la preparazione.
Considerate le seguenti domande e modificate la frequenza dei test:
- Quanto è dinamico il mio carico di lavoro?
- Più il carico di lavoro cambia, più spesso è necessario eseguire una forma di test DR. In questo modo è possibile verificare che le modifiche non influiscano sulla capacità di recupero. Le modifiche potrebbero includere nuove dipendenze, altri servizi cloud, modifiche all'infrastruttura e altro ancora. Il ripristino di set di dati in crescita richiede tempi più lunghi, il che potrebbe influire sulla capacità di soddisfare un RTO specifico.
- Quanto è dinamico il mio personale?
- Potreste anche considerare l'avvicendamento del personale nella frequenza dei test. Se il personale che esegue il ripristino cambia, assicuratevi che i nuovi membri del team comprendano il funzionamento del DR e il loro ruolo nel piano di DR. Se avete diversi nuovi membri del team che non sono sicuri o non hanno familiarità con i test DR, aggiungete un rischio al vostro piano di ripristino.
Su cos'altro dovrebbero concentrarsi i miei test?
L'obiettivo principale di qualsiasi test di disaster recovery è confermare la possibilità di recuperare i carichi di lavoro. Tuttavia, assicuratevi che anche i seguenti funzionino bene:
- Personale chiave: Il piano di DR deve delineare il personale necessario per il successo del ripristino e i suoi ruoli. Considerate se avete bisogno di più persone o ruoli durante i test, o se alcuni erano in eccesso rispetto ai requisiti, e quanto le persone sono state in grado di svolgere il loro ruolo.
- Comunicazione: Il piano di DR deve indicare chiaramente le modalità di comunicazione in caso di disastro. Valutare il funzionamento della comunicazione tra i partecipanti, compresi i canali di comunicazione utilizzati, durante i test.
- Dipendenze documentate: Il vostro piano di DR probabilmente delinea le dipendenze. Verificare che siano validi e che non ostacolino il processo di recupero. Allo stesso tempo, assicurarsi che tutte le nuove dipendenze siano registrate.
- Altra documentazione: I runbook potrebbero essere utilizzati per implementare il recupero, quindi è importante capire quanto siano accurati ed efficaci. Una documentazione insufficiente può causare ritardi, mentre fornire troppi dettagli o dettagli non pertinenti può avere lo stesso effetto. Chiedete a qualcuno che non sia l'autore di testare i passaggi per assicurarsi che siano chiari. In questo modo, il processo è utilizzabile anche se l'autore non è disponibile durante un disastro.
Dopo il test
Al termine di ogni test, registrare i risultati come parametro di riferimento per il test successivo. Se in seguito si modifica la procedura di test, è facile confrontare i risultati.
Dopo ogni test di disaster recovery, aggiornare il piano e la relativa documentazione in base ai risultati. Un piano di DR è un documento vivo che necessita di regolari aggiustamenti per rimanere efficace. Utilizzate il feedback dei partecipanti per identificare ciò che ha funzionato bene e ciò che non ha funzionato, e incorporate queste intuizioni nei test futuri. Inoltre, se necessario, prendete in considerazione l'idea di fornire ulteriore formazione, sia per chiarire i ruoli, sia per migliorare la comunicazione, sia per migliorare le competenze tecniche.