Gestione della continuità aziendale in Azure
Azure gestisce uno dei programmi di gestione della continuità aziendale più maturi e rispettati nel settore. L'obiettivo della continuità aziendale in Azure è creare e migliorare la recuperabilità e la resilienza per tutti i servizi recuperabili in modo indipendente, indipendentemente dal fatto che un servizio sia rivolto ai clienti (parte di un'offerta di Azure) o un servizio di piattaforma di supporto interno.
Per comprendere la continuità aziendale, è importante notare che molte offerte sono costituite da più servizi. In Azure ogni servizio viene identificato in modo statico tramite strumenti ed è l'unità di misura usata per la privacy, la sicurezza, l'inventario, la gestione della continuità aziendale dei rischi e altre funzioni. Per misurare correttamente le funzionalità di un servizio, i tre elementi di persone, processi e tecnologie sono inclusi per ogni servizio, indipendentemente dal tipo di servizio.
Ad esempio:
- Se è presente un processo aziendale basato su persone, ad esempio un help desk o un team, il recapito del servizio è quello che fanno. Le persone usano processi e tecnologie per eseguire il servizio.
- Se è disponibile una tecnologia come servizio, ad esempio Azure Macchine virtuali, la distribuzione del servizio è la tecnologia insieme alle persone e ai processi che ne supportano il funzionamento.
Modello di responsabilità condiviso
Molte delle offerte da Azure richiedono di configurare il ripristino di emergenza in più aree e non sono responsabilità di Microsoft. Non tutti i servizi di Azure replicano automaticamente i dati o eseguono automaticamente il fallback da un'area problematica per eseguire la replica incrociata in un'altra area abilitata. In questi casi, si è responsabili della configurazione del ripristino e della replica.
Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. In alcuni scenari, tuttavia, l'utilizzo richiede di duplicare le distribuzioni e l'archiviazione in una capacità in più aree, se si sceglie di. Questi esempi illustrano il modello di responsabilità condivisa. È un pilastro fondamentale nella strategia di continuità aziendale e ripristino di emergenza.
Divisione di responsabilità
In qualsiasi data center locale si è proprietari dell'intero stack. Quando si spostano gli asset nel cloud, alcune responsabilità vengono trasferite a Microsoft. Il diagramma seguente illustra le aree e la divisione delle responsabilità tra l'utente e Microsoft in base al tipo di distribuzione.
Un buon esempio del modello di responsabilità condivisa è la distribuzione di macchine virtuali. Se si vuole configurare la replica tra aree per la resilienza in caso di errore nell'area, è necessario distribuire un set duplicato di macchine virtuali in un'area abilitata alternativa. Azure non replica automaticamente questi servizi in caso di errore. È responsabilità dell'utente distribuire gli asset necessari. È necessario disporre di un processo per modificare manualmente le aree primarie oppure è necessario usare gestione traffico per rilevare e eseguire automaticamente il failover.
I servizi di ripristino di emergenza abilitati per i clienti dispongono di documentazione pubblica che ti guiderà. Per un esempio di documentazione pubblica per il ripristino di emergenza abilitato per il cliente, vedere Azure Data Lake Analytics.
Per altre informazioni sul modello di responsabilità condivisa, vedere Centro protezione Microsoft.
Conformità alla continuità aziendale: responsabilità a livello di servizio
Ogni servizio è necessario per completare i record di ripristino di emergenza di continuità aziendale nello strumento Di continuità aziendale di Azure. I proprietari dei servizi possono usare lo strumento per lavorare all'interno di un modello federato per completare e incorporare i requisiti che includono:
Proprietà del servizio: definisce il servizio e il modo in cui vengono raggiunti il ripristino di emergenza e la resilienza e identifica la parte responsabile per il ripristino di emergenza (per la tecnologia). Per informazioni dettagliate sulla proprietà del ripristino, vedere la discussione sul modello di responsabilità condivisa nella sezione e nel diagramma precedente.
Analisi dell'impatto aziendale: questa analisi consente al proprietario del servizio di definire l'obiettivo del tempo di ripristino (RTO) e l'obiettivo del punto di ripristino (RPO) in base alla criticità del servizio in una tabella degli impatti. Gli effetti operativi, legali, normativi, di immagine del marchio e finanziari vengono usati come obiettivi di recupero.
Nota
Microsoft non pubblica RTO o RPO per i servizi perché questi dati sono solo per misure interne. Tutte le promesse e le misure dei clienti sono basate sul contratto di servizio perché copre un intervallo più ampio rispetto a RTO o RPO, che è applicabile solo in caso di perdita irreversibile.
Dipendenze: ogni servizio esegue il mapping delle dipendenze (altri servizi) che deve operare indipendentemente dalla criticità e viene mappato al runtime, necessario solo per il ripristino o entrambi. Se sono presenti dipendenze di archiviazione, viene eseguito il mapping di altri dati che definiscono gli elementi archiviati e, ad esempio, se sono necessari snapshot temporizzato.
Forza lavoro: come indicato nella definizione di un servizio, è importante conoscere la posizione e la quantità di forza lavoro in grado di supportare il servizio, garantire nessun singolo punto di guasto e se i dipendenti critici sono dispersi per evitare errori in un'unica posizione.
Fornitori esterni: Microsoft mantiene un elenco completo di fornitori esterni e i fornitori ritenuti critici vengono misurati per le capacità. Se identificato da un servizio come dipendenza, le funzionalità dei fornitori vengono confrontate con le esigenze del servizio per garantire che un'interruzione di terze parti non interrompa i servizi di Azure.
Classificazione di ripristino: questa classificazione è univoca per il programma di gestione della continuità aziendale di Azure. Questa classificazione misura diversi elementi chiave per creare un punteggio di resilienza:
- Disponibilità al failover: anche se può esserci un processo, potrebbe non essere la prima scelta per interruzioni a breve termine.
- Automazione del failover.
- Automazione della decisione di eseguire il failover.
Il tempo più affidabile e più breve per il failover è un servizio automatizzato e non richiede alcuna decisione umana. Un servizio automatizzato usa il monitoraggio heartbeat o le transazioni sintetiche per determinare che un servizio è inattivo e per avviare una correzione immediata.
Piano di ripristino e test: Azure richiede che ogni servizio disponga di un piano di ripristino dettagliato e di testare tale piano come se il servizio non fosse riuscito a causa di un'interruzione irreversibile. I piani di ripristino devono essere scritti in modo che un utente con competenze e accesso simili possa completare le attività. Un piano scritto evita di affidarsi a esperti di materia disponibili.
I test vengono eseguiti in diversi modi, tra cui il self-test in un ambiente di produzione o quasi produzione, e come parte dei drill-down dell'area completa di Azure in set di aree canary. Queste aree abilitate sono identiche alle aree di produzione, ma possono essere disabilitate senza influire sui servizi. Il test viene considerato integrato perché tutti i servizi sono interessati simultaneamente.
Abilitazione del cliente: quando si è responsabili della configurazione del ripristino di emergenza, Azure deve avere indicazioni sulla documentazione pubblica. Per tutti questi servizi, vengono forniti collegamenti alla documentazione e ai dettagli sul processo.
Verificare la conformità alla continuità aziendale
Quando un servizio ha completato il record di gestione della continuità aziendale, è necessario inviarlo per l'approvazione. Viene assegnato a un professionista esperto di continuità aziendale che esamina l'intero record per completezza e qualità. Se il record soddisfa tutti i requisiti, viene approvato. In caso contrario, viene rifiutato con una richiesta di rielaborazione. Questo processo garantisce che entrambe le parti accettino che sia stata soddisfatta la conformità della continuità aziendale e che il lavoro sia attestato solo dal proprietario del servizio. I team di controllo interno e conformità di Azure eseguono anche il campionamento casuale periodico per garantire che i dati migliori vengano inviati.
Test dei servizi
Microsoft e Azure eseguono test estesi sia per il ripristino di emergenza che per l'idoneità della zona di disponibilità. I servizi vengono testati in modo autonomo in un ambiente di produzione o pre-produzione per dimostrare la recuperabilità indipendente per i servizi che non dipendono dai failover principali della piattaforma.
Per garantire che i servizi possano essere ripristinati in modo analogo in un vero scenario di down dell'area, i test di tipo pull-plug-the-type vengono eseguiti in ambienti canary che sono aree completamente distribuite corrispondenti alla produzione. Ad esempio, i cluster, i rack e le unità di alimentazione vengono letteralmente disattivati per simulare un errore di area totale.
Durante questi test, Azure usa lo stesso processo di produzione per il rilevamento, la notifica, la risposta e il ripristino. Nessun utente si aspetta un'esercitazione e i tecnici si affidano al recupero sono le normali risorse di rotazione su chiamata. Questo intervallo evita di dipendere da esperti in materia che potrebbero non essere disponibili durante un evento effettivo.
Inclusi in questi test sono servizi in cui l'utente è responsabile della configurazione del ripristino di emergenza seguendo la documentazione pubblica di Microsoft. I team di servizio creano istanze simili ai clienti per indicare che il ripristino di emergenza abilitato per il cliente funziona come previsto e che le istruzioni fornite sono accurate.
Per altre informazioni sulle certificazioni, vedere il Centro protezione Microsoft e la sezione sulla conformità.