Operazioni da eseguire durante un'interruzione del servizio di Azure

Microsoft si impegna costantemente per garantire agli utenti la disponibilità dei servizi in base alle esigenze. Tuttavia, si verificano interruzioni del servizio non pianificate. Questo articolo illustra cosa accade quando lo fanno.

Microsoft fornisce un Contratto di servizio (SLA) per molti dei suoi servizi come impegno per il tempo di attività e la connettività. I contratti di servizio relativi ai singoli servizi di Azure sono disponibili alla pagina Contratti di servizio.

Comprendere l'ambito degli eventi imprevisti

Quando si verifica un evento imprevisto, se si comprende l'ambito di tale evento imprevisto, è possibile determinare il miglior corso di azione.

Per comprendere l'ambito di un evento imprevisto, seguire questa procedura:

1. Passare a Integrità dei servizi di Azure, che fornisce:

   • Informazioni su problemi o eventi che potrebbero influire sui servizi.

   • Avvisi di aggiornamento automatico degli eventi imprevisti, in modo che sia possibile ricevere automaticamente una notifica degli aggiornamenti dello stato degli eventi imprevisti. Quando Microsoft riconosce l'ambito di un evento imprevisto, viene aggiornato lo stato dell'evento imprevisto. È possibile configurare questi aggiornamenti di stato per passare a un gruppo di azioni di Monitoraggio di Azure, che può inviare avvisi a un'ampia gamma di posizioni, ad esempio un indirizzo di posta elettronica o al proprio sistema di gestione degli eventi imprevisti.

2. Se si verificano problemi di accesso al portale di Azure, passare allo stato di Azure.

   Annotazioni

   Lo stato di Azure mostra solo problemi diffusi che soddisfano determinati criteri. Poiché la pagina Stato di Azure non conosce le sottoscrizioni e i tenant gestiti, non può fornire una visualizzazione accurata dei problemi più piccoli che potrebbero influire sui servizi.

3. Se si verificano problemi con la pagina di stato, controllare la presenza di post da @AzureSupport sulla piattaforma social X.

Eventi imprevisti della zona di disponibilità e del data center

Molti problemi sono limitati a una singola zona di disponibilità. Le zone di disponibilità rappresentano data center o gruppi di data center isolati da altre zone di disponibilità nella stessa area. Quando una zona di disponibilità riscontra un problema, l'impatto visualizzato dipende dalla modalità di distribuzione di un servizio:

• Potrebbero essere interessati i servizi di zona vincolati alla zona di disponibilità interessata.
• È improbabile che i servizi a ridondanza di zona siano interessati. Non dovresti dover eseguire alcuna azione correttiva per le risorse con ridondanza di zona.
• I servizi regionali (non di zona) potrebbero essere interessati perché potrebbero usare la zona di disponibilità interessata.

Per altre informazioni sul supporto della zona di disponibilità nei servizi di Azure e sulle differenze tra i servizi zonali, con ridondanza della zona e a livello di area (non di zona), vedere Servizi di Azure con supporto per la zona di disponibilità.

In caso di problemi relativi alle risorse di zona o a livello di area distribuite nella zona di disponibilità interessata, prendere in considerazione l'avvio dei piani di continuità aziendale e ripristino di emergenza (BC/DR).

Zone di disponibilità logiche e fisiche

Ogni sottoscrizione di Azure visualizza un elenco diverso di zone di disponibilità. Le zone logiche usate da ogni sottoscrizione possono corrispondere a zone fisiche diverse. È possibile eseguire il mapping tra le zone logiche e le zone fisiche per verificare quali risorse vengono eseguite nella zona di disponibilità fisica interessata. Per altre informazioni, vedere Zone di disponibilità fisiche e logiche.

Eventi imprevisti a livello di area

In alcuni casi, i problemi interessano un'intera area. I problemi a livello di area possono verificarsi quando un'area non dispone di zone di disponibilità. Quando si verifica un evento imprevisto a livello di area, potrebbe essere necessario prendere in considerazione l'avvio del piano di ripristino di emergenza. Il tuo piano potrebbe includere il failover in un'altra regione.

Assegnare priorità alla continuità aziendale

