Consigli per la gestione degli errori temporanei

Si applica a questa raccomandazione dell'elenco di controllo di affidabilità Well-Architected Power Platform:

Questa guida descrive i consigli per la gestione degli errori temporanei nelle applicazioni cloud. Tutte le applicazioni che comunicano con servizi e risorse remoti devono essere sensibili agli errori temporanei. Ciò è particolarmente vero per le applicazioni eseguite nel cloud, dove, a causa della natura dell'ambiente e della connettività Internet, è probabile che questo tipo di errore venga riscontrato più spesso. Gli errori temporanei includono la perdita momentanea di connettività di rete a componenti e servizi, la temporanea indisponibilità di un servizio e i timeout che si verificano quando un servizio è occupato. Questi errori spesso si correggono automaticamente, quindi, se l'azione viene ripetuta dopo un adeguato ritardo, è probabile che abbia successo.

Strategie di progettazione chiave

Gli errori temporanei possono verificarsi in qualsiasi ambiente, su qualsiasi piattaforma o sistema operativo e in qualsiasi tipo di applicazione.

Sfide

Gli errori temporanei possono avere un effetto significativo sulla disponibilità percepita di un'applicazione, anche se è stata testata approfonditamente in tutte le circostanze prevedibili. Per garantire che il tuo carico di lavoro Power Platform possa funzionare in modo affidabile, devi assicurarti che possa rispondere alle seguenti sfide:

• L'applicazione deve essere in grado di rilevare gli errori quando si verificano e determinare se è probabile che siano transitori, di lunga durata o guasti terminali. È probabile che risorse diverse restituiscano risposte diverse quando si verifica un errore e queste risposte possono anche variare a seconda del contesto dell'operazione. Ad esempio, la risposta per un errore quando l'applicazione recupera i dati da un connettore personalizzato potrebbe essere diversa dalla risposta quando l'applicazione esegue un flusso cloud e attende la risposta.

• L'applicazione deve essere in grado di ritentare l'operazione se determina che è probabile che l'errore sia temporaneo.

• L'applicazione deve utilizzare una strategia appropriata per i nuovi tentativi. La strategia specifica il numero di tentativi dell'applicazione, il ritardo tra ogni tentativo e le azioni da intraprendere dopo un tentativo fallito. Il numero appropriato di tentativi e il ritardo tra ciascuno di essi sono spesso difficili da determinare. La strategia varia a seconda del tipo di risorsa e delle attuali condizioni operative della risorsa e dell'applicazione.

Linee guida generali

Le seguenti linee guida possono aiutarti a progettare meccanismi di gestione degli errori temporanei adatti alle tue applicazioni.

Determina se è presente un meccanismo di ripetizione integrato

Alcuni servizi a cui ti stai connettendo potrebbero già fornire un meccanismo di gestione degli errori temporanei. I criteri di ripetizione dei tentativi utilizzati sono in genere adattati alla natura e ai requisiti del servizio di destinazione. In alternativa, le interfacce REST per i servizi potrebbero restituire informazioni che possono aiutare a determinare se un nuovo tentativo è appropriato e quanto tempo attendere prima del successivo tentativo.

È consigliabile utilizzare il meccanismo di ripetizione dei tentativi integrato quando disponibile, a meno che non si disponga di requisiti specifici e ben compresi che rendano più appropriato un comportamento di ripetizione diverso.

Determina se l'operazione è adatta per riprovare

