In che modo “l’ingegneria del caos” ti aiuta a evitare tempi di inattività non pianificati

pannello switch di rete network
asharkyu/Shutterstock.com

L’ingegneria del caos è un approccio al test della tolleranza agli errori del software che provoca intenzionalmente errori nelle distribuzioni live. Incorpora un elemento di casualità per imitare l’imprevedibilità della maggior parte delle interruzioni del mondo reale.

L’idea di aggiungere caos a un sistema è generalmente attribuita a Netflix. Nel 2011, l’azienda pubblicato Chaos Monkey, uno strumento che ha creato per disabilitare parti della sua infrastruttura di produzione. Inducendo guasti casuali in ambienti monitorati, Netflix ha scoperto che poteva scoprire problemi nascosti che passavano inosservati durante i test regolari.

L’ingegneria del caos fornisce un effetto di risposta immunitaria. È simile a come si vaccinano le persone sane. Introduci intenzionalmente una minaccia, che potrebbe causare problemi brevi ma osservabili, al fine di sviluppare una resistenza più forte a lungo termine.

Costruire la resilienza

È lecito ritenere che qualsiasi sistema sufficientemente grande contenga bug di cui non si è a conoscenza. Nonostante tutti i tuoi test automatizzati e l’utilizzo quotidiano nel mondo reale, non puoi catturare tutto. Alcuni problemi emergono solo in scenari molto specifici, come la perdita di connettività a un servizio di terze parti.

L’ingegneria del caos accetta che i problemi operativi imprevisti saranno sempre un dato di fatto, anche in ambienti di produzione apparentemente a tenuta stagna. Mentre molte organizzazioni finiscono per adottare un approccio “aspetta e vedi”, giocando a whack-a-mole quando arrivano i rapporti reali, l’ingegneria del caos funziona sul principio che una breve interruzione che si invoca è sempre meglio di quella che il cliente vede per prima.

Rompere le cose di proposito ti dà un modo per determinare la resilienza complessiva del tuo sistema. Cosa succede se il database non funziona? Che ne dici di un’interruzione del servizio di invio di e-mail di terze parti? La più grande forza dell’ingegneria del caos è la sua capacità di riprodurre eventi che i test unitari e l’uso nel mondo reale da soli di solito non coprono.

Gli strumenti di test del caos vengono spesso eseguiti su implementazioni reali per eliminare le discrepanze tra gli ambienti di sviluppo e produzione. Tuttavia, non è necessario applicare così tanti rischi: se si è certi di poter replicare accuratamente la propria infrastruttura, è possibile utilizzare la tecnica contro un ambiente di staging sandbox.

Aggiungi caos ai tuoi sistemi

Hai più opzioni se desideri aggiungere un po’ di caos alla tua infrastruttura. Strumenti automatizzati costruito per questo scopo fornisce un punto di partenza ma può essere difficile da incorporare nella propria infrastruttura. Normalmente devi integrarti con VM o piattaforme di gestione dei container in modo che lo strumento possa interagire con le tue istanze.

Nel caso di Chaos Monkey, devi usare Spinnaker, la piattaforma di distribuzione continua di Netflix. Sebbene abbia un’ampia compatibilità con i più diffusi provider di cloud pubblico, è anche un’altra dipendenza che stai aggiungendo al tuo stack.

Se stai usando Kubernetes, kube-scimmia prende i principi originali di Netflix e li impacchetta per l’uso nel tuo cluster. Funziona su base opt-in, quindi le risorse Kubernetes con il kube-monkey/enabled l’etichetta sarà ammissibile per la terminazione casuale.

Pumba fornisce funzionalità simili per i normali contenitori Docker. Può provocare arresti anomali dei container, stressare le risorse disponibili come CPU e memoria e causare errori di rete.

Uno strumento che mira specificamente agli errori di rete è Shopify’s Tossiproxy. Ciò fornisce un proxy TCP che simula un’ampia gamma di condizioni di rete. Puoi filtrare il traffico della tua applicazione tramite Toxiproxy per vedere come funziona il sistema con una latenza grave o una larghezza di banda ridotta.

Per un controllo avanzato, Mangle di VMWare è un “orchestratore di ingegneria del caos” che si rivolge a diversi meccanismi di distribuzione. Funziona con Kubernetes, Docker, VMware vCenter e connessioni SSH generiche. Mangle ti consente di definire errori personalizzati per i componenti dell’applicazione e dell’infrastruttura. Gli errori dell’applicazione dovrebbero interessare un singolo servizio. Gli errori dell’infrastruttura prendono di mira i componenti condivisi che potrebbero disattivare più servizi.

Sebbene l’ingegneria del caos sia più comunemente associata allo sviluppo di backend e DevOps, c’è un crescente interesse anche tra gli ingegneri di frontend. Reagire al caos è una libreria che genererà errori casuali dai componenti di React, permettendoti di identificare sezioni dell’interfaccia utente traballanti che potrebbero bloccare l’intera app.

Progettare i propri esperimenti di caos

