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à.

Ciclo di vita dell'esperimento di ingegneria del caos continuo

Come discusso nella sezione precedente, è possibile implementare esperimenti di ingegneria del caos in diversi modi. In tutti i casi, la chiave per creare un esperimento di caos efficace è comprendere l'applicazione, gli incidenti storici e le soluzioni implementate, nonché comprendere chiaramente le aree su cui indagare, come la resilienza o la sicurezza. Le conoscenze acquisite sull'applicazione consentono di formulare un'ipotesi sui potenziali punti deboli dell'applicazione e di comprendere in che modo l'applicazione rileverà, correggerà e ripristinerà l'errore.

Il ciclo di vita del Chaos Experiment include le seguenti fasi:

Questi passaggi sono illustrati nel diagramma e discussi nelle sezioni seguenti.

Definisci gli obiettivi e stabilisci le aspettative

Prima di ogni esperimento, assicurati che i tuoi obiettivi e le tue aspettative siano specifici, misurabili, raggiungibili, pertinenti e limitati nel tempo. Definisci chiaramente quanto segue:

Seleziona l'applicazione di destinazione

L'ingegneria del caos è una tecnica potente, ma richiede un'attenta definizione delle priorità per massimizzare il valore. Quando decidete dove concentrare le vostre attività di ingegneria del caos, iniziate a considerare i servizi essenziali della vostra azienda. Chiedete ai vostri team di ripetere le fasi del ciclo di vita dello sviluppo del software e iniziate innanzitutto a inserire errori negli ambienti di test. Le applicazioni aziendali critiche sono direttamente legate ai ricavi, all'esperienza del cliente e alle operazioni principali. Gli esperimenti sul caos condotti su questi servizi possono scoprire vulnerabilità che possono avere gravi ripercussioni sull'organizzazione, e potenzialmente su interi mercati, se non vengono risolte. Ad esempio, concentrati innanzitutto sui servizi rivolti ai clienti, come i sistemi di trading o i sistemi di ordinazione. Dare priorità a questi servizi centrali offre la massima protezione per ogni investimento di tempo.

Dopo i servizi critici, esamina i componenti fondamentali come database, code di messaggi, reti e servizi condivisi. APIs Questi potrebbero essere usati come componenti o servizi condivisi in tutta l'organizzazione, quindi il loro fallimento causerebbe problemi diffusi. La conferma della resilienza dei servizi di infrastruttura offre la certezza che non comprometteranno le applicazioni dipendenti che li sovrastano. Ad esempio, un esperimento di ingegneria del caos che smonta un cluster Kafka rivela molto sulla tolleranza ai guasti delle applicazioni downstream. Sebbene l'infrastruttura di sistema non sia direttamente rivolta ai clienti, è un obiettivo primario dell'ingegneria del caos.

Non dimenticate di mappare le lacune mentali relative a persone, processi, informazioni sulle strutture e dipendenze da terze parti, poiché queste possono causare gravi interruzioni se non sono in linea con gli obiettivi di tolleranza all'impatto dell'organizzazione. Per ulteriori informazioni sulla misurazione del ROI dell'ingegneria del caos, leggi Quantificare il ROI dell'ingegneria del caos nel documento strategico Investire nell'ingegneria del caos come necessità strategica.

Il diagramma seguente mostra il ritorno sull'investimento derivante dall'esecuzione di esperimenti sul caos su diversi livelli di servizi.

Allinea le mappe mentali (scoperta delle applicazioni)

