Analisi della modalità di guasto per le applicazioni di Azure

L'analisi della modalità di errore (FMA) è un processo che consente di ottenere la resilienza in un sistema, identificando possibili punti di errore in esso presenti. La FMA deve essere eseguita durante le fasi di progettazione e architettura, in modo che sia possibile integrare il ripristino dagli errori nel sistema dall'inizio.

Ecco il processo generale per eseguire una FMA:

1. Identificare tutti i componenti nel sistema. Includere le dipendenze esterne, ad esempio i provider di identità, i servizi di terze parti e così via.

2. Per ogni componente, identificare potenziali errori che potrebbero verificarsi. Un singolo componente può avere più di una modalità di errore. Ad esempio gli errori di lettura e i guasti di scrittura devono essere valutati separatamente, in quanto l'impatto e i passaggi di attenuazione sono diversi.

3. Classificare ogni modalità di errore in base al relativo rischio complessivo. Tenere presente questi fattori:

   • Qual è la probabilità dell'errore? È abbastanza comune? Estremamente raro? Non è necessario ragionare su numeri esatti, in quanto lo scopo è stabilire una classificazione della priorità.
   • Qual è l'impatto sull'applicazione in termini di disponibilità, perdita dei dati, costo monetario e interruzione dell'operatività?

4. Per ogni modalità di errore, determinare il modo in cui l'applicazione risponde ed esegue il ripristino. Prendere in considerazione eventuali compromessi relativi ai costi e alla complessità dell'applicazione.

Come punto di partenza per il processo di analisi delle modalità di guasto, questo articolo include un catalogo di potenziali modalità di guasto e delle relative misure di mitigazione. Il catalogo è organizzato in base alla tecnologia o al servizio di Azure, oltre a una categoria generale per la progettazione a livello di applicazione. Il catalogo non è esaustivo, ma copre molti dei principali servizi di Azure.

Nota

I guasti devono essere distinti dagli errori. Un guasto è un evento imprevisto all'interno di un sistema che impedisce di continuare a funzionare normalmente. Ad esempio, un malfunzionamento hardware che causa una partizione di rete è un guasto. In genere, i guasti richiedono un intervento o una progettazione specifica per tale classe di guasti. Al contrario, gli errori sono una parte prevista delle normali operazioni, vengono gestiti immediatamente e il sistema continuerà a funzionare alla stessa capacità dopo un errore. Ad esempio, gli errori individuati durante la convalida dell'input possono essere gestiti tramite la logica di business.

Servizio app

L'app Servizio app di Azure si arresta.

Rilevamento Le possibili cause:

• Arresto previsto

  • Un operatore arresta l'applicazione, ad esempio tramite il portale di Azure.
  • L'app è stata scaricata perché era inattiva (solo se l'impostazione Always On è disabilitata).

• Arresto imprevisto

  • L'app va in crash.
  • Un'istanza VM del Servizio app di Azure non è più disponibile.

La registrazione dell'evento Application_End consente di rilevare l'arresto del dominio applicazione (crash del processo il lieve) ed è l'unico modo per intercettare gli arresti del dominio applicazione.

Ripristino:

• Se l'arresto era previsto, usare l'evento di arresto dell'applicazione per spegnere normalmente il sistema. Ad esempio, in ASP.NET usare il metodo Application_End.
• Se l'applicazione è stata scaricata durante l'inattività, viene riavviata automaticamente alla richiesta successiva. Tuttavia, si incorrerà il costo di "avvio a freddo".
• Per evitare che l'applicazione venga scaricata durante l'inattività, abilitare l'impostazione Always On nell'app Web. Vedere Configurazione delle app Web in Servizio app di Azure.
• Per impedire che un operatore arresti l'app, impostare un blocco di risorsa con livello ReadOnly. Vedere Bloccare le risorse con Azure Resource Manager.
• In caso di arresto anomalo dell'app o se un'istanza VM del Servizio app di Azure non è più disponibile, il Servizio app riavvia automaticamente l'app.

Diagnostica. Log dell'applicazione e del server Web. Vedere Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure.

Un utente specifico esegue ripetutamente richieste non valide o sovraccarica il sistema.

Rilevamento Autenticare gli utenti e includere l'ID utente nei log dell'applicazione.

