Gestione della continuità aziendale in Azure

Azure gestisce uno dei programmi di gestione della continuità aziendale più maturi e apprezzati del settore. L'obiettivo della continuità aziendale in Azure è sviluppare e migliorare la recuperabilità e la resilienza di tutti i servizi recuperabili in modo indipendente, che si tratti di servizi rivolti 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 mediante 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, indipendentemente dal tipo, vengono considerati tre elementi: persone, processi e tecnologie.

Ad esempio:

• Se è presente un processo aziendale basato su persone, ad esempio un help desk o un team, queste persone si occupano del recapito di servizi. Le persone usano processi e tecnologie per recapitare il servizio.
• Nel caso di una tecnologia come servizio, ad esempio Macchine virtuali di Microsoft Azure, il recapito del servizio è rappresentato dalla tecnologia e dalle persone e dai processi che ne supportano il funzionamento.

Modello di responsabilità condiviso

Molte delle offerte di Azure richiedono di configurare il ripristino di emergenza in più aree e non sono di 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, l'utente è responsabile 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 farlo. Questi esempi illustrano il modello di responsabilità condivisa. Si tratta di un pilastro fondamentale della strategia di continuità aziendale e ripristino di emergenza.

Divisione di responsabilità

In qualsiasi data center locale si è proprietari dell'intero stack. Con lo spostamento degli 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 più aree per la resilienza in caso si verifichi un 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 usare un servizio di gestione del traffico per rilevare i problemi ed eseguire automaticamente il failover.

Tutti i servizi di ripristino di emergenza abilitati dai clienti dispongono di documentazione pubblica che ne illustra l'utilizzo. Per un esempio di documentazione pubblica per il ripristino di emergenza abilitato dai clienti, vedere Azure Data Lake Analytics.

Per altre informazioni sul modello di responsabilità condivisa, vedere il Centro protezione Microsoft.

Conformità della continuità aziendale: responsabilità a livello di servizio

Ogni servizio deve completare dei record di ripristino di emergenza e continuità aziendale nello strumento di gestione della 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 garantiti la resilienza e il ripristino di emergenza e identifica la parte responsabile del 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. Come obiettivi di ripristino vengono usati gli impatti in termini operativi, legali, normativi, di immagine del marchio e finanziari.

  Nota

  Microsoft non pubblica gli RTO o gli RPO per i servizi, perché questi dati servono solo per le misure interne. Tutte le promesse e le misure dei clienti sono basate sul contratto di servizio, perché questo ha una portata più estesa rispetto a RTO e RPO, che sono applicabili solo in caso di perdite irreversibili.

• Dipendenze: ogni servizio identifica le dipendenze (altri servizi) di cui ha bisogno per funzionare, indipendentemente dalla criticità, ed è identificato come in fase di esecuzione, necessario solo per il ripristino o entrambi. Se sono presenti dipendenze di archiviazione, sono identificati altri dati che definiscono gli elementi archiviati e, ad esempio, se sono necessari snapshot temporizzati.

• Forza lavoro: come indicato nella definizione di un servizio, è importante conoscere quanto personale è disponibile per supportare il servizio e dove si trova, per garantire che non vi sia un singolo punto di guasto e che il personale critico sia distribuito in modo da evitare eventuali interruzioni causate dal raggruppamento in un'unica sede.

• Fornitori esterni: Microsoft mantiene un elenco completo di fornitori esterni e i fornitori ritenuti critici vengono misurati in termini di capacità. Se un servizio identifica un fornitore come dipendenza, le capacità del fornitore vengono confrontate con le esigenze del servizio per garantire che un'interruzione di terze parti non interrompa i servizi di Azure.

• Valutazione del ripristino: questa valutazione è univoca per il programma di gestione della continuità aziendale di Azure. Questa valutazione misura diversi elementi chiave per creare un punteggio di resilienza:

  • Propensione al failover: anche se è disponibile un processo, potrebbe non rappresentare la prima scelta per le interruzioni a breve termine.
  • Automazione del failover.
  • Automazione della decisione di eseguire il failover.

  Il sistema più affidabile e più veloce per eseguire il failover è un servizio automatizzato che non richiede alcuna decisione umana. Un servizio automatizzato usa il controllo dell'heartbeat o le transazioni sintetiche per determinare che un servizio è inattivo e per avviare la correzione immediata.

• Piano di ripristino e test: Azure richiede che ogni servizio abbia un piano di ripristino dettagliato e di testare tale piano come se il servizio non fosse riuscito a causa di un'interruzione catastrofica. 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 dover dipendere dalla presenza di esperti in materia.

  I test possono essere eseguiti in vari modi, ad esempio mediante la verifica automatica in un ambiente di produzione o di quasi produzione, o come parte di esercitazioni per prepararsi a un'interruzione di Azure a livello di area in set di aree canary. Queste aree abilitate sono identiche alle aree di produzione, ma possono essere disabilitate senza influire sui servizi. Il testing viene considerato integrato perché tutti i servizi sono interessati simultaneamente.

• Abilitazione dei clienti: quando l'utente è responsabile della configurazione del ripristino di emergenza, Azure deve rendere disponibile documentazione di riferimento pubblica. Per tutti questi servizi, vengono forniti collegamenti alla documentazione e dettagli sul processo.

Verificare la conformità della continuità aziendale

Quando un servizio ha completato il suo record di gestione della continuità aziendale, è necessario inviarlo per l'approvazione. Viene assegnato a un professionista esperto nella gestione della continuità aziendale, che esamina l'intero record verificandone la completezza e la 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 concordino sul rispetto della conformità della continuità aziendale e che il lavoro sia certificato solo dal proprietario del servizio. I team di controllo interno e conformità di Azure eseguono inoltre campionamenti casuali periodici per garantire l'invio dei dati migliori.

Test dei servizi

Microsoft e Azure eseguono test approfonditi sia del ripristino di emergenza che della preparazione delle zone di disponibilità. I servizi vengono verificati automaticamente in un ambiente di produzione o pre-produzione per dimostrare la recuperabilità indipendente per i servizi che non dipendono dai failover della piattaforma principale.

Per garantire che i servizi possano essere ripristinati in modo analogo in un vero scenario di inattività dell'area, vengono eseguiti test di tipo pull-the-plug in ambienti canary, che sono aree completamente distribuite che combaciano con l'ambiente di produzione. Ad esempio, i cluster, i rack e le unità di alimentazione vengono fisicamente spenti per simulare un errore dell'intera area.

Durante questi test, Azure usa lo stesso processo di produzione per il rilevamento, la notifica, la risposta e il ripristino. Nessuno si aspetta un'esercitazione e i tecnici incaricati del ripristino sono le normali risorse reperibili su chiamata. Questa strategia evita di dipendere da esperti in materia, che potrebbero non essere disponibili durante un evento reale.

Questi test includono i servizi in cui l'utente è responsabile della configurazione del ripristino di emergenza sulla base della documentazione pubblica di Microsoft. I team dei servizi creano istanze simili a quelle dei clienti per dimostrare che il ripristino di emergenza abilitato dal cliente funziona come previsto e che le istruzioni fornite sono accurate.

Per altre informazioni sulle certificazioni, vedere il Centro protezione di Microsoft e la sezione sulla conformità.

Passaggi successivi

• Replica tra più aree
• Panoramica delle linee guida sull'affidabilità per prodotti e servizi di Microsoft Azure