Quando si affronta un evento imprevisto, la priorità principale consiste nel mantenere in esecuzione le operazioni aziendali. Concentrarsi troppo sull'isolamento o sulla correzione della causa di un problema può deviare l'attenzione dal ripristino delle operazioni della soluzione e dalla gestione della continuità aziendale.

I fattori seguenti presentano situazioni in cui non è necessariamente necessario eseguire alcuna operazione per mantenere la continuità aziendale:

• Impatto effettivo del problema sulle risorse di produzione e sugli utenti o sui carichi di lavoro. Ad esempio, un problema che si verifica al di fuori dell'orario di ufficio standard potrebbe non richiedere di eseguire immediatamente alcuna operazione.

• Ambito dell'evento imprevisto. Per i problemi isolati in una singola zona di disponibilità, potrebbe non essere necessario eseguire alcuna operazione se si usano risorse con ridondanza della zona o se le risorse usate si trovano in una zona di disponibilità fisica non interessata.

• Tempo di risoluzione stimato, se disponibile. Microsoft si impegna a fornire sequenze temporali chiare per il ripristino non appena possibile. Se le procedure di ripristino richiedono un periodo di tempo significativo per essere completate, valutare se il problema dovrebbe essere risolto quando vengono completate.

• Gli obiettivi del livello di servizio (SLO) stabiliti con gli utenti del carico di lavoro interessati, se presenti. Gli SLO servono a guidare il processo decisionale in situazioni come questa. In alcune situazioni, ad esempio, potrebbe essere possibile passare alle operazioni manuali fino a quando i servizi non tornano operativi, e questa decisione potrebbe riflettersi nel SLO per il sistema. Per ulteriori informazioni sugli obiettivi di livello di servizio e su come definirli, vedere Raccomandazioni per la definizione di obiettivi di affidabilità in Azure Well-Architected Framework.

Tuttavia, se la continuità aziendale richiede una qualche forma di azione e si dispone di un piano di ripristino di emergenza, il passaggio successivo consiste nel valutare se avviare tale piano.

Prendere in considerazione il piano di ripristino di emergenza

Un piano di ripristino di emergenza illustra le operazioni previste in caso di incidente grave. I piani di ripristino di emergenza in genere includono azioni come le seguenti:

• Per un'interruzione isolata all'interno di una zona di disponibilità, scalare la risorsa se possibile.
• Per un'interruzione della zona di disponibilità quando si usano servizi di zona, effettuare la distribuzione in un'altra zona di disponibilità ed eseguire il failover ad un'altra.
• Per un'interruzione della zona di disponibilità quando si usano servizi con ridondanza della zona, potrebbe non essere necessario eseguire alcuna operazione. Se si osservano problemi di prestazioni, considerare di espandere le risorse affinché le istanze nelle zone rimanenti possano elaborare l'afflusso di traffico ricevuto.
• Per un'interruzione a livello di regione, distribuire in un'altra area ed eseguire il failover.

Importante

Non eseguire alcuna azione senza pensarle. Le decisioni affrettate possono talvolta peggiorare le cose. Se è già stato sviluppato un piano di ripristino di emergenza che copre lo scenario, in genere è preferibile usarlo invece di creare un piano nel momento.

Il failover può essere un processo complesso. È consigliabile attivare un failover solo quando è possibile giustificare i costi e i rischi. In alcune situazioni potrebbe verificarsi una perdita di dati, ad esempio se le modifiche recenti non sono state replicate tra aree prima dell'avvio di un tempo di inattività. È anche possibile che si verifichino tempi di inattività, soprattutto se è necessario reindirizzare il traffico a una distribuzione in un'area diversa. A seconda della modalità di progettazione della soluzione, potrebbe essere necessario aggiornare i record DNS e attendere la propagazione.

Failover avviato da Microsoft

Alcuni servizi di Azure effettuano automaticamente il failover in regioni alternative durante gli incidenti. Microsoft gestisce il processo di failover per tali servizi. Tuttavia, il failover avviato da Microsoft viene in genere eseguito come ultima risorsa e solo dopo che è stato dedicato un tempo significativo ai tentativi di ripristino. In generale, i criteri di Microsoft consentono di ridurre al minimo la perdita di dati anche se ciò significa un tempo di ripristino più lungo. Non è consigliabile basarsi esclusivamente sul failover avviato da Microsoft per le proprie soluzioni, soprattutto se è necessario ridurre al minimo il tempo di ripristino. Se possibile, usare il failover avviato dal cliente per servizi come Archiviazione di Azure.

