Raccomandazioni per l'esecuzione dell'analisi della modalità di errore

Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:

Questa guida descrive le procedure consigliate per eseguire l'analisi della modalità di errore (FMA) per il carico di lavoro. FMA è la pratica di identificare i potenziali punti di errore all'interno del carico di lavoro e i flussi associati e pianificare le azioni di mitigazione di conseguenza. In ogni passaggio del flusso si identifica il raggio di azione di più tipi di errore, il che consente di progettare un nuovo carico di lavoro o di effettuare il refactoring di un carico di lavoro esistente per ridurre al minimo la propagazione degli effetti degli errori.

Un tenet chiave di FMA è che gli errori si verificano indipendentemente dal numero di livelli di resilienza applicati. Gli ambienti più complessi vengono esposti a più tipi di errori. Data questa realtà, FMA consente di progettare il carico di lavoro per resistere alla maggior parte dei tipi di errori e ripristinare normalmente quando si verifica un errore.

Se si ignora completamente FMA o si esegue un'analisi incompleta, il carico di lavoro è a rischio di comportamenti imprevisti e potenziali interruzioni causate dalla progettazione non ottimale.

Definizioni

Strategie di progettazione chiave

Esaminare e implementare le raccomandazioni per identificare i flussi. Si presuppone che siano stati identificati e classificati in ordine di priorità i flussi utente e di sistema in base alla criticità.

I dati raccolti e gli artefatti creati nel lavoro forniscono una descrizione concreta dei percorsi di dati coinvolti in tutti i flussi. Per avere successo nel lavoro FMA, l'accuratezza e l'accuratezza negli artefatti è fondamentale.

Dopo aver determinato i flussi critici, è possibile pianificare i relativi componenti necessari. Seguire quindi ogni passaggio del flusso per identificare le dipendenze, inclusi i servizi di terze parti e i potenziali punti di errore e pianificare le strategie di mitigazione.

Scomporre il carico di lavoro

