È consigliabile che le organizzazioni con elevata resilienza, maturità digitale e alta osservabilità attraverso dashboard e altri strumenti adottino il caos engineering per intervenire immediatamente sui problemi che si verificano attraverso gli esperimenti. Le organizzazioni che non dispongono di questa osservabilità⁴ (link esterno a ibm.com) possono impiegare troppo tempo per risolvere gli esperimenti che creano attraverso il caos engineering.

Il caos engineering è un must anche per le organizzazioni che utilizzano il cloud, in particolare il quello pubblico, e app cloud-native. Il cloud pubblico introduce potenziali problemi di interruzione che richiedono il coordinamento con il provider, il che comporta un approccio diverso rispetto alla gestione dei problemi on-premise. 

Secondo Constellation Research⁵, le aziende che utilizzano il cloud spesso affrontano ancora gli incidenti IT senza considerare il modo in cui il cloud e il Software-as-a-Service (SaaS) influiscono diversamente su tali incidenti. (link esterno a ibm.com) 

Inoltre, l'aumento dell'uso dei microservizi, che aumenta il numero di host o container in esecuzione in un sistema, crea sfide uniche (link esterno a ibm.com) che possono essere scoperte e risolte attraverso esperimenti di caos. Questo sposta le complessità dalla progettazione del codice alle operazioni di sistema, il che non elimina le complessità ma consente una maggiore automazione.

Il caos engineering aiutare le organizzazioni a migliorare anche la velocità delle loro pipeline di integrazione continua e di consegna continua (CI/CD). Incorporare il caos engineering nelle CI/CD, come ha fatto Netflix⁶ (link esterno a ibm.com), Consente alle organizzazioni di automatizzare gli esperimenti continui, controllandone al contempo l'impatto potenziale. 

Infine, il fatto che le organizzazioni siano sempre più connesse con i partner tramite API significa che un problema nei sistemi può avere un impatto a effetto domino su altre organizzazioni.

L’implementazione del caos engineering aiuta le organizzazioni a comprendere i punti deboli della loro architettura e a correggerli, creando in definitiva la capacità di anticipare i guasti futuri. Un caos engineering di successo aiuta le organizzazioni a ridurre al minimo i problemi tecnici con un impatto significativo sui clienti, e supporta anche la costruzione di architetture di sistema complesse più forti e resilienti. Una volta che un'organizzazione decide di perseguire il caos engineering, il passaggio successivo consiste nel determinare se eseguirlo nell'ambiente di pre-produzione o di produzione.

I team DevOps hanno diverse opzioni per eseguire esperimenti di caos engineering per testare vari processi di sistema.

• Immissione di latenza: i team DevOps creano intenzionalmente scenari che emulano una connessione di rete lenta o difettosa, che include l’introduzione di ritardi di rete o tempi di risposta più lenti.
• Immissione di guasti: comporta l'introduzione intenzionale di errori nel sistema per determinare come influisce su altri sistemi dipendenti e se interrompe i servizi. Esempi di immissioni di guasti includono l'induzione di errori al disco, l'interruzione dei processi, l'arresto di un host o l'introduzione di aumenti di potenza o temperatura. Le immissioni di guasti possono aiutare le organizzazioni a identificare eventuali singoli punti di guasto che possono causare il malfunzionamento dell'intero sistema.
• Generazione del carico: si riferisce allo stress intenzionale del sistema, raggiunto inviando i livelli di traffico significativi ben oltre le normali operazioni. Questo aiuta i Site Reliability Engineers (SRE) a capire eventuali colli di bottiglia nel sistema, che a loro volta consentono di costruire sistemi più scalabili. 
• Test canary: comporta il rilascio di un nuovo prodotto o funzionalità per un piccolo gruppo di utenti. In questo modo, eventuali problemi tecnici o bug influenzeranno solo una percentuale di visitatori, lasciando al resto del pubblico l'accesso all'esperienza del sito web esistente.

La creazione del processo di caos engineering ideale richiede diversi principi per garantire che un'organizzazione possa avere un sistema distribuito su larga scala. 

• Comprendere il sistema: implica una conoscenza completa del sistema olistico, delle sue proprietà e funzioni emergenti e di topologia, architettura, dipendenze, comportamento allo stato stabile, risposta in uscita e caratteristiche come disponibilità, latenza e velocità effettiva.
  
