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

  • Articolo

Si applica a questa raccomandazione per l'affidabilità di Azure Well-Architected Framework:

RE:03 Usare l'analisi della modalità di errore (FMA) per identificare e definire le priorità di potenziali errori nei componenti della soluzione. Eseguire FMA per valutare il rischio e l'effetto di ogni modalità di errore. Determinare il modo in cui il carico di lavoro risponde e recupera.

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 di conseguenza le azioni di mitigazione. In ogni passaggio del flusso si identifica il raggio di esplosione di più tipi di errore, che consente di progettare un nuovo carico di lavoro o di eseguire il refactoring di un carico di lavoro esistente per ridurre al minimo l'effetto diffuso degli errori.

Una chiave di rete di FMA è che gli errori si verificano indipendentemente dal numero di livelli di resilienza applicati. Gli ambienti più complessi sono esposti a più tipi di errori. Dato questa realtà, FMA consente di progettare il carico di lavoro per resistere alla maggior parte dei tipi di errori e ripristinare in modo normale 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

Termine Definizione
Modalità di errore Un tipo di problema che può causare il degrado di uno o più componenti del carico di lavoro o gravemente interessati al punto di non essere disponibile.
Strategia di riduzione del rischio Le attività identificate per risolvere i problemi in modo proattivo o reattivo.
Rilevamento L'infrastruttura, i dati e il monitoraggio delle app e i processi e le procedure di avviso.

Strategie di progettazione chiave

Prerequisiti

Esaminare e implementare le raccomandazioni per identificare i flussi. Si presuppone che sia stato identificato e con 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 dati coinvolti in tutti i flussi. Per avere successo nel lavoro FMA, accuratezza e accuratezza negli artefatti è fondamentale.

Approccio FMA

Dopo aver determinato i flussi critici, è possibile pianificare i 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.

Decomponere il carico di lavoro

Quando si passa dall'ideazione alla progettazione, è necessario identificare i tipi di componente necessari per supportare il carico di lavoro. Il carico di lavoro determina i componenti necessari da pianificare. 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 di chiavi o segreti) e il controllo in uscita. In questa fase del lavoro di progettazione, potrebbe non essere possibile conoscere le tecnologie specifiche distribuite, in modo che la progettazione possa essere simile all'esempio seguente.

Diagramma che mostra l'esempio di progettazione.

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 single point-of-failure. La scomposizione del carico di lavoro e dei flussi di sovrapposizione fornisce informazioni dettagliate sulle dipendenze interne ed esterne al carico di lavoro.

Le dipendenze interne sono componenti nell'ambito del carico di lavoro necessari per la funzione 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, ad esempio 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.

Punti di errore

Nei flussi critici del carico di lavoro prendere in considerazione ogni componente e determinare come tale componente e le relative dipendenze potrebbe essere influenzato da una modalità di errore. Tenere presente che esistono molte modalità di errore da considerare quando si pianifica la resilienza e il ripristino. Qualsiasi componente può essere interessato da più di una modalità di errore in qualsiasi momento. Queste modalità di errore includono:

  • Interruzione regionale. 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.

  • Attacco denial-of-service distribuito (DDoS) o altri attacchi dannosi.

  • Configurazione errata dell'app o del componente.

  • Errore dell'operatore.

  • Interruzione della manutenzione pianificata.

  • Overload del componente.

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.

Prendere in considerazione la probabilità di ogni tipo di modalità di errore. Alcuni sono molto improbabili, ad esempio interruzioni multi-zona o multi-area 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 più resilienza include l'aggiunta di ridondanza ai componenti, ad esempio l'infrastruttura, i dati e la rete, e la garanzia che la progettazione dell'applicazione segue le procedure consigliate per la durabilità, ad esempio suddividendo le applicazioni monolitiche in app isolate e microservizi. Per altre informazioni, vedere Raccomandazioni per la ridondanza e le raccomandazioni per l'auto-conservazione.

Per progettare prestazioni ridotte, identificare i 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 esegue una funzione, quindi la funzione non è più disponibile nell'esperienza utente. Per tornare all'applicazione e-commerce, un componente non riuscito come un microservizio potrebbe causare l'impossibilità del motore di raccomandazione, ma i clienti possono comunque cercare 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 forti 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 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 avere identificato correttamente i punti di errore nell'analisi e pianificare correttamente le strategie di mitigazione. Il rilevamento in questo contesto indica il monitoraggio dell'infrastruttura, dei dati e dell'applicazione e l'avviso quando si verificano problemi. Automatizzare il rilevamento il più possibile e creare ridondanza nei processi operativi per garantire che gli avvisi vengano sempre rilevati e vengano risposti in modo rapido 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 effettuate in relazione ai componenti del flusso e alla mitigazione e l'effetto dell'errore sul carico di lavoro.

