Nota. transl.: Questu articulu cuntinueghja una grande serie di articuli da l'evangelista di a tecnulugia AWS Adrian Hornsby, chì si mette à spiegà in modu simplice è chjaru l'impurtanza di l'esperimentazione per mitigà e cunsequenze di fallimenti in i sistemi IT.
"Se ùn avete micca preparatu un pianu, allora pensate di fallu". - Benjamin Franklin
В In questa serie di articuli, aghju introduttu u cuncettu di l'ingegneria di u caosu è spiegà cumu aiuta à truvà è corregge i difetti in u sistema prima di purtà à fallimenti di produzzione. Hè ancu discututu cumu l'ingegneria di u caosu prumove un cambiamentu culturale pusitivu in l'urganisazioni.
À a fine di a prima parte, aghju prumessu di parlà di "arnesi è metudi per l'introduzione di fallimenti in i sistemi". Alas, u mo capu avia i so piani in questu sensu, è in questu articulu pruvaraghju à risponde à a quistione più pupulare chì sorge trà e persone chì volenu entre in l'ingegneria di u caosu: Chì rompe prima?
Grande quistione! Tuttavia, ùn pare micca esse particularmente disturbatu da stu panda ...
Ùn missate micca cù u panda di u caosu !
Risposta corta: Target i servizii critichi longu u percorsu di a dumanda.
Risposta più longa ma più chjara: Per capiscenu induve cumincià à sperimentà cù u caosu, fate attenzione à trè spazii:
- Fighjulà storia di crash è identificà mudelli;
- Decide nantu dipendenze critiche;
- Aduprà u cusì chjamatu effettu eccessiva di fiducia.
Hè divertente, ma sta parte puderia esse chjamatu facilmente "Un viaghju à a scuperta di sè stessu è l'illuminazione". In questu avemu da cumincià à "giocà" cù qualchi strumenti cool.
1. A risposta si trova in u passatu
Se vi ricordate, in a prima parte aghju introduttu u cuncettu di Correction-of-Errors (COE) - un metudu per quale analizzemu i nostri sbagli - errori in tecnulugia, prucessu o urganizazione - per capiscenu a so causa (s) è impediscenu. recurrenza in u futuru. In generale, questu hè induve duvete principià.
"Per capisce u presente, avete bisognu di cunnosce u passatu". - Carl Sagan
Fighjate à a storia di i fallimenti, taggate in COE o post mortems è classificà. Identificà mudelli cumuni chì spessu portanu à prublemi, è per ogni COE, fatevi a seguente quistione:
"Puderia esse previstu è dunque impeditu da iniezione di difetti?"
Mi ricordu di un fallimentu prima di a mo carriera. Puderia esse facilmente impeditu se avemu fattu un paru di esperimenti di caos simplici:
In cundizioni normali, l'istanze di backend rispondenu à i cuntrolli di salute da ). ELB usa questi cuntrolli per reindirizzà e dumande à casi sani. Quandu si scopre chì un'istanza hè "malsana", ELB cessà di mandà richieste à ellu. Un ghjornu, dopu à una campagna di marketing successu, u voluminu di u trafficu hà aumentatu è i backends cuminciaru à risponde à i cuntrolli di salute più lentamente di l'usu. Ci vole à dì chì sti cuntrolli di salute eranu , vale à dì, u statu di e dependenzii hè statu verificatu.
Tuttavia, tuttu era bè per un tempu.
Allora, digià in cundizioni piuttostu stressanti, unu di l'istanze hà cuminciatu à eseguisce un compitu cron ETL regulare non criticu. A cumminazzioni di trafficu altu è cronjob spinta l'utilizazione di CPU à quasi 100%. L'overload di CPU hà più rallentatu e risposte à i cuntrolli di salute, tantu chì l'ELB hà decisu chì l'istanza hà avutu prublemi di rendiment. Cum'è l'aspittava, u balancer hà cessatu di distribuisce u trafficu à ellu, chì, à u turnu, hà purtatu à un aumentu di a carica nantu à i casi rimanenti in u gruppu.
Di colpu, tutti l'altri casi cuminciaru ancu à fallu u cuntrollu di salute.
L'iniziu di una nova istanza necessitava di scaricà è installà i pacchetti è hà pigliatu assai più di l'ELB per disattivà - unu per unu - in u gruppu autoscaling. Hè chjaru chì prestu tuttu u prucessu hà ghjuntu à un puntu criticu è l'appiecazione hè cascata.
Allora avemu sempre capitu i seguenti punti:
- A stallazione di u software quandu crea una nova istanza piglia assai tempu hè megliu dà preferenza à l'approcciu immutable è .
- In situazioni cumplessi, e risposte à i cuntrolli di salute è l'ELB anu da piglià a priorità - l'ultimu cosa chì vulete hè di cumplicà a vita per i casi rimanenti.
- A caching locale di i cuntrolli di salute aiuta assai (ancu per uni pochi seconde).
- In una situazione difficiule, ùn eseguite micca e funzioni cron è altri prucessi micca critichi - salvà risorse per i travaglii più impurtanti.
- Quandu l'autoscaling, utilizate istanze più chjuche. Un gruppu di 10 esemplari chjuchi hè megliu cà un gruppu di 4 grandi; se un casu falla, in u primu casu 10% di u trafficu serà distribuitu nantu à 9 punti, in u sicondu - 25% di u trafficu nantu à trè punti.
Cusì, Puderia esse previstu, è dunque impeditu intruducendu u prublema ?
chì, è in parechje manere.
Prima, simulendu un altu usu di CPU utilizendu strumenti cum'è o :
❯ stress-ng --matrix 1 -t 60s
stress-ng
Siconda, sopracarricà l'istanza cù è altre utilità simili:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
L'esperimenti sò relativamente sèmplice, ma ponu furnisce un bonu alimentu per u pensamentu senza avè da passà per u stress di un veru fallimentu.
Tuttavia, ùn ferma micca quì. Pruvate di ripruduce u crash in un ambiente di prova è verificate a vostra risposta à a quistione "Puderia esse previstu è dunque impeditu intruducendu un difettu ?" Questu hè un mini esperimentu di caosu in un esperimentu di caosu per pruvà ipotesi, ma partendu da un fallimentu.
Era un sognu, o hè accadutu veramente?
Allora studià a storia di fallimenti, analizà EOC, Tag è classificà per "hit radius" - o più precisamente, u numeru di clienti affettati - è dopu cercate mudelli. Dumandate se questu puderia esse previstu è prevenutu intruducendu u prublema. Verificate a vostra risposta.
Allora cambiate à i mudelli più cumuni cù a più grande gamma.
2. Custruì una mappa di dependenza
Pigliate un mumentu per pensà à a vostra applicazione. Ci hè una mappa chjara di e so dipendenze ? Sapete chì impattu anu da esse s'ellu ci hè un fallimentu?
Se ùn site micca assai familiarizatu cù u codice di a vostra applicazione o hè diventatu assai grande, pò esse difficiule di capisce ciò chì face u codice è ciò chì e so dependenze sò. Capisce queste dipendenze è u so impattu pussibule nantu à l'applicazione è l'utilizatori hè critica per sapè da induve principià cù l'ingegneria di u caosu: u puntu di partenza hè u cumpunente cù u più grande raghju d'impattu.
L'identificazione è a documentazione di dipendenze hè chjamatu "custruì una mappa di dependenza» (cartografia di dipendenza). Questu hè tipicamenti fattu per l'applicazioni cù una basa di codice grande chì utilizanu strumenti di profilazione di codice. (profiling codice) è strumentazione (strumentazione). Pudete ancu custruisce una mappa monitorendu u trafficu di a rete.
Tuttavia, micca tutte e dependenzii sò listessi (chì complica ancu u prucessu). Certi criticu, altri - secundariu (almenu in teoria, postu chì i crashes sò spessu accaduti per prublemi cù dipendenze chì eranu cunsiderate micca critichi).
Senza dipendenze critiche, u serviziu ùn pò micca travaglià. Dipendenze micca critiche "ùn deve micca» per influenzà u serviziu in casu di caduta. Per capiscenu e dipendenze, avete bisognu di avè una cunniscenza chjara di l'API utilizati da a vostra applicazione. Questu pò esse assai più difficiule di ciò chì pare - almenu per grandi applicazioni.
Accuminciate per passà tutte l'API. Evidenzià u più significativu è criticu. Pigliate dipendenze da u repositoriu di codice, verificate logs di cunnessione, poi vede documentazione (Di sicuru, s'ellu esiste - altrimenti avete sempreоprublemi più grande). Aduprà l'arnesi per prufilu è traccia, filtrà i chjamati esterni.
Pudete aduprà prugrammi cum'è netstat - una utilità di linea di cummanda chì mostra una lista di tutte e cunnessione di rete (sockets attivi) in u sistema. Per esempiu, per listinu tutte e cunnessione attuale, scrivite:
❯ netstat -a | more
In AWS pudete aduprà (logs di flussu) VPC hè un metudu chì vi permette di cullà infurmazioni nantu à u trafficu IP chì và à o da l'interfaccia di rete in un VPC. Tali logs pò ancu aiutà cù altre attività - per esempiu, truvà una risposta à a quistione di perchè certu trafficu ùn ghjunghje micca à l'istanza.
Pudete ancu aduprà . X-Ray permette di ottene dettagliate, "ultimu" (da fine à fine) Panoramica di e richieste mentre passanu attraversu l'applicazione, è ancu custruisce una mappa di i cumpunenti sottostanti di l'applicazione. Moltu còmuda s'ellu ci vole à identificà dipendenze.
Console AWS X-Ray
Una mappa di dependenza di a rete hè solu una suluzione parziale. Iè, mostra quale applicazione cumunica cù quale, ma ci sò altre dipendenze.
Parechje appricazzioni utilizanu DNS per cunnette à e dipendenze, mentri àutri ponu utilizà a scuperta di serviziu o ancu l'indirizzi IP codificati in i schedarii di cunfigurazione (per esempiu. /etc/hosts).
Per esempiu, pudete creà cun l'aiutu di iptables è vede ciò chì si rompe. Per fà questu, entre u cumandimu seguente:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
U bucu neru DNS
Sì in /etc/hosts o altri schedarii di cunfigurazione, truverete indirizzi IP chì ùn sapete nunda (iè, sfurtunatamenti, questu succede ancu), pudete vene in salvezza di novu iptables. Dicemu chì avete scupertu 8.8.8.8 è ùn sapete micca chì questu hè l'indirizzu publicu di u servitore DNS di Google. Utilizendu iptables Pudete bluccà u trafficu in entrata è in uscita à questu indirizzu usendu i seguenti cumandamenti:
❯ 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"
Accessu chjusu
A prima regula abbanduneghja tutti i pacchetti da u DNS publicu di Google: ping travaglia, ma i pacchetti ùn sò micca restituiti. A seconda regula abbanduneghja tutti i pacchetti originati da u vostru sistema versu u DNS publicu di Google - in risposta à ping avemu L'operazione ùn hè micca permessa.
Nota: in stu casu particulare, saria megliu à aduprà whois 8.8.8.8, ma questu hè solu un esempiu.
Pudemu andà ancu più in fondu à u cunigliu, perchè tuttu ciò chì usa TCP è UDP dipende ancu da IP. In a maiò parte di i casi, IP hè ligatu à ARP. Ùn vi scurdate di i firewall...
Se pigliate a pillola rossa, restate in u paese di e meraviglie, è vi mustraraghju quantu prufonda a tana di u cunigliu.
Un approcciu più radicali hè di disconnect vitture una per una è vede ciò chì hè rottu... diventa una "scimmia di caos". Di sicuru, assai sistemi di produzzione ùn sò micca pensati per un tali attaccu di forza bruta, ma almenu pò esse pruvatu in un ambiente di prova.
Custruì una mappa di a dependenza hè spessu una impresa assai longa. Recentemente aghju parlatu cun un cliente chì hà passatu quasi 2 anni à sviluppà un strumentu chì genera semi-automaticamente mape di dependenza per centinaie di microservizi è cumandamenti.
U risultatu, però, hè assai interessante è utile. Ampararete assai nantu à u vostru sistema, i so dependenzii è l'operazioni. Di novu, sia pacienza : hè u viaghju stessu chì importa di più.
3. Attenti à l'overconfidence
"Chi sognu di ciò chì crede in questu". — Demosthène
Avete mai intesu parlà effettu eccessiva di fiducia?
Sicondu Wikipedia, l'effettu di cunfidenza eccessiva hè "un preghjudiziu cognitivu in quale a fiducia di una persona in e so azzioni è e decisioni hè significativamente più grande di l'accuratezza obiettiva di quelli ghjudizii, soprattuttu quandu u livellu di cunfidenza hè relativamente altu".
Basatu nantu à stintu è sperienza ...
Da a mo spirimintà, possu dì chì sta distorsione hè un grande suggerimentu di induve principià cù l'ingegneria di u caosu.
Attenti à l'operatore troppu cunfidu:
Charlie: "Questa cosa ùn hè micca cascata in cinque anni, tuttu va bè!"
Crash: "Aspetta... Seraghju prestu!"
U preghjudiziu in cunsequenza di l'overconfidence hè una cosa insidiosa è ancu periculosa per i diversi fatturi chì l'influenzanu. Questu hè soprattuttu veru quandu i membri di l'equipa anu versatu u so core in una tecnulugia o passanu assai tempu "riparandu".
Riassuntu
A ricerca di un puntu di partenza per l'ingegneria di u caosu porta sempre più risultati di l'aspittatu, è e squadre chì cumincianu à rompe e cose troppu rapidamente perdenu di vista l'essenza più globale è interessante di (caos-)ingegneria - usu criativu metudi scientifichi и evidenza empirica per u disignu, u sviluppu, u funziunamentu, u mantenimentu è a migliione di sistemi (software).
Questu cuncludi a seconda parte. Per piacè scrivite recensioni, sparte opinioni o solu applaudite e mani . In a parte dopu I veramente Cunsidereraghju arnesi è metudi per l'introduzione di fallimenti in i sistemi. Finu à !
PS da u traduttore
Leghjite puru nant'à u nostru blog:
- «";
- «";
- «";
- «».
Source: www.habr.com