Esegui le operazioni per un nuovo tentativo solo quando gli errori sono temporanei (in genere indicati dalla natura dell'errore) e quando esiste almeno una certa probabilità che l'operazione abbia esito positivo quando viene ripetuta. Non ha senso riprovare operazioni che tentano un'operazione non valida, come l'aggiornamento di una riga in Microsoft Dataverse che non esiste o per la quale l'utente non ha l'autorizzazione, o chiamare un'API endpoint che non esiste.

Implementa i nuovi tentativi solo quando puoi determinarne l'effetto completo e quando le condizioni sono ben comprese e possono essere convalidate. Ricorda che gli errori restituiti da risorse e servizi al di fuori del tuo controllo potrebbero evolversi nel tempo e potrebbe essere necessario rivedere la logica di rilevamento degli errori temporanei.

Quando sviluppi singoli componenti o servizi chiamati dalle tue applicazioni, assicurati di restituire codici di errore e messaggi che aiutino i client a determinare se devono ritentare le operazioni non riuscite. Valuta la possibilità di indicare se il client deve ritentare l'operazione; ad esempio, restituendo un valore isTransient. Se crei un servizio Web, valuta la possibilità di restituire errori personalizzati definiti nei contratti di servizio.

Determina un conteggio e un intervallo di tentativi appropriati

Ottimizza il conteggio dei tentativi e l'intervallo in base al tipo di caso d'uso. Se non riprovi abbastanza volte, l'applicazione non potrà completare l'operazione e probabilmente fallirà. Se si riprova troppe volte o con un intervallo troppo breve tra i tentativi, l'applicazione potrebbe trattenere le risorse per lunghi periodi, con conseguenze negative sull'integrità dell'applicazione.

Adatta i valori per l'intervallo di tempo e il numero di tentativi al tipo di operazione. Ad esempio, se l'operazione fa parte di un'interazione con l'utente, l'intervallo dovrebbe essere breve e dovrebbero essere effettuati solo pochi tentativi. Utilizzando questo approccio, puoi evitare che gli utenti attendano una risposta. Se l'operazione fa parte di un flusso di lavoro critico o di lunga durata, in cui l'annullamento e il riavvio del processo sono costosi o richiedono molto tempo, è opportuno attendere più a lungo tra i tentativi e riprovare più volte.

Tieni presente che determinare gli intervalli appropriati tra i tentativi è la parte più difficile della progettazione di una strategia di successo. Le strategie tipiche utilizzano i seguenti tipi di intervallo tra i tentativi:

• Intervallo esponenziale. L'applicazione attende qualche istante prima del primo tentativo e poi aumenta esponenzialmente il tempo tra ogni tentativo successivo. Ad esempio, potrebbe ritentare l'operazione dopo 3 secondi, 12 secondi, 30 secondi e così via.

• Intervalli fissi. L'applicazione attende lo stesso periodo di tempo tra ogni tentativo.

• Nuovo tentativo immediato. A volte un errore temporaneo è breve ed è opportuno ritentare immediatamente l'operazione perché potrebbe riuscire se l'errore viene risolto nel tempo impiegato dall'applicazione per inviare la richiesta successiva. Tuttavia, non dovrebbe mai esserci più di un tentativo di nuovo tentativo immediato. È consigliabile passare a strategie alternative, come l'intervallo esponenziale o le azioni di fallback, se il nuovo tentativo immediato fallisce.

Come linea guida generale, utilizza una strategia di intervallo esponenziale per le operazioni in background e utilizza strategie di tentativi a intervallo immediato o fisso per le operazioni interattive. In entrambi i casi, è consigliabile scegliere il ritardo e il numero di tentativi in modo che la latenza massima per tutti i tentativi rientri nei requisiti di latenza end-to-end richiesti.

Considera la combinazione di tutti i fattori che contribuiscono al timeout massimo complessivo per un'operazione ripetuta. Questi fattori includono il tempo necessario affinché una connessione non riuscita produca una risposta, il ritardo tra i tentativi e il numero massimo di tentativi. La somma di tutti questi tempi può comportare tempi operativi complessivi lunghi, soprattutto quando si utilizza una strategia di ritardo esponenziale in cui l'intervallo tra i tentativi aumenta rapidamente dopo ogni errore. Se un processo deve soddisfare uno specifico contratto di servizio, il tempo operativo complessivo, inclusi tutti i timeout e i ritardi, deve rientrare nei limiti definiti nel contratto di servizio.

Non implementare strategie di ripetizione eccessivamente aggressive. Si tratta di strategie che hanno intervalli troppo brevi o tentativi troppo frequenti. Possono avere un effetto negativo sulla risorsa o sul servizio di destinazione. Queste strategie potrebbero impedire il ripristino della risorsa o del servizio dallo stato di sovraccarico e continuerà a bloccare o rifiutare le richieste. Questo scenario si traduce in un circolo vizioso, in cui sempre più richieste vengono inviate alla risorsa o al servizio. Di conseguenza, la sua capacità di recupero è ulteriormente ridotta.

Considera il timeout delle operazioni quando scegli gli intervalli tra i nuovi tentativi per evitare di avviare immediatamente un tentativo successivo (ad esempio, se il periodo di timeout è simile all'intervallo tra i nuovi tentativi).

Utilizza il tipo di errore o i codici errore e i messaggi restituiti dal servizio per ottimizzare il numero di tentativi e l'intervallo tra di essi. Ad esempio, alcune eccezioni o codici errore (come il codice HTTP 503, Servizio non disponibile, con un'intestazione Retry-After nella risposta) potrebbero indicare quanto tempo potrebbe durare l'errore o che il servizio non è riuscito e non risponderà ad alcun successivo tentativo.

Evita anti-criteri

Nella maggior parte dei casi, evita le implementazioni che includono livelli duplicati di codice di ripetizione. Evita progetti che includano meccanismi di tentativi a cascata o che implementano nuovi tentativi in ogni fase di un'operazione che coinvolge una gerarchia di richieste, a meno che non si dispongano di requisiti specifici per farlo. In queste circostanze eccezionali, utilizza criteri che impediscano un numero eccessivo di tentativi e periodi di ritardo e assicurati di comprenderne le conseguenze. Ad esempio, supponiamo che un componente effettui una richiesta a un altro, che quindi accede al servizio di destinazione. Se implementi i tentativi con un conteggio di tre su entrambe le chiamate, ci sono nove tentativi in totale sul servizio. Molti servizi e risorse implementano un meccanismo di tentativi integrato. È consigliabile indagare su come disabilitare o modificare questi meccanismi se hai bisogno di implementare nuovi tentativi a un livello superiore.

Non implementare mai un meccanismo di tentativi infiniti. Ciò potrebbe impedire il ripristino della risorsa o del servizio da situazioni di sovraccarico e causare limitazioni e connessioni rifiutate per un periodo di tempo più lungo.

Non eseguire mai un tentativo immediato più di una volta.

Evita di usare un intervallo tra tentativi fisso quando accedi a servizi e risorse in Azure, soprattutto quando disponi di un numero elevato di tentativi. L'approccio migliore in questo scenario è una strategia di intervallo esponenziale.

Testa la tua strategia e l'implementazione dei tentativi

Testa completamente la tua strategia di ripetizione nel più ampio insieme di circostanze possibile, soprattutto quando sia l'applicazione che le risorse o i servizi di destinazione utilizzati sono sottoposti a un carico estremo. Per verificare il comportamento durante il test, puoi:

• Inietta errori temporanei e non temporanei nel servizio. Ad esempio, invia richieste non valide o aggiungi codice che rilevi richieste di test e risponda con diversi tipi di errori.

• Crea un modello della risorsa o del servizio che restituisca una serie di errori che il servizio reale potrebbe restituire. Copri tutti i tipi di errori che la tua strategia di ripetizione è progettata per rilevare.

• Per i servizi personalizzati creati e distribuiti, forza il verificarsi di errori temporanei disabilitando o sovraccaricando temporaneamente il servizio. (Non tentare di sovraccaricare risorse condivise o servizi condivisi in Azure).

• Quando testi la resilienza di un'applicazione Web client agli errori temporanei, utilizza gli strumenti di sviluppo del browser o la capacità del tuo framework di test per inserire in modo fittizio o bloccare richieste di rete.

• Esegui test con fattore di carico elevato e simultanei per garantire che il meccanismo e la strategia dei nuovi tentativi funzionino correttamente in queste condizioni. Questi test aiutano inoltre a garantire che il nuovo tentativo non abbia un effetto negativo sul funzionamento del client o causi contaminazione incrociata tra le richieste.

Gestire le configurazioni dei criteri di ripetizione

Un criterio di ripetizione è una combinazione di tutti gli elementi della tua strategia di ripetizione. Definisce il meccanismo di rilevamento che determina se è probabile che un errore sia transitorio, il tipo di intervallo da utilizzare (come fisso o esponenziale), i valori effettivi dell'intervallo e il numero di tentativi da eseguire.

Sfrutta le strategie di ripetizione predefinite o integrate, ma solo quando sono appropriate per il tuo scenario. Queste strategie sono in genere generiche. In alcuni scenari potrebbero essere tutto ciò di cui hai bisogno, ma in altri scenari non offrono la gamma completa di opzioni per soddisfare le tue esigenze specifiche. Per determinare i valori più appropriati, è necessario eseguire dei test per comprendere in che modo le impostazioni influiscono sull'applicazione.

Registra e monitora gli errori temporanei e non temporanei

Nell'ambito della strategia di ripetizione dei tentativi, includi la gestione delle eccezioni e altri strumenti che registrano i tentativi. Sono previsti errori temporanei occasionali e nuovi tentativi che non indicano un problema. Un numero regolare e crescente di tentativi, tuttavia, è spesso un indicatore di un problema che potrebbe causare un errore o ridurre le prestazioni e la disponibilità dell'applicazione.

Registra gli errori temporanei come voci di avviso anziché come voci di errore in modo che i sistemi di monitoraggio non li rilevino come errori dell'applicazione che potrebbero attivare falsi avvisi.

Valuta la possibilità di archiviare un valore nelle voci di log che indichi se i nuovi tentativi sono causati dalla limitazione del servizio o da altri tipi di errori, come errori di connessione, in modo da poterli differenziare durante l'analisi dei dati. Un aumento del numero di errori di limitazione è spesso un indicatore di un difetto di progettazione dell'applicazione o della necessità di aggiungere capacità premium all'ambiente.

Prendi in considerazione l'implementazione di un sistema di telemetria e monitoraggio in grado di generare avvisi quando aumenta il numero e il tasso di errori, il numero medio di tentativi o il tempo complessivo trascorso prima che le operazioni abbiano successo.

Gestire le operazioni con errori continui

Considera come gestire le operazioni che continuano a fallire ad ogni tentativo. Situazioni come questa sono inevitabili.

Sebbene una strategia di ripetizioni definisca il numero massimo di volte in cui un'operazione deve essere ritentata, non impedisce all'applicazione di ripetere l'operazione con lo stesso numero di tentativi. Ad esempio, l'invio di un modulo nella tua applicazione potrebbe attivare un flusso. La strategia di ripetizione potrebbe rilevare un timeout della connessione e considerarlo un errore temporaneo. Il flusso ritenterà l'operazione un numero specificato di volte e poi rinuncerà. Tuttavia, quando lo stesso utente o un nuovo utente tenta di inviare nuovamente il modulo, l'operazione viene tentata nuovamente, anche se potrebbe continuare a non riuscire.

L'applicazione può testare periodicamente il servizio, in modo intermittente e con lunghi intervalli tra le richieste, per rilevare quando diventa disponibile. Un intervallo appropriato dipende da fattori quali la criticità dell'operazione e la natura del servizio. Potrebbe durare da pochi minuti a diverse ore. Quando il test ha esito positivo, l'applicazione può riprendere le normali operazioni e passare le richieste al servizio appena ripristinato.

Nel frattempo potresti riuscire ad effettuare alcune operazioni alternative sperando che il servizio torni presto disponibile. Ad esempio potrebbe essere opportuno archiviare le richieste del servizio in coda o archivio dati e riprovarle in seguito. Oppure potresti dover restituire un messaggio all'utente per indicare che l'applicazione non è disponibile.

Altre considerazioni

Quando decidi i valori per il numero di tentativi e gli intervalli tra i tentativi per un criterio, valuta se l'operazione sul servizio o sulla risorsa fa parte di un'operazione a lunga esecuzione o a più passaggi. Potrebbe essere difficile o costoso compensare tutte le altre fasi operative già riuscite quando una fallisce. In questo caso, un lungo intervallo e un gran numero di tentativi potrebbero essere accettabili, purché tale strategia non blocchi altre operazioni trattenendo o bloccando risorse scarse.

Valuta se riprovare la stessa operazione potrebbe causare incoerenze nei dati. Se alcune parti di un processo a più fasi vengono ripetute e le operazioni non sono idempotenti, potrebbero verificarsi incoerenze. Ad esempio, se viene ripetuta un'operazione che inserisce un record in Microsoft Dataverse, potrebbero verificarsi valori errati nella tabella. Oppure, se ripeti un'operazione che invia una notifica all'utente, questi potrebbero ricevere messaggi duplicati.

Considera l'ambito delle operazioni ritentate. Ad esempio, potrebbe essere più semplice implementare il codice di ripetizione a un livello che comprenda diverse operazioni e riprovarle tutte se una fallisce. Tuttavia, ciò potrebbe causare problemi di idempotenza o operazioni di rollback non necessarie.

Se scegli un ambito di tentativi che comprende diverse operazioni, considera la latenza totale di tutte quando si determinano gli intervalli tra tentativi, quando si monitorano i tempi trascorsi dell'operazione e prima di generare avvisi in caso di errori.

Facilitazione di Power Platform

Le sezioni seguenti descrivono i meccanismi che è possibile utilizzare per gestire gli errori temporanei.

Power Automate

Power Automate include una funzionalità per ritentare un'azione se non riesce. Configuralo a livello di azione. Informazioni sulla riduzione del rischio e pianificazione della gestione degli errori in un progetto Power Automate Power Automate offre anche azioni per restituire errori e dati personalizzati all'app o al flusso chiamante.

Alcuni flussi temporanei possono essere causati dalla velocità effettiva e dai limiti delle richieste. Scopri i limiti dei flussi automatizzati, programmati e istantanei e limiti e allocazioni delle richieste.

Configura la gestione degli errori e delle eccezioni nei flussi cloud utilizzando ambiti e impostazioni run-after.

Power Apps

Le app canvas Power Apps offrono la possibilità di controllare lo stato della connessione, consentendo loro di comportarsi diversamente se l'app è offline. Scopri come sviluppare app canvas che supportino l'uso offline.

Puoi anche utilizzare le funzioni Error, IfError, IsError e IsBlankOrError nelle app canvas per decidere cosa fare dopo se si verifica un errore.

Altre informazioni sulla gestione degli errori temporanei in Power Apps:

• Panoramica di Mobile Offline
• Mobile Offline per app canvas

Connettori personalizzati e Azure

Se il tuo carico di lavoro si connette ai servizi di Azure, scopri come gestire gli errori temporanei utilizzando Azure Well-Architected Framework.

Per gestire le risposte personalizzate del connettore agli errori, segui gli standard di codifica.

Application Insights

Utilizza le integrazioni di Application Insights per registrare gli errori in Power Automate e Power Apps:

• Configurare Application Insights con Power Automate (anteprima)
• Analizzare i log generati dal sistema utilizzando Application Insights in Power Apps

Vedi anche

Continuità aziendale e ripristino di emergenza per le app Dynamics 365 SaaS

Lista di controllo dell'affidabilità

Fare riferimento alla serie completa di raccomandazioni.