Che cos’è l’Ingegneria del Caos e perché è importante?
Perché l’ingegneria del caos è importante? Vediamo innanzitutto perché esiste il Quality Assurance (QA).
Semplicemente, il QA esiste perché, non importa quanto ci impegniamo per creare software perfetti che fanno 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 intendevamo. Succede di tutto. L’ingegneria della qualità esiste per cercare di trovare questi problemi non intenzionali prima che lo facciano i nostri clienti.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Cos'è l’ingegneria del caos?
L’ingegneria del caos è un approccio rigoroso per identificare i potenziali guasti prima che si trasformino in veri e propri malfunzionamenti. Con l’ingegneria del caos si progettano esperimenti per iniettare errori e si confronta ciò che si pensa che accadrà con ciò che accade realmente nei sistemi. In pratica, si “rompe qualcosa intenzionalmente” per imparare come costruire sistemi più resilienti.
Perché l’ingegneria del caos è importante?
Perché i sistemi stanno cambiando. Tradizionalmente, il QA esegue una varietà di test e tipologie di test per individuare proattivamente questi problemi, molto prima che il codice finisca in produzione. Questi test vengono eseguiti alla fine di una build e prima che il codice venga pubblicamente distribuito, di solito in un ambiente di stage o di test rispetto al test in produzione.
Fin qui tutto bene, finché operiamo secondo un modello di sviluppo e distribuzione del software tradizionale. Design monolitici e deployment su macchine aziendali garantiscono un grande controllo. In questo controllo è intrinseca una certa stabilità. Ciò rende questi ambienti di stage e test simili a quelli di produzione e consente di effettuare test con successo.
I sistemi distribuiti sono diversi. Il cloud è diverso. Non controlliamo più l’infrastruttura. È in costante cambiamento. L’infrastruttura si modifica secondo il nostro design grazie ai singoli servizi, microservizi e al bilanciamento del carico che può attivare o disattivare nodi di calcolo in base alle necessità. I sistemi di failover si regolano da soli per garantire che i rischi siano gestiti. Il cambiamento continuo causa comportamenti imprevisti ed emergenti. Si tratta di comportamenti che non possiamo sempre prevedere, ma che possiamo riprodurre e provocare usando 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 potranno affrontare testando in un altro ambiente. Possiamo testare molte cose, quelle che il QA tradizionale esegue molto bene e dovrebbe continuare a fare, sebbene adesso alcune si possano automatizzare durante la pipeline di build. Tuttavia, il modo in cui si è sempre svolto il QA non è sufficiente per testare come il nostro sistema distribuito reagirà, per esempio, quando la rete tra uno storage e più nodi di calcolo è congestionata e cresce la latenza.
I nostri test automatizzati e manuali non tengono conto di questo ambiente produttivo in rapido cambiamento, in cui i servizi si avviano e si spengono in base alla richiesta. L’unico modo per verificare se un sistema distribuito rimarrà affidabile quando si verificano comportamenti emergenti, dovuti a condizioni produttive in mutamento, è fare ciò che prevedono tutti i paradigmi di test: provarci e vedere cosa succede.
Come funziona l’ingegneria del caos: testare e apprendere dal fallimento
Tutti abbiamo degli obiettivi di uptime. Tutti vogliamo migliorare le nostre prestazioni. Per farlo, dobbiamo utilizzare ogni risorsa disponibile per imparare tutto il possibile su come i sistemi gestiscono i guasti, che si tratti dell’errore dell’utente nell’inserire dati corretti in un campo di un modulo o di un componente cloud che non funziona come previsto.
“Cosa succede se...?” è una domanda che amiamo tutti porci. Poi, proviamo effettivamente e vediamo cosa accade.
Poiché i nostri sistemi e le nostre architetture si sono evolute in modo senza precedenti, dobbiamo evolvere anche i nostri metodi di testing per capire meglio come i sistemi distribuiti reagiranno ai guasti e come l’insorgenza di problemi ai componenti o alle dipendenze impatta sull’intero sistema. Un testing olistico di questo tipo è proprio ciò che l’ingegneria del caos si pone come obiettivo, perché permette di collaudare l’intero sistema così come esiste realmente in produzione.
Un programma di ingegneria del caos inizia in piccolo, testando cose che già sappiamo o crediamo di sapere:
- Il nostro sistema di monitoring rileva attivamente la latenza della rete oltre una certa soglia?
- Questo fa scattare una chiamata all’ingegnere di turno o un intervento automatico di mitigazione?
- La nostra configurazione si è modificata nel tempo o stiamo ancora avviando nuove macchine di calcolo secondo le specifiche?
Come si comporta ogni singola istanza del servizio con carichi leggeri? Medi? Pesanti? Dovrebbero comportarsi tutte allo stesso modo e il nostro sistema di bilanciamento del carico dovrebbe ripartire il traffico tra loro in modo appropriato. Cosa succede se un’istanza comincia a ricevere un carico notevolmente superiore rispetto alle altre perché il servizio di bilanciamento del carico ha problemi?
Il testing sistematico dei sistemi caotici porta benefici fondamentali
Testiamo utilizzando il metodo scientifico, iniziando in piccolo ed essendo intenzionali. Progettiamo i primi esperimenti in modo da minimizzare il raggio d’azione, ovvero l’insieme dei servizi e dei componenti che riteniamo possano essere impattati e per ridurre al minimo l’entità dei parametri sperimentali.
Una volta ottenuto successo in questa fase, possiamo decidere di costruire passo dopo passo, accrescendo la nostra fiducia nel sistema o ampliando il backlog prioritizzato degli interventi da apportare. Quando effettuiamo questi miglioramenti e ripetiamo i test utilizzando lo stesso esperimento di caos e gli stessi parametri, il sistema supererà la prova e sapremo che è più affidabile rispetto al passato.
Questo è l’unico modo per imparare come i nostri sistemi gestiscono effettivamente i guasti una volta in produzione, lì dove i nostri clienti vivranno in prima persona i risultati. Se riusciamo a individuare ora i piccoli problemi, prima che abbiano la possibilità di trasformarsi in grandi problemi a catena, possiamo assicurarci che si verifichino sempre meno guasti sistemici.
Questo rende l’ingegneria del caos uno strumento straordinario per l’affidabilità. Si tratta di una disciplina che ci aiuta a fare nel cloud e su larga scala ciò che prima potevamo permetterci solo in ambienti più piccoli e controllati, utilizzando il QA tradizionale.
In definitiva, ciò si traduce in meno guasti o interruzioni di produzione su larga scala. Infatti, quando l’ingegneria del caos viene implementata e utilizzata in modo costante, i guasti di servizi e componenti che ci si aspetterebbe avvengano nel caos del cloud non avranno alcun impatto sui nostri clienti. Anzi, non sapranno nemmeno che si è verificato un guasto, e questo è il vero obiettivo.
E adesso?
Ho parlato in modo più approfondito di ingegneria del caos nell’episodio del podcast The QA Lead insieme a Jonathon Wright.
Nota dell’editore:
Puoi rimanere 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 potrai condividere best practices con altri professionisti QA e ingegneri della qualità. Speriamo di vederti lì!
Approfondimento correlato: I 10 MIGLIORI SOFTWARE PER QUALITY ENGINEERING: GUIDA COMPLETA
