Guida

Chaos engineering: misurare la resilienza e migliorare la sicurezza del cloud

Una tecnologia che nonostante non sia ancora matura è in grado di generare molti vantaggi come affidabilità, resilienza e sicurezza dei sistemi cloud computing.

Pubblicato il 17 Mag 2021

Gartner cloud security 2020

Applicare chaos engineering significa identificare vulnerabilità e punti deboli all’interno di un sistema inserendo volutamente errori secondo un approccio test-first. Lo scopo è rendere i sistemi più affidabili e misurare la resilienza. Pur essendo una tecnologia relativamente nuova, è stata inserita nel Hype Cycle 2020 da Gartner tra le innovazioni emergenti legate alla cloud security per la gestione della sicurezza e dei rischi. La sicurezza del cloud è alla base di una corretta strategia di cloud computing e l’uso combinato di chaos engineering è in grado di apportare dei vantaggi. Una combinazione che per gli analisti, come detto nel Gartner cloud security 2020, è solo all’inizio e con una previsione di crescita e diffusione tra i 5 e 10 anni.

Protagonista Gartner cloud security 2020 ecco cos’è e come nasce il chaos engineering

L’ingegneria del caos come approccio disciplinare permette di confrontare ciò che potrebbe accadere con ciò che accade. L’obiettivo non è aumentare caos, ma al contrario mitigarlo. Come? Testando proattivamente in che modo un sistema risponde sotto stress, per identificare e correggere bug, errori o guasti.

L’utilizzo di chaos engineering è stato introdotto per la prima volta da Netflix nel 2011 durante la supervisione della migrazione al cloud e da Google con i DiRT (Disaster Recovery Test).

I primi utilizzi più diffusi erano rivolti ad azioni semplici come l’eliminazione inaspettata di una macchina virtuale ma oggi, intorno a questa metodologia e al suo utilizzo concreto, c’è sempre più l’interesse della comunità IT dovuto anche dall’aumento dei processi di digitalizzazione e di migrazione al cloud.

Perché implementare chaos engineering

In passato, si eseguivano i sistemi software in ambienti on-premise altamente controllati e gestiti da amministratori di sistema. Oggi, con sistemi non più monolitici e sempre più strutturati in microservizi occorre resilienza di fronte ai diversi scenari come carichi imprevisti e interruzioni e ad eventi corner case, fuori dalla norma, causati anche da problemi di natura minore. Per aumentare la resilienza di questi sistemi, è emersa la disciplina dell’ingegneria del caos.

Lo stress test di un sistema con esperimenti caotici da errori casuali è in grado di rivelare un punto debole. Inoltre, la simulazione di condizioni avverse permette ai team IT e DevOps di integrare protezioni e meccanismi di risposta agli incidenti. Le infrastrutture IT richiedono sempre maggiore affidabilità anche perché i tempi di inattività sono costosi. Ogni downtime di un applicativo informatico non solo causa costi diretti, ma anche costi indiretti dovuti ai danni reputazionali per la mancata erogazione del servizio al cliente.

Quali sono i passaggi dell’ingegneria del caos?

L’ingegneria del caos implica l’esecuzione di esperimenti ponderati e pianificati che aiutano a comprendere come si comporta un sistema di fronte al fallimento.

La prima domanda da fare è: cosa potrebbe andare storto? da qui si parte per esaminare i potenziali punti deboli e discutere i risultati. Una modalità molto vicina alla valutazione del rischio.

Questi esperimenti seguono 3 passaggi:

  • Viene formulata un’ipotesi su come dovrebbe comportarsi un sistema quando qualcosa va storto. In pratica, si ipotizza in squadra cosa può andare storto e si discute sullo scenario e sul risultato atteso come primo punto.
  • Quindi, si progetta per testarlo nel proprio sistema. L’esperimento ha sempre un blast radius (raggio di esplosione) contenuto. E tale raggio man mano si allarga con il ripetersi in modo ciclico dell’esperimento. Ogni ciclo viene verificato.
  • Infine, si misura l’impatto in ogni fase, cercando segni di successo o fallimento per capire come si comporta un sistema sotto stress. Attraverso metriche si valutano prestazioni ma anche latenze ed effetti collaterali.

L’obiettivo è comprendere il comportamento del sistema. Questo sia che il sistema risulta resiliente al guasto introdotto sia quando c’è un problema da risolvere. Ogni risultato è sempre visto in positivo perché, da una parte aumenta l’affidabilità e dall’altra si riscontra un problema ancora prima che possa causare un’interruzione o un danno.

