Condividi tramite


Operazioni da eseguire durante un'interruzione del servizio 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à. Il contratto di servizio per i singoli servizi Azure è disponibile in Azure 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 dello stato per passare a un gruppo di azioni 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 a Azure stato.

    Annotazioni

    Azure status mostra solo problemi diffusi che soddisfano determinati criteri. Poiché la pagina stato 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 regionali (non di zona), vedere Azure servizi 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 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 Azure esegue automaticamente il failover in aree alternative durante gli eventi imprevisti. 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 da customer per servizi come Archiviazione di Azure.

Supporto Azure

Se l'evento imprevisto del servizio è già stato 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:

  • Vengono visualizzati problemi non trattati nella descrizione dell'evento imprevisto nel 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 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 supporto tecnico di Azure durante un'interruzione del servizio Azure al di fuori di queste condizioni descritte. Questo carico aggiunto sulle risorse di supporto Azure potrebbe sfortunatamente ritardare la gestione delle vostre esigenze di supporto.

Dopo un incidente

  1. Per capire cosa ha imparato Microsoft dall'incidente, leggere il Post Incident Review (PIR) nel riquadro della cronologia dello stato di integrità di integrità dei servizi di Azure o tramite gli 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 incidenti principali elencati nella nostra pagina dello stato pubblico, unisciti a una trasmissione in diretta di Azure Incident Retrospective per ottenere risposte a eventuali domande o guarda 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 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?

    • Ci sono guide sull'affidabilità dei servizi di Azure per i servizi che usi? Le guide all'affidabilità forniscono informazioni sul numero di Azure servizi 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 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 integrità dei servizi di Azure per ricevere automaticamente una notifica per eventuali eventi imprevisti futuri?

  5. Se hai feedback su come possiamo migliorare la risposta agli eventi imprevisti, comunicaci tramite il rappresentante Microsoft assegnato o tramite il sito di feedback Azure.