Raccomandazioni per l'esecuzione dell'analisi della modalità di errore
Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:
| RE:03 | Usare l'analisi della modalità di errore (FMA) per identificare e classificare in ordine di priorità i potenziali errori nei componenti della soluzione. Eseguire FMA per valutare il rischio e l'effetto di ogni modalità di errore. Determinare la modalità di risposta e ripristino del carico di lavoro. |
|---|
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
| Termine | Definizione |
|---|---|
| Modalità di errore | 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. |
| Strategia di riduzione del rischio | Le attività identificate per risolvere i problemi in modo proattivo o reattivo. |
| Rilevamento | 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 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
| Componente | Rischio | Probabilità | Effetto/Mitigazione/Nota | Outage |
|---|---|---|---|---|
| Microsoft Entra ID | Interruzione del servizio | Basso | Interruzione completa del carico di lavoro. Dipendente da Microsoft per la correzione. | Completo |
| Microsoft Entra ID | Errore di configurazione | Medio | Gli utenti non sono in grado di accedere. Nessun effetto downstream. L'help desk segnala il problema di configurazione al team di identità. | None |
| 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 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 interessate. | None |
| Frontdoor di Azure | Errore di configurazione | 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 interruzione. Microsoft gestisce la protezione DDoS (L3 e L4) e Web Application Firewall di Azure blocca la maggior parte delle minacce. Potenziale rischio di effetto da attacchi L7. | Potenziale interruzione parziale |
| Azure SQL | Interruzione del servizio | Basso | Interruzione completa del carico di lavoro. Dipendente da Microsoft per la correzione. | Completo |
| Azure SQL | Interruzione a livello di area | Molto bassa | Il gruppo di failover automatico esegue il failover nell'area 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 | None |
| Azure SQL | Attacco dannoso (injection) | 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. | Potenziale rischio basso |
| Servizio app | Interruzione del servizio | Basso | Interruzione completa del carico di lavoro. Dipendente da Microsoft per la correzione. | Completo |
| Servizio app | Interruzione a livello di area | Molto bassa | Effetto minimo. Latenza per gli utenti nelle aree interessate. Frontdoor di Azure instrada automaticamente il traffico alle aree non interessate. | None |
| Servizio app | Interruzione della zona di disponibilità | Basso | Nessun effetto. I servizi app sono stati distribuiti come ridondanti della zona. Senza ridondanza della zona, esiste un potenziale di effetto. | None |
| Servizio app | Attacco DDoS | Medio | Effetto minimo. Il traffico in ingresso è protetto da Frontdoor di Azure e web application firewall di Azure. | None |
Collegamenti correlati
Elenco di controllo per l'affidabilità
Fare riferimento al set completo di raccomandazioni.