Notă. transl.: Acest articol continuă o mare serie de articole ale evanghelistului tehnologic AWS Adrian Hornsby, care își propune să explice într-un mod simplu și clar importanța experimentării pentru a atenua consecințele defecțiunilor în sistemele IT.
„Dacă nu reușești să pregătești un plan, atunci plănuiești să eșuezi.” - Benjamin Franklin
В În această serie de articole, am introdus conceptul de inginerie haos și am explicat cum ajută la găsirea și remedierea defectelor în sistem înainte ca acestea să ducă la eșecuri de producție. De asemenea, a discutat despre modul în care ingineria haosului promovează schimbarea culturală pozitivă în cadrul organizațiilor.
La sfârșitul primei părți, am promis că voi vorbi despre „instrumente și metode pentru introducerea defecțiunilor în sisteme”. Din păcate, capul meu avea propriile planuri în acest sens și în acest articol voi încerca să răspund la cea mai populară întrebare care apare în rândul oamenilor care doresc să intre în ingineria haosului: Ce să spargi mai întâi?
Superba intrebare! Cu toate acestea, nu pare să fie deosebit de deranjat de acest panda...
Nu te încurca cu panda haosului!
Răspuns scurt: vizați serviciile critice de-a lungul căii de solicitare.
Răspuns mai lung, dar mai clar: Pentru a înțelege de unde să începeți să experimentați cu haosul, acordați atenție trei domenii:
- Privi la istoricul accidentelor și să identifice modele;
- Decide cu privire la dependențe critice;
- Utilizați așa-numitul efect de exces de încredere.
Este amuzant, dar această parte ar putea fi numită la fel de ușor „O călătorie către auto-descoperire și iluminare”. În ea vom începe să „cântăm” cu niște instrumente cool.
1. Răspunsul se află în trecut
Dacă vă amintiți, în prima parte am introdus conceptul de corecție a erorilor (COE) - o metodă prin care ne analizăm greșelile - greșelile de tehnologie, proces sau organizare - pentru a înțelege cauza(ele) lor și a preveni recidivă în viitor. În general, de aici ar trebui să începeți.
„Pentru a înțelege prezentul, trebuie să cunoști trecutul.” — Carl Sagan
Uitați-vă la istoricul eșecurilor, etichetați-le în COE sau post-mortems și clasificați-le. Identificați modele comune care duc adesea la probleme și, pentru fiecare COE, puneți-vă următoarea întrebare:
„Ar fi putut fi prezis acest lucru și, prin urmare, prevenit prin injectare defectuoasă?”
Îmi amintesc un eșec la începutul carierei mele. Ar fi putut fi prevenit cu ușurință dacă am fi efectuat câteva experimente simple de haos:
În condiții normale, instanțele backend răspund la verificările de sănătate de la ). ELB folosește aceste verificări pentru a redirecționa cererile către instanțe sănătoase. Când se dovedește că o instanță este „nesănătoasă”, ELB încetează să îi trimită cereri. Într-o zi, după o campanie de marketing de succes, volumul de trafic a crescut, iar backend-urile au început să răspundă la controalele de sănătate mai lent decât de obicei. Trebuie spus că aceste controale de sănătate au fost , adică a fost verificată starea dependențelor.
Totuși, totul a fost bine pentru o vreme.
Apoi, deja în condiții destul de stresante, una dintre instanțe a început să execute o sarcină cron ETL obișnuită, necritică. Combinația dintre trafic mare și cronjob a împins utilizarea procesorului la aproape 100%. Supraîncărcarea procesorului a încetinit și mai mult răspunsurile la verificările de sănătate, atât de mult încât ELB a decis că instanța se confruntă cu probleme de performanță. Așa cum era de așteptat, echilibrerul a oprit distribuirea traficului către acesta, ceea ce, la rândul său, a condus la o creștere a încărcăturii asupra instanțelor rămase din grup.
Dintr-o dată, toate celelalte cazuri au început să eșueze controlul de sănătate.
Pornirea unei noi instanțe a necesitat descărcarea și instalarea pachetelor și a durat mult mai mult decât a fost nevoie de ELB pentru a le dezactiva - unul câte unul - în grupul de autoscaling. Este clar că în curând întregul proces a ajuns la un punct critic și aplicația s-a prăbușit.
Atunci am înțeles pentru totdeauna următoarele puncte:
- Instalarea software-ului la crearea unei noi instanțe durează mult timp este mai bine să acordați preferință abordării imuabile; .
- În situații dificile, răspunsurile la controalele de sănătate și ELB ar trebui să aibă prioritate - ultimul lucru pe care îl doriți este să vă complicați viața pentru cazurile rămase.
- Memorarea în cache locală a verificărilor de sănătate ajută foarte mult (chiar și pentru câteva secunde).
- Într-o situație dificilă, nu rulați sarcini cron și alte procese necritice - economisiți resurse pentru cele mai importante sarcini.
- Când autoscaling, utilizați instanțe mai mici. Un grup de 10 exemplare mici este mai bine decât un grup de 4 exemplare mari; dacă o instanță eșuează, în primul caz 10% din trafic va fi repartizat în 9 puncte, în al doilea - 25% din trafic peste trei puncte.
Astfel, ar fi putut fi prevăzut acest lucru și, prin urmare, prevenit prin introducerea problemei?
Da, și în mai multe feluri.
În primul rând, prin simularea utilizării ridicate a procesorului folosind instrumente precum sau :
❯ stress-ng --matrix 1 -t 60s
stres-ng
În al doilea rând, prin supraîncărcarea instanței cu si alte utilitati similare:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Experimentele sunt relativ simple, dar pot oferi ceva bun de gândit fără a fi nevoie să treci prin stresul unui eșec real.
Dar nu te opri aici. Încercați să reproduceți accidentul într-un mediu de testare și verificați răspunsul la întrebarea "Ar fi putut fi prevăzut acest lucru și, prin urmare, prevenit prin introducerea unei defecțiuni?" Acesta este un mini experiment de haos în cadrul unui experiment de haos pentru a testa ipotezele, dar începând cu un eșec.
A fost un vis sau s-a întâmplat cu adevărat?
Așa că studiază istoria eșecurilor, analizează EOC, etichetează-le și clasifică-le după „raza lovirii” – sau mai precis, numărul de clienți afectați – și apoi caută modele. Întrebați-vă dacă acest lucru ar fi putut fi prezis și prevenit prin introducerea problemei. Verifica-ti raspunsul.
Apoi treceți la cele mai comune modele cu cea mai mare gamă.
2. Construiți o hartă a dependențelor
Gândește-te puțin la aplicația ta. Există o hartă clară a dependențelor sale? Știți ce impact vor avea dacă va exista un eșec?
Dacă nu sunteți foarte familiarizat cu codul aplicației dvs. sau a devenit foarte mare, poate fi dificil să înțelegeți ce face codul și care sunt dependențele sale. Înțelegerea acestor dependențe și impactul lor posibil asupra aplicației și utilizatorilor este esențială pentru a ști de unde să începem cu ingineria haosului: punctul de plecare este componenta cu cea mai mare rază de impact.
Identificarea și documentarea dependențelor se numește „construirea unei hărți a dependenței» (cartarea dependenței). Acest lucru se face de obicei pentru aplicații cu o bază de cod mare, folosind instrumente de profilare a codului. (profilare cod) si instrumentare (instrumentaţie). De asemenea, puteți construi o hartă prin monitorizarea traficului din rețea.
Cu toate acestea, nu toate dependențele sunt la fel (ceea ce complică și mai mult procesul). niste critic, alte - secundar (cel puțin în teorie, deoarece blocările apar adesea din cauza problemelor cu dependențele care au fost considerate necritice).
Fără dependențe critice, serviciul nu poate funcționa. Dependențe non-critice "nu ar trebui» pentru a influenţa serviciul în caz de cădere. Pentru a înțelege dependențele, trebuie să înțelegeți clar API-urile utilizate de aplicația dvs. Acest lucru poate fi mult mai dificil decât pare - cel puțin pentru aplicații mari.
Începeți prin a parcurge toate API-urile. Evidențiați cel mai mult semnificativă și critică... Lua зависимости din depozitul de coduri, verificați-l jurnalele de conectare, apoi vizualizați documentație (desigur, dacă există - altfel mai aiоprobleme mai mari). Folosiți instrumentele pentru a profilare și urmărire, filtrați apelurile externe.
Puteți folosi programe precum netstat - un utilitar de linie de comandă care afișează o listă a tuturor conexiunilor de rețea (prize active) din sistem. De exemplu, pentru a lista toate conexiunile curente, tastați:
❯ netstat -a | more
În AWS puteți utiliza (jurnalele de flux) VPC este o metodă care vă permite să colectați informații despre traficul IP care merge către sau de la interfețele de rețea într-un VPC. Astfel de jurnale pot ajuta și la alte sarcini - de exemplu, găsirea unui răspuns la întrebarea de ce un anumit trafic nu ajunge la instanță.
De asemenea, puteți utiliza . X-Ray vă permite să obțineți detalii, „final” (un capăt la altul) prezentare generală a cererilor pe măsură ce acestea se deplasează prin aplicație și, de asemenea, construiește o hartă a componentelor de bază ale aplicației. Foarte convenabil dacă trebuie să identificați dependențe.
Consola AWS X-Ray
O hartă a dependenței de rețea este doar o soluție parțială. Da, arată ce aplicație comunică cu care, dar există și alte dependențe.
Multe aplicații folosesc DNS pentru a se conecta la dependențe, în timp ce altele pot folosi descoperirea serviciului sau chiar adrese IP codificate în fișierele de configurare (de ex. /etc/hosts).
De exemplu, puteți crea via iptables si vezi ce se rupe. Pentru a face acest lucru, introduceți următoarea comandă:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
gaură neagră DNS
În cazul în care /etc/hosts sau alte fișiere de configurare, vei găsi adrese IP despre care nu știi nimic (da, din păcate, se întâmplă și asta), poți veni din nou la salvare iptables. Să zicem că ai descoperit 8.8.8.8 și nu știu că aceasta este adresa publică a serverului DNS Google. Prin utilizarea iptables Puteți bloca traficul de intrare și de ieșire către această adresă folosind următoarele comenzi:
❯ 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"
Închiderea accesului
Prima regulă elimină toate pachetele din DNS-ul public Google: ping funcționează, dar pachetele nu sunt returnate. A doua regulă trimite toate pachetele care provin din sistemul dvs. către DNS-ul public Google - ca răspuns la ping primim operatie nepermisa.
Notă: în acest caz particular ar fi mai bine să utilizați whois 8.8.8.8, dar acesta este doar un exemplu.
Putem merge și mai adânc în virajul iepurelui, pentru că tot ceea ce folosește TCP și UDP depinde de fapt și de IP. În cele mai multe cazuri, IP-ul este legat de ARP. Nu uita de firewall-uri...
Dacă iei pastila roșie, rămâi în Țara Minunilor și îți voi arăta cât de adânc este gaura iepurelui.”
O abordare mai radicală este să Deconectat mașinile una câte una și vezi ce s-a stricat... devii o „maimuță haos”. Desigur, multe sisteme de producție nu sunt proiectate pentru un astfel de atac de forță brută, dar cel puțin poate fi încercat într-un mediu de testare.
Construirea unei hărți a dependenței este adesea o întreprindere foarte lungă. Am vorbit recent cu un client care a petrecut aproape 2 ani dezvoltând un instrument care generează semi-automat hărți de dependență pentru sute de microservicii și comenzi.
Rezultatul este însă extrem de interesant și util. Veți învăța multe despre sistemul dvs., dependențele și operațiunile sale. Din nou, ai răbdare: călătoria în sine contează cel mai mult.
3. Feriți-vă de excesul de încredere
„Cine visează la ce, crede în asta.” — Demostene
Ai auzit vreodată de efect de exces de încredere?
Potrivit Wikipedia, efectul de supraîncredere este „o prejudecată cognitivă în care încrederea unei persoane în acțiunile și deciziile sale este semnificativ mai mare decât acuratețea obiectivă a acelor judecăți, mai ales atunci când nivelul de încredere este relativ ridicat”.
Bazat pe instinct și experiență...
Din experiența mea, această distorsiune este un indiciu excelent de unde să începem cu ingineria haosului.
Atenție la operatorul prea încrezător:
Charlie: „Chestia asta nu a căzut în cinci ani, totul este în regulă!”
Crash: „Stai... Voi fi acolo în curând!”
Prejudecățile ca urmare a excesului de încredere este un lucru insidios și chiar periculos din cauza diferiților factori care o influențează. Acest lucru este valabil mai ales atunci când membrii echipei și-au turnat inima într-o tehnologie sau au petrecut mult timp „reparând-o”.
Rezumând
Căutarea unui punct de plecare pentru ingineria haosului aduce întotdeauna mai multe rezultate decât se aștepta, iar echipele care încep să spargă lucrurile prea repede pierd din vedere esența mai globală și mai interesantă a (haos-)Inginerie - aplicare creativa metode științifice и dovada empirica pentru proiectarea, dezvoltarea, operarea, întreținerea și îmbunătățirea sistemelor (software).
Aceasta încheie partea a doua. Vă rugăm să scrieți recenzii, să împărtășiți opinii sau să bateți din palme . În partea următoare I într-adevăr Voi lua în considerare instrumentele și metodele pentru introducerea defecțiunilor în sisteme. Pana cand!
PS de la traducator
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com