Raccomandazioni per l'esecuzione dell'analisi della modalità di errore
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 potenziali errori nel carico di lavoro. Identificare le dipendenze e i punti di errore e sviluppare strategie di mitigazione per tali errori. |
|---|
Questa guida descrive le migliori pratiche per eseguire l'analisi delle modalità di guasto (FMA) per il tuo 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 esplosione di più tipi di errore, che consente di progettare un nuovo carico di lavoro o di effettuare il refactoring di un carico di lavoro esistente per ridurre al minimo l'effetto diffuso 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
| Termine | Definizione |
|---|---|
| Modalità di guasto | Tipo di problema che può causare la riduzione o la gravità di uno o più componenti del carico di lavoro al punto di non essere disponibile. |
| Mitigazione | Le attività identificate per risolvere i problemi in modo proattivo o reattivo. |
| Scoperta | L'infrastruttura, i dati e le procedure di monitoraggio e avvisi delle app. |
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 la completezza negli artefatti sono fondamentali.
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
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 per cui è necessario 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 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. Considerare l'effetto di un malfunzionamento del componente sui 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 dei segreti/chiavi come Azure Key Vault. Per queste dipendenze, acquisite i dati di affidabilità, come gli SLA di disponibilità e i 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 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.
Distributed Denial of Service (DDoS) o altri attacchi dannosi.
Configurazione errata dell'app o del componente.
Errore dell'operatore.
Interruzione della manutenzione pianificata.
Sovraccarico 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.
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.
Mitigazione
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 ulteriori informazioni, vedere Raccomandazioni per la ridondanza e Raccomandazioni per l'autoconservazione.
Per progettare considerando prestazioni degradate, identificare potenziali punti di errore che potrebbero disabilitare uno o più componenti del flusso senza però interromperlo completamente. 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 complesse svolgono un ruolo critico nella funzione e nella disponibilità 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.
Scoperta
Il rilevamento degli errori è essenziale per assicurarsi di aver identificato correttamente i punti di errore nell'analisi e di pianificare correttamente le strategie di mitigazione. 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, consultare le raccomandazioni per il monitoraggio di.
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 prioritizzazione per concentrare la documentazione sulle modalità di errore che sono comuni e sufficientemente gravi da giustificare l'impiego di tempo, sforzo e risorse nella progettazione di strategie di mitigazione. Ad esempio, potrebbero esserci alcune modalità di errore molto rare nell'occorrenza o nel rilevamento. La progettazione di strategie di mitigazione intorno a essi non vale la pena.
Fare riferimento alla tabella di esempio seguente per un punto di partenza per la documentazione.
Durante l'esercizio iniziale di FMA, i documenti prodotti saranno principalmente una pianificazione teorica. I documenti FMA devono essere esaminati e aggiornati regolarmente per assicurarsi che rimangano up-to-date con il carico di lavoro. I test chaos e le esperienze reali consentono di perfezionare le analisi nel tempo.
Facilitazione di Azure
Usare Azure Monitor 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 Insightse SQL Insights.
azure Chaos Studio è un servizio gestito che usa la progettazione chaos 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 dei guasti per le applicazioni di Azure.
Esempio
La tabella seguente mostra un esempio di FMA per un sito web di e-commerce ospitato su istanze del Servizio App di Azure, con database SQL di Azure, ed è gestito da Azure Front Door.
Flusso utente: accesso utente, ricerca di prodotti e interazione del carrello acquisti
| Componente | Rischio | Probabilità | Effetto/Mitigazione/Nota | Interruzione |
|---|---|---|---|---|
| Microsoft Entra ID | Interruzione del servizio | Basso | Interruzione completa del carico di lavoro. Dipendente da Microsoft per la correzione. | Pieno |
| Microsoft Entra ID | Errata configurazione | Medio | Gli utenti non sono in grado di accedere. Nessun effetto downstream. L'help desk segnala un problema di configurazione al team addetto all'identità. | Nessuno |
| Frontdoor di Azure | Interruzione del servizio | Basso | Interruzione completa per gli utenti esterni. Dipendente da Microsoft per la correzione. | Solo esterno |
| Frontdoor di Azure | Interruzione regionale | Molto basso | Effetto minimo. Frontdoor di Azure è un servizio globale, quindi il routing globale del traffico indirizza il traffico attraverso aree di Azure non interessate. | Nessuno |
| Frontdoor di Azure | Configurazione errata | Medio | Le configurazioni errate devono essere rilevate durante la distribuzione. Se si verificano durante un aggiornamento della 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 perturbazione. Microsoft gestisce la protezione DDoS (L3 e L4) e Web Application Firewall di Azure blocca la maggior parte delle minacce. Potenziale rischio di impatto da attacchi L7. | Potenziale interruzione parziale |
| Azure SQL | Interruzione del servizio | Basso | Interruzione completa del carico di lavoro. Dipendente da Microsoft per la correzione. | Pieno |
| Azure SQL | Interruzione regionale | Molto basso | Il gruppo di failover automatico passa alla regione secondaria. Potenziale interruzione durante il failover. Obiettivi del tempo di ripristino (RTO) e obiettivi del punto di ripristino (RPO) da determinare durante i test di affidabilità. | Potenziale pieno |
| Azure SQL | Interruzione della zona di disponibilità | Basso | Nessun effetto | Nessuno |
| Azure SQL | Attacco dannoso (iniezione) | Medio | Rischio minimo. Tutte le istanze sql di Azure sono associate alla rete virtuale tramite endpoint privati e gruppi di sicurezza di rete (NSG) aggiungono ulteriore protezione all'interno della rete virtuale. | Basso rischio, potenziale di interruzione parziale |
| Servizio app | Interruzione del servizio | Basso | Interruzione completa del carico di lavoro. Dipendente da Microsoft per la correzione. | Pieno |
| Servizio app | Interruzione regionale | Molto basso | Effetto minimo. Latenza per gli utenti nelle aree interessate. Frontdoor di Azure instrada automaticamente il traffico alle aree non interessate. | Nessuno |
| Servizio app | Interruzione della zona di disponibilità | Basso | Nessun effetto. I servizi app sono stati distribuiti come ridondanti tra zone. Senza ridondanza della zona, esiste un potenziale di effetto. | Nessuno |
| Servizio app | Attacco DDoS | Medio | Effetto minimo. Il traffico in ingresso è protetto da Frontdoor di Azure e web application firewall di Azure. | Nessuno |
Collegamenti correlati
Elenco di controllo per l'affidabilità
Fare riferimento al set completo di raccomandazioni.