IL TUO SISTEMA È PRONTO AL CHAOS?

Spingi i tuoi sistemi al fallimento, migliorali imparando dai risultati.

Non solo robustezza ma anche resilienza

COS’È IL CHAOS ENGINEERING?

Il Chaos Engineering è una pratica che aiuta i team IT ad individuare i punti deboli di applicazioni e infrastrutture attraverso l'immissione di fallimenti controllati nei sistemi. Si tratta di esperimenti mirati che permettono di creare fiducia nelle capacità dei sistemi di resistere a condizioni di funzionamento avverse o impreviste, migliorandone in modo proattivo resilienza ed affidabilità.

L'obiettivo del Chaos Engineering è di raccogliere informazioni su come i singoli componenti reagiscono quando uno di questi subisce un guasto. Gli incidenti accadono, non è possibile evitarne a priori ogni occorrenza o tipologia, ma bisogna ridurne frequenza ed impatto. È fondamentale essere preparati al disastro facendo propri i principi del Chaos Engineering, che vanno utilizzati non solo in ambito tecnologico ma anche su persone e processi.

PER ESEMPIO?

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.

QUALI SONO I 5 PASSAGGI PRINCIPALI DA SEGUIRE?

  • Definizione dello stato stazionario

    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.

  • Formulazione di una o più ipotesi

    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?”.

  • Progettazione ed esecuzione del test

    Partendo da una delle ipotesi fatte: è necessario definire un perimetro ben preciso per mantenere il controllo dell’esperimento. Il raggio d’azione deve essere inizialmente limitato al minimo possibile per evitare impatti non previsti. Durante il test vanno raccolti tutti i dati necessari alle successive analisi, quali metriche e log.

  • Verifica
    dell’ipotesi

    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.

  • Applicazione delle Fix

    L’output dell’analisi, in caso di fallimento, deve essere un elenco di azioni necessarie a migliorare il sistema, per poi rieseguire lo stesso esperimento. In caso di successo invece è possibile aumentare il raggio d’azione e ripetere l’esperimento con eventuali variazioni.

QUAL è LA PROPOSTA DI LIQUID REPLY

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.

Quali BENEFICI otteniamo da queste iniziative?

Il Chaos Engineering, unito alla potenza dell'osservabilità e del monitoraggio (https://www.reply.com/liquid-reply/it/SitePages/observability-by-design), 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 di rispondere a situazioni di stress, e reagire ai fallimenti utilizzando l’esperienza fatta durante gli esperimenti di Chaos Engineering.

CHALLENGE

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;

SRE & CHAOS ENGINEERING

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à.

CHAOS EXPERIMENT VS. SOFTWARE TESTING

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à.