Supporto di Azure

Se l'evento imprevisto del servizio è già comunicato in Integrità dei servizi di Azure, vengono fornite tutte le informazioni più recenti e non è necessario aprire una richiesta di supporto.

Tuttavia, è possibile considerare l'apertura di un caso di supporto quando:

• Vedi problemi non trattati nella descrizione dell'incidente in Integrità dei servizi di Azure.

• È necessaria assistenza da Microsoft nell'ambito delle attività di ripristino.

  Suggerimento

  Se si è interessati da un'interruzione del servizio, sarà possibile generare un ticket di supporto gratuito per un massimo di 72 ore dopo l'attenuazione del problema per facilitare eventuali passaggi che potrebbero essere necessari per il ripristino.

Quando si apre un caso di supporto, spiegare chiaramente le risorse interessate e l'impatto del problema. Specificare l'ID sottoscrizione di Azure e l'area in cui si è verificato un problema. Impostare la gravità del caso di supporto in base all'impatto sulla tua azienda. Tenere presente che molti clienti potrebbero contattare in modo reattivo il supporto tecnico di Azure durante un'interruzione del servizio di Azure al di fuori di queste condizioni descritte. Questo carico aggiunto sulle risorse di supporto di Azure potrebbe purtroppo ritardare la risoluzione delle vostre esigenze di supporto.

Dopo un incidente

1. Per capire quello che Microsoft ha appreso dall'incidente, leggere la Revisione Post Incidente (PIR) dal riquadro Cronologia integrità di Azure Service Health, o attraverso avvisi di integrità del servizio configurati dal cliente. Incidenti diversi possono ottenere tipi diversi di revisione post-incidente. I Rapporti di Indagine Preliminari vengono in genere pubblicati alcuni giorni dopo un incidente, e i Rapporti di Indagine più completi seguono alcune settimane dopo.

2. Per gli eventi imprevisti principali elencati nella pagina relativa allo stato pubblico, partecipare a un livestream retrospettivo degli eventi imprevisti di Azure per ottenere risposte alle domande o guardare la registrazione.

3. Se si ritiene di essere idoneo per un credito SLA, creare una nuova richiesta di supporto con un tipo di problema "Richiesta di rimborso" e includere l'ID di tracciamento dell'incidente.

4. Prendere in considerazione ciò che è possibile apprendere dall'evento imprevisto per migliorare la resilienza e i processi. Prendere in considerazione domande come:

   • Quanto funziona il piano di ripristino di emergenza? Sono stati apportati miglioramenti? Per altre informazioni, vedere le linee guida di Azure Well-Architected Framework sulle strategie di ripristino di emergenza.

   • La risposta all'evento imprevisto è appropriata per la sua gravità? In caso contrario, ci sono modi per essere meglio informati e prendere decisioni migliori su cosa fare?

   • Sono disponibili guide all'affidabilità dei servizi di Azure per i servizi usati? Le guide all'affidabilità forniscono informazioni sul numero di servizi di Azure che possono essere configurati per soddisfare i requisiti di resilienza.

   • Esiste un compromesso di progettazione che è possibile apportare per migliorare la resilienza in futuro per questo tipo di problema? Per altre informazioni, vedere il pilastro dell'affidabilità di Azure Well-Architected Framework.

   • Lo SLO o il contratto di servizio è ancora adatto agli utenti ora che si è verificata questa interruzione non pianificata? Ora è un buon momento per rivedere gli impegni che si stanno prendendo per la vostra base utenti per allineare le aspettative a ciò che avete appreso da questo incidente.

   • È necessario configurare gli avvisi di Integrità dei servizi di Azure per ricevere automaticamente una notifica per eventuali eventi imprevisti futuri?

5. Se si hanno commenti e suggerimenti su come è possibile migliorare la risposta agli eventi imprevisti, inviare un messaggio tramite il rappresentante Microsoft assegnato o tramite il sito di feedback di Azure.