Strategie di architettura per la progettazione di una strategia di test di affidabilità

Si applica alla seguente raccomandazione della check-list di Affidabilità del framework Azure Well-Architected:

RE:08 Testare la resilienza e gli scenari di disponibilità applicando i principi di chaos engineering. Usa i test di affidabilità per verificare che il carico di lavoro possa resistere ai guasti, scalare in base alla domanda e riprendersi entro gli obiettivi definiti.

I test di affidabilità rilevano i punti deboli dell'architettura prima di causare interruzioni. Senza eseguire test intenzionali sugli scenari di errore, non è possibile sapere se i modelli di resilienza funzionano effettivamente o se il carico di lavoro viene ripristinato entro le destinazioni definite.

Si rafforza l'affidabilità del carico di lavoro quando si testano i rischi per la sicurezza che influiscono sulla disponibilità, sui problemi di prestazioni che rendono inutilizzabile il sistema e sui gap operativi che limitano la risposta agli eventi imprevisti. Usare le strategie descritte in questo articolo per stabilire una cadenza di test che convalida regolarmente il carico di lavoro in base alle relative modalità di errore. Evolvere i test man mano che l'architettura cambia e gli eventi imprevisti rivelano nuovi punti deboli. Acquisisci la certezza che il tuo carico di lavoro possa resistere ai guasti, scalare per soddisfare la domanda e riprendersi entro gli obiettivi RTO e RPO, creando al contempo un ciclo di feedback che rafforzi nel tempo la tua strategia di affidabilità.

Le strategie principali di questo articolo si basano sulle procedure di test di base descritte in Strategie di architettura di OE:09 per i test. Esaminare prima l'articolo. Le raccomandazioni contenute in questa guida hanno come ambito l'affidabilità e si concentrano sul raggiungimento della fiducia nella capacità del carico di lavoro di resistere agli errori e di ripristinare all'interno degli obiettivi.

La tabella seguente definisce i termini chiave per l'affidabilità usati in questo articolo.

Definizioni

