Che cos'è il caos engineering?

Ogni giorno c'è il rischio che un'applicazione o un'infrastruttura critica di un'organizzazione non funzionino, minacciando potenzialmente la sua capacità di fornire servizi ai clienti. Le cause di malfunzionamento possono variare tra diversi problemi, come violazioni della sicurezza, configurazioni errate o interruzioni del servizio. La probabilità di errori o interruzioni aumenta di pari passo con l'aumento delle applicazioni e dei dati ospitati nel cloud, che può creare maggiori problemi di sicurezza.

Un modo per affrontare le interruzioni è il chaos engineering. Non si tratta di un processo casuale in cui gli ingegneri interrompono le istanze o i servizi o altrimenti causano il malfunzionamento dei sistemi senza alcuno scopo. Questo processo identifica i potenziali problemi futuri, consentendo ai team di ingegneria di risolvere i problemi in modo proattivo e di evitarli nell'ambiente live più avanti nel tempo.

Il chaos engineering è importante perché errori o interruzioni possono rallentare lo slancio di un'organizzazione, facendo perdere tempo prezioso per trovare una soluzione rapidamente mentre i tempi di inattività aumentano. Netflix ha imparato questo concetto in prima persona quando è passata dal sistema on-premise al cloud¹: ha sperimentato un guasto che ha portato a un'interruzione di tre giorni della fornitura del servizio nel 2008.

Questa interruzione precede la trasformazione in un'operazione di streaming video, il che avrebbe reso il guasto stesso immensamente più costoso. Di conseguenza, Netflix ha deciso che avrebbe fatto tutto il possibile per ridurre al minimo le interruzioni e ha iniziato a introdurre il chaos engineering nei suoi workflow. Questo processo consente di identificare i problemi prima che si verifichino e di minimizzare i danni se e quando si verifica un guasto inevitabile.

Netflix ha creato chaos monkey², uno strumento open source che crea errori casuali nei servizi e nelle infrastrutture IT destinato a identificare i punti deboli che possono essere corretti o risolti tramite procedure di ripristino automatiche. Hanno implementato chaos monkey durante lo spostamento da un data center privato ad Amazon Web Services (AWS) in risposta all'inaffidabilità del cloud. Molte organizzazioni ora usano chaos monkey per eseguire i loro esperimenti di chaos engineering.

Il chaos engineering è una difesa importante contro i guasti dell'infrastruttura, le interruzioni o i componenti mancanti nell'ambiente di produzione di un'organizzazione. Aiuta i tecnici dell'affidabilità del sito (SRE) e gli altri membri del team DevOps a fornire una fornitura continua di servizi evitando interruzioni significative del loro servizio. Il chaos engineering li aiuta a comprendere meglio le vulnerabilità e informa su come minimizzare l'impatto in caso di interruzione.

Anche un piccolo problema nel codice può avere un effetto catastrofico sull'ambiente di produzione complessivo, date le varie dipendenze del programma. Ad esempio, un errore nel sistema software delle transazioni di una società di servizi finanziari può comportare la perdita di milioni di dollari³.

Forse le organizzazioni non sono in grado di evitare tutti gli incidenti IT, ma possono ridurre al minimo i danni utilizzando il chaos management per comprendere gli scenari probabili e le migliori soluzioni possibili.

È consigliabile che le organizzazioni con elevata resilienza, maturità digitale e alta osservabilità attraverso dashboard e altri strumenti adottino il chaos engineering per intervenire immediatamente sui problemi che si verificano attraverso gli esperimenti. Le organizzazioni che mancano di questa osservabilità⁴ possono impiegare troppo tempo per risolvere gli esperimenti che creano attraverso il chaos engineering.

Il chaos 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.

Inoltre, l'aumento dell'uso dei microservizi, che aumenta il numero di host o container in esecuzione in un sistema, crea sfide uniche 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 chaos engineering aiutare le organizzazioni a migliorare anche la velocità delle loro pipeline di integrazione continua e di consegna continua (CI/CD). Incorporare il chaos engineering nella CI/CD, come ha fatto Netflix⁶, consente alle organizzazioni di automatizzare gli esperimenti continui controllando al contempo il loro 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 chaos 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 indurre guasti al disco, terminare processi, arrestare un host o introdurre 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.
• Canary testing: si tratta del rilascio di un nuovo prodotto o funzionalità per un piccolo gruppo di utenti. Così, eventuali malfunzionamenti 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 chaos 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 chaos 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 chaos 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 chaos engineering automatizzando gli esperimenti, che richiederebbero troppo lavoro se condotti manualmente. Ciò riduce parte del carico sui team IT durante il processo di chaos 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 al di fuori 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 chaos engineering devono decidere se utilizzare i test di caos nei propri ambienti di produzione o pre-produzione. Esistono diversi motivi per cui il chaos 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. Inoltre potrebbe non avere le 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 scelgono quale ambiente utilizzare in base alla loro tolleranza al rischio. In definitiva, il chaos engineering mira a testare problemi reali su larga scala, motivo per cui gli ambienti di produzione forniscono il quadro più accurato di ciò che sta accadendo e di ciò che deve essere risolto.

Il caos engineering offre alle organizzazioni diversi vantaggi chiave.

I clienti hanno grandi aspettative riguardo alla disponibilità dei servizi che acquistano dalle aziende. Qualsiasi downtime o incapacità di accedere a quanto hanno pagato può avere un effetto serio sulla soddisfazione del cliente, portando a una perdita di entrate e danni alla reputazione. I sistemi di test e l'identificazione delle soluzioni riducono il rischio che un sistema sia inattivo per un lungo periodo di tempo.

Le interruzioni possono derivare da codice errato, problemi al server o minacce esterne. Quest'ultimo può colpire anche con pratiche di sicurezza eccellenti. Il chaos engineering aiuta a identificare i problemi che possono essere sfruttati, in modo che le organizzazioni possano introdurre patch e correzioni di bug per mantenere i loro servizi sicuri.

Il chaos engineering consente alle organizzazioni di creare un progetto più informato su come affrontare i problemi che si presenteranno in futuro. Le organizzazioni che adottano il chaos engineering avranno piani di intervento specifici per molti incidenti, consentendo una riparazione più rapida e tempi di inattività ridotti. Il chaos engineering può ridurre i tempi di inattività⁷ di oltre il 20%.

Gli esperimenti di caos engineering identificano il modo in cui un sistema alloca le risorse. L'introduzione degli esperimenti dimostrerà in che modo il sistema gestisce i carichi, mostrando dove sono o dove è probabile che si verifichino i colli di bottiglia.

Il caos engineering aiuta i team a creare maggiore resilienza e flessibilità del sistema nel proprio software. Pertanto, le organizzazioni possono affrontare la codifica di nuovi software e soluzioni in modo più intelligente, perché sanno come il sistema attuale gestisce i problemi.