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:

   • Che cos'è la probabilità di 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 della modalità di errore, questo articolo include un catalogo di potenziali modalità di guasto e dei relativi passaggi di attenuazione. 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 tiene conto di molti dei servizi di base 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 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 si arresta in modo anomalo.
  • Un'istanza VM del Servizio app di Azure non è più disponibile.

La registrazione Application_End è l'unico modo per individuare gli arresti di dominio dell'app (arresto anomalo del processo software).

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à nei costi dell'"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 per impedire modifiche impreviste.
• 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 la Documentazione di Gestione API 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 è raggiungibile 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 riesce a 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. Tentativi utente.

Ricerca di Azure

La scrittura dei dati in Ricerca di Azure non riesce.

Rilevamento Individuare 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.

Il criterio di ripetizione dei tentativi predefinito usa il backoff esponenziale. Per usare un criterio di ripetizione dei tentativi diverso, chiamare SetRetryPolicy sulla classe SearchIndexClient o SearchServiceClient. Per altre informazioni, vedere Tentativi automatici.

Diagnostica. Usare Analisi del traffico di ricerca.

La lettura dei dati da Ricerca di Azure non riesce.

Rilevamento Individuare 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.

Il criterio di ripetizione dei tentativi predefinito usa il backoff esponenziale. Per usare un criterio di ripetizione dei tentativi diverso, chiamare SetRetryPolicy sulla classe SearchIndexClient o SearchServiceClient. Per altre informazioni, vedere Tentativi automatici.

Diagnostica. Usare Analisi del traffico di ricerca.

Cassandra

La lettura o la scrittura in un nodo non riesce.

Rilevamento Individuare l'eccezione. Per i client .NET, in genere è System.Web.HttpException. Altri client potrebbero avere altri tipi di eccezione. Per altre informazioni, vedere la pagina relativa alla gestione degli errori Cassandra eseguita correttamente.

Ripristino:

• Ogni client Cassandra presenta capacità e criteri specifici di ripetizione dei tentativi. Per altre informazioni, vedere la pagina relativa alla gestione degli errori Cassandra eseguita correttamente.
• Usare una distribuzione con riconoscimento del rack e i nodi di dati distribuiti nei domini di errore.
• Distribuire in più aree con coerenza del quorum locale. Se si verifica un errore non temporaneo, eseguire il failover in un'altra area.

Diagnostica. Registri applicazioni

Servizio cloud

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

Rilevamento Viene generato l'evento RoleEnvironment.Stopping.

Ripristino. Eseguire l'override del metodo RoleEntryPoint.OnStop per eseguire normalmente la pulizia. Per altre informazioni, vedere Come gestire correttamente gli eventi OnStop d Azure (blog).

Azure Cosmos DB

La lettura dei dati non riesce.

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

Ripristino:

• L'SDK esegue automaticamente nuovi tentativi. Per impostare il numero di tentativi e il tempo di attesa massimo, configurare ConnectionPolicy.RetryOptions. Le eccezioni generate dal client escludono il criterio di ripetizione oppure non sono errori temporanei.
• Se Azure Cosmos DB limita il client, viene restituito un errore HTTP 429. Verificare il codice di stato in DocumentClientException. Se l'errore 429 si verifica in modo coerente, è consigliabile aumentare il valore di throughput della raccolta.
  • Se si usa l'API di MongoDB, il servizio restituisce il codice di errore 16500 in caso di limitazione.
• Abilitare la ridondanza della zona quando si lavora con un'area che supporta le zone di disponibilità. Quando si usa la ridondanza della zona, Azure Cosmos DB esegue automaticamente il failover in caso di interruzione della 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.

La scrittura dei dati non riesce.

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

Ripristino:

• L'SDK esegue automaticamente nuovi tentativi. Per impostare il numero di tentativi e il tempo di attesa massimo, configurare ConnectionPolicy.RetryOptions. Le eccezioni generate dal client escludono il criterio di ripetizione oppure non sono errori temporanei.
• Se Azure Cosmos DB limita il client, viene restituito un errore HTTP 429. Verificare il codice di stato in DocumentClientException. Se l'errore 429 si verifica in modo coerente, è consigliabile aumentare il valore di throughput della raccolta.
• Abilitare la ridondanza della zona quando si lavora con 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 riesce, verrà alzata di livello per la scrittura un'area diversa. È 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 fallback, rendere persistente il documento in una coda di backup ed elaborare la coda in un secondo momento.

Diagnostica. Registrare tutti gli errori sul lato client.

Archiviazione code

La scrittura di un messaggio in Archiviazione code di Azure non riesce sistematicamente.

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 separato per esaminare i messaggi in quella coda.

Usare le code di messaggistica del Bus di servizio di Microsoft Azure, che fornisce una funzionalità coda di messaggi non recapitabili a questo scopo.

Nota

Se si usano le code di archiviazione con Processi Web, WebJobs SDK fornisce la funzionalità incorporata di gestione di messaggi non elaborabili. Vedere Come usare il servizio di archiviazione di accodamento di Azure con WebJobs SDK.

Diagnostica. Usare la registrazione delle applicazioni.

Cache Redis di Azure

La lettura dalla cache non riesce.

Rilevamento Individuare StackExchange.Redis.RedisConnectionException.

Ripristino:

1. Riprovare in caso di errori temporanei. Cache di Azure per Redis supporta la ripetizione dei tentativi predefinita. Per maggiori informazioni, consultare la sezione Cache Azure per linee guida relative ai nuovi tentativi Redis.
2. Considerare i guasti non temporanei come un mancato riscontro nella cache e usare l'origine dati originale.

