Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
REL12-BP05 Verifica la resilienza utilizzando l'ingegneria del caos
Esegui regolarmente esperimenti di ingegneria del caos in ambienti di produzione o per quanto possibile ambienti analoghi per capire in che modo il sistema risponde a condizioni avverse.
Risultato desiderato:
La resilienza del carico di lavoro viene regolarmente verificata mediante l'applicazione dell'ingegneria del caos sotto forma di esperimenti di iniezione di guasti o di inserimento di carichi imprevisti, nonché mediante il test della resilienza che convalida i comportamenti previsti noti del carico di lavoro durante un evento. Combina l'ingegneria del caos e i test della resilienza per verificare se il carico di lavoro è in grado di superare i guasti dei componenti ed eseguire il ripristino da interruzioni del servizio impreviste con un impatto minimo o nullo.
Anti-pattern comuni:
-
Progettazione della resilienza, ma mancata verifica del funzionamento del carico di lavoro nel suo complesso in caso di errori.
-
Mancata sperimentazione in scenari reali e con carichi previsti.
-
Mancato trattamento degli esperimenti come codice o loro conservazione durante il ciclo di sviluppo.
-
Mancata esecuzione degli esperimenti di ingegneria del caos sia nella pipeline CI/CD che esternamente alle implementazioni.
-
Mancato utilizzo delle precedenti analisi post-incidente durante la determinazione degli errori su cui eseguire i test.
Vantaggi dell'adozione di questa best practice: l'introduzione di errori per verificare la resilienza del carico di lavoro consente di verificare che le procedure di ripristino della progettazione resiliente funzionerà se viene generato un vero e proprio errore.
Livello di rischio associato se questa best practice non fosse adottata: medio
Guida all'implementazione
L'ingegneria del caos offre ai team la possibilità di continuare a inserire scenari di errore reali (simulazioni) in modo controllato a livello di fornitore di servizi, infrastruttura, carico di lavoro e componente con un impatto minimo o nullo per i clienti. Consente inoltre ai team di imparare dagli errori e osservare, misurare e migliorare la resilienza dei carichi di lavoro, nonché verificare l'attivazione degli avvisi e se tali avvisi vengono recapitati ai team se si verifica un evento definito.
Se applicata in modo continuativo, l'ingegneria del caos può mettere in evidenza i difetti del carico di lavoro che, se non risolti, possono avere ripercussioni negative sulla disponibilità e sulle operazioni.
Nota
L'ingegneria del caos è la disciplina che sperimenta un sistema per creare fiducia nella capacità del sistema di affrontare condizioni turbolenti nella produzione. – Principles of Chaos Engineering
Se un sistema è in grado di sopportare queste interruzioni, l'esperimento di ingegneria del caos deve essere convertito in test automatico di regressione. In questo modo, gli esperimenti sul caos devono essere eseguiti come parte del ciclo di vita di sviluppo dei sistemi (SDLC) e come parte della pipeline CI/CD.
Per garantire che il carico di lavoro sia in grado di gestire un guasto del componente, esegui l'iniezione di eventi di errore reali durante l'esecuzione degli esperimenti. Ad esempio, sperimenta la perdita di EC2 istanze Amazon o il failover dell'istanza di RDS database Amazon principale e verifica che il carico di lavoro non ne risenta (o lo sia solo in minima parte). Utilizza una combinazione di errori dei componenti per simulare gli eventi che possono essere causati da un'interruzione del servizio in una zona di disponibilità.
Per i guasti a livello di applicazione (come i crash), puoi iniziare con fattori di stress come la memoria e l'esaurimento. CPU
Per convalidare i meccanismi di fallback o failover
Altre modalità di degrado possono causare funzionalità ridotte e risposte lente, spesso con conseguente interruzione dei servizi. Le fonti comuni di questo degrado sono una maggiore latenza nei servizi critici e una comunicazione di rete inaffidabile (pacchetti persi). Gli esperimenti con questi errori, inclusi effetti di rete come latenza, messaggi persi ed DNS errori, potrebbero includere l'impossibilità di risolvere un nome, accedere al servizio o stabilire connessioni a servizi dipendenti. DNS
Strumenti dell'ingegneria del caos:
AWS Fault Injection Service (AWS FIS) è un servizio completamente gestito per l'esecuzione di esperimenti di iniezione dei guasti che può essere utilizzato come parte della pipeline CD o al di fuori della pipeline. AWS FIS è un'ottima scelta da usare durante le giornate dedicate ai giochi di Chaos Engineering. Supporta l'introduzione simultanea di errori su diversi tipi di risorse tra cui AmazonEC2, Amazon Elastic Container Service (AmazonECS), Amazon Elastic Kubernetes Service (Amazon) e EKS Amazon. RDS Questi errori includono l'interruzione delle risorse, il failover forzato, lo stress della memoria, la limitazione, la latenza e la perdita di CPU pacchetti. Poiché è integrato con Amazon CloudWatch Alarms, puoi impostare condizioni di arresto come guardrail per annullare un esperimento se causa un impatto imprevisto.
AWS Fault Injection Service si integra con AWS le risorse per consentirti di eseguire esperimenti di iniezione dei guasti per i tuoi carichi di lavoro.
Esistono anche diverse opzioni di terze parti per gli esperimenti di iniezione di guasti. Queste opzioni comprendono strumenti open source come Chaos Toolkit
Passaggi dell'implementazione
-
Determinazione dei guasti da utilizzare per gli esperimenti.
Valutazione della progettazione del carico di lavoro a livello di resilienza. Tali progettazioni (create seguendo le best practice del Framework Well-Architected) tengono conto dei rischi basati su dipendenze critiche, eventi passati, problemi noti e requisiti di conformità. Elenca i singoli elementi della progettazione che devono conservare la resilienza e gli errori per mitigare i quali è stata sviluppata. Per ulteriori informazioni sulla creazione di tali elenchi, consulta il whitepaper sulla prontezza operativa, che illustra come creare un processo finalizzato alla prevenzione del ripetersi di incidenti precedenti. Il processo Failure Modes and Effects Analysis (FMEA) fornisce un framework per eseguire un'analisi a livello di componente dei guasti e del loro impatto sul carico di lavoro. FMEAè descritto più dettagliatamente da Adrian Cockcroft in Failure Modes and Continuous Resilience.
-
Assegna una priorità a ogni errore.
Comincia con una categorizzazione approssimativa, ad esempio alta, media o bassa. Per valutare la priorità, considera la frequenza dell'errore e l'impatto dell'errore sul carico di lavoro nel suo complesso.
Durante la valutazione della frequenza di un errore specifico, analizza i precedenti dati per lo stesso carico di lavoro, se disponibili. Se non sono disponibili, utilizza i dati di altri carichi di lavoro eseguiti in un ambiente simile.
Durante la valutazione dell'impatto di un errore specifico, in genere maggiore è l'ambito dell'errore, maggiore sarà l'impatto. Considera la progettazione e lo scopo del carico di lavoro. Ad esempio, la capacità di accedere ai datastore di origine è di cruciale importanza per un carico di lavoro responsabile della trasformazione e dell'analisi dei dati. In questo caso, darai la precedenza agli esperimenti relativi agli errori di accesso, nonché a quelli con limitazione (della larghezza di banda della rete) e inserimento di latenza.
Le analisi post-incidente rappresentano un'ottima fonte di dati per la comprensione della frequenza e dell'impatto delle modalità di errore.
Utilizza la priorità assegnata per determinare il primo errore su cui eseguire l'esperimento e l'ordine in cui sviluppare i nuovi esperimenti di iniezione di guasti.
-
Per ogni esperimento eseguito, attieniti ai principi del volano dell'ingegneria del caos e della resilienza continua nella figura seguente.
Volano dell'ingegneria del caos e della resilienza continua, che utilizza il metodo scientifico di Adrian Hornsby.
-
Definisci lo stato stazionario come output misurabile di un carico di lavoro che indica un comportamento normale.
Il carico di lavoro è associato allo stato stazionario se il suo funzionamento è affidabile e conforme a quanto previsto. Verifica pertanto che il carico di lavoro sia integro prima di definire lo stato stazionario. Lo stato stazionario non necessariamente indica l'assenza di impatto sul carico di lavoro se si verifica un errore in quanto una data percentuale di errori può rientrare nei limiti di valori accettabili. Lo stato stazionario rappresenta il punto di riferimento che verrà osservato durante l'esperimento e che metterà in evidenza le anomalie se le ipotesi definite nel passaggio successivo non sono conformi alle previsioni.
Ad esempio, lo stato stazionario di un sistema di pagamenti può essere definito come l'elaborazione di 300 TPS con una percentuale di successo del 99% e un tempo di andata e ritorno di 500 ms.
-
Definisci un'ipotesi in merito alle reazioni del carico di lavoro all'errore.
Un'ipotesi ottimale fa riferimento al modo in cui il carico di lavoro presumibilmente è in grado di ridurre l'impatto dell'errore e salvaguardare lo stato stazionario. Nell'ipotesi è definito che, dato un errore di un tipo specifico, il sistema o il carico di lavoro rimarrà nello stato stazionario poiché la progettazione del carico di lavoro ha previsto sistemi specifici di attenuazione degli errori. Il tipo di errore specifico e i sistemi di attenuazione devono essere specificati nell'ipotesi.
Per l'ipotesi è possibile utilizzare il seguente modello, anche se è accettabile una formulazione diversa:
Nota
Se
specific faultsi verifica, ilworkload nameil carico di lavoro saràdescribe mitigating controlsmantenerebusiness or technical metric impact.Per esempio:
-
Se il 20% dei nodi del EKS gruppo di nodi Amazon viene disattivato, Transaction Create API continua a soddisfare il 99° percentile di richieste in meno di 100 ms (stato stazionario). EKSI nodi Amazon verranno ripristinati entro cinque minuti e i pod riceveranno il traffico pianificato ed elaborato entro otto minuti dall'inizio dell'esperimento. Gli avvisi verranno attivati entro tre minuti.
-
Se si verifica un errore di una singola EC2 istanza Amazon, il controllo dello stato di Elastic Load Balancing del sistema di ordinazione farà sì che Elastic Load Balancing invii le richieste solo alle istanze integre rimanenti, mentre Amazon EC2 Auto Scaling sostituisce l'istanza fallita, mantenendo un aumento inferiore allo 0,01% degli errori lato server (5xx) (stato stazionario).
-
Se l'istanza principale del RDS database Amazon si guasta, il carico di lavoro di raccolta dati Supply Chain eseguirà il failover e si connetterà all'istanza di database RDS Amazon in standby per mantenere meno di 1 minuto di errori di lettura o scrittura del database (stato stazionario).
-
-
Esegui l'esperimento inserendo l'errore.
Per impostazione predefinita, un esperimento deve essere a prova di errore e tollerato dal carico di lavoro. Se sei consapevole del fatto che il carico di lavoro avrà esito negativo, non eseguire l'esperimento. L'ingegneria del caos deve essere utilizzata per individuare scenari noti sconosciuti o scenari completamente sconosciuti. Per scenari noti sconosciuti si intendono gli scenari di cui sei consapevole ma che non comprendi appieno, mentre scenari completamente sconosciuti si riferiscono a quegli scenari a te non noti e che non comprendi appieno. L'esecuzione di esperimenti su un carico di lavoro non funzionante non può fornire nuovi approfondimenti chiarificatori. L'esperimento deve infatti essere pianificato con attenzione, essere caratterizzato da un ambito ben definito relativamente al suo impatto, nonché fornire un meccanismo di rollback applicabile in caso di esiti negativi imprevisti. Se il criterio di due diligence indica che il carico di lavoro è in grado di sostenere l'esperimento, procedi ed esegui l'esperimento. Sono disponibili varie opzioni per l'inserimento degli errori. Per i carichi di lavoro su AWS, AWS FIS offre diverse simulazioni di guasto predefinite denominate operazioni. Puoi anche definire azioni personalizzate da eseguire utilizzando documenti. AWS FISAWS Systems Manager
È sconsigliato l'uso di script personalizzati per gli esperimenti di ingegneria del caos, a meno che gli script non siano in grado di rilevare lo stato corrente del carico di lavoro, generare log e fornire meccanismi di rollback e condizioni di arresto, laddove possibile.
Un framework o set di strumenti efficace che supporta l'ingegneria del caos deve tenere traccia dello stato corrente di un esperimento, generare log e fornire meccanismi di rollback a supporto dell'esecuzione controllata di un esperimento. Inizia con un servizio consolidato come AWS FIS questo, che ti consenta di eseguire esperimenti con un ambito ben definito e meccanismi di sicurezza che annullino l'esperimento se l'esperimento introduce turbolenze impreviste. Per ulteriori informazioni su una più ampia varietà di esperimenti di utilizzo AWS FIS, consulta anche il laboratorio Resilient and Well-Architected Apps
with Chaos Engineering. Inoltre, AWS Resilience Hub analizzerà il carico di lavoro e creerà gli esperimenti che potrai scegliere di implementare ed eseguire in AWS FIS. Nota
Per ogni esperimento, devi essere consapevole del suo ambito e del relativo impatto. È consigliabile eseguire la simulazione dell'errore in un ambiente non di produzione prima di eseguirla in un ambiente di produzione vero e proprio.
Gli esperimenti andrebbero eseguiti in produzione con un carico reale mediante distribuzioni canary
che attivano l'implementazione di sistemi sperimentali e di controllo, laddove possibile. L'esecuzione degli esperimenti durante gli orari non di punta è altamente consigliata al fine di ridurre al massimo potenziali eventi negativi durante la prima esecuzione dell'esperimento negli ambienti di produzione. Inoltre, se l'utilizzo dell'effettivo traffico clienti costituisce un rischio eccessivo, puoi eseguire gli esperimenti utilizzando una sintesi del traffico nell'infrastruttura di produzione utilizzando implementazioni sperimentali e di controllo. Se l'utilizzo di un ambiente di produzione non è possibile, esegui gli esperimenti in ambienti di pre-produzione il più simili possibile agli effettivi ambienti di produzione. Devi definire e monitorare i guardrail per essere sicuro che l'esperimento non abbia un impatto sul traffico di produzione o sugli altri sistemi che superi i limiti accettabili. Definisci condizioni di arresto per interrompere l'esperimento se viene raggiunta la soglia definita nella metrica del guardrail. In tali condizioni devono essere incluse le metriche relative allo stato stazionario del carico di lavoro e le metriche riferite ai componenti in cui inserisci l'errore. Un monitoraggio sintetico (definito anche canary utente) è una metrica che in genere deve essere inclusa come proxy utente. Le condizioni di arresto per AWS FIS sono supportate nel modello di esperimento, nella misura di un massimo di cinque condizioni di arresto per modello.
Uno dei principi dell'ingegneria del caos prevede la riduzione dell'ambito dell'esperimento e del relativo impatto.
Se da un lato deve essere prevista la possibilità di un determinato impatto negativo a breve termine, dall'altro il contenimento e la riduzione delle conseguenze negative degli esperimenti sono una responsabilità esclusiva dell'addetto all'ingegneria del caos.
Un metodo per verificare l'ambito e il potenziale impatto prevede l'esecuzione dell'esperimento dapprima in un ambiente non di produzione, la verifica che le soglie delle condizioni di arresto vengano attivate come previsto durante lo svolgimento di un esperimento e l'utilizzo effettivo delle misure di osservabilità finalizzate all'acquisizione di un'eccezione, anziché eseguire l'esperimento direttamente in produzione.
Durante l'esecuzione di esperimenti di iniezione di guasti, verifica che tutte le parti responsabili ne siano a conoscenza. Comunica ai team appropriati, ad esempio i team responsabili delle operazioni, dell'affidabilità dei servizi e del supporto clienti, quando verranno eseguiti gli esperimenti e l'impatto previsto. Metti a disposizione di questi team strumenti di comunicazione che consentano loro di informare i responsabili dell'esperimento di eventuali effetti avversi.
È necessario ripristinare lo stato originario del carico di lavoro e dei relativi sistemi sottostanti. La progettazione resiliente del carico di lavoro è spesso caratterizzata da funzionalità di riparazione automatica. Tuttavia, alcune progettazioni con difetti o alcuni esperimenti non riusciti possono compromettere in modo imprevisto lo stato del carico di lavoro. Entro la fine dell'esperimento dovrai essere consapevole di questa situazione e ripristinare il carico di lavoro e i sistemi. Con AWS FIS puoi impostare una configurazione di rollback (chiamata anche azione successiva) all'interno dei parametri dell'azione. Una post-operazione ripristina una destinazione allo stato in cui si trovava prima dell'esecuzione dell'operazione stessa. Che siano automatizzate (come l'utilizzo AWS FIS) o manuali, queste azioni relative ai post dovrebbero far parte di un manuale che descrive come rilevare e gestire gli errori.
-
Verifica l'ipotesi.
Principles of Chaos Engineering
fornisce le linee guida su come verificare lo stato stazionario del carico di lavoro. È necessario concentrarsi sull'output misurabile di un sistema e non sugli attributi interni del sistema. Le misurazioni di tale output in un breve periodo di tempo costituiscono un'attestazione dello stato stazionario del sistema. Il throughput del sistema nel suo complesso, le percentuali di errori e i percentili della latenza possono essere considerati metriche di interesse che rappresentano il comportamento di uno stato stazionario. Sulla base dei rilevamenti dei modelli di comportamento sistematico durante gli esperimenti, l'ingegneria del caos verifica che il sistema funzioni correttamente anziché tentare di convalidare il modo in cui funziona.
Nei due esempi precedenti sono state incluse le metriche dello stato stazionario relative a un incremento inferiore allo 0,01% di errori (5xx) lato server e inferiore a un minuto di errori di lettura e scrittura del database.
Gli errori 5xx rappresentano una buona metrica perché sono la conseguenza della modalità di errore che un client del carico di lavoro sperimenterà direttamente. La misurazione degli errori del database risulta valida come conseguenza diretta dell'errore, ma deve essere supportata da una misurazione diretta dell'impatto, ad esempio le richieste cliente non riuscite o gli errori restituiti a livello di client. Inoltre, includi un monitor sintetico (noto anche come user canary) su qualsiasi dispositivo del tuo carico di lavoro APIs o a cui accede URIs direttamente il client.
-
Migliora la progettazione del carico di lavoro con un occhio di riguardo per la resilienza.
Se lo stato stazionario non è stato preservato, analizza in che modo puoi migliorare la progettazione del carico di lavoro per azzerare l'impatto dell'errore applicando le best practice illustrate nel pilastro dell'affidabilità di AWS Well-Architected. Puoi trovare ulteriori informazioni nella AWS Builder's Library
, che offre, tra gli altri, articoli su come migliorare i controlli dell'integrità o impiegare nuovi tentativi con backoff nel codice dell'applicazione . Dopo aver implementato queste modifiche, esegui di nuovo l'esperimento (rappresentato dalla linea punteggiata nel volano relativo all'ingegneria del caos) per determinare la relativa efficacia. Se nella fase di verifica risulta che l'ipotesi è vera, il carico di lavoro sarà in stato stazionario e il ciclo continuerà.
-
-
Esegui gli esperimenti con regolarità.
Un esperimento di ingegneria del caos è un ciclo e gli esperimenti devono essere eseguiti regolarmente nell'ambito dell'ingegneria del caos. Se un carico di lavoro è conforme all'ipotesi dell'esperimento, l'esperimento deve essere automatizzato affinché venga eseguito continuamente come fase di regressione della pipeline CI/CD. Per scoprire come eseguire questa operazione, consulta questo blog su come eseguire AWS FIS esperimenti utilizzando
. AWS CodePipeline Poi fare pratica con questo lab sugli esperimenti AWS FIS ricorrenti in una pipeline CI/CD . Gli esperimenti di iniezione di guasti fanno inoltre parte delle giornate di gioco (consulta REL12-BP06 Conduci regolarmente giornate di gioco). Le giornate di gioco simulano un errore o un evento per verificare sistemi, processi e risposte dei team. Lo scopo è di eseguire effettivamente le azioni che compirebbe il team come se si verificasse un evento eccezionale.
-
Acquisisci e archivia i risultati degli esperimenti.
I risultati degli esperimenti di iniezione di guasti devono essere acquisiti e resi persistenti. Includi tutti i dati necessari, ad esempio orari, carico di lavoro e condizioni, in modo da essere in grado di analizzare i risultati e i trend in un secondo momento. Esempi di risultati potrebbero includere schermate di dashboard, CSV dump dal database della metrica o un record digitato a mano di eventi e osservazioni dell'esperimento. Puoi inserire la creazione di log degli esperimenti mediante AWS FIS nel processo di acquisizione dei dati.
Risorse
Best practice correlate:
Documenti correlati:
Video correlati:
Esempi correlati:
Strumenti correlati:
