Shënim. përkth.: Ky artikull vazhdon një seri të madhe artikujsh nga ungjilltari i teknologjisë AWS Adrian Hornsby, i cili synon të shpjegojë në mënyrë të thjeshtë dhe të qartë rëndësinë e eksperimentimit për të zbutur pasojat e dështimeve në sistemet e IT.
"Nëse nuk arrin të përgatisë një plan, atëherë planifikon të dështojë." - Benjamin Franklin
В Në këtë seri artikujsh, unë prezantova konceptin e inxhinierisë së kaosit dhe shpjegova se si ndihmon për të gjetur dhe korrigjuar të metat në sistem përpara se ato të çojnë në dështime të prodhimit. Ai gjithashtu diskutoi se si inxhinieria e kaosit promovon ndryshime pozitive kulturore brenda organizatave.
Në fund të pjesës së parë, unë premtova të flas për "mjetet dhe metodat për futjen e dështimeve në sisteme". Mjerisht, koka ime kishte planet e veta në këtë drejtim, dhe në këtë artikull do të përpiqem t'i përgjigjem pyetjes më të njohur që lind në mesin e njerëzve që duan të futen në inxhinierinë e kaosit: Çfarë të thyej së pari?
Pyetje e madhe! Megjithatë, ai duket se nuk shqetësohet veçanërisht nga kjo panda...
Mos u ngatërroni me pandat e kaosit!
Përgjigja e shkurtër: Synoni shërbimet kritike përgjatë rrugës së kërkesës.
Përgjigje më e gjatë por më e qartë: Për të kuptuar se ku të filloni të eksperimentoni me kaosin, kushtojini vëmendje tre fushave:
- Shikoni historia e përplasjes dhe të identifikojë modelet;
- Vendos varësitë kritike;
- Përdorni të ashtuquajturat efekti i mbibesimit.
Është qesharake, por kjo pjesë mund të quhet po aq lehtë "Një udhëtim drejt vetë-zbulimit dhe iluminizmit". Në të do të fillojmë të "luajmë" me disa instrumente të lezetshme.
1. Përgjigja qëndron në të kaluarën
Nëse ju kujtohet, në pjesën e parë prezantova konceptin e korrigjimit të gabimeve (COE) - një metodë me të cilën ne analizojmë gabimet tona - gabimet në teknologji, proces ose organizatë - në mënyrë që të kuptojmë shkakun(et) e tyre dhe të parandalojmë përsëritje në të ardhmen. Në përgjithësi, këtu duhet të filloni.
"Për të kuptuar të tashmen, duhet të njohësh të kaluarën." - Carl Sagan
Shikoni historinë e dështimeve, etiketoni ato në COE ose postmortem dhe klasifikojini ato. Identifikoni modelet e zakonshme që shpesh çojnë në probleme dhe për çdo COE, bëni vetes pyetjen e mëposhtme:
"A mund të ishte parashikuar kjo dhe për këtë arsye të parandalohej nga injektimi i gabimit?"
Më kujtohet një dështim në fillim të karrierës sime. Mund të ishte parandaluar lehtësisht nëse do të kishim kryer disa eksperimente të thjeshta kaosi:
Në kushte normale, rastet mbështetëse i përgjigjen kontrolleve shëndetësore nga ). ELB përdor këto kontrolle për të ridrejtuar kërkesat në raste të shëndetshme. Kur rezulton se një shembull është "i pashëndetshëm", ELB ndalon dërgimin e kërkesave për të. Një ditë, pas një fushate të suksesshme marketingu, vëllimi i trafikut u rrit dhe kompanitë e prapambetura filluan t'i përgjigjen kontrolleve shëndetësore më ngadalë se zakonisht. Duhet thënë se këto kontrolle shëndetësore ishin dmth u kontrollua gjendja e varësive.
Sidoqoftë, gjithçka ishte mirë për një kohë.
Më pas, tashmë në kushte mjaft stresuese, një nga rastet filloi të ekzekutonte një detyrë jo-kritike, të rregullt ETL cron. Kombinimi i trafikut të lartë dhe cronjob e shtynë përdorimin e CPU-së në pothuajse 100%. Mbingarkesa e CPU-së ngadalësoi më tej përgjigjet ndaj kontrolleve shëndetësore, aq sa ELB vendosi që shembulli po përjetonte probleme të performancës. Siç pritej, balancuesi ndaloi shpërndarjen e trafikut tek ai, gjë që, nga ana tjetër, çoi në një rritje të ngarkesës në rastet e mbetura në grup.
Papritur, edhe të gjitha rastet e tjera filluan të dështojnë në kontrollin shëndetësor.
Fillimi i një shembulli të ri kërkonte shkarkimin dhe instalimin e paketave dhe iu desh shumë më gjatë sesa iu desh ELB për t'i çaktivizuar ato - një nga një - në grupin e shkallëzimit automatik. Është e qartë se së shpejti i gjithë procesi arriti në një pikë kritike dhe aplikacioni u rrëzua.
Atëherë ne kuptuam përgjithmonë pikat e mëposhtme:
- Instalimi i softuerit kur krijoni një shembull të ri kërkon shumë kohë; është më mirë t'i jepet përparësi qasjes së pandryshueshme dhe .
- Në situata komplekse, përgjigjet ndaj kontrolleve shëndetësore dhe ELB-ve duhet të kenë përparësi - gjëja e fundit që dëshironi është të ndërlikoni jetën për rastet e mbetura.
- Memoria lokale e kontrolleve shëndetësore ndihmon shumë (edhe për disa sekonda).
- Në një situatë të vështirë, mos ekzekutoni detyrat cron dhe procese të tjera jo kritike - kurseni burime për detyrat më të rëndësishme.
- Gjatë shkallëzimit automatik, përdorni instanca më të vogla. Një grup prej 10 ekzemplarësh të vegjël është më i mirë se një grup prej 4 ekzemplarësh të mëdhenj; nëse njëra shembull dështon, në rastin e parë 10% e trafikut do të shpërndahet në 9 pika, në të dytën - 25% e trafikut mbi tre pika.
Pra, a mund të ishte parashikuar kjo, dhe për këtë arsye të parandalohej duke paraqitur problemin?
Po, dhe në disa mënyra.
Së pari, duke simuluar përdorimin e lartë të CPU-së duke përdorur mjete si p.sh ose :
❯ stress-ng --matrix 1 -t 60s
stresi-ng
Së dyti, duke e mbingarkuar shembullin me dhe shërbime të tjera të ngjashme:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Eksperimentet janë relativisht të thjeshta, por mund të ofrojnë ushqim të mirë për të menduar pa pasur nevojë të kalojnë stresin e një dështimi të vërtetë.
Por mos u ndal me kaq. Përpiquni të riprodhoni përplasjen në një mjedis testimi dhe kontrolloni përgjigjen tuaj për pyetjen "A mund të ishte parashikuar kjo dhe për këtë arsye të parandalohej duke futur një defekt?" Ky është një mini eksperiment kaosi brenda një eksperimenti kaosi për të testuar supozimet, por duke filluar me një dështim.
Ishte një ëndërr, apo ndodhi vërtet?
Pra, studioni historinë e dështimeve, analizoni KE, etiketoni dhe klasifikoni ato sipas "rrezes së goditjes" - ose më saktë, numrit të klientëve të prekur - dhe më pas kërkoni modele. Pyesni veten nëse kjo mund të ishte parashikuar dhe parandaluar duke paraqitur problemin. Kontrolloni përgjigjen tuaj.
Pastaj kaloni në modelet më të zakonshme me gamën më të madhe.
2. Ndërtoni një hartë varësie
Merrni një moment për të menduar për aplikimin tuaj. A ka një hartë të qartë të varësive të saj? A e dini se çfarë ndikimi do të kenë nëse ka një dështim?
Nëse nuk jeni shumë të njohur me kodin e aplikacionit tuaj ose nëse ai është bërë shumë i madh, mund të jetë e vështirë të kuptoni se çfarë bën kodi dhe cilat janë varësitë e tij. Kuptimi i këtyre varësive dhe ndikimi i tyre i mundshëm në aplikacion dhe përdoruesit është thelbësor për të ditur se ku të filloni me inxhinierinë e kaosit: pika e fillimit është komponenti me rrezen më të madhe të ndikimit.
Identifikimi dhe dokumentimi i varësive quhet "ndërtimi i një harte varësie» (harta e varësisë). Kjo zakonisht bëhet për aplikacionet me një bazë të madhe kodi duke përdorur mjete të profilizimit të kodit. (profilimi i kodit) dhe instrumentimi (instrumentim). Ju gjithashtu mund të ndërtoni një hartë duke monitoruar trafikun e rrjetit.
Megjithatë, jo të gjitha varësitë janë të njëjta (gjë që e ndërlikon më tej procesin). Disa kritike, te tjera - dytësore (të paktën në teori, pasi përplasjet shpesh ndodhin për shkak të problemeve me varësitë që konsideroheshin jo kritike).
Pa varësi kritike, shërbimi nuk mund të funksionojë. Varësi jo kritike "nuk duhet» për të ndikuar në shërbim në rast rrëzimi. Për të kuptuar varësitë, duhet të keni një kuptim të qartë të API-ve të përdorura nga aplikacioni juaj. Kjo mund të jetë shumë më e vështirë se sa duket - të paktën për aplikacione të mëdha.
Filloni duke kaluar nëpër të gjitha API-të. Theksoni më së shumti domethënëse dhe kritike. Merrni зависимости nga depoja e kodit, kontrollojeni regjistrat e lidhjes, pastaj shikoni dokumentacionin (natyrisht, nëse ekziston - përndryshe ju ende keniоprobleme më të mëdha). Përdorni mjetet për të profilizimi dhe gjurmimi, filtro thirrjet e jashtme.
Ju mund të përdorni programe si netstat - një mjet i linjës komanduese që shfaq një listë të të gjitha lidhjeve të rrjetit (prizat aktive) në sistem. Për shembull, për të renditur të gjitha lidhjet aktuale, shkruani:
❯ netstat -a | more
Në AWS mund të përdorni (regjistrat e rrjedhës) VPC është një metodë që ju lejon të grumbulloni informacion në lidhje me trafikun IP që shkon në ose nga ndërfaqet e rrjetit në një VPC. Regjistrat e tillë mund të ndihmojnë gjithashtu me detyra të tjera - për shembull, gjetja e një përgjigje për pyetjen se pse një trafik i caktuar nuk arrin në shembull.
Ju gjithashtu mund të përdorni . X-Ray ju lejon të merrni të detajuara, "të fundit" (nga fundi në fund) pasqyrë e kërkesave ndërsa ato lëvizin nëpër aplikacion, dhe gjithashtu ndërton një hartë të komponentëve themelorë të aplikacionit. Shumë i përshtatshëm nëse keni nevojë të identifikoni varësitë.
Konsola AWS me rreze X
Një hartë e varësisë së rrjetit është vetëm një zgjidhje e pjesshme. Po, tregon se me cilin aplikacion komunikon, por ka varësi të tjera.
Shumë aplikacione përdorin DNS për t'u lidhur me varësitë, ndërsa të tjerët mund të përdorin zbulimin e shërbimit ose edhe adresat IP të koduara në skedarët e konfigurimit (p.sh. /etc/hosts).
Për shembull, ju mund të krijoni me ndihmën e iptables dhe shikoni se çfarë prishet. Për ta bërë këtë, futni komandën e mëposhtme:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Vrima e zezë DNS
Nëse në /etc/hosts ose skedarë të tjerë konfigurimi, do të gjeni adresa IP për të cilat nuk dini asgjë (po, për fat të keq, edhe kjo ndodh), mund të vini përsëri në shpëtim iptables. Le të themi se keni zbuluar 8.8.8.8 dhe nuk e di që kjo është adresa publike e serverit DNS të Google. Duke përdorur iptables Ju mund të bllokoni trafikun hyrës dhe dalës në këtë adresë duke përdorur komandat e mëposhtme:
❯ 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"
Mbyllja e aksesit
Rregulli i parë heq të gjitha paketat nga DNS-ja publike e Google: ping punon, por paketat nuk kthehen. Rregulli i dytë hedh të gjitha paketat që vijnë nga sistemi juaj drejt DNS-së publike të Google - në përgjigje të ping ne marrim Operacioni nuk lejohet.
Shënim: në këtë rast të veçantë do të ishte më mirë të përdoret whois 8.8.8.8, por ky është vetëm një shembull.
Ne mund të shkojmë edhe më thellë në vrimën e lepurit, sepse gjithçka që përdor TCP dhe UDP varet gjithashtu nga IP. Në shumicën e rasteve, IP është e lidhur me ARP. Mos harroni për muret e zjarrit...
Nëse merrni pilulën e kuqe, qëndroni në Botën e Çudirave dhe unë do t'ju tregoj se sa thellë shkon vrima e lepurit."
Një qasje më radikale është që shkëputem makinat një nga një dhe shikoni se çfarë është prishur... bëhuni një "majmun kaosi". Natyrisht, shumë sisteme prodhimi nuk janë të dizajnuara për një sulm të tillë të forcës brutale, por të paktën mund të provohet në një mjedis provë.
Ndërtimi i një harte varësie është shpesh një ndërmarrje shumë e gjatë. Kohët e fundit fola me një klient i cili kaloi gati 2 vjet duke zhvilluar një mjet që gjeneron në mënyrë gjysmë automatike hartat e varësisë për qindra mikroshërbime dhe komanda.
Rezultati, megjithatë, është jashtëzakonisht interesant dhe i dobishëm. Do të mësoni shumë rreth sistemit tuaj, varësive dhe operacioneve të tij. Përsëri, jini të durueshëm: është vetë udhëtimi që ka më shumë rëndësi.
3. Kujdes nga vetëbesimi i tepërt
"Kushdo që ëndërron për çfarë, beson në të." - Demosteni
A keni dëgjuar ndonjëherë për efekti i mbibesimit?
Sipas Wikipedia, efekti i mbibesimit është "një paragjykim njohës në të cilin besimi i një personi në veprimet dhe vendimet e tij është dukshëm më i madh se sa saktësia objektive e atyre gjykimeve, veçanërisht kur niveli i besimit është relativisht i lartë".
Bazuar në instinkt dhe përvojë...
Në përvojën time, ky shtrembërim është një sugjerim i shkëlqyeshëm se ku të fillohet me inxhinierinë e kaosit.
Kujdes nga operatori me vetëbesim të tepruar:
Charlie: "Kjo gjë nuk ka rënë për pesë vjet, gjithçka është në rregull!"
Crash: "Prit... do të jem atje së shpejti!"
Paragjykimi si pasojë e vetëbesimit të tepërt është një gjë tinëzare dhe madje e rrezikshme për shkak të faktorëve të ndryshëm që ndikojnë në të. Kjo është veçanërisht e vërtetë kur anëtarët e ekipit kanë derdhur zemrat e tyre në një teknologji ose kanë shpenzuar shumë kohë për ta "rregulluar" atë.
Duke përmbledhur
Kërkimi për një pikënisje për inxhinierinë e kaosit sjell gjithmonë më shumë rezultate sesa pritej, dhe ekipet që fillojnë t'i thyejnë gjërat shumë shpejt humbasin nga sytë thelbin më global dhe interesant të (kaos-)inxhinieri - përdorim krijues metodat shkencore и dëshmi empirike për projektimin, zhvillimin, funksionimin, mirëmbajtjen dhe përmirësimin e sistemeve (softuerike).
Kjo përfundon pjesën e dytë. Ju lutemi shkruani komente, ndani mendimet ose thjesht duartrokitni . Në pjesën tjetër I vërtet Do të shqyrtoj mjetet dhe metodat për futjen e dështimeve në sisteme. Derisa!
PS nga përkthyesi
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «"?
- «'.
Burimi: www.habr.com