Ripristino:

• Usare API Management di Azure per limitare le richieste da parte dell'utente. Vedere Limitazione avanzata delle richieste con Gestione API di Azure
• Bloccare l'utente.

Diagnostica. Registrare tutte le richieste di autenticazione.

È stato distribuito un aggiornamento non valido.

Rilevamento Monitorare l'integrità dell'applicazione tramite il portale di Azure (vedere Monitoraggio delle prestazioni dell'applicazione Web di Azure) o implementare il modello di monitoraggio degli endpoint per l'integrità.

Ripristino. Usare più slot di distribuzione ed eseguire il rollback all'ultima distribuzione valida. Per altre informazioni, vedere Applicazione Web di base.

Microsoft Entra ID

L'autenticazione di OpenID Connect non riesce.

Rilevamento Le modalità di errore possibili includono:

1. Microsoft Entra ID non è disponibile o non può essere raggiunto a causa di un problema di rete. Il reindirizzamento all'endpoint di autenticazione non riesce e il middleware OpenID Connect genera un'eccezione.
2. Il tenant di Microsoft Entra non esiste. Il reindirizzamento all'endpoint di autenticazione restituisce un codice di errore HTTP e il middleware OpenID Connect genera un'eccezione.
3. L'utente non può eseguire l'autenticazione. Non è necessaria alcuna strategia di rilevamento; Microsoft Entra ID gestisce gli errori di accesso.

Ripristino:

1. Individuare le eccezioni non gestite dal middleware.
2. Gestire gli eventi AuthenticationFailed.
3. Reindirizzare l'utente a una pagina di errore.
4. Riprova dell'utente.

Ricerca di intelligenza artificiale di Azure

La scrittura di dati in Azure AI Search ha esito negativo.

Rilevamento Individua gli errori Microsoft.Rest.Azure.CloudException.

Ripristino:

L'SDK Search .NET esegue automaticamente nuovi tentativi dopo gli errori temporanei. Tutte le eccezioni generate dall'SDK client devono essere considerate come errori non temporanei.

La politica dei tentativi di ripetizione predefinita utilizza il backoff esponenziale. Per usare un criterio di ripetizione dei tentativi diverso, chiamare SetRetryPolicy sulla classe SearchIndexClient o SearchServiceClient. Per ulteriori informazioni, consultare Tentativi automatici.

Diagnostica. Usare Analisi del traffico di ricerca.

La lettura dei dati dalla Ricerca AI di Azure fallisce.

Rilevamento Individua gli errori Microsoft.Rest.Azure.CloudException.

Ripristino:

L'SDK Search .NET esegue automaticamente nuovi tentativi dopo gli errori temporanei. Tutte le eccezioni generate dall'SDK client devono essere considerate come errori non temporanei.

La politica dei tentativi di ripetizione predefinita utilizza il backoff esponenziale. Per usare un criterio di ripetizione dei tentativi diverso, chiamare SetRetryPolicy sulla classe SearchIndexClient o SearchServiceClient. Per ulteriori informazioni, consultare Tentativi automatici.

Diagnostica. Usare Analisi del traffico di ricerca.

Cassandra

La lettura o la scrittura di un nodo non riesce.

Rilevamento Cattura l'eccezione. Per i client .NET, in genere è System.Web.HttpException. Altri client potrebbero avere altri tipi di eccezione. Per altre informazioni, vedere Gestione degli errori Cassandra eseguita correttamente.

Ripristino:

• Ogni client Cassandra presenta capacità e criteri specifici di ripetizione dei tentativi. Per ulteriori informazioni, vedere Gestione corretta degli errori di Cassandra.
• Usare una distribuzione consapevole del rack, con nodi di dati distribuiti nei domini di guasto.
• Distribuire in più regioni con coerenza di quorum locale. Se si verifica un errore non temporaneo, eseguire il failover in un'altra area.

Diagnostica. Registri applicazioni

Servizio cloud

I ruoli Web o di lavoro vengono arrestati in modo imprevisto.

Rilevamento Viene generato l'evento RoleEnvironment.Stopping.

Ripristino. Effettuare l'override del metodo RoleEntryPoint.OnStop per garantire una pulizia impeccabile. Per altre informazioni, vedere Come gestire correttamente gli eventi OnStop d Azure (blog).

Azure Cosmos DB

Impossibile leggere i dati.

Rilevamento Afferra System.Net.Http.HttpRequestException o Microsoft.Azure.Documents.DocumentClientException.

Ripristino:

• L'SDK esegue automaticamente nuovi tentativi in caso di errore. Per impostare il numero di tentativi e il tempo di attesa massimo, configurare ConnectionPolicy.RetryOptions. Le eccezioni sollevate dal client sono o al di fuori della politica di ripetizione o non sono errori transitori.
• Se Azure Cosmos DB limita il client, viene restituito un errore HTTP 429. Verificare il codice di stato in DocumentClientException. Se stai ricevendo l'errore 429 costantemente, considera di aumentare il valore di throughput della raccolta.
  • Se si usa l'API MongoDB, il servizio restituisce il codice di errore 16500 in caso di limitazione delle richieste.
• Abilitare la ridondanza della zona quando si utilizza un'area che supporta le zone di disponibilità. Quando si usa la ridondanza zonale, Azure Cosmos DB esegue automaticamente il failover in caso di interruzione di una zona. Per altre informazioni, vedere Raggiungere una disponibilità elevata con Azure Cosmos DB.
• Se si progetta una soluzione in più aree, replicare il database di Azure Cosmos DB in due o più aree. Tutte le repliche sono leggibili. Specificare il parametro PreferredLocations mediante gli SDK client. Si tratta di un elenco ordinato di aree di Azure. Tutte le letture verranno inviate alla prima area disponibile nell'elenco. Se la richiesta non riesce, il client proverà con altre aree nell'elenco seguendo l'ordine. Per maggiori informazioni, consultare la sezione Procedura di configurazione della distribuzione globale in Azure Cosmos DB per NoSQL.

Diagnostica. Registrare tutti gli errori sul lato client.

Errore nella scrittura dei dati.

Rilevamento Catturare System.Net.Http.HttpRequestException o Microsoft.Azure.Documents.DocumentClientException.

Ripristino:

• L'SDK esegue automaticamente nuovi tentativi in caso di errore. Per impostare il numero di tentativi e il tempo di attesa massimo, configurare ConnectionPolicy.RetryOptions. Le eccezioni sollevate dal client sono o al di fuori della politica di ripetizione o non sono errori transitori.
• Se Azure Cosmos DB limita il client, viene restituito un errore HTTP 429. Verificare il codice di stato in DocumentClientException. Se stai ricevendo l'errore 429 costantemente, considera di aumentare il valore di throughput della raccolta.
• Abilitare la ridondanza della zona quando si utilizza un'area che supporta le zone di disponibilità. Quando si usa la ridondanza della zona, Azure Cosmos DB replica in modo sincrono tutte le scritture tra le zone di disponibilità. Per altre informazioni, vedere Raggiungere una disponibilità elevata con Azure Cosmos DB.
• Se si progetta una soluzione in più aree, replicare il database di Azure Cosmos DB in due o più aree. Se l'area primaria non funziona, un'altra area verrà promossa per la scrittura. È inoltre possibile attivare manualmente un failover. L'SDK esegue l'individuazione e il routing automatici, pertanto dopo un failover il codice di applicazione continua a funzionare. Durante il periodo di failover (in genere minuti), le operazioni di scrittura avranno una latenza maggiore, in quanto l'SDK deve individuare la nuova area di scrittura. Per maggiori informazioni, consultare la sezione Procedura di configurazione della distribuzione globale in Azure Cosmos DB per NoSQL.
• Come soluzione di ripiego, conservare il documento in una coda di backup e elaborare successivamente la coda.

Diagnostica. Registrare tutti gli errori sul lato client.

Archiviazione delle code di messaggi

L'invio di un messaggio ad Azure Queue storage fallisce costantemente.

Rilevamento Dopo N tentativi l'operazione di scrittura continua a non riuscire.

Ripristino:

• Archiviare i dati in una cache locale e inoltrare le operazioni di scrittura per l'archiviazione in un secondo momento, quando il servizio diventa disponibile.
• Creare una coda secondaria e scrivere in tale coda se quella primaria non è disponibile.

Diagnostica. Usare le metriche di archiviazione.

L'applicazione non è in grado di elaborare un determinato messaggio dalla coda.

Rilevamento (specifico dell'applicazione). Ad esempio il messaggio contiene dati non validi o la logica di business non riesce per qualche motivo.

Ripristino:

Spostare il messaggio in una coda separata. Eseguire un processo distinto per esaminare i messaggi in quella coda.

Considerare di usare le code di messaggistica di Azure Service Bus, che fornisce una funzionalità coda di messaggi non recapitabili a questo scopo.

Nota

Se si usano code di storage con WebJobs, l'SDK di WebJobs offre la gestione predefinita dei messaggi velenosi. Vedere Come usare il servizio di archiviazione di accodamento di Azure con WebJobs SDK.

Diagnostica. Utilizzare il log delle applicazioni.

Cache Redis di Azure

La lettura dalla cache non riesce.

Rilevamento Cattura StackExchange.Redis.RedisConnectionException.

Ripristino:

1. Riprovare in caso di errori temporanei. Cache di Azure per Redis supporta i tentativi di ripetizione integrati.
2. Trattare i guasti non temporanei come un mancato accesso alla cache e usare l'origine dati originale.

Diagnostica. Usare la diagnostica di Azure Cache per Redis.

La scrittura nella cache non riesce.

Rilevamento Cattura StackExchange.Redis.RedisConnectionException.

Ripristino:

1. Riprovare in caso di errori temporanei. Cache di Azure per Redis supporta i tentativi di ripetizione integrati.
2. Se l'errore non è temporaneo, ignorarlo e lasciare che altre transazioni scrivano nella cache in un secondo momento.

Diagnostica. Usare la diagnostica di Azure Cache per Redis.

Database SQL

Non è possibile connettersi al database nell'area primaria.

Rilevamento La connessione non riesce.

Ripristino:

• Abilitare la ridondanza zonale. Abilitando la ridondanza delle zone, il database SQL di Azure replica automaticamente le scritture in più zone di disponibilità di Azure all'interno delle aree supportate. Per maggiori informazioni, consultare la sezione Disponibilità con ridondanza di zona.

• Abilita replica geografica. Se si sta progettando una soluzione in più aree, è consigliabile abilitare database SQL replica geografica attiva.

  Prerequisito: Il database deve essere configurato per la replica geografica attiva. Vedere Replica geografica attiva del database SQL.

  • Per le interrogazioni, leggi da una replica secondaria.
  • Per inserimenti e aggiornamenti, eseguire manualmente il failover su una replica secondaria. Vedere Avviare un failover pianificato o non pianificato per il database SQL di Azure.

  La replica usa una stringa di connessione diversa, quindi è necessario aggiornare la stringa di connessione nell'applicazione.

Il client esaurisce le connessioni nel pool di connessioni.

Rilevamento Individua gli errori System.InvalidOperationException.

Ripristino:

• Ripetere l'operazione.
• Come piano di mitigazione, isolare il pool di connessioni per ciascun caso d'uso, in modo che un solo caso d'uso non possa dominare tutte le connessioni.
• Aumentare il pool di connessioni massimo.

Diagnostica. Log delle applicazioni.

È stato raggiunto il limite di connessioni di database.

Rilevamento Il database SQL di Azure limita il numero di accessi, sessioni e ruoli di lavoro simultanei. I limiti dipendono dal livello di servizio. Per altre informazioni, vedere Limiti delle risorse del database SQL di Azure.

Per rilevare questi errori, individuare System.Data.SqlClient.SqlException e controllare il valore di SqlException.Number per il codice di errore SQL. Per un elenco di codici di errore rilevanti, vedere Codici di errore SQL per le applicazioni client del database SQL: errore di connessione e altri problemi del database.

Ripristino. Questi errori sono considerati temporanei, pertanto il problema si può risolvere con altri tentativi. Se si riscontrano questi errori in modo sistematico, valutare se non sia opportuno un ridimensionamento del database.

Diagnostica - La query sys.event_log restituisce connessioni di database riuscite, non riuscite e deadlock.

• Creare una regola di avviso per le connessioni non riuscite.
• Abilitare il controllo del database SQL di Microsoft Azure e verificare la presenza di accessi non riusciti.

Messaggistica del bus di servizio

La lettura di un messaggio da una coda del bus di servizio non riesce.

Rilevamento Individuare le eccezioni dal client SDK. La classe base per le eccezioni del bus di servizio è MessagingException. Se l'errore è temporaneo, la proprietà IsTransient è vera.

Per altre informazioni, vedere Eccezioni di messaggistica del bus di servizio.

Ripristino:

1. Riprovare in caso di errori temporanei.
2. I messaggi che non si riesce a recapitare a nessun ricevitore vengono inseriti nella coda di messaggi non recapitabili. Usare questa coda per vedere quali messaggi non potevano essere ricevuti. Non è prevista alcuna pulizia automatica della coda di messaggi non recapitabili. I messaggi rimangono lì fino a quando non vengono recuperati in modo esplicito. Consulta Panoramica delle code dei messaggi non recapitabili di Service Bus.

La scrittura di un messaggio in una coda del Service Bus ha fallito.

Rilevamento Individuare le eccezioni dal client SDK. La classe base per le eccezioni del bus di servizio è MessagingException. Se l'errore è temporaneo, la proprietà IsTransient è vera.

Per altre informazioni, vedere Eccezioni di messaggistica del bus di servizio.

Ripristino:

• Il client del bus di servizio esegue automaticamente nuovi tentativi dopo gli errori temporanei. Per impostazione predefinita, usa il backoff esponenziale. Superato il numero massimo di tentativi o trascorso il periodo di timeout massimo, il client genera un'eccezione.

• Se viene superata la quota della coda, il client genera QuotaExceededException. Per informazioni dettagliate, vedere il messaggio di eccezione. Eliminare alcuni messaggi dalla coda prima di fare un nuovo tentativo e provare a usare il modello Interruttore per evitare che vengano fatti tentativi continuativi superando la quota. Assicurarsi inoltre che la proprietà BrokeredMessage.TimeToLive non sia impostata su un valore troppo elevato.

• All'interno di un'area è possibile migliorare la resilienza tramite code o argomenti partizionati. Una coda o un argomento non partizionato viene assegnato a un archivio di messaggistica. Se l'archivio di messaggistica in questione non è disponibile, tutte le operazioni eseguite sulla coda o sull'argomento avranno esito negativo. Una coda o un argomento partizionati sono suddivisi in più archivi di messaggistica.

• Usare la ridondanza della zona per replicare automaticamente le modifiche tra più zone di disponibilità. Se una zona di disponibilità ha esito negativo, il failover viene eseguito automaticamente. Per altre informazioni, vedere Procedure consigliate per isolare le applicazioni del bus di servizio da interruzioni ed emergenze del servizio.

• Se stai progettando una soluzione multi-regione, crea due namespace di Service Bus in aree geografiche diverse e replica i messaggi. È possibile usare sia la replica attiva sia quella passiva.

  • Replica attiva: il client invia tutti i messaggi a entrambe le code. Il ricevitore è in ascolto su entrambe le code. Contrassegnare i messaggi con un identificatore univoco, in modo che il client possa eliminare i messaggi duplicati.
  • Replica passiva: il client invia il messaggio a una coda. Se si verifica un errore, il client ripiega sull'altra coda. Il ricevitore ascolta entrambe le code. Questo approccio riduce il numero di messaggi duplicati inviati. Tuttavia, il ricevitore deve comunque gestire i messaggi duplicati.

  Per altre informazioni, vedere l'esempio di replica geografica e Procedure consigliate per isolare le applicazioni del bus di servizio da interruzioni ed emergenze del servizio.

Messaggio duplicato.

Rilevamento Esaminare le proprietà MessageId e DeliveryCount del messaggio.

Ripristino:

• Se possibile, concepire le operazioni di elaborazione dei messaggi in modo che siano idempotenti. In caso contrario, archiviare gli ID dei messaggio che sono già stati elaborati e verificare l'ID prima di elaborare un messaggio.

• Abilitare il rilevamento dei duplicati creando la coda con RequiresDuplicateDetection impostato su "true". Con questa impostazione, il bus di servizio elimina automaticamente qualsiasi messaggio inviato con lo stesso MessageId di un messaggio precedente. Notare quanto segue:

  • Questa impostazione impedisce di inserire nella coda messaggi duplicati. Non impedisce tuttavia a un ricevitore di elaborare più volte lo stesso messaggio.
  • Il rilevamento di duplicati prevede una finestra temporale. Se un duplicato viene inviato al di là di questa finestra, non verrà rilevato.

Diagnostica. Registrare messaggi duplicati.

L'applicazione non può elaborare un determinato messaggio dalla coda.

Rilevamento (specifico dell'applicazione). Ad esempio il messaggio contiene dati non validi o la logica di business non riesce per qualche motivo.

Ripristino:

Esistono due modalità di errore da considerare.

• Il ricevitore rileva l'errore. In questo caso spostare il messaggio nella coda di messaggi non recapitabili. Successivamente, esegui un processo separato per esaminare i messaggi nella coda dei messaggi morti.
• Si verifica un errore del ricevitore durante l'elaborazione del messaggio, ad esempio, a causa di un'eccezione non gestita. Per gestire questo caso, usare la modalità PeekLock. In questa modalità, se il blocco scade, il messaggio diventa disponibile per altri ricevitori. Se il messaggio supera il numero massimo di recapiti o il tempo di vita, il messaggio viene spostato automaticamente nella coda di lettere morte.

Per altre informazioni, vedere Panoramica delle code dei messaggi non recapitabili del bus di servizio.

Diagnostica. Ogni volta che l'applicazione sposta un messaggio nella coda di messaggi non recapitabili, scrivere un evento nel log dell'applicazione.

Archiviazione

Scrittura dati in Archiviazione di Azure fallisce

Rilevamento Il client riceve errori durante la scrittura.

Ripristino:

1. Ritenta l'operazione per recuperare da errori temporanei. Il criterio di ripetizione dei tentativi nel client SDK viene gestito automaticamente.

2. Implementare il pattern Circuit Breaker per evitare di sovraccaricare l'archiviazione.

3. Se N tentativi di riprovare falliscono, esegui un ripiego ordinato. Ad esempio:

   • Archiviare i dati in una cache locale e inoltrare le operazioni di scrittura per l'archiviazione in un secondo momento, quando il servizio diventa disponibile.
   • Se l'azione di scrittura viene eseguita in un ambito transazionale, è possibile compensare la transazione.

Diagnostica. Usare le metriche di archiviazione.

La lettura dei dati dall'archiviazione di Azure fallisce.

Rilevamento Il client riceve errori durante la lettura.

Ripristino:

1. Ritenta l'operazione per recuperare da errori temporanei. Il criterio di ripetizione dei tentativi nel client SDK viene gestito automaticamente.
2. Per l'archiviazione RA-GRS, se la lettura dall'endpoint primario non riesce, provare a leggere dall'endpoint secondario. Il client SDK può gestire questa operazione automaticamente. Vedere replica di archiviazione di Azure.
3. Se i N tentativi di ripetizione falliscono, eseguire un'azione di riserva per degradare gradualmente. Ad esempio, se non è possibile recuperare un'immagine del prodotto dall'archivio, mostra un'immagine segnaposto generica.

Diagnostica. Usare le metriche di archiviazione.

Macchina virtuale

La connessione a una macchina virtuale di back-end non riesce.

Rilevamento Errori delle connessioni di rete.

Ripristino:

• Distribuire almeno due macchine virtuali di back-end in un set di disponibilità dietro a un bilanciatore del carico.
• Quando l'errore di connessione è temporaneo, talvolta i protocollo TCP riesce a ritentare l'invio del messaggio.
• Implementare un criterio di ripetizione dei tentativi nell'applicazione.
• Per gli errori persistenti o non temporanei, implementare il modello Circuit Breaker.
• Se la macchina virtuale chiamante supera il limite di rete in uscita, la coda in uscita si riempirà. Se la coda in uscita è costantemente piena, valutare la scalabilità orizzontale.

Diagnostica. Registrare gli eventi ai confini del servizio.

Un'istanza VM diventa non disponibile o presenta problemi di integrità.

Rilevamento Configurare una sonda di integrità del Load Balancer che segnali se l'istanza della macchina virtuale è funzionante. La sonda deve verificare se le funzioni critiche rispondono correttamente.

Ripristino. Per ogni livello di applicazione, inserire più istanze di macchina virtuale nello stesso set di disponibilità e posizionare un bilanciamento del carico di fronte alle macchine virtuali. Se la sonda di integrità non riesce, il Load Balancer interrompe l'invio di nuove connessioni all'istanza non integra.

Diagnostica. - Usare l'analisi dei log di Load Balancer.

• Configurare il sistema di monitoraggio per monitorare tutti gli endpoint di monitoraggio dello stato.

L'operatore spegne accidentalmente una VM.

Rilevamento N/A

Ripristino. Impostare un blocco di risorsa con livello ReadOnly. Vedere Bloccare le risorse con Azure Resource Manager.

Diagnostica. Usare i Log Attività di Azure.

WebJobs

L'attività continua si interrompe quando l'host SCM è inattivo.

Rilevamento Passare un token di annullamento alla funzione WebJob. Per altre informazioni, vedere l'articolo sull' arresto normale dei processi.

Ripristino. Abilitare l'impostazione Always On nell'app Web. Per altre informazioni, vedere Eseguire attività in background con Processi Web.

Progettazione di applicazioni

L'applicazione non riesce a gestire un picco nelle richieste in arrivo.

Rilevamento Dipende dall'applicazione. Sintomi tipici:

• Il sito Web inizia a restituire codici di errore HTTP 5xx.
• I servizi dipendenti, come i database o l'archiviazione, iniziano a limitare le richieste. Cercare gli errori HTTP, ad esempio HTTP 429 (troppe richieste), a seconda del servizio.
• La lunghezza della coda HTTP aumenta.

Ripristino:

• Scalare orizzontalmente per gestire il carico maggiore.

• Ridurre gli errori per evitare che errori a cascata interferiscano con l'intera applicazione. Le strategie di mitigazione includono:

  • Implementare il modello di limitazione per evitare il sovraccarico dei sistemi back-end.
  • Usare lo schema di livellamento del carico basato sulle code per memorizzare nel buffer le richieste ed elaborarle a un ritmo adeguato.
  • Assegnare la priorità a alcuni clienti. Ad esempio, se l'applicazione prevede livelli gratuiti e a pagamento, limitare i clienti del livello gratuito, ma non quelli a pagamento. Vedere Modello di coda con priorità.

Diagnostica. Utilizzare la registrazione diagnostica del servizio app. Usare un servizio come Azure Log Analytics, Application Insights o New Relic per interpretare i log di diagnostica.

Un esempio è disponibile qui. Usa Polly per queste eccezioni:

• 429 - Regolazione
• 408 - Timeout
• 401 - Non autorizzato
• 503 o 5xx - Indisponibilità del servizio

Una delle operazioni in una transazione distribuita o un flusso di lavoro non riesce.

Rilevamento Dopo N ritentativi, continua a fallire.

Ripristino:

• Come piano di mitigazione, implementare il modello Supervisore agente di pianificazione per gestire l'intero flusso di lavoro.
• Non riprovare in caso di timeout. Esiste una bassa percentuale di successo per questo errore.
• Mettere il lavoro in coda per riprovare più tardi.

Diagnostica. Accedere a tutte le operazioni (riuscite e non riuscite), incluse le azioni di compensazione. Usare gli ID di correlazione, in modo che sia possibile tenere traccia di tutte le operazioni all'interno della stessa transazione.

Una chiamata a un servizio remoto non riesce.

Rilevamento Codice di errore HTTP.

Ripristino:

1. Riprovare in caso di errori temporanei.
2. Se la chiamata non riesce dopo N tentativi, eseguire un'azione di fallback (specifica dell'applicazione).
3. Implementare il pattern Circuit Breaker per evitare guasti a catena.

Diagnostica. Registrare tutti i fallimenti delle chiamate remote.

Passaggi successivi

Consultare Resilienza e dipendenze nel Azure Well-Architected Framework. L'implementazione del ripristino dei guasti nel sistema deve far parte dell'architettura e delle fasi di progettazione fin dall'inizio per evitare il rischio di guasti.