Condividi tramite

Raccomandazioni per la progettazione di una strategia di ripristino di emergenza

  • Articolo

Si applica alla seguente raccomandazione della check-list di Affidabilità del framework Azure Well-Architected:

RE:09 Implementare piani di continuità aziendale e ripristino di emergenza strutturati, testati e documentati che si allineano agli 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 ai clienti, è necessario avere una strategia di ripristino di emergenza affidabile e affidabile. Sono previsti errori e altri problemi principali. I tuoi preparativi per gestire questi eventi imprevisti determinano quanto i tuoi 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
Ripristino automatico Il passaggio automatico e/o manuale del traffico del carico di lavoro di produzione da un'area non disponibile a un'area geografica non interessata.
Ritornare alla situazione precedente Il passaggio automatico e/o manuale del traffico del carico di lavoro di produzione da una regione di failover alla regione primaria.

Strategie di progettazione chiave

Questa guida presuppone che siano già state eseguite le attività seguenti come parte della pianificazione dell'affidabilità:

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 creazione del carico di lavoro per assicurarsi che le parti necessarie per il ripristino ottimizzato siano disponibili 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

L'elemento fondamentale 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 l'ambiente si evolve. Presentare regolarmente il piano ai team appropriati (operazioni, leadership tecnologica e stakeholder aziendali) (ad esempio ogni sei mesi). Archiviarlo in un archivio dati sicuro a disponibilità elevata, ad esempio OneDrive for Business.

Segui 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 guasto che non sono considerate emergenze, come ad esempio il guasto di una singola risorsa, in modo che gli operatori non attivino impropriamente le escalation del Disaster Recovery. Queste modalità di errore possono essere risolte risolvendo il problema sul posto, ridistribuendo le risorse non riuscite o usando un piano di backup

  • Costruisci il piano di disaster recovery sulla documentazione 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 il piano di ripristino di emergenza e i documenti FMA in parallelo in modo che siano accurati quando l'ambiente cambia o quando il test rileva comportamenti imprevisti.

    • L'eventuale sviluppo di 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 preliminari, è 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.

    • L'entità responsabile della dichiarazione di chiusura dell'incidente.

    • Ruoli operativi.

    • Ruoli di test e validazione.

    • Ruoli di comunicazione interni ed esterni.

    • Ruoli di responsabilità principali nell'analisi retrospettiva e nella analisi della causa principale (RCA).

  • Definire i percorsi di escalation che il team responsabile 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 patrimonio dati e processi di ripristino a livello dell'intero carico di lavoro. Includere un ordine di operazioni prescritto 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. Includere screenshot, se possibile.

    • Definire le responsabilità del team rispetto alle responsabilità del provider di hosting cloud. Microsoft, ad esempio, è responsabile del ripristino di un PaaS (piattaforma come servizio), ma tu sei 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 significative dopo il failover prima di rendere nuovamente disponibile il carico di lavoro ai clienti. Il lavoro post-failover può includere aggiornamenti DNS, aggiornamenti delle stringhe di connessione del database e modifiche al routing del traffico. Catturare tutte le operazioni successive al failover nelle procedure di ripristino.

    Annotazioni

    La progettazione della ridondanza potrebbe consentire al sistema di ripristinarsi automaticamente da incidenti maggiori, completamente o parzialmente, quindi assicurati che il piano includa processi e procedure per questi scenari. Ad esempio, se si dispone di una progettazione completamente attiva-attiva che copre zone di disponibilità o regioni, è possibile eseguire il passaggio al funzionamento alternativo automaticamente in modo trasparente dopo un'interruzione della zona di disponibilità o della regione e ridurre al minimo i passaggi del piano di ripristino di emergenza che devono essere eseguiti. Analogamente, se il tuo carico di lavoro è stato progettato usando rubriche di distribuzione, potresti subire solo un'interruzione parziale se i stampi vengono distribuiti zonalmente. In questo caso, il piano di ripristino di emergenza deve coprire come recuperare 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 totale della distribuzione deve essere allineata agli obiettivi 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 situazioni di emergenza, non si vuole che gli script sviluppati in modo non corretto causino più danni o rallentano il processo di ripristino.

    Annotazioni

    L'automazione comporta rischi. Gli operatori sottoposti a training devono monitorare attentamente i processi automatizzati e intervenire in caso di problemi riscontrati da qualsiasi processo. Per ridurre al minimo il rischio che l'automazione reagisca ai falsi positivi, esaminare attentamente le 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 confusioni con le procedure di ripristino di emergenza. Il piano di failback dovrebbe seguire tutte le raccomandazioni di sviluppo e manutenzione del piano di ripristino di emergenza e dovrebbe essere strutturato allo stesso modo. Tutti i passaggi manuali necessari per il failover devono essere rispecchiati nel piano di failback. Il failback potrebbe 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 dipende dalla 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 quanto un piano di ripristino di emergenza ben sviluppato. Molti settori dispongono di quadri di conformità che richiedono un numero specificato di esercitazioni di ripristino di emergenza da svolgere 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 sul ripristino di emergenza di produzione all'anno. Le simulazioni su tavolo o le simulazioni non produttive aiutano a garantire che le parti coinvolte conoscano i loro ruoli e responsabilità. Queste esercitazioni aiutano anche gli operatori a creare 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 tempi di ripristino dei componenti e dei flussi per garantire che le destinazioni RTO e RPO definite per il carico di lavoro siano raggiungibili. 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 costruire familiarità con gli operatori esperti, ma anche per istruire nuovi operatori sui processi e sulle procedure di ripristino di emergenza (DR). Gli operatori senior dovrebbero impiegare tempo per consentire ai nuovi operatori di svolgere il proprio ruolo e di controllare le opportunità di miglioramento. 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.

  • Date al vostro team il maggior tempo possibile per la manutenzione durante le esercitazioni. Quando si pianifica il tempo di manutenzione, usare le metriche di ripristino acquisite durante i test come tempo minimo necessario per gli allocamenti.

  • Man mano che le procedure di esercitazione sul ripristino di emergenza maturano, si apprenderà quali procedure è possibile eseguire in parallelo e quali eseguire in sequenza. Nelle prime fasi delle pratiche di esercitazione, considerare che ogni procedura debba essere eseguita in sequenza e che sia necessario tempo aggiuntivo in ogni passaggio per gestire i problemi imprevisti.

Definire e gestire piani di backup per le risorse all'interno di flussi critici

Il backup è una parte importante del processo di ripristino complessivo. Spesso è solo una parte dell'ambiente che richiede il ripristino. I piani di ripristino per emergenze sono generalmente su scala di applicazione o persino regionale. L'eliminazione accidentale o dannosa di dati, danneggiamento dei file, malware e attacchi ransomware mirati può influire sulla disponibilità del carico di lavoro. Avere piani di backup solidi per ogni parte dell'ambiente è altrettanto importante quanto avere un piano di ripristino di emergenza efficace, in quanto un piano di ripristino di emergenza dipende da un piano di backup solido per essere efficace. Analogamente al piano di ripristino di emergenza, anche i piani di backup devono essere concordati in base ai livelli appropriati di gestione, rivisitati regolarmente per i possibili aggiornamenti e documentati in un archivio dati sicuro a disponibilità elevata.

  • Determinare le soluzioni di backup appropriate per i diversi servizi di Azure che fanno parte dei percorsi critici all'interno del carico di lavoro.

  • Definire i periodi di conservazione necessari per ogni servizio diverso.

  • Comprendere che uno strumento potrebbe non funzionare per tutto. Gli strumenti di Backup di Azure possono coprire molti tipi di risorse, ma non tutti.

  • A volte l'opzione migliore per ripristinare determinati tipi di oggetti è una ridistribuzione da un tipo di livello di repository a disponibilità elevata. (Azure DevOps, GitHub o altri)

  • I servizi dati avranno requisiti diversi rispetto agli oggetti correlati all'applicazione.

  • Assicurarsi di prendere in considerazione una strategia di archiviazione in più aree per i dati di backup per creare la recuperabilità tra aree.

  • Eseguire normali ripristini di test pianificati dei dati di backup per assicurarsi che i servizi funzionino come previsto.

Facilitazione del supporto per il ripristino di emergenza 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 ambiente dati aziendale per il Ripristino di Emergenza, consultare la serie sulla piattaforma dati di Azure relativa al Ripristino di Emergenza.

Facilitazione di Backup di Azure

Molti prodotti Azure hanno funzionalità di backup predefinite. Acquisire familiarità con queste funzionalità e includerle nelle procedure di ripristino.

Per i sistemi IaaS (infrastruttura distribuita come servizio), usare Backup di Azure per facilitare il backup di macchine virtuali e servizi correlati alle macchine virtuali e alcuni servizi dati. Per i prodotti comuni, vedere gli articoli seguenti:

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'affidabilità