)
Spingi i tuoi sistemi al fallimento, migliorali imparando dai risultati. Non solo robustezza ma anche resilienza
Il Chaos Engineering consente ai team IT di identificare i punti deboli di sistemi e applicazioni simulando guasti controllati. Attraverso esperimenti mirati, migliora resilienza e affidabilità, riducendo l’impatto degli incidenti inevitabili. L’obiettivo è comprendere come i componenti reagiscono ai guasti e prepararsi a condizioni impreviste, applicando questi principi anche a processi e persone per un approccio più completo alla gestione del rischio.
La natura ci insegna come un vaccino istruisce il sistema immunitario con uno stress controllato, preparandolo a fronteggiare il virus, riducendone o annullandone l'effetto potenzialmente devastante. Così, con l’applicazione della metodologia direttamente in ambienti di produzione, si procede a scollegare dalla rete un database o a spegnere una delle istanze di un servizio in alta affidabilità, oppure a perturbare la comunicazione di rete tra due componenti per capire come mitigare un problema simile nel caso avvenga inaspettatamente.
)
Basandosi sul monitoraggio è possibile identificare e documentare i valori di alcune metriche riepilogative che rappresentano lo stato normale di corretto funzionamento di un’applicazione/servizio.
)
Su come dovrebbe comportarsi il sistema quando qualcosa va storto: è necessario che tutto il team si riunisca per porsi le domande “What if?”; ad esempio “Quali sono le possibili conseguenze se il servizio X cade?”.
)
Partendo da una delle ipotesi fatte: è necessario definire un perimetro ben preciso per mantenere il controllo dell’esperimento. Durante il test vanno raccolti tutti i dati necessari alle successive analisi.
)
I dati e i risultati ottenuti rispetto all’ipotesi iniziale. Si cercano segni di successo o fallimento nelle eventuali differenze dallo stato stazionario riscontrate durante e dopo l’esecuzione del test.
)
L’output dell’analisi, in caso di fallimento, deve essere un elenco di azioni necessarie a migliorare il sistema. In caso di successo invece è possibile aumentare il raggio d’azione e ripetere l’esperimento.
Liquid Reply guida le iniziative di grandi realtà bancarie italiane che hanno deciso di fare propria questa strategia, formando i team non solo IT e DevOps, ma anche Business. Tutti i settori dell’azienda vengono coinvolti e sono a conoscenza dei principi del Chaos Engineering, per poterli applicare gradualmente alle proprie infrastrutture, applicazioni, procedure e persone.
Nei cantieri aperti, Liquid Reply sta ottenendo risultati interessanti. Partendo da piccoli esperimenti mirati, al cliente è permesso di capire quanto valore può portare questo nuovo modo di operare, che predilige la prevenzione ed il sondaggio attivo, complementari all'analisi statica e al test del software.
Liquid Reply supporta i clienti in tutte le fasi dell’adozione del Chaos Engineering: dalla formazione teorica alla selezione degli strumenti, dalla progettazione degli esperimenti all' analisi dei risultati. Attraverso approccio e metodologia consolidate nel tempo, disegna assieme ai propri clienti soluzioni ad-hoc nel contesto di riferimento. Li accompagna nella valutazione e comprensione delle evidenze per migliorare i processi di gestione degli incidenti minimizzando i costi legati al disservizio e l'eventuale esperienza negativa per gli utenti finali.
Il Chaos Engineering, unito alla potenza dell'osservabilità e del monitoraggio , consente di:
- ridurre il tempo medio di rilevamento (Mean Time to Detection - MTTD) e il tempo medio di risoluzione (Mean Time to Resolution - MTTR) portando al minimo i tempi di inattività;
- evitare le violazioni dei Service Level Agreement;
- limitare l'impatto negativo sul business di eventi imprevisti;
La potenzialità della disciplina è di portare tutta l’infrastruttura ad un livello di affidabilità tale da sentirsi confidenti nello spegnere un’intero datacenter, o qualsiasi cosa sia considerata ad elevato impatto per l’azienda. Allo stesso tempo le persone saranno in grado dirispondere a situazioni di stress, ereagire ai fallimentiutilizzando l’esperienza fatta durante gli esperimenti di Chaos Engineering.
.
Nonostante sia una pratica ancora poco matura, molte realtà la considerano rischiosa: spesso durante l’adozione del Chaos Engineering nelle aziende è necessario far fronte a blocchi culturali; come ad esempio la paura che il simulare disastri sia una perdita di tempo, dato che solitamente i team sono già pieni di lavoro per sistemare le rotture.
Molti sono restii a sbilanciare gli ambienti di produzione per effettuare i test, nonostante siano gli unici con il carico adeguato perché questi abbiano dei risultati utili. C’è inoltre la preoccupazione che la pratica del Chaos Engineering potrebbe far emergere che le infrastrutture su cui molto si è investito (microservizi, layer di bilanciamento, componenti orientati alla scalabilità) potrebbero non essere così robuste a situazioni che si discostano da quanto è stato preventivato in fase di analisi e sviluppo; l’approccio empirico sarebbe indicativamente in grado di mostrare il debito tecnico ovvero le conseguenze come negligenza, errori di sviluppo, carenze nel codice.
Il Chaos Engineering però:
• crea fiducia nei sistemi implementati e tra i team che contribuiscono a tali sistemi;
• identifica integrazioni testabili e potenziali punti di errore;
• favorisce l’apprendimento basato sugli esperimenti: ogni test è utile per acquisire ed implementare nuove conoscenze;
• garantisce una maggiore affidabilità e resilienza dei sistemi;
Le organizzazioni hanno realizzato quanto sia cruciale per il business garantire l'affidabilità dei propri asset tecnologici. La necessità di rimanere al passo con il time-to-market e con l'evoluzione delle tecnologie, sta accelerando il cambiamento di applicazioni e infrastrutture, con il conseguente aumento della complessità di gestione.
In quest'ambito si rivela quindi fondamentale ridurre i fallimenti dei sistemi IT e diminuirne i danni economici derivati.
Negli ultimi anni la gran parte delle aziende che basano la propria affidabilità e i propri servizi ai clienti su sistemi informativi ha adottato l'approccio SRE (Site Reliability Engineering), che mira ad automatizzare i processi DevOps per gestire i sistemi e risolvere le criticità.
Oggi Liquid Reply sta integrando e potenziando questa pratica con l'introduzione del Chaos Engineering nella loro quotidianità.
I test di resilienza non sono sostituibili con il più conosciuto testing del software.
Unit test, smoke test e performance test, anche se utilizzati in ambienti diversi, vengono effettuati quando lo stato del sistema sottostante è stazionario. Questi test corrispondono a fasi di collaudo specifiche per convalidare usabilità e correttezza funzionale e non-funzionale dell’applicazione.
I test che la pratica del Chaos Engineering mette in atto non vengono necessariamente effettuati su una singola applicazione o servizio, ma su una determinata porzione del sistema.
La differenza sostanziale con i test del software risiede nel principio che sta alla base della disciplina: rompere consapevolmente pezzi del sistema.
Gli esperimenti di Chaos infatti mirano a disturbare o disattivare determinati componenti e verificarne le conseguenze; non a verificare che l’applicazione riesca a portare a termine un compito specifico o in un determinato modo, sotto stress o per periodi prolungati. È necessario sottolineare che questi due diversi tipi di test possono essere eseguiti congiuntamente per unirne le potenzialità.