Diagnostica. Usare la diagnostica Cache Azure per Redis.

La scrittura nella cache non riesce.

Rilevamento Individuare StackExchange.Redis.RedisConnectionException.

Ripristino:

1. Riprovare in caso di errori temporanei. Cache di Azure per Redis supporta la ripetizione dei tentativi predefinita. Per maggiori informazioni, consultare la sezione Cache Azure per linee guida relative ai nuovi tentativi Redis.
2. Se l'errore non è temporaneo, ignorarlo e lasciare che altre transazioni scrivano nella cache in un secondo momento.

Diagnostica. Usare la diagnostica Cache Azure per Redis.

Database SQL

Non è possibile connettersi al database nell'area primaria.

Rilevamento La connessione non riesce.

Ripristino:

• Abilitare la ridondanza della zona. Abilitando la ridondanza della zona, 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à 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 Panoramica: gruppi di failover e replica geografica attiva.

  • Per le query, leggere da una replica secondaria.
  • Per inserimenti e aggiornamenti, eseguire manualmente il failover in una replica secondaria. Vedere Configurare la replica geografica attiva per il database SQL di Azure nel portale di Azure e avviare il failover.

  La replica usa una stringa di connessione diversa, pertanto sarà necessario aggiornare la stringa di connessione nella propria applicazione.

Il client esaurisce le connessioni nel pool di connessioni.

Rilevamento Individuare 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 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, a proprietà IsTransient è true.

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

Ripristino:

1. Riprovare in caso di errori temporanei. Vedere Bus di servizio - Linee guida per la ripetizione di tentativi.
2. I messaggi che non si riesce a recapitare a nessun ricevitore vengono inseriti nella coda di messaggi non recapitabili. Usare questa cosa per vedere i messaggi che non sono stati ricevuti. Non è prevista alcuna pulizia automatica della coda di messaggi non recapitabili. I messaggi rimangono nella coda fino a quando non vengono recuperati in modo esplicito. Vedere Panoramica delle code dei messaggi non recapitabili del bus di servizio.

La scrittura di un messaggio in 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, a proprietà IsTransient è true.

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. Per altre informazioni, vedere Bus di servizio - Linee guida per la ripetizione di tentativi.

• 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. Assicurasi 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 si progetta una soluzione in più aree, creare due spazi dei nomi bus di servizio in aree diverse e replicare 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 tutti i messaggi a una sola coda. Se si verifica un errore, il client esegue il fallback alla coda di altri. Il ricevitore è in ascolto su 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 eseguire un processo separato per esaminare i messaggi in quella coda.
• 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 la durata, il messaggio viene spostato automaticamente nella coda di messaggi non recapitabili.

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

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

Storage

La scrittura dei dati in Archiviazione di Azure non riesce

Rilevamento Il client riceve errori durante la scrittura.

Ripristino:

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

2. Implementare il modello Interruttore per evitare di oltrepassare le limitazioni di archiviazione.

3. Se N tentativi non sono riusciti, eseguire un normale fallback. 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 da Archiviazione di Azure non riesce.

Rilevamento Il client riceve errori durante la lettura.

Ripristino:

1. Ritentare l'operazione per il ripristino 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 N tentativi hanno esito negativo, eseguire un'azione di fallback per ridurre le prestazioni in modo graduale. Ad esempio, se non è possibile recuperare un'immagine del prodotto non può essere recuperata dall'archivio, mostrare 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 du macchine virtuali di back-end in un set di disponibilità dietro un bilanciamento 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 Interruttore.
• Se la macchina virtuale chiamante supera il limite di rete in uscita, la coda in uscita si riempirà. Se la coda in uscita è completa in modo coerente, prendere in considerazione la scalabilità orizzontale.

Diagnostica. Registrare gli eventi in base ai limiti del servizio.

Un'istanza VM non è più disponibile o non è più integra.

Rilevamento Configurare il probe di integrità di Load Balancer che segnala se l'istanza di macchina virtuale è integra. Il probe 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 il probe di integrità non riesce, 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 arrestato accidentalmente una macchina virtuale.

Rilevamento N/D

Ripristino. Impostare un blocco di risorsa con livello ReadOnly. Vedere Bloccare le risorse per impedire modifiche impreviste.

Diagnostica. Usare i Log attività di Azure.

Processi Web

L'esecuzione del processo continuo viene interrotta 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 in Servizio app di Azure.

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, ad esempio di database o archiviazione, iniziano a limitare le richieste. Cercare gli errori HTTP, ad esempio HTTP 429 (troppe richieste), a seconda del servizio.
• La lunghezza della coda aumenta.

Ripristino:

• Aumentare il numero di istanze 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à per alcuni client. 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. Usare Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure. 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 - Limitazione
• 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 tentativi, il problema persiste.

Ripristino:

• Come piano di mitigazione, implementare il modello Supervisore agente di pianificazione per gestire l'intero flusso di lavoro.
• Non riprovare ai timeout. La percentuale di successo per questo errore è bassa.
• 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 modello di Interruttore per evitare che si verifichino errori a catena.

Diagnostica. Accedere a tutti gli errori di chiamata remota.

Passaggi successivi

Vedere Resilienza e dipendenze in Azure Well-Architected Framework. La compilazione del ripristino degli errori nel sistema deve far parte dell'architettura e delle fasi di progettazione fin dall'inizio per evitare il rischio di errori.