Se non riesci a utilizzare con successo uno strumento di caos open source, progetta invece i tuoi esperimenti. Fai un elenco dei presupposti all’interno dell’ambiente della tua applicazione. Identifica le connessioni tra i servizi e pensa a cosa accadrebbe se uno abbandonasse.

Devi quindi verificare la tua ipotesi. Rompi il sistema e osserva le conseguenze. Quindi, determinare se l’effetto era accettabile. L’app si è arrestata in modo anomalo e ha visualizzato una traccia dello stack per l’utente? Oppure ha mostrato una pagina di stato di interruzione e ha inviato per e-mail la traccia dello stack al personale di guardia?

È importante mantenere ogni test piccolo e concentrato. Ciò limita l’impatto in caso di interruzione della produzione e aiuta a essere sicuri che il problema derivi dall’ipotesi testata, non da un’altra parte del sistema.

Assicurati sempre di avere una procedura di ripristino chiara prima di condurre manualmente un esperimento di caos. Elevare un’interruzione provocata a un’interruzione attiva e non pianificata è l’ultima cosa che vuoi. Se stai terminando un servizio, tieni presente il tempo necessario per riavviarlo. Potrebbero esserci impatti a catena sulla tua applicazione durante interruzioni più lunghe: se abbandoni un servizio di distribuzione di posta elettronica, potrebbe esserci un arretrato su cui lavorare quando torna online. Questi aspetti devono essere incorporati nel tuo piano d’azione prima di iniziare a lavorare.

Al termine dell’esperimento, potrebbe essere necessario aggiornare il sistema prima di eseguire nuovamente il test. Testare la tua correzione migliora effettivamente la situazione e ti consente di essere sicuro che il tuo sistema è ora resiliente a quello scenario specifico.

Ecco un riassunto del processo dell’esperimento del caos:

  1. Sviluppa un’ipotesi: “Il sistema è resiliente a una maggiore latenza di rete”.
  2. Progetta un esperimento mirato: “Aumenteremo artificialmente la latenza a 500 ms sul 70% delle richieste.” Assicurati di avere una chiara strategia di rollback e ripristino.
  3. Esegui l’esperimento: Osserva l’impatto sulla tua applicazione. Ripristina le modifiche dannose agli ambienti di produzione il prima possibile.
  4. Analizza i risultati: Se decidi che il tuo sistema non era abbastanza resiliente, implementa miglioramenti e ripeti il ​​processo.

Il lato non tecnico dell’ingegneria del caos

L’ingegneria del caos è normalmente vista come un compito tecnico per i team di sviluppo e operazioni, dopo tutto, “ingegneria” è nel nome. Oltre ai dadi e bulloni di reti e servizi, è importante guardare anche al lato umano. È facile pensare che il tuo sistema dipenda solo da un database, alcuni server di app e una rete stabile. Di solito non è così.

Pensa a come il tuo sistema risponderebbe se i membri del team non fossero disponibili. La conoscenza è facilmente accessibile se un amministratore deve fare un passo indietro inaspettatamente? Soprattutto nelle organizzazioni più piccole, è comune che una “squadra” sia una singola persona. Cosa succede se il tuo addetto alla rete si ammala durante un’interruzione dal vivo?

Allo stesso modo in cui testate gli aspetti tecnici abbandonando i servizi, potete anche anticipare scenari umani. Prova a escludere intenzionalmente le persone chiave mentre provi un’interruzione. Il resto del team è stato in grado di ripristinare il servizio a uno stato accettabile? In caso contrario, potresti trarre vantaggio dalla documentazione di una parte maggiore del sistema e delle sue dipendenze.

Sommario

Il termine “ingegneria del caos” si riferisce alla pratica di rompere intenzionalmente le cose in produzione per scoprire problemi precedentemente nascosti. Sebbene l’approccio possa sembrare scoraggiante all’inizio, strumenti dedicati come Scimmia del caos può aiutarti a iniziare con il minimo rischio.

L’aggiunta di caos è una tecnica utile, poiché scopre problemi sia transitori che sistemici. Potresti scoprire che il picco di utilizzo della memoria provoca impatti a catena sulla tua infrastruttura, ma che l’aumento della latenza di rete ha un effetto sporadico su parti specifiche del tuo stack.

L’uso efficace dell’ingegneria del caos può aiutarti a trovare i bug più velocemente, prima che i tuoi clienti se ne accorgano. Ti aiuta a costruire la resilienza nel tuo sistema incoraggiando l’anticipazione dei problemi. La maggior parte dei team affronta ancora i problemi in modo reattivo, portando a un aumento del tempo di ciclo che impedisce l’efficienza.

L’ingegneria del caos è meglio trattata come una mentalità piuttosto che come una procedura specifica o un prodotto software. Se riconosci che i sistemi tendono al caos, inizierai naturalmente a inserire nel tuo codice il supporto per più scenari “what-if”.

Vale sempre la pena pensare agli eventi “impossibili”, come un’interruzione del data center o una grave congestione della rete. In realtà, non sono impossibili, solo estremamente rari. Quando colpiscono, è probabile che siano gli eventi più distruttivi che il tuo sistema incontra, a meno che la tua infrastruttura non sia pronta a gestirli con routine di fallback.