Quando esegui esperimenti ad hoc o giornate di gioco, inizierai il processo di scoperta dell'applicazione organizzando una sessione sulla lavagna incentrata sulla mappatura dei dettagli dell'applicazione. (Se esegui gli esperimenti nella pipeline del caos, avrai già allineato quella mappa mentale definendo l'applicazione di destinazione.) Un buon approccio per comprendere le lacune mentali consiste nel chiedere al membro del team più giovane di disegnare prima un diagramma della domanda, e poi chiedere ai membri dello staff più senior di aggiungerlo progressivamente al diagramma. Questo permetterà di scoprire eventuali lacune di comprensione tra i diversi livelli di esperienza.

Il diagramma dovrebbe illustrare sia le dipendenze dirette a monte che quelle a valle dell'applicazione, nonché eventuali integrazioni critiche di terze parti. Assicurati che vi sia un allineamento sul flusso previsto di una richiesta tramite l'applicazione. Mappa i flussi di lavoro e i percorsi degli utenti chiave per avere più chiarezza su come i clienti utilizzano l'applicazione. Prendi in considerazione l'utilizzo di un diagramma di sequenza per acquisire queste informazioni.

Dopo questa sessione collaborativa, il team dovrebbe disporre di un modello mentale condiviso dell'applicazione, delle sue dipendenze critiche e delle sue capacità di monitoraggio, nonché di una comprensione dei rischi necessari per prendere una decisione informata se procedere o annullare un potenziale esperimento di caos.

Risolvete i problemi noti dell'applicazione

Gli esperimenti di Chaos Engineering sono progettati per far emergere in modo proattivo i difetti di un'applicazione. Inserendo errori come aumenti della latenza, riavvii del server o interruzioni dell'alimentazione della zona di disponibilità, è possibile verificare la capacità dell'applicazione di tollerare interruzioni realistiche. Tuttavia, questo processo presuppone un livello di stabilità e integrità di base nell'applicazione di destinazione. Eseguire esperimenti di caos su un'applicazione già problematica rischia di mascherare problemi più profondi.

Prima di intraprendere l'ingegneria del caos, i team devono risolvere eventuali difetti, bug e problemi di prestazioni noti nella loro applicazione.

Definisci l'ipotesi e l'esperimento

Gli incidenti passati che hanno causato interruzioni dell'applicazione o di altre applicazioni all'interno dell'organizzazione possono costituire un'ottima fonte di idee per sperimentare il caos. Ad esempio, le interruzioni precedenti sono state causate da errori di configurazione o dalla mancanza di modelli di resilienza? Rivedere le cronologie degli incidenti e ripercorrere le cause profonde di questi fallimenti nel mondo reale attraverso esperimenti sul caos è un modo efficace per sviluppare la resilienza contro problemi simili in futuro.

Un'altra preziosa fonte di concetti sperimentali può provenire direttamente dagli ingegneri, dagli architetti e dagli operatori che hanno più familiarità con un'applicazione. Consentire ai membri del team di presentare ipotetici scenari di errore che ritengono possano compromettere in modo significativo l'applicazione consente di raccogliere idee basate su conoscenze privilegiate. Il team addetto all'applicazione può quindi valutare quale di questi scenari proposti potrebbe avere il maggiore impatto potenziale o esporre i maggiori rischi sconosciuti. Intraprendere esperimenti di caos mirati a scenari così rischiosi e meno compresi può generare importanti insegnamenti e prevenire problemi futuri.

Una terza fonte di idee proviene dall'esecuzione di modelli di resilienza per anticipare le condizioni che porterebbero a perdite aziendali identificate. Alcuni esercizi di modellizzazione della resilienza hanno un approccio basato sui componenti per la creazione di un modello di resilienza, mentre altri hanno un approccio basato sui sistemi. Un approccio basato sui componenti pone la domanda: «Cosa succede quando il componente x è sottoposto a un carico estremo o è guasto?» Il team che sviluppa il modello di resilienza ipotizza quindi l'effetto di tale scenario sull'applicazione più ampia e identifica i controlli di monitoraggio e prevenzione attualmente in atto per rilevare e mitigare gli effetti dello scenario. In alternativa, un approccio basato sui sistemi segue un processo dall'alto verso il basso per evidenziare uno stato indesiderato dell'applicazione, ad esempio «La vetrina web mostra livelli di inventario obsoleti», e invita il team dell'applicazione a prevedere quale condizione o condizioni indurrebbero l'applicazione a comportarsi in questo modo.

Garantite la prontezza operativa per l'esperimento

Sono necessari indicatori quantificabili per misurare l'impatto delle condizioni avverse sull'applicazione e sul suo comportamento, come descritto in precedenza nella sezione sull'osservabilità. La possibilità di misurare il comportamento dell'applicazione consente di determinare se le condizioni avverse hanno influito sull'applicazione e in che misura.

Il modo migliore per capire se c'è un impatto sull'applicazione è misurarne lo stato stazionario. Lo stato stazionario misura l'aspetto del normale funzionamento e in genere si allinea agli indicatori di esperienza aziendale e del cliente per una determinata applicazione. Prima di passare alla fase successiva, assicuratevi di disporre dell'osservabilità necessaria per comprendere l'impatto e di disporre dei meccanismi di rollback nel caso in cui l'esperimento non si risolva come previsto.

Esegui esperimenti e scenari controllati

Noi AWS sconsigliamo di condurre un esperimento iniziale basato sul caos su un'applicazione in produzione. Lo scopo di un esperimento basato sul caos è imparare qualcosa di nuovo sul comportamento dell'applicazione in condizioni di stress. Il comportamento dell'applicazione potrebbe essere imprevedibile durante l'esperimento, quindi eseguire un esperimento per la prima volta in produzione potrebbe avere conseguenze sul cliente. Pertanto, dovreste sempre eseguire un esperimento iniziale basato sul caos in un ambiente di livello inferiore con un potenziale minimo di impatto sugli utenti del mondo reale, e quindi ripetere l'analisi degli ambienti dopo aver verificato e aver avuto la certezza che l'applicazione sia in grado di assorbire, adattarsi e riprendersi dalle azioni iniettate.

Pianificate accuratamente ogni esperimento utilizzando un documento che riporti i dettagli chiave, simile al documento di pianificazione dell'esperimento fornito nell'appendice. Alcuni dei campi critici da includere sono la definizione dello stato stazionario, l'ipotesi e il metodo di iniezione in caso di guasto. La pianificazione, l'esecuzione e l'analisi di un esperimento di caos possono essere incluse in un unico artefatto.

Dopo aver finalizzato il piano scritto per l'esperimento, preparate il codice necessario per inserire le interruzioni pianificate descritte nel documento.

Per cogliere il potenziale impatto durante l'esperimento, assicuratevi che siano presenti meccanismi di osservabilità. Se non disponete ancora di un metodo automatizzato per acquisire i risultati degli esperimenti, ad esempio i report degli AWS FIS esperimenti, identificate i membri del team che prenderanno appunti durante l'esecuzione, acquisite schermate delle dashboard e guidate il team durante l'esperimento.

Impara e perfeziona

Dopo ogni esperimento, riunitevi in squadra per rivedere e riflettere sull'esperimento del caos. Sforzatevi consapevolmente di mantenere una mentalità irreprensibile. Il vostro obiettivo dovrebbe essere quello di instaurare un dialogo aperto e costruttivo che si concentri interamente sulla massimizzazione dell'apprendimento e non sull'attribuzione di colpe.

Inizia esaminando la definizione e l'ipotesi dello stato stazionario per l'esperimento. L'applicazione si è comportata come previsto? Ci sono state sorprese che hanno invalidato le ipotesi? Discutete le osservazioni su come l'applicazione ha reagito durante l'esperimento, sia positive che negative. I dati raccolti (metriche, registri, schermate e così via) dovrebbero raccontare esattamente cosa è successo.

Affrontate questa revisione dei dati con curiosità anziché con giudizio e individuate le aree in cui è possibile apportare miglioramenti alla progettazione delle applicazioni, alla documentazione, al monitoraggio o ad altre funzionalità basate sulle conoscenze acquisite. Queste azioni vengono raccolte come progetti successivi per rendere l'applicazione più resiliente.

Grazie a questo approccio irreprensibile, puoi avere conversazioni sincere su cosa è andato storto e su come risolverlo. Presumete l'intenzione positiva di tutte le persone coinvolte e abbiate fiducia nel fatto che stessero lavorando per ottenere buoni risultati. Il vostro obiettivo condiviso è la crescita e la progressione organizzativa attraverso l'apprendimento e l'adattamento continui. Le revisioni degli esperimenti Chaos, condotte in modo costruttivo e irreprensibile, offrono al team uno spazio sicuro in cui acquisire informazioni preziose che rendono le applicazioni e l'organizzazione più affidabili e resilienti a lungo termine. L'attenzione rimane sugli apprendimenti, non sulle persone. Per diffondere le conoscenze tra i tuoi team, pubblica il rapporto sui risultati dell'esperimento in una posizione centrale e pubblicizza i risultati in modo che altri possano trarne vantaggio.