Nell'analisi definire la priorità delle modalità di errore e delle strategie di mitigazione identificate in base alla gravità e alla probabilità. Usare questa priorità per concentrarsi sulla documentazione sulle modalità di errore comuni e gravi per garantire la spesa di tempo, sforzo e risorse sulla progettazione di strategie di mitigazione. Ad esempio, potrebbero essere presenti alcune modalità di errore molto rare in occorrenza o rilevamento. La progettazione di strategie di mitigazione intorno a loro non vale il costo.

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

Durante l'esercizio FMA iniziale, i documenti prodotti saranno principalmente la pianificazione teorica. I documenti FMA devono essere esaminati e aggiornati regolarmente per garantire che rimangano aggiornati con il carico di lavoro. I test di 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 ulteriori 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 la progettazione del caos per 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 di Azure.

Esempio

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

Flusso utente: Accesso utente, ricerca prodotto e interazione carrello acquisti

Componente Rischio Probabilità Effetto/Mitigazione/Nota Outage
Microsoft Entra ID Interruzione del servizio Basso Interruzione completa del carico di lavoro. Dipendente da Microsoft per correggere. Full
Microsoft Entra ID Errore di configurazione Medio Gli utenti non possono accedere. Nessun effetto downstream. Help desk segnala il problema di configurazione del team di identità. Nessuno
Frontdoor di Azure Interruzione del servizio Basso Interruzione completa per gli utenti esterni. Dipendente da Microsoft per correggere. Solo esterno
Frontdoor di Azure Interruzione a livello di area Molto bassa Effetto minimo. Frontdoor di Azure è un servizio globale, quindi il routing globale del traffico indirizza il traffico attraverso aree di Azure non effettive. Nessuno
Frontdoor di Azure Errore di configurazione Medio Le configurazioni non configurate devono essere rilevate durante la distribuzione. Se si verificano durante un aggiornamento di configurazione, gli amministratori devono eseguire il rollback delle modifiche. L'aggiornamento della configurazione causa una breve interruzione esterna. Solo esterno
Frontdoor di Azure Attacco DDoS Medio Potenziale di interruzione. Microsoft gestisce la protezione DDoS (L3 e L4) e Azure Web application firewall blocca la maggior parte delle minacce. Rischio potenziale di effetto da attacchi L7. Potenziale di interruzione parziale
SQL di Azure Interruzione del servizio Basso Interruzione completa del carico di lavoro. Dipendente da Microsoft per correggere. Full
SQL di Azure Interruzione a livello di area Molto bassa Il gruppo di failover automatico esegue il failover in un'area secondaria. Interruzione potenziale durante il failover. Obiettivi di tempo di ripristino (RTO) e obiettivi del punto di ripristino (RPO) da determinare durante i test di affidabilità. Potenziale completo
SQL di Azure Interruzione della zona di disponibilità Basso Nessun effetto Nessuno
SQL di Azure Attacco dannoso (inserimento) Medio Rischio minimo. Tutte le istanze di Azure SQL sono associate alla rete virtuale tramite endpoint privati e gruppi di sicurezza di rete (NSG) aggiungono ulteriore protezione tra reti virtuali. Potenziale rischio basso
Servizio app Interruzione del servizio Basso Interruzione completa del carico di lavoro. Dipendente da Microsoft per correggere. Full
Servizio app Interruzione a livello di area Molto bassa Effetto minimo. Latenza per gli utenti in aree effettive. Frontdoor di Azure instrada automaticamente il traffico alle aree non effettive. Nessuno
Servizio app Interruzione della zona di disponibilità Basso Nessun effetto. I servizi app sono stati distribuiti come ridondanti della zona. Senza ridondanza della zona, c'è un potenziale per effetto. Nessuno
Servizio app Attacco DDoS Medio Effetto minimo. Il traffico in ingresso è protetto da Frontdoor di Azure e azure Web application firewall. Nessuno

Elenco di controllo affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo affidabilità