Nel passaggio dall'ideazione alla progettazione, è necessario identificare i tipi di componenti necessari per supportare il carico di lavoro. Il carico di lavoro determina i componenti necessari per la pianificazione. In genere, è necessario pianificare il controllo in ingresso, la rete, il calcolo, i dati, l'archiviazione, i servizi di supporto (ad esempio l'autenticazione, la messaggistica e la gestione dei segreti o delle chiavi) e il controllo in uscita. In questa fase del lavoro di progettazione, è possibile che non si conoscano le tecnologie specifiche che verranno distribuite, quindi la progettazione potrebbe essere simile all'esempio seguente.

Dopo aver creato la progettazione iniziale dell'architettura, è possibile sovrapporre i flussi per identificare i componenti discreti usati in tali flussi e creare elenchi o diagrammi di flusso di lavoro che descrivono i flussi e i relativi componenti. Per comprendere la criticità dei componenti, usare le definizioni di criticità assegnate ai flussi. Prendere in considerazione l'effetto di un malfunzionamento del componente nei flussi.

Identificare le dipendenze

Identificare le dipendenze del carico di lavoro per eseguire l'analisi dei singoli punti di errore. La scomposizione del carico di lavoro e dei flussi sovrapposti fornisce informazioni dettagliate sulle dipendenze interne ed esterne al carico di lavoro.

Le dipendenze interne sono componenti nell'ambito del carico di lavoro necessario per il funzionamento del carico di lavoro. Le dipendenze interne tipiche includono API o soluzioni di gestione di segreti/chiavi come Azure Key Vault. Per queste dipendenze, acquisire i dati di affidabilità, ad esempio contratti di servizio di disponibilità e limiti di scalabilità. Le dipendenze esterne sono componenti necessari all'esterno dell'ambito del carico di lavoro, ad esempio un'altra applicazione o un servizio di terze parti. Le dipendenze esterne tipiche includono soluzioni di autenticazione, come Microsoft Entra ID e soluzioni di connettività cloud, ad esempio Azure ExpressRoute.

Identificare e documentare le dipendenze nel carico di lavoro e includerle negli artefatti della documentazione del flusso.

Valutare i punti di errore

Nei flussi critici del carico di lavoro prendere in considerazione ogni componente e determinare in che modo tale componente e le relative dipendenze potrebbero essere influenzati da una modalità di errore. Tenere presente che esistono molte modalità di errore da considerare durante la pianificazione della resilienza e del ripristino. Qualsiasi componente può essere interessato da più di una modalità di errore in qualsiasi momento. Queste modalità di errore includono:

• Interruzione a livello di area. Un'intera area di Azure non è disponibile.

• Interruzione della zona di disponibilità. Una zona di disponibilità di Azure non è disponibile.

• Interruzione del servizio. Uno o più servizi di Azure non sono disponibili.

• Distributed Denial of Service (DDoS) o altri attacchi dannosi.

• Configurazione errata dell'app o del componente.

• Errore dell'operatore.

• Interruzione della manutenzione pianificata.

• Overload dei componenti.

L'analisi deve essere sempre nel contesto del flusso che si sta tentando di analizzare, quindi assicurarsi di documentare l'effetto sull'utente e il risultato previsto di tale flusso. Ad esempio, se si dispone di un'applicazione di e-commerce e si sta analizzando il flusso del cliente, l'effetto di una particolare modalità di errore su uno o più componenti potrebbe essere che tutti i clienti non sono in grado di completare il checkout.

Considerare la probabilità di ogni tipo di modalità di errore. Alcuni sono molto improbabili, ad esempio interruzioni in più zone o in più aree e l'aggiunta di pianificazione della mitigazione oltre la ridondanza non è un buon uso di risorse e tempo.

Strategia di riduzione del rischio

Le strategie di mitigazione rientrano in due categorie generali: la creazione di una maggiore resilienza e la progettazione per prestazioni ridotte.

La creazione di una maggiore resilienza include l'aggiunta di ridondanza ai componenti, ad esempio l'infrastruttura, i dati e la rete, e garantire che la progettazione dell'applicazione segua le procedure consigliate per la durabilità, ad esempio suddividendo le applicazioni monolitiche in app e microservizi isolati. Per altre informazioni, vedere Raccomandazioni per la ridondanza e raccomandazioni per l'auto-conservazione.

Per progettare prestazioni ridotte, identificare potenziali punti di errore che potrebbero disabilitare uno o più componenti del flusso, ma non disabilitare completamente tale flusso. Per mantenere la funzionalità del flusso end-to-end, potrebbe essere necessario reindirizzare uno o più passaggi ad altri componenti o accettare che un componente non riuscito esegua una funzione, quindi la funzione non è più disponibile nell'esperienza utente. Per tornare all'esempio di applicazione di e-commerce, un componente non riuscito come un microservizio potrebbe causare la mancata disponibilità del motore di raccomandazione, ma i clienti possono comunque cercare i prodotti e completare la transazione.

È anche necessario pianificare la mitigazione delle dipendenze. Le dipendenze forti svolgono un ruolo fondamentale nella disponibilità e nella funzione dell'applicazione. Se sono assenti o riscontrano un malfunzionamento, potrebbe verificarsi un effetto significativo. L'assenza di dipendenze deboli potrebbe influire solo su funzionalità specifiche e non influisce sulla disponibilità complessiva. Questa distinzione riflette il costo per mantenere la relazione di disponibilità elevata tra il servizio e le relative dipendenze. Classificare le dipendenze come complesse o deboli per identificare quali componenti sono essenziali per l'applicazione.

Se l'applicazione ha dipendenze complesse che non può funzionare senza, le destinazioni di disponibilità e ripristino di queste dipendenze devono essere allineate alle destinazioni dell'applicazione stessa. Ridurre al minimo le dipendenze per ottenere il controllo sull'affidabilità dell'applicazione. Per altre informazioni, vedere Ridurre al minimo il coordinamento tra i servizi dell'applicazione per ottenere la scalabilità.

Se il ciclo di vita dell'applicazione è strettamente associato al ciclo di vita delle relative dipendenze, l'agilità operativa dell'applicazione potrebbe essere limitata, in particolare per le nuove versioni.

Rilevamento

Il rilevamento degli errori è essenziale per assicurarsi di aver identificato i punti di errore nell’analisi e pianificato le strategie di mitigazione correttamente. Il rilevamento in questo contesto indica il monitoraggio dell'infrastruttura, dei dati e dell'applicazione e l'invio di avvisi in caso di problemi. Automatizzare il rilevamento il più possibile e creare la ridondanza nei processi operativi per garantire che gli avvisi vengano sempre rilevati e vengano risposti abbastanza rapidamente per soddisfare i requisiti aziendali. Per altre informazioni, vedere Raccomandazioni per il monitoraggio.

Risultato

Per il risultato dell'analisi, creare un set di documenti che comunicano in modo efficace i risultati, le decisioni prese in relazione ai componenti e alla mitigazione del flusso e l'effetto dell'errore sul carico di lavoro.

Nell'analisi classificare in ordine di priorità le modalità di errore e le strategie di mitigazione identificate in base alla gravità e alla probabilità. Usare questa definizione di priorità per concentrare la documentazione sulle modalità di errore comuni e sufficientemente severe per garantire la spesa per il tempo, lo sforzo e le risorse per la progettazione di strategie di mitigazione. Ad esempio, potrebbero esserci alcune modalità di errore molto rare in caso di occorrenza o rilevamento. La progettazione di strategie di mitigazione intorno a essi non vale la pena.

Per un punto di partenza della documentazione, vedere la tabella di esempio seguente.

Durante l'esercizio iniziale di FMA, i documenti prodotti saranno principalmente la pianificazione teorica. I documenti FMA devono essere esaminati e aggiornati regolarmente per assicurarsi che rimangano aggiornati con il carico di lavoro. I test chaos e le esperienze reali consentono di perfezionare le analisi nel tempo.

Facilitazione di Azure

Usare Monitoraggio di Azure e Log Analytics per rilevare i problemi nel carico di lavoro. Per altre informazioni sui problemi relativi all'infrastruttura, alle app e ai database, usare strumenti come Application Insights, Container Insights, Network Insights, VM Insights e SQL Insights.

Azure Chaos Studio è un servizio gestito che usa l'ingegneria chaos per aiutare a misurare, comprendere e migliorare la resilienza dell'applicazione cloud e del servizio.

Per informazioni sull'applicazione dei principi FMA ai servizi comuni di Azure, vedere Analisi della modalità di errore per le applicazioni Azure.

Esempio

La tabella seguente illustra un esempio di FMA per un sito Web di e-commerce ospitato in istanze del servizio app Azure con i database SQL di Azure e viene anteriore da Frontdoor di Azure.

Flusso utente: accesso utente, ricerca di prodotti e interazione del carrello acquisti

Collegamenti correlati

• Analisi della modalità di errore per le applicazioni Di Azure
• Resilienza e dipendenze

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.