Suggerimenti per la progettazione di una strategia di ripristino di emergenza
Si applica a questa raccomandazione per l'affidabilità di Azure Well-Architected Framework:
| RE:09 | Implementare piani di continuità aziendale e ripristino di emergenza strutturati, testati e documentati in linea con gli obiettivi di ripristino. I piani devono coprire tutti i componenti e il sistema nel suo complesso. |
|---|
Questa guida descrive le raccomandazioni per la progettazione di una strategia di ripristino di emergenza affidabile per un carico di lavoro. Per soddisfare gli obiettivi interni a livello di servizio (SLO) o anche un contratto di servizio (SLA) garantito per i clienti, è necessario avere una strategia di ripristino di emergenza affidabile e affidabile. Sono previsti errori e altri problemi principali. I preparativi per gestire questi eventi imprevisti determinano quanto i clienti possono fidarsi dell'azienda per offrire loro in modo affidabile. Una strategia di ripristino di emergenza è la spina dorsale della preparazione per gli eventi imprevisti principali.
Definizioni
| Termine | Definizione |
|---|---|
| Failover | Il trasferimento automatico e/o manuale del traffico del carico di lavoro di produzione da un'area non disponibile a un'area geografica non interessata. |
| Failback | Il passaggio automatico e/o manuale del traffico del carico di lavoro di produzione da un'area di failover all'area primaria. |
Strategie di progettazione chiave
Questa guida presuppone che siano già state eseguite le attività seguenti come parte della pianificazione dell'affidabilità:
Identificare i flussi critici e non critici.
Eseguire l'analisi della modalità di errore (FMA) per i flussi.
Identificare le destinazioni di affidabilità.
Progettare per garantire l'affidabilità tramite ridondanza, scalabilità, auto-conservazione e riparazione automatica.
Progettare una strategia di test affidabile.
Una strategia di ripristino di emergenza affidabile si basa sulla base di un'architettura affidabile del carico di lavoro. Affrontare l'affidabilità in ogni fase della compilazione del carico di lavoro per garantire che i componenti necessari per il ripristino ottimizzato siano soddisfatti prima di iniziare a progettare la strategia di ripristino di emergenza. Questa base garantisce che gli obiettivi di affidabilità del carico di lavoro, ad esempio l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO), siano realistici e raggiungibili.
Gestire un piano di ripristino di emergenza
La base di una strategia di ripristino di emergenza affidabile per un carico di lavoro è il piano di ripristino di emergenza. Il piano deve essere un documento vivente che viene regolarmente esaminato e aggiornato man mano che si evolve l'ambiente. Presentare il piano ai team appropriati (operazioni, leadership tecnologica e stakeholder aziendali) regolarmente (ogni sei mesi, ad esempio). Archiviarlo in un archivio dati sicuro a disponibilità elevata, ad esempio OneDrive for Business.
Seguire queste raccomandazioni per sviluppare il piano di ripristino di emergenza:
Definire chiaramente ciò che costituisce un'emergenza e quindi richiede l'attivazione del piano di ripristino di emergenza.
Le emergenze sono problemi su larga scala. Potrebbero trattarsi di interruzioni a livello di area, interruzioni dei servizi, ad esempio ID Microsoft Entra o DNS di Azure, o attacchi dannosi gravi come attacchi ransomware o attacchi DDoS.
Identificare le modalità di errore non considerate emergenze, ad esempio l'errore di una singola risorsa, in modo che gli operatori non richiamino erroneamente le escalation di ripristino di emergenza.
Compilare il piano di ripristino di emergenza nella documentazione di FMA. Assicurarsi che il piano di ripristino di emergenza acquisisca le modalità di errore e le strategie di mitigazione per le interruzioni definite come emergenze. Aggiornare sia il piano di ripristino di emergenza che i documenti FMA in parallelo in modo che siano accurati quando l'ambiente cambia o quando il test individua comportamenti imprevisti.
- Se si sviluppano piani di ripristino di emergenza per ambienti non di produzione dipende dai requisiti aziendali e dall'impatto sui costi. Ad esempio, se si offrono ambienti di controllo di qualità (QA) a determinati clienti per i test non definitive, è possibile includere tali ambienti nella pianificazione del ripristino di emergenza.
Definire chiaramente ruoli e responsabilità all'interno del team del carico di lavoro e comprendere eventuali ruoli esterni correlati all'interno dell'organizzazione. I ruoli devono includere:
L'entità responsabile della dichiarazione di emergenza.
Parte responsabile della dichiarazione di chiusura degli eventi imprevisti.
Ruoli operativi.
Test e convalida dei ruoli.
Ruoli di comunicazione interni ed esterni.
Ruoli potenziali di analisi retrospettiva e radice della causa principale.
Definire i percorsi di escalation che il team del carico di lavoro deve seguire per assicurarsi che lo stato di ripristino venga comunicato agli stakeholder.
Acquisire procedure di ripristino a livello di componente, ripristino a livello di dati e processi di ripristino a livello di carico di lavoro. Includere un ordine prestabilito di operazioni per garantire che i componenti vengano recuperati nel modo meno significativo. Ad esempio, ripristinare e controllare i database prima di ripristinare l'applicazione.
Illustra in dettaglio ogni procedura di ripristino a livello di componente come guida dettagliata. Se possibile, includere screenshot.
Definire le responsabilità del team rispetto alle responsabilità del provider di hosting cloud. Microsoft, ad esempio, è responsabile del ripristino di un paaS (piattaforma distribuita come servizio), ma è responsabile della riattivazione dei dati e dell'applicazione della configurazione al servizio.
Includere i prerequisiti per l'esecuzione della procedura. Ad esempio, elencare gli script o le credenziali necessari che devono essere raccolti.
Acquisire la causa radice dell'evento imprevisto ed eseguire la mitigazione prima di avviare il ripristino. Ad esempio, se la causa dell'evento imprevisto è un problema di sicurezza, attenuare il problema prima di ripristinare i sistemi interessati nell'ambiente di failover.
A seconda della progettazione della ridondanza per il carico di lavoro, potrebbe essere necessario eseguire operazioni di post-failover significative prima di rendere nuovamente disponibile il carico di lavoro per i clienti. Il lavoro post-failover può includere aggiornamenti DNS, aggiornamenti del database stringa di connessione e modifiche al routing del traffico. Acquisire tutte le operazioni successive al failover nelle procedure di ripristino.
Nota
La progettazione della ridondanza potrebbe consentire di eseguire automaticamente il ripristino da eventi imprevisti gravi completamente o parzialmente, quindi assicurarsi che il piano includa processi e procedure per questi scenari. Ad esempio, se si dispone di una progettazione completamente attiva-attiva che si estende su zone o aree di disponibilità, potrebbe essere possibile eseguire il failover in modo trasparente automaticamente dopo un'interruzione della zona di disponibilità o di un'area e ridurre al minimo i passaggi del piano di ripristino di emergenza che devono essere eseguiti. Analogamente, se il carico di lavoro è stato progettato usando indicatori di distribuzione, è possibile che si verifichi un'interruzione parziale solo se i francobolli vengono distribuiti in modo zonale. In questo caso, il piano di ripristino di emergenza deve coprire come ripristinare i timbri in zone o aree non interessate.
Se è necessario ridistribuire l'app nell'ambiente di failover, usare gli strumenti per automatizzare il processo di distribuzione il più possibile. Assicurarsi che le pipeline DevOps siano state pre-distribuite e configurate negli ambienti di failover in modo da poter iniziare immediatamente le distribuzioni dell'app. Usare distribuzioni end-to-end automatizzate, con controlli di approvazione manuali, se necessario, per garantire un processo di distribuzione coerente ed efficiente. La durata completa della distribuzione deve essere allineata alle destinazioni di ripristino.
- Quando una fase del processo di distribuzione richiede un intervento manuale, documentare i passaggi manuali. Definire chiaramente ruoli e responsabilità.
Automatizzare la maggior parte della procedura possibile. Negli script usare la programmazione dichiarativa perché consente l'idempotenza. Quando non è possibile usare la programmazione dichiarativa, tenere presente lo sviluppo e l'esecuzione del codice personalizzato. Usare la logica di ripetizione dei tentativi e la logica dell'interruttore per evitare di perdere tempo sugli script bloccati in un'attività interrotta. Poiché questi script vengono eseguiti solo in caso di emergenza, non si vuole che gli script sviluppati in modo non corretto causino più danni o rallentano il processo di ripristino.
Nota
L'automazione comporta rischi. Gli operatori con training devono monitorare attentamente i processi automatizzati e intervenire se si verificano problemi. Per ridurre al minimo il rischio che l'automazione reagisca ai falsi positivi, è necessario eseguire esercitazioni sul ripristino di emergenza. Testare tutte le fasi del piano. Simulare il rilevamento per generare avvisi e quindi spostarsi nell'intera procedura di ripristino.
Tenere presente che le esercitazioni sul ripristino di emergenza devono convalidare o informare gli aggiornamenti delle metriche di destinazione del ripristino. Se si rileva che l'automazione è soggetta a falsi positivi, potrebbe essere necessario aumentare le soglie di failover.
Separare il piano di failback dal piano di ripristino di emergenza per evitare potenziali confusione con le procedure di ripristino di emergenza. Il piano di failback deve seguire tutte le raccomandazioni di sviluppo e manutenzione del piano di ripristino di emergenza e deve essere strutturato nello stesso modo. Tutti i passaggi manuali necessari per il failover devono essere rispecchiati nel piano di failback. Il failback può verificarsi rapidamente dopo il failover o potrebbe richiedere giorni o settimane. Prendere in considerazione il failback come separato dal failover.
- La necessità di eseguire il failback è situazione. Se si instrada il traffico tra aree per motivi di prestazioni, il failback del carico originariamente nell'area di failover è importante. In altri casi, è possibile che il carico di lavoro sia stato progettato per funzionare completamente indipendentemente dall'ambiente di produzione in cui si trova in qualsiasi momento.
Eseguire esercitazioni sul ripristino di emergenza
Una pratica di test del ripristino di emergenza è importante come un piano di ripristino di emergenza ben sviluppato. Molti settori hanno framework di conformità che richiedono un numero specificato di esercitazioni sul ripristino di emergenza da eseguire regolarmente. Indipendentemente dal tuo settore, le normali esercitazioni sul ripristino di emergenza sono fondamentali per il tuo successo.
Seguire queste raccomandazioni per le esercitazioni sul ripristino di emergenza riuscite:
Eseguire almeno un'esercitazione di ripristino di emergenza di produzione all'anno. Le esercitazioni da tavolo (esecuzione secca) o le esercitazioni non di produzione contribuiscono a garantire che le parti coinvolte conoseguano i ruoli e le responsabilità. Queste esercitazioni aiutano anche gli operatori a costruire familiarità ("memoria muscolare") seguendo i processi di recupero. Ma solo le esercitazioni di produzione testano realmente la validità del piano di ripristino di emergenza e le metriche RTO e RPO. Usare le esercitazioni di produzione per tempore i processi di ripristino per componenti e flussi per garantire che le destinazioni RTO e RPO definite per il carico di lavoro siano ottenibili. Per le funzioni fuori controllo, ad esempio la propagazione DNS, assicurarsi che le destinazioni RTO e RPO per i flussi che coinvolgono tali funzioni tengano conto di possibili ritardi oltre il controllo.
Usare le esercitazioni su tavolo non solo per creare familiarità per gli operatori conditi, ma anche per informare i nuovi operatori sui processi e sulle procedure di ripristino di emergenza. Gli operatori senior devono impiegare tempo per consentire ai nuovi operatori di svolgere il proprio ruolo e devono watch per migliorare le opportunità. Se un nuovo operatore è esitante o confuso da un passaggio di una procedura, esaminare tale procedura per assicurarsi che sia scritto chiaramente.
Considerazioni
L'esecuzione di esercitazioni sul ripristino di emergenza nell'ambiente di produzione può causare errori irreversibili imprevisti. Assicurarsi di testare le procedure di ripristino in ambienti non di produzione durante le distribuzioni iniziali.
Assegnare al team il tempo di manutenzione più lungo possibile durante le esercitazioni. Quando si pianifica il tempo di manutenzione, usare le metriche di ripristino acquisite durante i test come tempo minimo necessario .
Man mano che le procedure di drill-down di ripristino di emergenza maturano, si apprenderà quali procedure è possibile eseguire in parallelo e quali è necessario eseguire in sequenza. Nelle prime fasi delle procedure di drill- si presuppone che ogni procedura debba essere eseguita in sequenza e che sia necessario tempo aggiuntivo in ogni passaggio per gestire i problemi imprevisti.
Facilitazione di Azure
Molti prodotti Azure hanno funzionalità di failover predefinite. Acquisire familiarità con queste funzionalità e includerle nelle procedure di ripristino.
Per i sistemi IaaS (infrastruttura distribuita come servizio), usare Azure Site Recovery per automatizzare il failover e il ripristino. Per i prodotti PaaS comuni, vedere gli articoli seguenti:
Esempio
Per indicazioni sulla preparazione di un patrimonio di dati aziendale per il ripristino di emergenza, vedere la serie di piattaforma dati di Azure per il ripristino di emergenza.
Collegamenti correlati
Elenco di controllo per l'affidabilità
Fare riferimento al set completo di raccomandazioni.