• Accettare il fallimento: inizialmente, sembra paradossale che gli ingegneri del software permettano che si verifichi un incidente, quando esistono proprio per prevenire tali eventi. Tuttavia, le interruzioni si verificheranno sempre nei servizi IT, ed è meglio sperimentarle in un ambiente controllato per identificare la soluzione in anticipo, anziché dopo ore, se il team dell'organizzazione è fuori servizio o non ha mai riscontrato quel problema specifico.
• Stabilire un comportamento in stato stabile: innanzitutto, il team di progettazione deve definire come deve comportarsi il sistema quando funziona correttamente, in modo da poter confrontare l'impatto degli esperimenti rispetto a tale stato stabile.
• Identificare gli incidenti del mondo reale: gli esperimenti di caos engineering devono avvicinarsi il più possibile a ciò che potrebbe accadere in un giorno qualunque, invece di creare situazioni improbabili. Guasti alla rete e all'infrastruttura, codice errato, problemi di alimentazione e sovraccarico del traffico sono potenziali eventi.
• Creare una giornata di simulazione: il caos engineering può studiare l'ambiente in una giornata di simulazione, in cui vengono eseguiti più test durante un unico giorno per massimizzare le risorse e identificare e risolvere quanti più problemi possibile. 
• Utilizzare l’automazione: le organizzazioni di tutte le dimensioni possono utilizzare il caos engineering automatizzando gli esperimenti, che richiederebbero troppo lavoro se condotti manualmente. Ciò riduce parte del carico sui team IT durante il processo di caos engineering. La progettazione degli esperimenti, l'immissione dei guasti e il provisioning dell'infrastruttura sono tutti aspetti della sperimentazione che le organizzazioni possono automatizzare.
• Fare attenzione alla portata dell'impatto: un caos engineer deve fare molta attenzione per ridurre al minimo la portata dell'impatto, in modo che il danno effettivo per i clienti sia il minore possibile. Alcuni modi per ridurre al minimo la portata dell'impatto sono:
  • Puntare su un sottoinsieme di servizi: il caos engineering, soprattutto in un contesto di produzione, non deve interrompere in modo sostanziale il servizio di un'organizzazione. Se si tratta di un sottoinsieme specifico di servizi, l'impatto di un incidente può essere ridotto al minimo, garantendo che non si verifichi un blocco dell'intero sistema.
  • Eseguire l'esperimento per un tempo stabilito: l'esperimento deve avere un inizio e una fine. Lo scopo dell'esperimento è creare un incidente e risolverlo, non quello di lasciarlo proseguire senza controllo per un lungo periodo.
  • Eseguire l'esperimento lontano dai picchi di traffico: le organizzazioni devono evitare di eseguire esperimenti durante i periodi di picco, a meno che non stiano cercando specificamente di valutare in che modo l'elevata capacità influisce sul sistema durante un incidente. 
  • Eseguire l'esperimento nell'ambiente di sviluppo: il modo più semplice per garantire che nessun cliente subisca interruzioni del servizio è eseguirlo nell'ambiente di pre-produzione. Tuttavia, ciò significa che le condizioni saranno diverse da quelle dell'ambiente di produzione, fornendo potenzialmente un'immagine errata di ciò che sta accadendo. Per ridurre al minimo questo problema, assicurati che gli ambienti di pre-produzione e di produzione siano il più simili possibile. 
  • Sperimentare su ogni componente: la sperimentazione del caos non finisce mai, perché il sistema di un'organizzazione è in continua evoluzione. Un altro obiettivo dovrebbe essere quello di testare "tutto": esaminare tutti i componenti, gli strati, i servizi e le loro dipendenze durante il processo.

Le organizzazioni che utilizzano il caos engineering devono decidere se utilizzare i test di caos nei propri ambienti di produzione o pre-produzione. Esistono diversi motivi per cui il caos engineering è più vantaggioso se applicato agli ambienti di produzione. Gli ambienti dal vivo forniscono l'ambiente più accurato per comprendere l'impatto di un incidente sull'esperienza del cliente. Un altro motivo è che l'ambiente di pre-produzione potrebbe non avere le impostazioni definitive dell'ambiente dal vivo, introducendo quindi una certa variabilità negli esperimenti.

Ad esempio, un incidente in un ambiente di pre-produzione potrebbe non creare una risposta realistica perché non ha gli stessi livelli di traffico dell'ambiente dal vivo e potrebbe non avere le sue stesse configurazioni di sicurezza. 

Alcune organizzazioni hanno paura di causare intenzionalmente problemi al loro sito dal vivo, quindi eseguono i loro esperimenti sul sito di pre-produzione o di sviluppo. Ciò garantisce che eventuali problemi non influiscano sull'esperienza del cliente dal vivo. Per mitigare questo problema, alcune organizzazioni iniziano in ambienti di pre-produzione per gestire il processo prima di passare all'ambiente di produzione dal vivo.

Le organizzazioni sceglieranno quale ambiente utilizzare in base alla loro tolleranza al rischio. In definitiva, il caos engineering mira a testare problemi reali su larga scala, motivo per cui gli ambienti di produzione forniranno il quadro più accurato di ciò che sta accadendo e di ciò che deve essere risolto.