I vantaggi nell’utilizzo di chaos engineering

Nonostante sia una pratica ancora poco matura, molte realtà la considerano rischiosa. Al contrario e nonostante il nome che richiama appunto al caos, fornisce un approccio empirico in grado di apportare vantaggi. Infatti:

  • Mostra il debito tecnico ovvero le conseguenze come negligenza, errori di sviluppo, carenze nel codice.
  • Crea fiducia nei sistemi implementati e tra i team che contribuiscono a tali sistemi.
  • Identifica e crea integrazioni testabili e potenziali punti di errore.
  • Favorisce l’apprendimento basato sugli esperimenti: ogni test è utile per imparare ed implementare nuove conoscenze.
  • Fornisce una maggiore affidabilità e resilienza dei sistemi.

In sostanza, non solo garantisce disponibilità e durata del servizio senza alcuna interruzione, garantisce una minore vulnerabilità e può aiutare a prevenire perdite in termini di ricavi e costi di manutenzione per il business. Migliora la conoscenza e la formazione dei team, favorisce il loro benessere ed è utile nelle fasi di assistenza.

I benefici per i Team

Il benessere dei team DevOps o di infrastruttura merita di essere approfondito perché rappresenta un cambio di passo culturale. Adottare un approccio che mira a capire come è possibile evitare un errore equivale ad adottare una cultura del no-blaming sostituendola ad un sistema spesso accusatorio: perché hai sbagliato? perchè l’hai fatto? Questo significa avere team più felici e collaborativi meno stressati e sicuramente proattivi. Aspetto fondamentale in una visione in cui la centralità della persona migliora la qualità del lavoro.

Chaos experiment verso Testing del software

I test del caos non sono sostituibili con i più conosciuti testing. Infatti, il testing del software e la relativa fase di collaudo si basa su un aspetto fondamentale: parte da conoscenze note del sistema e corrisponde ad una fase di collaudo necessaria e generale per convalidare usabilità e correttezza dell’intero funzionamento.

Per i test di chaos engineering il discorso è diverso. Gli esperimenti vengono fatti su una porzione limitata del sistema e man mano dopo la verifica, si aumenta il raggio d’azione. Inoltre, si parte sempre da un’ipotesi e si va avanti fino a smentire quell’ipotesi formulata. Ogni punto debole è una novità da cui ripartire.

Chaos engineering: dalla sicurezza al business

Non è una tecnica di sicurezza ma è in grado di scoprire problemi di sicurezza. Risulta importante sottolineare che attraverso l’uso continuo è possibile sviluppare secondo la definizione di Gartner un “sistema immunitario digitale” all’interno di un’applicazione o di un sistema.

Ma come impatta sul business? Con l’ingegneria del caos si può ridurre al minimo, il tempo per il ripristino e il tasso di errore di modifica e il tempo in attività o di funzionamento in modo da ottenere una maggiore user experience per il cliente, una maggiore soddisfazione e fidelizzazione fino all’acquisizione di nuovi clienti.

Gartner stima nonostante ancora non sia una tecnologia matura, una penetrazione sul mercato dall’1% al 5% e attribuisce una valutazione alta ai diversi vantaggi che è in grado di generare.

Chi utilizza il chaos engineering

Le parti coinvolte in un esperimento di chaos engineering possono essere più o meno tante a seconda della grandezza o della natura del test stesso. Team DevOps e di sicurezza cloud per infrastruttura e la sicurezza degli endpoint, di controllo, di conformità. Lo scopo finale è misurare la resilienza, essere proattivi e rendere affidabile un qualunque sistema.

Molte grandi aziende tecnologiche praticano chaos engineering per comprendere meglio i loro sistemi distribuiti e le architetture di microservizi. Si tratta, per esempio, dei team di Netflix, LinkedIn, Facebook, Google, Microsoft, Amazon e molti altri. Ma anche in settori più tradizionali, come quello bancario e finanziario: ad esempio, la National Australia Bank è migrata dall’infrastruttura fisica a un web services e ha utilizzato chaos engineering per ridurre drasticamente il conteggio degli incidenti. Esistono diverse community dedicate.

Conclusioni

Il futuro vede lo sviluppo di chaos engineering sempre più incorporato nei processi di sviluppo e di test del sistema e come delineato nel Gartner cloud security 2020, utilizzato in modo continuo per aumentare robustezza e sicurezza. Per questo, sono necessari investimenti maggiori e più significativi da parte delle aziende. Uno degli obiettivo dovrebbe essere avere sistemi sempre più utili con un tempo di attività che si avvicini al 100%.

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati