Attività del cliente necessarie
Pre-evento imprevisto
Per i servizi di Azure
- Acquisire familiarità con Integrità dei servizi di Azure nella portale di Azure. Questa pagina fungerà da "negozio mono-stop" durante un evento imprevisto.
- Prendere in considerazione l'uso degli avvisi di integrità dei servizi, che possono essere configurati per generare automaticamente notifiche quando si verificano eventi imprevisti di Azure.
Per Power BI
- Acquisire familiarità con l'integrità dei servizi nella interfaccia di amministrazione di Microsoft 365. Questa pagina fungerà da "negozio mono-stop" durante un evento imprevisto.
- Prendere in considerazione l'uso di Amministrazione Microsoft 365'app per dispositivi mobili per ricevere notifiche di avviso sugli eventi imprevisti del servizio automatico.
Durante l'evento imprevisto
Per i servizi di Azure
- Integrità dei servizi di Azure nel portale di gestione di Azure fornirà gli aggiornamenti più recenti.
- In caso di problemi di accesso all'integrità dei servizi, vedere la pagina Stato di Azure.
- Se si verificano problemi durante l'accesso alla pagina Stato, passare a @AzureSupport su X (in precedenza Twitter).
- Se l'impatto o i problemi non corrispondono all'evento imprevisto (o persistono dopo la mitigazione), contattare il supporto tecnico per generare un ticket di supporto del servizio.
Per Power BI
- La pagina Integrità dei servizi all'interno del interfaccia di amministrazione di Microsoft 365 fornirà gli aggiornamenti più recenti
- In caso di problemi di accesso all'integrità dei servizi, vedere la pagina relativa allo stato di Microsoft 365
- Se l'impatto o i problemi non corrispondono all'evento imprevisto (o se i problemi vengono mantenuti dopo la mitigazione), è necessario generare un ticket di supporto del servizio.
Dopo il ripristino di Microsoft
Per informazioni dettagliate, vedere le sezioni seguenti.
Post-evento imprevisto
Per i servizi di Azure
- Microsoft pubblicherà un PIR nella portale di Azure - Integrità dei servizi per la revisione.
Per Power BI
- Microsoft pubblicherà un PIR nel Amministrazione Microsoft 365 - Integrità dei servizi per la revisione.
Attendere il processo Microsoft
Il processo "Wait for Microsoft" è semplicemente in attesa che Microsoft ripristini tutti i componenti e i servizi nell'area primaria interessata. Dopo il ripristino, convalidare l'associazione della piattaforma dati a servizi condivisi o altri servizi aziendali, la data del set di dati e quindi eseguire i processi di aggiornamento del sistema alla data corrente.
Una volta completato questo processo, è possibile completare la convalida di esperti tecnici e aziendali (SME) abilitando l'approvazione degli stakeholder per il ripristino del servizio.
Ridistribuire in caso di emergenza
Per una strategia di ridistribuzione in caso di emergenza, è possibile descrivere il flusso di processo generale seguente.
Ripristinare i servizi condivisi e i sistemi di origine aziendali di Contoso
- Questo passaggio è un prerequisito per il ripristino della piattaforma dati.
- Questo passaggio verrà completato dai vari gruppi di supporto operativo Contoso responsabili dei servizi condivisi aziendali e dei sistemi di origine operativi.
Ripristinare i servizi di Azure si riferisce alle applicazioni e ai servizi che rendono disponibile l'offerta cloud di Azure all'interno dell'area secondaria per la distribuzione.
Servizi di Azure si riferisce alle applicazioni e ai servizi che rendono disponibile l'offerta cloud di Azure all'interno dell'area secondaria per la distribuzione.
- Questo passaggio è un prerequisito per il ripristino della piattaforma dati.
- Questo passaggio verrà completato da Microsoft e da altri partner PaaS (Platform as a Service)/Software as a Service (SaaS).
Ripristinare le basi della piattaforma dati
- Questo passaggio è il punto di ingresso per le attività di ripristino della piattaforma.
- Per la strategia di ridistribuzione, ogni componente/servizio necessario verrà acquistato e distribuito nell'area secondaria.
- Per una suddivisione dettagliata dei componenti e delle strategie di distribuzione, vedere la sezione Servizio e componente di Azure in questa serie.
- Questo processo deve includere anche attività come l'associazione ai servizi condivisi aziendali, garantire la connettività all'accesso/autenticazione e convalidare il funzionamento dell'offload del log, garantendo al tempo stesso la connettività ai processi upstream e downstream.
- I dati o l'elaborazione devono essere confermati. Ad esempio, la convalida del timestamp della piattaforma ripristinata.
- In caso di domande sull'integrità dei dati, è possibile prendere la decisione di eseguire il rollback nel tempo prima di eseguire la nuova elaborazione per aggiornare la piattaforma.
- Avere un ordine di priorità per i processi (in base all'impatto aziendale) consentirà di orchestrare il ripristino.
- Questo passaggio deve essere chiuso dalla convalida tecnica, a meno che gli utenti aziendali non interagiscano direttamente con i servizi. Se è presente l'accesso diretto, sarà necessario un passaggio di convalida aziendale.
- Una volta completata la convalida, viene eseguito un passaggio al team della soluzione individuale per avviare il proprio processo di ripristino di emergenza.
- Questo passaggio deve includere la conferma del timestamp corrente dei dati e dei processi.
- Se i processi di dati aziendali di base verranno eseguiti, le singole soluzioni devono essere consapevoli di questo tipo, ad esempio i flussi in ingresso/in uscita.
Ripristinare le singole soluzioni ospitate dalla piattaforma
- Ogni singola soluzione deve avere un proprio runbook di ripristino di emergenza. I runbook devono contenere almeno gli stakeholder aziendali designati che testano e confermano che il ripristino del servizio è stato completato.
- A seconda della contesa o della priorità delle risorse, le soluzioni chiave o i carichi di lavoro possono essere classificati in ordine di priorità rispetto ad altri, ad esempio i processi aziendali principali su lab ad hoc.
- Una volta completati i passaggi di convalida, viene eseguito un passaggio alle soluzioni downstream per avviare il processo di ripristino di emergenza.
Passaggio a downstream, sistemi dipendenti
- Una volta ripristinati i servizi dipendenti, il processo di ripristino del ripristino di emergenza E2E è stato completato.
Nota
Sebbene sia teoricamente possibile automatizzare completamente un processo di ripristino di emergenza E2E, è improbabile che venga considerato il rischio dell'evento rispetto al costo delle attività SDLC necessarie per coprire il processo E2E.
Il fallback nell'area primaria è il processo di spostamento del servizio della piattaforma dati e dei relativi dati nell'area primaria, una volta disponibile per BAU.
A seconda della natura dei sistemi di origine e dei vari processi di dati, il fallback della piattaforma dati può essere eseguito indipendentemente da altre parti dell'eco system dei dati.
I clienti sono invitati a esaminare le dipendenze della propria piattaforma dati (upstream e downstream) per prendere la decisione appropriata. La sezione seguente presuppone un ripristino indipendente della piattaforma dati.
- Una volta che tutti i componenti/servizi necessari sono stati resi disponibili nell'area primaria, i clienti completano un smoke test per convalidare il ripristino Microsoft.
- La configurazione del componente/servizio verrà convalidata. I delta vengono risolti tramite ridistribuzione dal controllo del codice sorgente.
- La data di sistema nell'area primaria verrebbe stabilita tra i componenti con stato. Il delta tra la data stabilita e il timestamp di data/ora nell'area secondaria deve essere risolto eseguendo nuovamente o riproducendo i processi di inserimento dati da quel punto in avanti.
- Con l'approvazione di stakeholder aziendali e tecnici, verrà selezionata una finestra di fallback. Idealmente, questo dovrebbe verificarsi durante un'attività e un'elaborazione del sistema.
- Durante il fallback, l'area primaria verrebbe sincronizzata con l'area secondaria, prima del passaggio del sistema.
- Dopo un periodo di esecuzione parallela, l'area secondaria viene presa offline dal sistema.
- I componenti nell'area secondaria verranno eliminati o rimossi, a seconda della strategia di ripristino di emergenza selezionata.
Processo di riserva a caldo
Per una strategia "Warm Spare", il flusso di processo di alto livello è strettamente allineato a quello della "Ridistribuzione in caso di emergenza", la differenza principale è che i componenti sono già stati acquistati nell'area secondaria. Questa strategia elimina il rischio di conflitti di risorse da altre organizzazioni che cercano di completare il proprio ripristino di emergenza in tale area.
Processo di riserva a caldo
La strategia "Hot Spare" significa che i servizi della piattaforma, tra cui PaaS e i sistemi IaaS (Infrastructure as a Service) verranno mantenuti nonostante l'evento di emergenza man mano che i sistemi secondari vengono eseguiti in parallelo con i sistemi primari. Come per la strategia "Warm Spare", questa strategia elimina il rischio di conflitti di risorse da altre organizzazioni che cercano di completare il proprio ripristino di emergenza in tale area.
I clienti con hot spare monitorano il ripristino di componenti/servizi Microsoft nell'area primaria. Al termine, i clienti convalidano i sistemi di area primaria e completano il fallback nell'area primaria. Questo processo sarà simile al processo di failover di ripristino di emergenza, ovvero controllare la codebase e i dati disponibili, ridistribuendo in base alle esigenze.
Nota
È consigliabile prendere una nota speciale per garantire che i metadati di sistema siano coerenti tra le due aree.
- Al termine del fallback al database primario, i servizi di bilanciamento del carico di sistema possono essere aggiornati per riportare l'area primaria nella topologia di sistema. Se disponibile, è possibile usare un approccio canary release per cambiare in modo incrementale l'area primaria per il sistema.
Struttura del piano di ripristino di emergenza
Un piano di ripristino di emergenza efficace presenta una guida dettagliata per il ripristino del servizio che può essere eseguito da una risorsa tecnica di Azure. Di conseguenza, i seguenti elencano una struttura MVP proposta per un piano di ripristino di emergenza.
- Requisiti dei processi
- Qualsiasi dettaglio specifico del processo di ripristino di emergenza del cliente, ad esempio l'autorizzazione corretta necessaria per avviare il ripristino di emergenza e prendere decisioni chiave sul ripristino in base alle esigenze (inclusa la "definizione del fatto"), il supporto del servizio di riferimento per il ripristino di emergenza e i dettagli del ripristino di emergenza.
- Conferma della risorsa, incluso il backup del lead e dell'executor di ripristino di emergenza. Tutte le risorse devono essere documentate con contatti primari e secondari, percorsi di escalation e calendari di uscita. In situazioni critiche di ripristino di emergenza, potrebbe essere necessario prendere in considerazione i sistemi del roster.
- Computer portatile, power pack o alimentazione di backup, connettività di rete e dettagli del telefono cellulare per executor di ripristino di emergenza, backup di ripristino di emergenza ed eventuali punti di escalation.
- Il processo da seguire se uno dei requisiti del processo non viene soddisfatto.
- Elenco contatti
- Leadership e gruppi di supporto per il ripristino di emergenza.
- PMI aziendali che completeranno il ciclo di test/revisione per il recupero tecnico.
- Proprietari aziendali interessati, inclusi i responsabili approvazione del ripristino del servizio.
- Proprietari tecnici interessati, inclusi i responsabili approvazione del ripristino tecnico.
- Il supporto delle PMI in tutte le aree interessate, incluse le principali soluzioni ospitate dalla piattaforma.
- Sistemi downstream interessati: supporto operativo.
- Sistemi di origine upstream: supporto operativo.
- Contatti dei servizi condivisi aziendali. Ad esempio, il supporto per l'accesso e l'autenticazione, il monitoraggio della sicurezza e il supporto del gateway
- Qualsiasi fornitore esterno o di terze parti, inclusi i contatti di supporto per i provider di servizi cloud.
- Progettazione dell'architettura
- Descrivere i dettagli dello scenario end-end (E2E) e allegare tutta la documentazione di supporto associata.
- Dipendenze
- Elencare tutte le relazioni e le dipendenze dei componenti.
- Prerequisiti per il ripristino di emergenza
- Conferma che i sistemi di origine upstream sono disponibili in base alle esigenze.
- L'accesso con privilegi elevati nello stack è stato concesso alle risorse dell'executor di ripristino di emergenza.
- I servizi di Azure sono disponibili in base alle esigenze.
- Il processo da seguire se uno dei prerequisiti non è stato soddisfatto.
- Ripristino tecnico: istruzioni dettagliate
- Eseguire l'ordine.
- Descrizione passaggio.
- Prerequisito del passaggio.
- Passaggi dettagliati del processo per ogni azione discreta, inclusi gli URL.
- Istruzioni di convalida, incluse le prove necessarie.
- Tempo previsto per il completamento di ogni passaggio, incluse le contingenze.
- Processo da seguire se il passaggio ha esito negativo.
- I punti di escalation in caso di errore o di supporto delle PMI.
- Ripristino tecnico - prerequisiti
- Confermare il timestamp di data corrente del sistema tra i componenti chiave.
- Verificare gli URL e gli INDIRIZZI IP del sistema di ripristino di emergenza.
- Prepararsi per il processo di revisione degli stakeholder aziendali, inclusa la conferma dell'accesso ai sistemi e delle PMI aziendali che completano la convalida e l'approvazione.
- Revisione e approvazione degli stakeholder aziendali
- Dettagli contatto risorsa business.
- I passaggi di convalida aziendale in base al ripristino tecnico precedente.
- Il percorso di prova richiesto dal responsabile approvazione aziendale che firma il ripristino.
- Prerequisiti di ripristino
- Consegna al supporto operativo per eseguire i processi di dati per aggiornare il sistema.
- Consegnare i processi downstream e le soluzioni, confermando la data e i dettagli di connessione del sistema di ripristino di emergenza.
- Verificare che il processo di ripristino sia stato completato con il lead di ripristino di emergenza, confermando l'evidenza e il runbook completato.
- Notificare ai team di sicurezza che i privilegi di accesso elevati possono essere rimossi dal team di ripristino di emergenza.
Callout
- È consigliabile includere screenshot di sistema di ogni processo di passaggio. Questi screenshot consentiranno di risolvere la dipendenza dalle PMI di sistema per completare le attività.
- Per mantenere il passo con i servizi cloud in rapida evoluzione, il piano di ripristino di emergenza deve essere regolarmente rivisto, testato ed eseguito dalle risorse con conoscenze attuali di Azure e dei relativi servizi.
- I passaggi di ripristino tecnico devono riflettere la priorità del componente e della soluzione per l'organizzazione. Ad esempio, i flussi di dati aziendali principali vengono recuperati prima di lab di analisi dei dati ad hoc.
- I passaggi di ripristino tecnico devono seguire l'ordine dei flussi di lavoro (in genere da sinistra a destra), dopo il ripristino dei componenti di base o del servizio come Key Vault. Questa strategia garantisce che le dipendenze upstream siano disponibili e che i componenti possano essere testati in modo appropriato.
- Una volta completato il piano dettagliato, è necessario ottenere un tempo totale per le attività con emergenza. Se il totale è superiore all'obiettivo del tempo di ripristino concordato (RTO), sono disponibili diverse opzioni:
- Automatizzare i processi di ripristino selezionati (laddove possibile).
- Cercare le opportunità di eseguire i passaggi di ripristino selezionati in parallelo (laddove possibile). Tuttavia, notando che questa strategia potrebbe richiedere risorse aggiuntive dell'executor di ripristino di emergenza.
- Elevare i componenti chiave a livelli più elevati di livelli di servizio, ad esempio PaaS, in cui Microsoft assume maggiore responsabilità per le attività di ripristino del servizio.
- Estendere l'obiettivo RTO con gli stakeholder.
Test di ripristino di emergenza
La natura dell'offerta del servizio cloud di Azure comporta vincoli per qualsiasi scenario di test di ripristino di emergenza. Di conseguenza, il materiale sussidiario consiste nell'alzarsi di una sottoscrizione di ripristino di emergenza con i componenti della piattaforma dati in quanto saranno disponibili nell'area secondaria.
Da questa baseline, il runbook del piano di ripristino di emergenza può essere eseguito in modo selettivo, prestando particolare attenzione ai servizi e ai componenti che possono essere distribuiti e convalidati. Questo processo richiederà un set di dati di test curato, abilitando la conferma dei controlli di convalida tecnici e aziendali in base al piano.
Un piano di ripristino di emergenza deve essere testato regolarmente non solo per assicurarsi che sia aggiornato, ma anche per creare "memoria muscolare" per i team che eseguono attività di failover e ripristino.
- Anche i backup dei dati e della configurazione devono essere testati regolarmente per assicurarsi che siano "adatti allo scopo" per supportare eventuali attività di ripristino.
L'area chiave su cui concentrarsi durante un test di ripristino di emergenza consiste nel garantire che i passaggi prescrittivi siano ancora corretti e i tempi stimati siano ancora rilevanti.
- Se le istruzioni riflettono le schermate del portale anziché il codice, le istruzioni devono essere convalidate almeno ogni 12 mesi a causa della frequenza di modifica nel cloud.
Anche se l'aspirazione è quella di avere un processo di ripristino di emergenza completamente automatizzato, l'automazione completa potrebbe non essere probabile a causa della rarità dell'evento. È quindi consigliabile stabilire la linea di base di ripristino con l'infrastruttura DSC (Desired State Configuration) come codice (IaC) usata per distribuire la piattaforma e quindi elevarsi come nuovi progetti compilati sulla base della baseline.
- Nel corso del tempo durante l'estensione di componenti e servizi, deve essere applicata una NFR, che richiede il refactoring della pipeline di distribuzione di produzione per fornire copertura per il ripristino di emergenza.
Se i tempi del runbook superano l'obiettivo RTO, sono disponibili diverse opzioni:
- Estendere l'obiettivo RTO con gli stakeholder.
- Ridurre il tempo necessario per le attività di ripristino, tramite l'automazione, l'esecuzione di attività in parallelo o la migrazione a livelli di server cloud superiori.
Azure Chaos Studio
Azure Chaos Studio è un servizio gestito per migliorare la resilienza inserendo errori nelle applicazioni Azure. Chaos Studio consente di orchestrare l'inserimento degli errori nelle risorse di Azure in modo sicuro e controllato, usando esperimenti. Per una descrizione dei tipi di errori attualmente supportati, vedere la documentazione del prodotto.
L'iterazione corrente di Chaos Studio copre solo un subset di componenti e servizi di Azure. Fino a quando non vengono aggiunte più librerie di errore, Chaos Studio è un approccio consigliato per i test di resilienza isolata anziché per i test completi del ripristino di emergenza del sistema.
Altre informazioni su Chaos Studio sono disponibili nella documentazione di Azure Chaos Studio.
Azure Site Recovery
Per i componenti IaaS, Azure Site Recovery proteggerà la maggior parte dei carichi di lavoro in esecuzione in una macchina virtuale o in un server fisico supportato
Sono disponibili linee guida avanzate per:
- Esecuzione di un'esercitazione sul ripristino di emergenza di una macchina virtuale di Azure
- Esecuzione di un failover di ripristino di emergenza in un'area secondaria
- Esecuzione di un fallback di ripristino di emergenza nell'area primaria
- Abilitazione dell'automazione di un piano di ripristino di emergenza
Risorse correlate
- Progettazione della resilienza e della disponibilità
- Continuità aziendale e ripristino di emergenza
- Backup e ripristino di emergenza per le applicazioni Azure
- Resilienza in Azure
- Riepilogo dei contratti di servizio
- Cinque procedure consigliate per anticipare l'errore
Passaggi successivi
Dopo aver appreso come distribuire lo scenario, è possibile leggere un riepilogo della serie di piattaforme dati di Ripristino di emergenza per Azure.