La complessità dei sistemi informatici
Microservizi e architetture cloud distribuite stanno rendendo lo sviluppo per il web sempre più complesso. Creare sistemi affidabili è la vera sfida di noi sviluppatori moderni, e individuare le debolezze di questo genere di sistemi è sempre più difficile.
Come se non bastasse, tutti noi ormai dipendiamo in maniera diretta da questi servizi, nessuno escluso. Ma è possibile stimare il costo dei guasti causati da queste debolezze? Le interruzioni dei servizi danneggiano gli utilizzatori dei servizi che cercano, per esempio, di fare acquisti, o transazioni di qualsiasi genere. Anche interruzioni di breve durata — che poi bisognerebbe definire il significato di “breve”… — possono avere un impatto sui profitti di un’azienda, al punto che questi costi di “fermo macchina” stanno diventando dei KPI importanti per molti team di ingegneri.
Nel 2017, il 98% delle organizzazioni ha dichiarato che una singola ora di fermo macchina sarebbe costata alla propria azienda oltre centomila dollari! [1]. L’amministratore delegato di British Airways ha recentemente spiegato come un solo guasto che ha bloccato decine di migliaia di passeggeri British Airways nel maggio 2017 sia costato all’azienda 80 milioni di sterline.
Uno degli strumenti che molte aziende stanno sempre più adottando per fronteggiare questa sfida è quello del Chaos Engineering.
C’era una volta
Per capire di cosa si tratta, vediamo una breve panoramica storica, che ci consentirà di comprendere le ragioni e le motivazioni alla base di una scelta tecnologica come quella di cui stiamo parlando.
Le prime a introdurre Chaos Engineering fra i propri strumenti sono state infatti le aziende che operano prevalentemente in Internet, essendo state pioniere del sistema distribuito su larga scala. Questi sistemi sono così complessi che richiedono un nuovo approccio per testare debolezze e quindi, eventuali guasti. Ma proviamo a partire dall’origine per cercare di capire come e dove è nato Chaos Engineering.
1564-1642
Galileo Galilei è stato il primo a introdurre il metodo scientifico, o metodo sperimentale. È la modalità con cui, tutt’oggi, la scienza procede per raggiungere una conoscenza della realtà che sia quanto più possibile oggettiva, affidabile, verificabile e condivisibile.
Il metodo scientifico consiste nella raccolta di dati empirici secondo determinate ipotesi formulate, e nell’analisi rigorosa, logico-razionale e/o matematica ove possibile, di questi dati, aggiungendo, come lui stesso per primo enunciò, le “sensate esperienze” alle “dimostrazioni necessarie”.
Sempre restando fra i grandi del passato, lo stesso Albert Einstein enunciò
Nemmeno un gran numero di esperimenti riuscirà a provare che io abbia ragione, laddove invece un singolo esperimento sarà in grado di farmi capire che la mia ipotesi è sbagliata.
Questa frase è stata poi ripresa da Amir Ghahnrai e rivista in chiave più da sviuppatore:
No amount of testing can prove software right; a single test can prove software wrong.
2000
Jesse Robbins, fondatore e CEO di Orion Labs, quando lavorava in Amazon era soprannominato “Master of Disaster”, ed è praticamente colui che ha applicato, se così possiamo dire, Chaos Engineering al nostro mondo. Rifacendosi alla sua esperienza di Vigile del Fuoco, e ai metodi di addestramento — è qui potremmo partire con una altra discussione a me molto cara… — nella sua attività volontaria al di fuori del suo lavoro in Amazon, creò “Game Day”.
In pratica si tratta di strumenti che avevano lo scopo di preparare i sistemi Amazon a essere pronti in caso di guasto. Per “sistema” J. Robbins intende server, network, applicazioni e, soprattutto, persone, sostenendo che
Non sei tu a scegliere il momento, ma è il momento che sceglie te. Tu puoi solo scegliere come essere preparato quando sarà il momento.
2010
Il team degli ingegneri do Netflix crea Chaos Monkey. Chaos Monkey fu creato in risposta alla scelta di Netflix di spostarsi dalla propria infrastruttura fisica al cloud, in particolare su Amazon, e alla necessità di essere sicuri che un guasto di qualsiasi istanza e/o risorsa su Amazon non influenzasse l’esperienza dell’utente finale del servizio di streaming di Netflix stessa.
2011
Nasce Simian Army. Simian Army aggiunge ulteriori modalità di iniezione dei guasti a Chaos Monkey che non consentirebbe di testare una suite completa di stati di guasto, e quindi di costruire la resilienza anche a quelli. L’obiettivo di Simian Army, e di Netflix in primis, è semplice:
Il cloud è tutta una questione di ridondanza e di tolleranza ai guasti. Poiché nessun singolo componente può garantire il 100% di uptime [… e] anche l’hardware più costoso prima o poi si guasta […] è necessario progettare un’architettura Cloud in cui i singoli componenti possano guastarsi senza compromettere la disponibilità dell’intero sistema.
2012
Netflix rende pubblico il codice di Chaos Monkey su GitHub [2], affermando di
aver scoperto che la miglior difesa contro i grandi fallimenti inaspettati è quella di fallire spesso. Causando fallimenti frequenti, costringiamo i nostri sviluppatori a progettare servizi in un modo che siano più resilienti.
2014
Sempre Netflix introduce la nuova figura del Chaos Engineer. Il termine è stato coniato da Bruce Wong, e Dan Woods lo ha condiviso via Twitter. Dan Woods ha dichiarato
Ho imparato più cose sul Chaos Engineering da Kolton Andrus che da chiunque altro; lui lo chiamava test di iniezione dei guasti.
Nell’ottobre del 2014, mentre il co-fondatore di Gremlin, Kolton Andrus, era a Netflix, il suo team ha annunciato il Failure Injection Testing (FIT), un nuovo tool costruito sui concetti base di Simian Army, ma che fornisce agli sviluppatori un maggior controllo sul blast radius del guasto iniettato.
Gli strumenti di Simian Army erano stati così efficaci che in alcuni casi il raggio d’azione della loro azione aveva generato problematiche interruzioni di servizio facendo crescere diffidenza sul suo utilizzo in molti sviluppatori in Netflix. Grazie alla FIT gli sviluppatori hanno maggior controllo sulla portata del fallimento iniettato in modo da poter verificare sul campo le teorie, e gli esperimenti, del Chaos Engineering, ma mitigandone i potenziali lati negativi.
Definizione
La definizione di Chaos Engineering secondo i Principles of Chaos Engineering [3] è:
Il Chaos Engineering è la disciplina che si occupa di sperimentare su un sistema in maniera da costruire la sicurezza che il sistema abbia la capacità di fronteggiare condizioni di turbolenza in produzione.
In sintesi, lo scopo del Chaos Engineering è di fornire prove delle debolezze del sistema. Attraverso esperimenti scientifici di Chaos Engineering è possibile testare le debolezze del sistema che forniscono indicazioni su come il sistema potrebbe rispondere a condizioni di produzione turbolente. Queste debolezze a volte vengono chiamate Dark Debt.
Dark Debt
Quest “debito oscuro” si trova in sistemi complessi e le anomalie che genera sono guasti complessi del sistema. Il Dark Debt non è riconoscibile al momento della creazione, e il suo impatto non è quello di impedire lo sviluppo, ma di generare anomalie a run time.
Non esiste una contromisura preventiva specifica che possa essere utilizzata contro il Dark Debt, proprio perché esso non è visibile fino a quando un’anomalia, dovuta a una particolare circostanza, non ne rivela la sua presenza.
Chaos Engineering esiste proprio per aiutarci a far emergere le prove della presenza del Dark Debt, in modo che possiamo affrontare la sua sfida, e correre ai ripari, prima che diventi un problema per il sistema che stiamo rilasciando.
Dove si trova il Dark Debt?
Il dark Debt può essere ovunque nel nostro sistema, ma alle origini, i tool di Chaos Engineering tendevano a focalizzare la ricerca sull’infrastruttura del sistema stesso.
Chaos Monkey, ad esempio, è riconosciuto come il primo tool focalizzato sulle capacità di esplorare il modo in cui un sistema risponderebbe allo spegnimento di una macchina virtuale in modo incontrollato e causale.
Ma ci sono almeno altre tre aree di fallimento da considerare quando si esplora la potenziale debolezza di un sistema
- la piattaforma
- le applicazioni
- le persone e i processi
Il Dark Debt può influire su una o più di queste aree, in modo isolato o con un effetto composito. Perciò, quando esploreremo il sistema alla ricerca di eventuali debolezze da far emergere, dovremo esplorarlo nel suo insieme, in quello che viene definito l’intorno sociotecnico.
Cosa succede se già conosciamo le debolezze?
La risposta è molto semplice: non abbiamo bisogno di nessun tool di Chaos Engineering, ma semplicemente dobbiamo dare precedenza assoluta al trovare soluzioni che mettano al riparo il nostro sistema da queste debolezze.
Tuttavia è bene ricordare che noi spesso usiamo il termine “conosciamo” quando in realtà intendiamo più “sospettiamo fortemente”, oppure “crediamo che”; e allora un esperimento di Chaos Engineering ci potrebbe aiutare a far emergere le eventuali debolezze, oppure a dimostrare che ci sbagliamo, proprio come un test che diventa verde.
Sistema sociotecnico
Ho accennato prima all’aspetto sociotecnico del sistema, ma cosa si intende veramente con questo termine? Chaos Engineering non si occupa soltanto degli aspetti tecnici del nostro sistema software, ma incoraggia anche l’esplorazione dell’intero sistema sociotecnico, ossia anche del comportamento delle persone coinvolte e delle loro interazioni con il sistema stesso.
È solo in fase di produzione che il nostro sistema è sottoposto alle più ostili sollecitazioni, e non ci sono test che ci possono aiutare a pre-sottoporlo a interferenze esterne che ne possano causare un malfunzionamento o, peggio, l’interruzione. L’approccio del Chaos Engineering è l’opposto di quello di un normale test. Invece di cercare di evitare i guasti, Chaos Engineering li abbraccia.
Il processo del Chaos Engineering
Applicare il Chaos Engineering non significa letteralmente liberare una scimmia nella nostra sala server, lasciarla libera di distruggere tutto ciò che le aggrada, e verificare se il nostro sistema è ancora in grado di funzionare. Il Chaos Engineering comporta l’esecuzione di esperimenti ponderati che ci insegnano il modo in cui i nostri sistemi si comportano di fronte ai guasti.
Per raggiungere l’obiettivo questi esperimenti seguono tre fasi
- Pianficazione di un esperimento: ossia, la creazione di un’ipotesi. “Sappiamo come reagirebbe il sistema se …?”.
- Contenere il raggio d’esplosione (Blast Radius): Eseguiamo il più piccolo dei test che sia in grado di fornirci delle risposte… non vi suona un po’ familiare? Può trattarsi di un Game Day, o di un esperimento automatizzato.
- Scale or squash: Trovato il problema? Ottimo! Lavoro ben fatto e obiettivo raggiunto. In alternativa, aumentiamo il raggio d’azione fino a raggiungere la scala completa.
Come risultato di un Game Day, o di un esperimento automatico, avremo una raccolta di osservazioni che forniscono la prova dell’esistenza di uno o più punti deboli e che dovrebbero essere considerati come candidati al miglioramento.
Conclusioni
Abbiamo fatto in questo articolo una panoramica sul Chaos Engineering che ci consente di iniziare a intravvedere alcuni innegabili benefici di questa pratica apparentemente “distruttiva”. Scoprire le debolezze nascoste nel nostro sistema e capirne la loro natura, non solo tecnologica, è fondamentale per ottenere sistemi sempre più sicuri e resilienti.
Nel prossimo numero ci occuperemo di dare uno sguardo ad alcuni aspetti pratici del Chaos Engineering.
Riferimenti
[1] How Much Does 1 Hour of Downtime Cost the Average Business?
https://www.randgroup.com/insights/cost-of-business-downtime/
[2] Il codice di Chaos Monkey su GitHub
https://github.com/Netflix/chaosmonkey
[3] Principles of Chaos Engineering
https://principlesofchaos.org/?lang=ENcontent