Termine Definizione
Availability Periodo di tempo in cui un carico di lavoro dell'applicazione viene eseguito in uno stato operativo corretto senza tempi di inattività significativi.
Ingegneria di Chaos La pratica che incorpora in modo sicuro i test di caos nella cultura del team, nelle procedure di progettazione e nel ciclo di vita di sviluppo per favorire il miglioramento continuo della resilienza del sistema.
Test di ingegneria del caos Esperimento controllato che convalida un'ipotesi di resilienza specifica sul comportamento di un carico di lavoro in condizioni di interruzione.
Iniezione di errori Una tecnica per introdurre deliberatamente errori a un componente, una dipendenza o un percorso di sistema.
Recuperabilità Possibilità di ripristinare le normali operazioni dopo un'interruzione entro gli obiettivi del tempo di ripristino concordato (RTO) e del punto di ripristino (RPO).
Resiliency La capacità di un carico di lavoro di resistere agli errori (ad esempio errori temporanei, interruzioni dell'infrastruttura, picchi di domanda) e continuare a funzionare all'interno di un'esperienza utente accettabile.
Failover Processo di passaggio a un componente secondario in caso di errore del componente primario.
Failback Processo in cui si ripristinano le operazioni nell'area primaria dopo il ripristino.
Budget degli errori Livello massimo di errore accettabile per un sistema in un periodo definito, derivato dagli obiettivi del livello di servizio .

Definire l'ambito di test dell'affidabilità in base ai tipi di servizio

Quando si definisce l'ambito dei test di affidabilità, prendere in considerazione il modello di responsabilità condivisa dei servizi usati. Ogni tipo di servizio (IaaS, PaaS, SaaS) include garanzie di affidabilità diverse e diversi livelli di controllo sulla gestione degli errori. Concentrate i test sugli aspetti dell'affidabilità di vostra competenza.

  • Adatta la profondità dei test al tuo livello di responsabilità. Per i servizi infrastrutturali (IaaS), il tuo team è responsabile della maggior parte delle decisioni in materia di affidabilità, quindi investi in una validazione approfondita tramite chaos engineering e iniezione di guasti. Per i servizi PaaS (Platform) e Software (SaaS), il provider gestisce gran parte dell'affidabilità sottostante. Concentrarsi sul modo in cui il carico di lavoro interagisce con tali servizi, ad esempio come gestisce i failover dell'infrastruttura in PaaS, la limitazione, la riduzione delle prestazioni dei servizi o le modifiche nei modelli di carico.

  • Tenere conto dei carichi di lavoro con servizi misti. Quando il carico di lavoro si estende su più tipi di servizio, le responsabilità di test variano in base ai componenti. È possibile testare il failover dei componenti dell'infrastruttura basata su macchine virtuali durante un'interruzione della zona di disponibilità, ma basarsi sulle garanzie del provider per un database PaaS progettato per la disponibilità elevata. Identificare dove si trovano tali limiti e assicurarsi che i test coprano le lacune tra di esse.

Testare end-to-end in base ai propri obiettivi di affidabilità

I tuoi obiettivi di affidabilità, come SLO, RTO e RPO, definiscono come il tuo carico di lavoro deve comportarsi in condizioni di guasto. Usali come criteri di superamento e fallimento nell'intero flusso critico, non solo nei singoli componenti.

  • Convalida il ripristino nell'intero flusso. Un singolo componente potrebbe essere ripristinato entro il proprio RTO, ma il tempo di ripristino complessivo può superare l'obiettivo previsto se anche le dipendenze a valle devono essere ripristinate. Tenere conto del tempo di ripristino totale nell'intero flusso, incluso il tempo necessario per rilevare il problema e rispondere.

  • Definire l'ambito dei test con gli SLO e i budget degli errori. Il budget degli errori rappresenta l'investimento che è possibile effettuare nell'inserimento di errori. Limita i test di chaos engineering per rimanere entro i tuoi SLO e usa i tuoi obiettivi di ripristino del flusso per definire i confini di ogni test.

Creare scenari di affidabilità da flussi critici e modalità di errore

Iniziare con i flussi critici nel carico di lavoro e le modalità di errore che possono influire su di essi. Usa la tua analisi delle modalità di guasto per identificare gli scenari di guasto di maggiore impatto e creare test per convalidare le tue strategie di resilienza e ripristino.

Assegnare priorità in base all'impatto e alla probabilità. Non tutte le modalità di guasto garantiscono lo stesso investimento di test. Concentrarsi prima sugli scenari con il massimo impatto potenziale dell'utente e la più alta probabilità di verificarsi. Lascia che l'analisi dei modi di guasto guidi questa prioritizzazione.

Convalidare i meccanismi di tolleranza di errore e ripristino

Concentrarsi sugli scenari che potrebbero causare tempi di inattività o ridurre l'esperienza utente. Usare le strategie descritte in questa sezione per compilare test che convalidano la capacità del carico di lavoro di gestire gli errori e ripristinare in modo efficace.

Backup e ripristino

I test di backup e ripristino devono verificare che l'approccio alla protezione dei dati soddisfi gli obiettivi di ripristino.

  • Stabilire una cadenza di test. Determinare la frequenza con cui è necessario testare i ripristini in base alla frequenza di modifica della configurazione del backup, dello schema dei dati o dell'infrastruttura. Le modifiche più frequenti richiedono test di ripristino più frequenti.

  • Imposta gli obiettivi di ripristino. Misurare i tempi di ripristino effettivi rispetto agli obiettivi RPO e RTO per verificare che la strategia di backup soddisfi gli obiettivi di ripristino.

  • Non presupporre la completezza del backup. I backup possono essere configurati in modo errato per acquisire solo un subset dei dati. Convalidare l'integrità e la completezza dei dati, non solo se un'operazione di ripristino ha esito positivo.

  • Esegui il test in modo isolato. Convalidare i ripristini in un ambiente separato dall'ambiente di produzione in modo da poter eseguire controlli accurati senza interrompere i carichi di lavoro in tempo reale.

Errori temporanei

Gli errori temporanei, ad esempio le interruzioni di rete momentanee, la breve indisponibilità del servizio e i timeout di connessione, sono rischi comuni per l'affidabilità. Verificare che il carico di lavoro gestisca questi errori senza influire sugli utenti. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

  • Concentrati su ciò che possiedi. Se gli SDK o i servizi della piattaforma gestiscono automaticamente tentativi e interruzioni del circuito, verificare cosa accade quando questi meccanismi predefiniti vengono esauriti, ad esempio quando tutti i tentativi hanno esito negativo o si apre un interruttore.

  • Convalidare le configurazioni di gestione degli errori. Valutare le configurazioni di gestione degli errori del carico di lavoro. Verificare che i criteri di ripetizione dei tentativi, le soglie dell'interruttore e i valori di timeout si comportino come previsto in condizioni di errore realistiche.

  • Testare il limite tra un errore temporaneo e un errore permanente. Verificare che il carico di lavoro passi normalmente dal comportamento di ripetizione dei tentativi al fallback o alla riduzione delle prestazioni quando un errore persiste oltre le soglie previste.

  • Considerare i guasti transitori dovuti alle funzionalità di resilienza. La ridondanza della zona e le progettazioni simili spesso producono errori temporanei durante le normali operazioni di failover. Ad esempio, un database con ridondanza tra zone potrebbe causare errori di connessione transitori quando il traffico viene spostato a una zona funzionante durante un'interruzione. Verificare se il carico di lavoro può gestire questi errori temporanei previsti senza un impatto significativo sull'utente.

Carico e scalabilità

Verificare che il carico di lavoro mantenga l'affidabilità durante le modifiche alla domanda, sia picchi improvvisi che aumenti graduali. Per altre informazioni, vedere Strategia di ridimensionamento. Per indicazioni sui test di carico e stress, vedere Raccomandazioni per i test.

  • Testare sia lo scale-out che lo scale-in. Verificare che la nuova capacità entri in funzione abbastanza rapidamente e che la riduzione della capacità non provochi la perdita di richieste né lasci risorse orfane.

  • Considera il ritardo della scalabilità. C'è sempre un ritardo tra soddisfare le condizioni per attivare il ridimensionamento e avere una nuova capacità pronta. Stabilisci se il tuo carico di lavoro è in grado di gestire la domanda durante quell'intervallo o se devi predisporre in anticipo capacità aggiuntiva.

Errori di dipendenza

Il carico di lavoro dipende probabilmente da servizi esterni al controllo diretto, ad esempio API di terze parti, servizi della piattaforma gestita o servizi interni condivisi. Verifica che il workload gestisca i guasti di tali dipendenze senza causare interruzioni significative agli utenti.

  • Classificare le dipendenze in base alla criticità. Non tutte le dipendenze giustificano lo stesso investimento di test. Classificare in ordine di priorità i test per le dipendenze presenti nei flussi critici e che non dispongono di percorsi di ridondanza o fallback predefiniti.

  • Verifica il comportamento di fallback per ciascuna dipendenza. Quando una dipendenza non è più disponibile, il carico di lavoro dovrebbe ricorrere a un percorso o a un comportamento alternativi, invece di interrompersi completamente. Verificare che ogni fallback venga attivato correttamente e che le funzionalità non correlate continuino a funzionare.

  • Tenere conto degli errori parziali e a catena. Le dipendenze raramente falliscono in modo netto. Non limitarti a testare le interruzioni complete. Coprire gli aumenti della latenza, gli errori intermittenti e la disponibilità parziale dei dati.

  • Convalidare l'isolamento e il contenimento del raggio di esplosione. Verificare che il guasto di una singola dipendenza non si propaghi a funzionalità non correlate.

Autoprotezione e ripristino

Convalidare il modo in cui la progettazione di riparazione automatica e conservazione automatica risponde a malfunzionamenti, ad esempio se il carico di lavoro può continuare a funzionare in una capacità ridotta quando il ripristino completo non è immediato.

  • Testare il ripristino end-to-end automatizzato. Valuta i tuoi modelli di integrità per verificare che includano i controlli appropriati. Verificare che questi controlli rilevino gli errori in modo accurato, attivino la correzione automatica come previsto e restituiscono il sistema a uno stato integro entro intervalli di tempo accettabili.

  • Convalidare i runbook di ripristino manuale. Il ripristino automatizzato non copre tutti gli scenari. Testate i runbook manuali in condizioni realistiche per assicurarvi che gli operatori siano in grado di eseguirli sotto pressione ed entro gli obiettivi di tempo di ripristino.

  • Verificare il comportamento di degradazione graduale. Quando un componente si guasta, il carico di lavoro dovrebbe ridursi in modo graduale anziché interrompersi completamente. Verificare che possa funzionare in modalità ridotta, ad esempio mettendo in coda le richieste per una revisione manuale, e che l'esperienza degradata sia accettabile per gli utenti. Verificare che il team sappia come gestire il carico di lavoro in questo stato e come ripristinare le funzionalità complete.

Eventi imprevisti e ripristino di emergenza

Quando si verifica un evento imprevisto o un'emergenza, la possibilità di rilevarla rapidamente e rispondere in modo efficace è fondamentale. Testare i piani e i processi per assicurarsi che affrontino errori irreversibili e eventi imprevisti gravi. Utilizzare un ambiente dedicato per i test di disaster recovery, per evitare di influire sui carichi di lavoro di produzione. Per altre informazioni, vedere Piano di ripristino di emergenza.

  • Convalidare i meccanismi di rilevamento degli eventi imprevisti. Simulare gli eventi imprevisti per verificare che i log di monitoraggio acquisiscano le informazioni necessarie e che gli avvisi vengano attivati in modo appropriato. Ad esempio, testare quanto rapidamente vengono rilevati gli aumenti dei tassi di errore delle richieste e con quale frequenza vengono campionati i dati di monitoraggio.

  • Testare i processi di gestione degli eventi imprevisti. Verificare che il team possa seguire in modo efficace le procedure di risposta agli eventi imprevisti. Per altre informazioni, vedere Risposta agli eventi imprevisti.

  • Testare il failover completo e il failback. Testare singoli componenti in isolamento può non rilevare errori di coordinamento che emergono solo durante una reale commutazione. Verificare l'intera sequenza di failover, inclusi la commutazione DNS, il ripristino dei backup, la coerenza della replica dei dati e la riconnessione dei client. Verificate anche il failback verso l'ambiente di distribuzione primario, che spesso è più complesso della commutazione iniziale.

  • Verificare la capacità nell'ambiente di failover. Assicurati che il tuo ambiente di failover disponga di una capacità preallocata sufficiente per gestire il traffico non appena si verifica il failover, senza collassare sotto carico. Verificare che l'ambiente possa sostenere le operazioni durante l'attivazione dei meccanismi di ridimensionamento e convalidare l'approccio di ridimensionamento. Per altre informazioni, vedere Caricare e ridimensionare la risposta.

  • Misura rispetto ai tuoi obiettivi. Se un test di disaster recovery non soddisfa gli obiettivi RTO o RPO, analizza le carenze e aggiorna di conseguenza il piano di disaster recovery.

  • Convalidare le persone e il processo. I test di DR dovrebbero verificare i canali di comunicazione, confermare che gli operatori abbiano l'accesso e le autorizzazioni necessarie per eseguire le procedure di ripristino e garantire che possano trovare rapidamente i runbook specifici per il DR anche sotto pressione.

Metti alla prova e valuta il tuo piano con esercitazioni tabletop

Le esercitazioni tabletop aiutano a individuare le lacune nei test di affidabilità prima che un incidente reale le metta in evidenza. Simulando scenari di errore con il team, è possibile identificare le condizioni non testata e verificare che le procedure di risposta funzionino come previsto.

  • Simulare eventi imprevisti realistici. Esaminare uno scenario di errore, ad esempio un'interruzione a livello di area o una distribuzione danneggiata, e chiedere al team di descrivere i passaggi da eseguire per rilevare, rispondere e ripristinarlo. Queste discussioni rivelano spesso presupposti sul comportamento del sistema che non sono stati convalidati tramite test.

  • Trasforma i risultati in casi di test. Usare le lacune e le incognite che si verificano durante l'esercizio per creare nuovi test di affidabilità. Se il team rileva che nessuno sa come si comporta il carico di lavoro quando una dipendenza specifica ha esito negativo, si tratta di uno scenario da aggiungere alla strategia di test.

Sfruttare i vantaggi delle interruzioni pianificate e non pianificate

Quando il carico di lavoro è offline a causa di una manutenzione pianificata o di un'interruzione non pianificata, è possibile eseguire test e migliorare la comprensione del carico di lavoro.

Manutenzione pianificata

Durante le finestre di manutenzione per gli aggiornamenti o le patch, testare i componenti e i flussi non interessati dagli interventi di manutenzione. È possibile eseguire test senza il rischio di degradare in modo imprevisto il carico di lavoro o di portarlo offline. Se si dispone di tempo sufficiente, testare anche i componenti coinvolti nella manutenzione dopo il completamento del lavoro.

Interruzione non pianificata

Ogni interruzione non pianificata è un'opportunità per rafforzare la strategia di test di affidabilità. Dopo aver ripristinato il servizio e aver completato la revisione post-evento imprevisto, usare i risultati per migliorare i test.

  • Testare le misure di mitigazione. Se è stata applicata una soluzione alternativa o una correzione temporanea, verificare che sia in grado di gestire il carico previsto prima che sia stata applicata la correzione permanente.

  • Cercare punti deboli simili. Esaminare gli altri componenti per gli stessi modelli di configurazione o progettazione che hanno contribuito all'interruzione. Aggiungere test per tali componenti prima che abbiano esito negativo nello stesso modo.

Combinare tipi diversi di test

Quando si eseguono diversi tipi di test insieme, è possibile rivelare problemi di affidabilità che non sono visibili quando ogni test viene eseguito in isolamento. Un carico di lavoro può gestire un carico specifico in condizioni normali, ma lo stesso carico causa errori quando si introduce un errore.

  • Riutilizzare l'infrastruttura di test esistente. Se si dispone già dell'infrastruttura e di un test harness per i test di carico, usarlo per eseguire i test chaos contemporaneamente. La combinazione di caricamento e inserimento di errori nella stessa esecuzione del test mostra il comportamento del carico di lavoro in condizioni realistiche, in cui la domanda e gli errori si verificano contemporaneamente.

  • Iniziare in ambienti non di produzione. Iniziare i test di affidabilità in ambienti a basso rischio in cui è possibile esplorare in modo sicuro le modalità di errore. Passare ai test in produzione solo dopo aver sfruttato appieno tutte le indicazioni ricavate dagli ambienti non di produzione e aver predisposto adeguate misure di salvaguardia per limitare l’impatto di eventuali problemi e consentire un rollback rapido.

Usare l'inserimento di errori e la progettazione chaos

L'inserimento degli errori e la progettazione chaos consentono di acquisire fiducia nella resilienza del carico di lavoro introducendo deliberatamente errori e osservando la risposta. Assicurarsi di disporre di strategie di mitigazione prima di eseguire esperimenti.

  • Eseguire regolarmente esperimenti chaos. Valuta l'ambito del test. Inserire errori nei componenti e nei flussi che si presuppone siano affidabili. Man mano che l'architettura cambia, emergono nuove modalità di errore e i presupposti precedenti potrebbero non essere più contenuti. Eseguire esperimenti a cadenza regolare per intercettare le regressioni, convalidare le nuove dipendenze e verificare che le modifiche recenti non introducono punti deboli.

  • Usare l'analisi della modalità di errore per concentrare gli esperimenti. Ogni esperimento deve avere come destinazione un errore specifico o un set di errori e avere un'ipotesi chiara, ad esempio testare la capacità di un determinato flusso di resistere alla perdita di un determinato componente. Man mano che gli esperimenti rivelano nuove modalità di errore o dipendenze non individuate, aggiornare l'analisi della modalità di errore per mantenerla aggiornata.

  • Limitare l’impatto durante gli esperimenti. I componenti di destinazione che è possibile ripristinare rapidamente e per i quali è possibile definire aspettative consapevoli sull'effetto di ogni iniezione di guasti. Se un esperimento supera l'ambito o produce risultati imprevisti, arrestarlo. Bilanciare la raccolta di dati significativi riducendo al minimo l'effetto sugli utenti.

  • Misurare rispetto alle linee di base. Stabilire metriche di affidabilità e prestazioni coerenti per i flussi e i componenti in ogni esperimento. Confronta le metriche dello stato degradato con questi valori di riferimento per comprendere il pieno effetto del guasto e determinare se l'architettura di resilienza raggiunge i propri obiettivi.

  • Reintegrate i risultati nella vostra strategia di test. Usare i risultati dell'esperimento per guidare nuovi test, aggiornare i piani di ripristino e informare gli elementi del backlog di correzione. Man mano che si verificano comportamenti imprevisti, creare test mirati per tali comportamenti e progettare strategie di correzione.

Controindicazione: i test di iniezione di guasti in produzione possono risultare destabilizzanti e causare potenzialmente interruzioni del servizio. Essere trasparenti con gli stakeholder su questa possibilità. Mettere in atto misure di sicurezza in modo da arrestare gli esperimenti e eseguire rapidamente il rollback e rimanere flessibili su quando eseguire test o evitarli durante periodi sensibili. Per proteggersi da interruzioni non intenzionali, pianifica una ridondanza sufficiente e assicurati che gli stakeholder comprendano il compromesso in termini di costi.

Rischio: I test di affidabilità possono espandere la copertura in molte modalità di errore, ma è consigliabile arrestare una volta che non fornisce più un valore significativo. Se si dispone già di un backlog di problemi di affidabilità noti, assegnare priorità alla risoluzione dei problemi anziché aggiungere altri test.

Facilitazione di Azure

Piani di test di Azure è una soluzione di gestione dei test basata su browser che fornisce tutte le funzionalità necessarie per i test manuali pianificati, i test di accettazione degli utenti, i test esplorativi e la raccolta di feedback dagli stakeholder.

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

Test app di Azure è un servizio che consente di eseguire test funzionali con Spazi di lavoro Playwright e test delle prestazioni usando Test di carico di Azure per identificare i problemi nelle applicazioni.

integrità dei servizi di Azure include un riquadro di manutenzione pianificato, che è una sezione dedicata nel portale di Azure che consente di tenere informati sulle attività di manutenzione future. Evidenzia gli eventi che possono influire sulle risorse Azure, aiutandoti a prepararti in anticipo.

Il monitoraggio delle connessioni è una funzionalità di Azure Network Watcher che è possibile usare per il monitoraggio sintetico e il test in tempo reale della connettività di rete in ambienti azure e ibridi. Negli scenari di progettazione chaos, il monitoraggio delle connessioni può essere usato per inserire errori nei componenti di rete di destinazione e misurare continuamente le metriche chiave, ad esempio la latenza e la perdita di pacchetti. Questa funzionalità consente ai team di osservare in che modo le interruzioni influiscono sull'affidabilità della rete, sia per i singoli componenti di flusso che per i percorsi di rete end-to-end. Per valutare l'impatto dei difetti e identificare le aree di miglioramento, confrontare la telemetria di monitoraggio della connessione con le metriche di base.

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'affidabilità

  • Last updated on