Nota. trad.: Questo articolo continua una grande serie di articoli del divulgatore della tecnologia AWS Adrian Hornsby, che si propone di spiegare in modo semplice e chiaro l'importanza della sperimentazione per mitigare le conseguenze dei guasti nei sistemi IT.
“Se non riesci a preparare un piano, allora pensi di fallire.” - Benjamin Franklin
В In questa serie di articoli ho introdotto il concetto di ingegneria del caos e spiegato come aiuta a trovare e correggere i difetti nel sistema prima che portino a fallimenti nella produzione. Si è inoltre discusso di come l'ingegneria del caos promuova un cambiamento culturale positivo all'interno delle organizzazioni.
Alla fine della prima parte avevo promesso di parlare di “strumenti e metodi per introdurre fallimenti nei sistemi”. Ahimè, la mia testa aveva i suoi piani a questo riguardo, e in questo articolo cercherò di rispondere alla domanda più popolare che si pone tra le persone che vogliono dedicarsi all'ingegneria del caos: Cosa rompere prima?
Ottima domanda! Tuttavia, non sembra essere particolarmente infastidito da questo panda...
Non scherzare con il panda del caos!
Risposta breve: indirizza i servizi critici lungo il percorso della richiesta.
Risposta più lunga ma più chiara: Per capire da dove iniziare a sperimentare il caos, prestare attenzione a tre aree:
- Guardare cronologia degli incidenti e identificare modelli;
- Decidere dipendenze critiche;
- Usa il cosiddetto effetto di eccessiva fiducia.
È divertente, ma questa parte potrebbe essere chiamata altrettanto facilmente "Un viaggio alla scoperta di sé e all'illuminazione". In esso inizieremo a "suonare" con alcuni strumenti interessanti.
1. La risposta sta nel passato
Se ricordi, nella prima parte ho introdotto il concetto di Correzione degli Errori (COE) - un metodo mediante il quale analizziamo i nostri errori - errori nella tecnologia, nei processi o nell'organizzazione - al fine di comprenderne le cause e prevenirli. ricorrenza in futuro. In generale, è da qui che dovresti iniziare.
“Per capire il presente bisogna conoscere il passato.” —Carl Sagan
Guarda la cronologia dei fallimenti, taggali nel COE o negli autopsie e classificali. Identifica i modelli comuni che spesso portano a problemi e, per ciascun COE, poniti la seguente domanda:
“Questo avrebbe potuto essere previsto e quindi evitato mediante l’iniezione di guasti?”
Ricordo un fallimento all'inizio della mia carriera. Avremmo potuto facilmente evitarlo se avessimo effettuato un paio di semplici esperimenti sul caos:
In condizioni normali, le istanze di backend rispondono ai controlli di integrità da ). ELB utilizza questi controlli per reindirizzare le richieste a istanze integre. Quando si scopre che un'istanza è "malsana", ELB smette di inviarle richieste. Un giorno, dopo una campagna di marketing di successo, il volume del traffico è aumentato e i backend hanno iniziato a rispondere ai controlli di integrità più lentamente del solito. Va detto che questi controlli sanitari c'erano , cioè è stato controllato lo stato delle dipendenze.
Tuttavia per un po' andò tutto bene.
Quindi, già in condizioni piuttosto stressanti, una delle istanze ha iniziato a eseguire un'attività cron ETL regolare e non critica. La combinazione di traffico elevato e cronjob ha spinto l'utilizzo della CPU quasi al 100%. Il sovraccarico della CPU ha rallentato ulteriormente le risposte ai controlli di integrità, tanto che l'ELB ha deciso che l'istanza presentava problemi di prestazioni. Come previsto, il bilanciatore ha smesso di distribuirgli traffico, il che, a sua volta, ha portato ad un aumento del carico sulle restanti istanze del gruppo.
All'improvviso, anche tutte le altre istanze hanno iniziato a non superare il controllo sanitario.
L'avvio di una nuova istanza ha richiesto il download e l'installazione di pacchetti e ha richiesto molto più tempo di quello impiegato dall'ELB per disabilitarli, uno per uno, nel gruppo di scalabilità automatica. È chiaro che presto l'intero processo ha raggiunto un punto critico e l'applicazione si è bloccata.
Quindi abbiamo capito per sempre i seguenti punti:
- L'installazione del software durante la creazione di una nuova istanza richiede molto tempo, è meglio dare la preferenza all'approccio immutabile e .
- In situazioni complesse, le risposte ai controlli sanitari e agli ELB dovrebbero avere la priorità: l’ultima cosa che vuoi è complicare la vita ai restanti casi.
- La memorizzazione nella cache locale dei controlli sanitari aiuta molto (anche per pochi secondi).
- In una situazione difficile, non eseguire attività cron e altri processi non critici: risparmia risorse per le attività più importanti.
- Durante la scalabilità automatica, utilizza istanze più piccole. È meglio un gruppo di 10 esemplari piccoli che un gruppo di 4 grandi; se un'istanza fallisce, nel primo caso il 10% del traffico verrà distribuito su 9 punti, nel secondo il 25% del traffico su tre punti.
Così, si sarebbe potuto prevedere, e quindi prevenire, introducendo il problema?
Sì, e in diversi modi.
Innanzitutto, simulando un utilizzo elevato della CPU utilizzando strumenti come o :
❯ stress-ng --matrix 1 -t 60s
stress-ng
In secondo luogo, sovraccaricando l'istanza con e altre utilità simili:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Gli esperimenti sono relativamente semplici, ma possono fornire buoni spunti di riflessione senza dover affrontare lo stress di un vero fallimento.
tuttavia non fermarti qui. Prova a riprodurre l'arresto anomalo in un ambiente di test e controlla la tua risposta alla domanda "Ciò avrebbe potuto essere previsto e quindi evitato introducendo un guasto?" Questo è un mini esperimento del caos all'interno di un esperimento del caos per verificare le ipotesi, ma che inizia con un fallimento.
Era un sogno o è successo davvero?
Quindi studia la storia dei fallimenti, analizza Coe., taggali e classificali in base al "raggio di successo" o, più precisamente, al numero di clienti interessati, quindi cerca i modelli. Chiediti se ciò avrebbe potuto essere previsto e prevenuto introducendo il problema. Controlla la tua risposta.
Quindi passa ai modelli più comuni con la gamma più ampia.
2. Costruisci una mappa delle dipendenze
Prenditi un momento per pensare alla tua candidatura. Esiste una mappa chiara delle sue dipendenze? Sapete quale impatto avranno in caso di fallimento?
Se non hai molta familiarità con il codice della tua applicazione o è diventato molto grande, può essere difficile capire cosa fa il codice e quali sono le sue dipendenze. Comprendere queste dipendenze e il loro possibile impatto sull'applicazione e sugli utenti è fondamentale per sapere da dove iniziare con l'ingegneria del caos: il punto di partenza è il componente con il raggio di impatto maggiore.
L'identificazione e la documentazione delle dipendenze si chiama "costruire una mappa delle dipendenze» (mappatura delle dipendenze). Questa operazione viene in genere eseguita per le applicazioni con una base di codice di grandi dimensioni utilizzando strumenti di profilazione del codice. (profilazione del codice) e strumentazione (strumentazione). Puoi anche creare una mappa monitorando il traffico di rete.
Tuttavia, non tutte le dipendenze sono uguali (il che complica ulteriormente il processo). Alcuni critico, altro - secondario (almeno in teoria, poiché spesso si verificano arresti anomali a causa di problemi con dipendenze considerate non critiche).
Senza dipendenze critiche, il servizio non può funzionare. Dipendenze non critiche"non dovrebbe» influenzare il servizio in caso di caduta. Per comprendere le dipendenze, devi avere una chiara comprensione delle API utilizzate dalla tua applicazione. Questo può essere molto più difficile di quanto sembri, almeno per le applicazioni di grandi dimensioni.
Inizia esaminando tutte le API. Evidenzia di più significativo e critico... Prendere a seconda dal repository del codice, dai un'occhiata registri di connessione, quindi visualizza documentazione (ovviamente, se esiste, altrimenti lo hai ancoraоproblemi più grandi). Utilizza gli strumenti per profilazione e tracciabilità, filtrare le chiamate esterne.
Puoi usare programmi come netstat - un'utilità della riga di comando che visualizza un elenco di tutte le connessioni di rete (prese attive) nel sistema. Ad esempio, per elencare tutte le connessioni correnti, digitare:
❯ netstat -a | more
In AWS puoi utilizzare (log di flusso) VPC è un metodo che consente di raccogliere informazioni sul traffico IP in entrata o in uscita dalle interfacce di rete in un VPC. Tali registri possono anche aiutare con altre attività, ad esempio trovare una risposta alla domanda sul perché un determinato traffico non raggiunge l'istanza.
Puoi anche usare . I raggi X ti consentono di ottenere risultati dettagliati, "definitivi" (da un capo all'altro) panoramica delle richieste mentre si spostano attraverso l'applicazione e crea anche una mappa dei componenti sottostanti dell'applicazione. Molto comodo se è necessario identificare le dipendenze.
Console a raggi X AWS
Una mappa delle dipendenze di rete è solo una soluzione parziale. Sì, mostra quale applicazione comunica con quale, ma ci sono altre dipendenze.
Molte applicazioni utilizzano DNS per connettersi alle dipendenze, mentre altre possono utilizzare il rilevamento dei servizi o persino indirizzi IP codificati nei file di configurazione (ad es. /etc/hosts).
Ad esempio, puoi creare via iptables e vedere cosa si rompe. Per fare ciò, inserisci il seguente comando:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Buco nero dei DNS
Se l' /etc/hosts o altri file di configurazione, troverai indirizzi IP di cui non sai nulla (sì, purtroppo succede anche questo), puoi venire in soccorso ancora una volta iptables. Diciamo che hai scoperto 8.8.8.8 e non so che questo è l'indirizzo del server DNS pubblico di Google. Usando iptables Puoi bloccare il traffico in entrata e in uscita verso questo indirizzo utilizzando i seguenti comandi:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Chiusura dell'accesso
La prima regola elimina tutti i pacchetti dal DNS pubblico di Google: ping funziona, ma i pacchetti non vengono restituiti. La seconda regola indirizza tutti i pacchetti provenienti dal tuo sistema verso il DNS pubblico di Google, in risposta a ping otteniamo Operazione non consentita.
Nota: in questo caso particolare sarebbe meglio utilizzare whois 8.8.8.8, ma questo è solo un esempio.
Possiamo andare ancora più in profondità nella tana del coniglio, perché tutto ciò che utilizza TCP e UDP dipende in realtà anche dall'IP. Nella maggior parte dei casi, l’IP è legato all’ARP. Non dimenticare i firewall...
Se prendi la pillola rossa rimani nel Paese delle Meraviglie e io ti mostrerò quanto è profonda la tana del coniglio."
Un approccio più radicale è quello di disconnettersi le auto una per una e vedi cosa è rotto... diventa una "scimmia del caos". Naturalmente molti sistemi di produzione non sono progettati per un simile attacco di forza bruta, ma almeno è possibile provarlo in un ambiente di prova.
Costruire una mappa delle dipendenze è spesso un'impresa molto lunga. Di recente ho parlato con un cliente che ha trascorso quasi 2 anni a sviluppare uno strumento che genera in modo semiautomatico mappe delle dipendenze per centinaia di microservizi e comandi.
Il risultato, tuttavia, è estremamente interessante e utile. Imparerai molto sul tuo sistema, sulle sue dipendenze e sulle sue operazioni. Ancora una volta, sii paziente: è il viaggio in sé che conta di più.
3. Attenzione all'eccessiva sicurezza
“Chi sogna cosa, ci crede.” — Demostene
Ne hai mai sentito parlare effetto di eccessiva fiducia?
Secondo Wikipedia, l’effetto di eccessiva fiducia è “un pregiudizio cognitivo in cui la fiducia di una persona nelle proprie azioni e decisioni è significativamente maggiore dell’accuratezza oggettiva di tali giudizi, soprattutto quando il livello di fiducia è relativamente alto”.
Basandosi sull'istinto e sull'esperienza...
Nella mia esperienza, questa distorsione è un ottimo indizio su dove iniziare con l’ingegneria del caos.
Attenzione all'operatore troppo sicuro di sé:
Charlie: “Questa cosa non cade da cinque anni, va tutto bene!”
Crash: "Aspetta... arrivo presto!"
Il pregiudizio derivante da un’eccessiva fiducia è una cosa insidiosa e persino pericolosa a causa dei vari fattori che lo influenzano. Ciò è particolarmente vero quando i membri del team hanno messo il cuore in una tecnologia o hanno trascorso molto tempo a “aggiustarla”.
Riassumendo
La ricerca di un punto di partenza per l’ingegneria del caos porta sempre più risultati del previsto, e i team che iniziano a rompere le cose troppo in fretta perdono di vista l’essenza più globale e interessante di (chaos-)ingegneria - uso creativo metodi scientifici и evidenza empirica per la progettazione, lo sviluppo, il funzionamento, la manutenzione e il miglioramento dei sistemi (software).
Questo conclude la seconda parte. Per favore scrivi recensioni, condividi opinioni o semplicemente batti le mani . Nella parte successiva I davvero Prenderò in considerazione strumenti e metodi per introdurre fallimenti nei sistemi. Fino a!
PS da traduttore
Leggi anche sul nostro blog:
- «";
- «";
- «";
- «'.
Fonte: habr.com