Opomba. prevod: Ta članek nadaljuje veliko serijo člankov evangelista tehnologije AWS Adriana Hornsbyja, ki si prizadeva na preprost in jasen način razložiti pomen eksperimentiranja za ublažitev posledic napak v sistemih IT.
"Če vam ne uspe pripraviti načrta, potem načrtujete neuspeh." - Benjamin Franklin
В V tej seriji člankov sem predstavil koncept inženiringa kaosa in razložil, kako pomaga najti in popraviti napake v sistemu, preden povzročijo napake v proizvodnji. Razpravljalo je tudi o tem, kako inženiring kaosa spodbuja pozitivne kulturne spremembe v organizacijah.
Na koncu prvega dela sem obljubil, da bom govoril o "orodjih in metodah za vnašanje napak v sisteme." Žal, moja glava je imela svoje načrte v zvezi s tem in v tem članku bom poskušal odgovoriti na najbolj priljubljeno vprašanje, ki se poraja med ljudmi, ki se želijo ukvarjati z inženiringom kaosa: Kaj najprej zlomiti?
Odlično vprašanje! Vendar se zdi, da ga ta panda ne moti posebej ...
Ne zapletajte se s pando kaosa!
Kratek odgovor: Ciljajte na kritične storitve na poti zahteve.
Daljši, a jasnejši odgovor: Če želite razumeti, kje začeti eksperimentirati s kaosom, bodite pozorni na tri področja:
- Poglej zgodovina zrušitve in prepoznati vzorce;
- Odloča o kritične odvisnosti;
- Uporabite t.i učinek pretirane samozavesti.
Smešno je, toda ta del bi se prav tako lahko imenoval "Potovanje k samoodkrivanju in razsvetljenju". V njem se bomo začeli "igrati" z nekaj kul instrumenti.
1. Odgovor je v preteklosti
Če se spomnite, sem v prvem delu predstavil koncept popravka napak (COE) – metodo, s katero analiziramo svoje napake – napake v tehnologiji, procesu ali organizaciji – da bi razumeli njihov vzrok(-e) in preprečili ponovitev v prihodnosti. Na splošno bi morali začeti tukaj.
"Da bi razumeli sedanjost, morate poznati preteklost." — Carl Sagan
Oglejte si zgodovino napak, jih označite v COE ali postmortemih in jih razvrstite. Prepoznajte pogoste vzorce, ki pogosto vodijo do težav, in si za vsak COE zastavite naslednje vprašanje:
"Ali je bilo to mogoče predvideti in torej preprečiti z vbrizgavanjem napak?"
Spominjam se enega neuspeha na začetku svoje kariere. Lahko bi ga zlahka preprečili, če bi izvedli nekaj preprostih poskusov kaosa:
V normalnih pogojih se zaledne instance odzovejo na preglede zdravja ). ELB uporablja ta preverjanja za preusmeritev zahtev na zdrave primerke. Ko se izkaže, da je primerek »nezdrav«, mu ELB preneha pošiljati zahteve. Nekega dne, po uspešni marketinški kampanji, se je obseg prometa povečal in zaledja so se začela odzivati na preglede zdravja počasneje kot običajno. Treba povedati, da so bili ti zdravstveni pregledi , torej je bilo preverjeno stanje odvisnosti.
Vendar je bilo nekaj časa vse v redu.
Nato je ena od instanc, že v precej stresnih razmerah, začela izvajati nekritično, običajno nalogo ETL cron. Kombinacija velikega prometa in cronjoba je izkoriščenost procesorja potisnila na skoraj 100 %. Preobremenitev procesorja je dodatno upočasnila odzive na preglede zdravja, tako da je ELB odločil, da ima primerek težave z zmogljivostjo. Kot je bilo pričakovano, je uravnoteženje prenehalo distribuirati promet nanj, kar je posledično povzročilo povečanje obremenitve preostalih primerkov v skupini.
Nenadoma so tudi vsi drugi primerki začeli padati na zdravstvenem pregledu.
Zagon novega primerka je zahteval prenos in namestitev paketov in je trajalo veliko dlje, kot je trajalo, da jih je ELB onemogočil - enega za drugim - v skupini za samodejno skaliranje. Jasno je, da je kmalu celoten proces dosegel kritično točko in aplikacija se je zrušila.
Potem smo za vedno razumeli naslednje točke:
- Namestitev programske opreme pri ustvarjanju novega primerka traja dolgo; bolje je dati prednost nespremenljivemu pristopu in .
- V zapletenih situacijah bi morali imeti prednost odzivi na zdravstvene preglede in ELB - zadnja stvar, ki bi jo želeli, je zakomplicirati življenje preostalim primerkom.
- Lokalno predpomnjenje pregledov zdravja zelo pomaga (tudi za nekaj sekund).
- V težkih razmerah ne izvajajte nalog cron in drugih nekritičnih procesov - prihranite sredstva za najpomembnejša opravila.
- Pri samodejnem skaliranju uporabite manjše primerke. Skupina 10 majhnih primerkov je boljša od skupine 4 velikih; če en primer ne uspe, bo v prvem primeru 10% prometa razdeljeno na 9 točk, v drugem - 25% prometa na tri točke.
Torej, ali bi bilo to mogoče predvideti in torej preprečiti z uvedbo problema?
Da, in to na več načinov.
Prvič, s simulacijo visoke obremenitve procesorja z orodji, kot je npr ali :
❯ stress-ng --matrix 1 -t 60s
stres
Drugič, s preobremenitvijo primerka z in drugi podobni pripomočki:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Poskusi so razmeroma preprosti, vendar lahko ponudijo dobro hrano za razmislek, ne da bi morali iti skozi stres zaradi pravega neuspeha.
Vendar ne ustavi se tam. Poskusite reproducirati zrušitev v testnem okolju in preverite svoj odgovor na vprašanje "Ali je bilo to mogoče predvideti in torej preprečiti z vnosom napake?" To je mini eksperiment kaosa znotraj eksperimenta kaosa za preizkušanje predpostavk, vendar se začne z neuspehom.
So bile sanje ali se je res zgodilo?
Zato preučite zgodovino napak, analizirajte EOC, jih označite in razvrstite po »radiju zadetkov« – ali natančneje, po številu prizadetih strank – in nato poiščite vzorce. Vprašajte se, ali je bilo to mogoče predvideti in preprečiti z vnosom problema. Preverite svoj odgovor.
Nato preklopite na najpogostejše vzorce z največjim obsegom.
2. Zgradite zemljevid odvisnosti
Vzemite si trenutek in razmislite o svoji prijavi. Ali obstaja jasen zemljevid njegovih odvisnosti? Ali veste, kakšen vpliv bodo imeli, če pride do napake?
Če niste dobro seznanjeni s kodo svoje aplikacije ali če je postala zelo velika, je lahko težko razumeti, kaj koda počne in kakšne so njene odvisnosti. Razumevanje teh odvisnosti in njihovega možnega vpliva na aplikacijo in uporabnike je ključnega pomena, če želite vedeti, kje začeti z inženiringom kaosa: izhodišče je komponenta z največjim radijem vpliva.
Prepoznavanje in dokumentiranje odvisnosti se imenuje "izdelava zemljevida odvisnosti» (preslikava odvisnosti). To se običajno naredi za aplikacije z veliko bazo kode z uporabo orodij za profiliranje kode. (profiliranje kode) in instrumentacijo (instrumentacija). Zemljevid lahko sestavite tudi s spremljanjem omrežnega prometa.
Niso pa vse odvisnosti enake (kar še dodatno oteži postopek). nekaj kritično, drugo - sekundarni (vsaj v teoriji, saj do zrušitev pogosto pride zaradi težav z odvisnostmi, ki so veljale za nekritične).
Brez kritičnih odvisnosti storitev ne more delovati. Nekritične odvisnosti "ne bi smel» vplivati na servis v primeru padca. Če želite razumeti odvisnosti, morate jasno razumeti API-je, ki jih uporablja vaša aplikacija. To je lahko veliko težje, kot se zdi - vsaj za velike aplikacije.
Začnite tako, da pregledate vse API-je. Izpostavite največ pomembno in kritično. Vzemi odvisnost iz repozitorija kode, preverite dnevnike povezav, nato si oglejte dokumentacijo (seveda, če obstaja - sicer pa še vednoоvečje težave). Uporabite orodja za profiliranje in sledenje, filtrira zunanje klice.
Uporabite lahko programe, kot je netstat - pripomoček ukazne vrstice, ki prikaže seznam vseh omrežnih povezav (aktivnih vtičnic) v sistemu. Na primer, za seznam vseh trenutnih povezav vnesite:
❯ netstat -a | more
V AWS lahko uporabite (dnevniki pretoka) VPC je metoda, ki vam omogoča zbiranje informacij o prometu IP, ki poteka do ali iz omrežnih vmesnikov v VPC. Takšni dnevniki so lahko v pomoč tudi pri drugih opravilih – na primer pri iskanju odgovora na vprašanje, zakaj določen promet ne pride do instance.
Lahko tudi uporabite . X-Ray vam omogoča podrobno, "končno" (konec koncev) pregled zahtev, ko se premikajo skozi aplikacijo, in tudi sestavi zemljevid osnovnih komponent aplikacije. Zelo priročno, če morate identificirati odvisnosti.
AWS X-Ray konzola
Zemljevid odvisnosti od omrežja je le delna rešitev. Da, kaže, katera aplikacija s katero komunicira, vendar obstajajo še druge odvisnosti.
Številne aplikacije uporabljajo DNS za povezavo z odvisnostmi, druge pa lahko uporabljajo odkrivanje storitev ali celo trdo kodirane naslove IP v konfiguracijskih datotekah (npr. /etc/hosts).
Na primer, lahko ustvarite s pomočjo iptables in poglej, kaj se zlomi. Če želite to narediti, vnesite naslednji ukaz:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Črna luknja DNS
Če ste v /etc/hosts ali druge konfiguracijske datoteke, boste našli naslove IP, o katerih ne veste nič (ja, žal se tudi to dogaja), lahko ponovno priskočite na pomoč iptables. Recimo, da ste odkrili 8.8.8.8 in ne vedo, da je to naslov Googlovega javnega strežnika DNS. Z uporabo iptables Dohodni in odhodni promet na ta naslov lahko blokirate z naslednjimi ukazi:
❯ 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"
Zapiranje dostopa
Prvo pravilo odstrani vse pakete iz Googlovega javnega DNS-ja: ping deluje, vendar se paketi ne vrnejo. Drugo pravilo spusti vse pakete, ki izvirajo iz vašega sistema, proti Googlovemu javnemu DNS - kot odgovor na ping dobimo Operacija ni dovoljena.
Opomba: v tem primeru bi bilo bolje uporabiti whois 8.8.8.8, ampak to je samo primer.
Lahko gremo še globlje v zajčjo luknjo, saj je vse, kar uporablja TCP in UDP, dejansko odvisno tudi od IP-ja. V večini primerov je IP vezan na ARP. Ne pozabite na požarne zidove...
Če vzameš rdečo tabletko, ostaneš v čudežni deželi in pokazal ti bom, kako globoka je zajčja luknja."
Bolj radikalen pristop je prekinite povezavo avtomobile enega za drugim in poglejte, kaj je pokvarjeno... postanite "opica kaosa." Seveda veliko produkcijskih sistemov ni zasnovanih za napad s tako surovo silo, vendar ga je mogoče vsaj preizkusiti v testnem okolju.
Izdelava zemljevida odvisnosti je pogosto zelo dolgotrajen podvig. Pred kratkim sem govoril s stranko, ki je skoraj 2 leti razvijala orodje, ki polavtomatsko ustvarja zemljevide odvisnosti za stotine mikrostoritev in ukazov.
Rezultat pa je izjemno zanimiv in uporaben. Izvedeli boste veliko o vašem sistemu, njegovih odvisnostih in delovanju. Še enkrat, bodite potrpežljivi: najpomembnejše je samo potovanje.
3. Pazite se pretirane samozavesti
"Kdor kaj sanja, v to verjame." — Demosten
Ste že slišali za učinek pretirane samozavesti?
Glede na Wikipedijo je učinek pretirane samozavesti »kognitivna pristranskost, pri kateri je posameznikovo zaupanje v svoja dejanja in odločitve znatno večje od objektivne točnosti teh sodb, zlasti kadar je stopnja zaupanja razmeroma visoka.«
Na podlagi instinkta in izkušenj...
Po mojih izkušnjah je to popačenje odličen namig, kje začeti z inženiringom kaosa.
Pazite se preveč samozavestnega operaterja:
Charlie: "Ta stvar ni padla že pet let, vse je v redu!"
Crash: "Počakaj ... kmalu bom tam!"
Pristranskost kot posledica pretirane samozavesti je zaradi različnih dejavnikov, ki nanjo vplivajo, zahrbtna in celo nevarna stvar. To še posebej velja, če so člani ekipe vložili srce v tehnologijo ali porabili veliko časa za njeno "popravljanje".
Če povzamem
Iskanje izhodišča za inženiring kaosa vedno prinese več rezultatov od pričakovanih in ekipe, ki začnejo prehitro razbijati stvari, izgubijo izpred oči bolj globalno in zanimivo bistvo (kaosa-)inženiring - kreativna aplikacija znanstvene metode и empirični dokazi za načrtovanje, razvoj, delovanje, vzdrževanje in izboljšanje sistemov (programske opreme).
S tem se zaključi drugi del. Prosimo, napišite recenzije, delite mnenja ali samo plosknite . V naslednjem delu I res Upošteval bom orodja in metode za vnašanje napak v sisteme. dokler!
PS od prevajalca
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «".
Vir: www.habr.com