L'ingegneria del caos, ovvero come rompere i sistemi per renderli indistruttibili

L'incubo di ogni membro di un team IT è sicuramente il crash del server. In caso di blackout elettrico, di connessione Internet mancata o di un virus che termina processi casualmente. In realtà ci sono anche altri problemi che sono davvero comuni tra gli sviluppatori: fare il deploying di una release con un bug notato subito dopo, trovare un bug critico in uno stack complesso da modificare, e così via.

In Netflix conoscono bene questa paura e durante la transizione dai server proprietari al cloud di Amazon Web Services, il team IT ha pensato di costruire un processo, chiamato Chaos Monkey, che consiste nel tenere sotto stress i server e gli applicativi in modo da renderli resilienti nelle occasioni più difficili.

A descrivere questo processo è Jason Yee, Technical Evangelist di DataDog durante un talk del Cloud Conf 2019.

"Eseguendo Chaos Monkey nel bel mezzo di un giorno lavorativo, in un ambiente accuratamente monitorato con ingegneri pronti ad individuare qualsiasi problema, possiamo sempre imparare quali sono le debolezze del nostro sistema, e costruire meccanismi di recupero automatico in grado di contrastarle.
In questo modo, la prossima volta che una macchina va in crash alle 3 di mattina di domenica, non ce ne accorgeremo nemmeno."

Analizzando questo estratto dal blog tech di Netflix, Jason descrive nel dettaglio quali sono i passi da compiere per eseguire questo tipo di test, facendo anche una demo durante il talk.
Secondo Jason, il processo deve essere diviso in 3 fasi, così come durante una partita di calcio: i primi 30 minuti si pianifica e ci si studia, i 50 minuti dopo si gioca davvero e gli ultimi 10 minuti si fanno i conti del lavoro svolto.

Allo stesso modo, c'è bisogno di un team estremamente specializzato e focalizzato: un esperto degli oggetti del test, un Site Reliability Engineer e un junior developer.

Before

Nella prima fase, che si potrebbe semplicemente definire 'Before', bisogna:

• pianificare un orario di svolgimento;
• selezionare il tipo e numero di test, cominciando dal più facile;
• scrivere in un foglio di testo cosa ci si aspetta che succeda e cosa ci si aspetta nel caso nel cose non vadano come previsto;
• condividere il foglio testo.

During

Nella seconda fase invece, che si potrebbe definire 'During', bisogna:

• spostare la release sulla versione di produzione;
• annunciare l'inizio del test nella chat di gruppo (Slack, Teams, HipChat, etc.). Deve essere chiaro che l'annuncio è stato effettuato, in modo da evitare eventuali conflitti tra colleghi successivamente;
• mantenere attiva la discussione nella chat di gruppo;
• monitorare eventuali crash;
• eseguire il test e prendere nota.

Nello specifico, le procedure che possono essere eseguite come test sono le seguenti (dal meno complesso al più disastroso):

• 0. Termina il servizio. Blocca l'accesso ad una dipendenza.
• 1. Blocca l'accesso a tutte le dipendenze.
• 2. Termina l'host.
• 3. Degrada l'ambiente di sviluppo.
• 4. Crea degli spike nel traffico.
• 5. Termina il cloud/server regionale.

È importante tenere a mente almeno le seguenti domande quando si verifica un crash:

• Dovrei ricevere un alert?
• Il sito dovrebbe essere irraggiungibile comunque?
• Dovrebbe presentarsi una pagina specifica durante la navigazione?

After

Nell'ultima fase, quella che avviene dopo il test, che si potrebbe chiamare 'After', bisogna poi:

• creare schede/ticket per tenere traccia dei problemi che hanno bisogno di essere risolti;
• scrivere un piccolo report e delle lezioni chiave apprese;
• mandare una mail a tutto il reparto IT;
• celebrare!

Sembra superfluo, ma alcune cerimonie sono importanti per stimolare lo sviluppo continuo, come ad esempio la celebrazione di un test ben riuscito e per una release completata. I bug e gli errori sono sempre dietro l'angolo: meglio godersi le piccole vittorie, una alla volta.