Che cos’è l’Ingegneria del Caos e perché è importante?
Perché l’ingegneria del caos è importante? Vediamo innanzitutto perché esiste il Quality Assurance (QA).
In poche parole, il QA esiste perché, nonostante tutti i nostri sforzi per creare software perfetti che facciano sempre ciò per cui sono stati progettati e dovrebbero fare, il mondo reale sembra non permetterlo.
Gli errori si insinuano. Le macchine interpretano il nostro codice in modo diverso da come avevamo previsto. Succede di tutto. L’ingegneria della qualità esiste per cercare di individuare questi problemi involontari prima che lo facciano i nostri clienti.
Vuoi di più da The CTO Club?
Crea un account gratuito per completare questo articolo e unirti a una comunità di CTO e leader ingegneristici che condividono framework, strumenti e approfondimenti reali per progettare, implementare e scalare tecnologie guidate dall'IA.
Have an account? Log In
Che cos’è l’ingegneria del caos?
L’ingegneria del caos è un approccio sistematico per identificare i potenziali malfunzionamenti prima che diventino interruzioni. Con l’ingegneria del caos si progettano esperimenti di iniezione dei guasti e si confronta ciò che si pensa accadrà con ciò che accade realmente nei sistemi. Si arriva letteralmente a “rompere le cose di proposito” per imparare a costruire sistemi più resilienti.
Perché l’ingegneria del caos è importante?
Perché i sistemi cambiano. Tradizionalmente, il QA esegue una varietà di test e di tipologie di test per individuare proattivamente questi problemi, molto prima che il codice finisca in produzione. Questi test vengono eseguiti al termine di una build e prima che quel codice venga distribuito pubblicamente, normalmente in un ambiente di staging o di test rispetto al test in produzione.
Fin qui tutto bene, se operiamo secondo un modello di sviluppo e distribuzione software tradizionale. I design monolitici e le distribuzioni su macchine di proprietà aziendale offrono un grande controllo. Questa stabilità intrinseca permette che gli ambienti di staging e test siano simili agli ambienti di produzione e consente che il testing abbia successo.
I sistemi distribuiti sono diversi. Il cloud è diverso. Non controlliamo l’infrastruttura. È in continuo cambiamento. L’infrastruttura cambia in base ai nostri progetti, con servizi individuali, microservizi, bilanciamento del carico che avvia nuovi nodi di calcolo o li rimuove secondo necessità. I sistemi di failover si adattano per assicurare la gestione dei rischi. Questo cambiamento continuo genera comportamenti inaspettati ed emergenti. Sono comportamenti che non possiamo sempre prevedere, ma che possiamo riprodurre e causare utilizzando una forma di testing chiamata ingegneria del caos.
Il testing deve adattarsi al cambiamento dei sistemi
Non possiamo testare efficacemente tutto ciò che il nostro codice di produzione e l’ambiente incontreranno, utilizzando qualsiasi altro ambiente di test. Possiamo sicuramente testare molte cose, quelle che il QA tradizionale gestisce bene e dovrebbe continuare a fare, magari ora anche tramite automazione lungo la build pipeline. Tuttavia, il modo in cui abbiamo fatto QA finora non può testare come reagirà il nostro sistema distribuito quando, ad esempio, la rete tra un data store e più nodi di calcolo viene sovraccaricata e la latenza aumenta.
I nostri test automatizzati e manuali non tengono conto di questo ambiente di produzione in rapido cambiamento, dove i servizi si attivano e si disattivano a seconda della domanda. L’unico modo per verificare se un sistema distribuito rimarrà affidabile quando si verificano comportamenti emergenti a causa delle condizioni di produzione che cambiano è seguire ciò che fanno tutti i paradigmi di test: provare e vedere il risultato.
Come funziona l’ingegneria del caos: testare e imparare dagli errori
Tutti abbiamo obiettivi di uptime. Tutti vogliamo migliorare le nostre prestazioni. Per farlo, dobbiamo utilizzare ogni risorsa disponibile per imparare il più possibile su come i nostri sistemi gestiscono i fallimenti, che si tratti del mancato inserimento, da parte di un utente, di dati idonei in un campo di un modulo o di un componente del sistema nel cloud che non funziona come previsto.
“Cosa succede se…?” è una domanda che tutti amiamo porci. Poi proviamo e scopriamo cosa succede.
Poiché i nostri sistemi e le nostre architetture si sono evoluti in modo senza precedenti, dobbiamo a nostra volta evolvere i metodi di testing per capire meglio come i nostri sistemi distribuiti funzioneranno in caso di guasti e come i problemi di componenti e dipendenze impattino sull’intero sistema. Un testing olistico di questo tipo è esattamente ciò che l’ingegneria del caos si propone di fare perché è in grado di testare tutto il sistema così come si trova in produzione.
Un programma di ingegneria del caos inizia in piccolo, testando cose che già sappiamo o crediamo di sapere:
- Il nostro sistema di monitoraggio rileva attivamente la latenza di rete sopra una certa soglia?
- Questo genera un avviso all’ingegnere di turno o magari attiva una mitigazione automatica?
- La nostra configurazione si è modificata nel tempo o stiamo ancora avviando nodi di calcolo secondo le specifiche?
Come si comporta ciascuna istanza di servizio sotto un carico leggero? E sotto un carico medio? Pesante? Dovrebbero tutte reagire allo stesso modo e il nostro bilanciamento del carico dovrebbe distribuire il carico tra di esse in modo appropriato. Cosa succede se un'istanza inizia a ricevere un carico significativamente maggiore rispetto alle altre perché il nostro servizio di bilanciamento del carico sta avendo problemi?
Il test sistematico dei sistemi caotici porta benefici fondamentali
Testiamo utilizzando il metodo scientifico, partendo in piccolo ed essendo intenzionali. Progettiamo gli esperimenti iniziali per minimizzare il raggio d'azione, cioè l'insieme di servizi e componenti che riteniamo possano essere impattati, e per ridurre al minimo la magnitudo dei parametri dell'esperimento.
Una volta ottenuto il successo in questa fase, possiamo decidere di costruire passo dopo passo, aumentando la nostra fiducia nel sistema o aumentando la lista di miglioramenti prioritari che implementeremo. Quando apportiamo questi miglioramenti e rieseguiamo i test utilizzando lo stesso esperimento di caos e parametri, il sistema supererà la prova e sapremo che è più affidabile rispetto a prima.
Questo è l'unico modo per imparare come i nostri sistemi gestiscono effettivamente i guasti nell'ambiente di produzione, dove saranno poi i nostri clienti a sperimentarne i risultati. Se riusciamo a trovare ora i piccoli problemi, prima che possano trasformarsi in grandi criticità, possiamo assicurarci che si verifichino sempre meno guasti sistemici.
Questo rende la Chaos Engineering uno strumento straordinario per la resilienza. È una disciplina che ci aiuta a fare nel cloud e su larga scala ciò che prima riuscivamo a fare in ambienti più piccoli e controllati con il QA tradizionale.
Questo significa, in ultima analisi, meno incidenti e interruzioni su larga scala in produzione. Infatti, quando la Chaos Engineering viene implementata e utilizzata con costanza, i guasti di servizi e componenti che ci si dovrebbe aspettare nel caos del cloud non avranno alcun impatto sui nostri clienti. Anzi, non si accorgeranno nemmeno che c'è stato un problema, e questo è il vero obiettivo.
E ora?
Ho parlato di chaos engineering in modo più approfondito nell'episodio del podcast The QA Lead con Jonathon Wright.
Nota della redazione:
Puoi restare aggiornato su altri podcast e articoli di The QA Lead iscrivendoti alla newsletter.
Puoi anche diventare membro per accedere al forum della community di The QA Lead, dove puoi condividere le best practice con altri QA e ingegneri della qualità. Speriamo di vederti lì!
Lettura correlata: I 10 migliori strumenti software per quality engineering: guida completa
