Bilješka. prev.: Ovaj članak nastavlja veliku seriju članaka evangelista tehnologije AWS Adriana Hornsbyja, koji na jednostavan i jasan način namjerava objasniti važnost eksperimentiranja za ublažavanje posljedica kvarova u IT sustavima.
"Ako ne uspijete pripremiti plan, onda planirate neuspjeh." - Benjamin Franklin
В U ovoj seriji članaka predstavio sam koncept inženjeringa kaosa i objasnio kako pomaže pronaći i ispraviti nedostatke u sustavu prije nego dovedu do kvarova u proizvodnji. Također se raspravljalo o tome kako inženjerstvo kaosa promiče pozitivne kulturne promjene unutar organizacija.
Na kraju prvog dijela obećao sam govoriti o “alatima i metodama za uvođenje kvarova u sustave”. Jao, moja je glava imala svoje planove po tom pitanju, au ovom ću članku pokušati odgovoriti na najpopularnije pitanje koje se postavlja među ljudima koji žele ući u inženjerstvo kaosa: Što prvo slomiti?
Super pitanje! No, čini se da mu ova panda posebno ne smeta...
Ne petljajte se s pandom kaosa!
Kratak odgovor: Ciljajte kritične usluge na putu zahtjeva.
Duži, ali jasniji odgovor: Da biste razumjeli gdje započeti eksperimentirati s kaosom, obratite pozornost na tri područja:
- Pogledati na povijest sudara i identificirati obrasce;
- Odluči kritične ovisnosti;
- Koristite tzv učinak pretjeranog samopouzdanja.
Smiješno je, ali ovaj dio bi se isto tako mogao nazvati "Putovanje do samootkrivanja i prosvjetljenja". U njemu ćemo se početi “svirati” s nekim cool instrumentima.
1. Odgovor leži u prošlosti
Ako se sjećate, u prvom sam dijelu predstavio koncept ispravljanja pogrešaka (COE) - metodu kojom analiziramo svoje pogreške - pogreške u tehnologiji, procesu ili organizaciji - kako bismo razumjeli njihov uzrok(e) i spriječili ponavljanje u budućnosti . Općenito, ovo je mjesto gdje biste trebali početi.
“Da biste razumjeli sadašnjost, morate znati prošlost.” — Carl Sagan
Pogledajte povijest kvarova, označite ih u COE ili obdukcijama i klasificirajte ih. Identificirajte uobičajene obrasce koji često dovode do problema i za svaki COE postavite si sljedeće pitanje:
"Je li se to moglo predvidjeti i stoga spriječiti ubacivanjem greške?"
Sjećam se jednog neuspjeha na početku svoje karijere. Moglo se lako spriječiti da smo proveli nekoliko jednostavnih eksperimenata kaosa:
U normalnim uvjetima, pozadinske instance odgovaraju na provjere zdravlja od ). ELB koristi ove provjere za preusmjeravanje zahtjeva na zdrave instance. Kada se pokaže da je instanca “nezdrava”, ELB joj prestaje slati zahtjeve. Jednog dana, nakon uspješne marketinške kampanje, obujam prometa se povećao i pozadine su počele reagirati na provjere zdravlja sporije nego inače. Treba reći da su ti zdravstveni pregledi bili , odnosno provjereno je stanje ovisnosti.
Ipak, neko je vrijeme sve bilo u redu.
Tada je, već pod prilično stresnim uvjetima, jedna od instanci počela izvršavati nekritičan, uobičajeni ETL cron zadatak. Kombinacija velikog prometa i cronjoba pogurala je iskorištenost CPU-a na gotovo 100%. Preopterećenje CPU-a dodatno je usporilo odgovore na provjere zdravlja, toliko da je ELB odlučio da instanca ima problema s performansama. Kao što se i očekivalo, balanser je prestao distribuirati promet prema njemu, što je zauzvrat dovelo do povećanja opterećenja na preostalim instancama u grupi.
Odjednom su i sve druge instance počele padati na zdravstvenoj provjeri.
Pokretanje nove instance zahtijevalo je preuzimanje i instaliranje paketa i trajalo je mnogo dulje nego što je trebalo ELB-u da ih onemogući - jednog po jednog - u grupi za automatsko skaliranje. Jasno je da je ubrzo cijeli proces došao do kritične točke i da se aplikacija srušila.
Tada smo zauvijek shvatili sljedeće točke:
- Instalacija softvera prilikom stvaranja nove instance traje dugo; bolje je dati prednost nepromjenjivom pristupu i .
- U složenim situacijama, odgovori na zdravstvene provjere i ELB-ove trebali bi imati prioritet - posljednja stvar koju želite je zakomplicirati život preostalim instancama.
- Lokalno predmemoriranje provjera ispravnosti puno pomaže (čak i na nekoliko sekundi).
- U teškoj situaciji nemojte pokretati cron zadatke i druge nekritične procese - sačuvajte resurse za najvažnije zadatke.
- Prilikom automatskog skaliranja koristite manje instance. Skupina od 10 malih primjeraka bolja je od skupine od 4 velika; ako jedna instanca ne uspije, u prvom slučaju 10% prometa bit će raspoređeno na 9 točaka, u drugom - 25% prometa na tri točke.
Dakle, da li se to moglo predvidjeti, a time i spriječiti uvođenjem problema?
Da, i to na nekoliko načina.
Prvo, simuliranjem velike upotrebe procesora pomoću alata kao što su ili :
❯ stress-ng --matrix 1 -t 60s
stres-ng
Drugo, preopterećenjem instance s i druge slične alate:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Eksperimenti su relativno jednostavni, ali mogu pružiti dobru hranu za razmišljanje bez potrebe da prolazite kroz stres zbog stvarnog neuspjeha.
Ali nemoj stati tu. Pokušajte reproducirati rušenje u testnom okruženju i provjerite svoj odgovor na pitanje "Je li se to moglo predvidjeti i stoga spriječiti uvođenjem greške?" Ovo je mini eksperiment kaosa unutar eksperimenta kaosa za testiranje pretpostavki, ali počinje s neuspjehom.
Je li to bio san ili se stvarno dogodilo?
Stoga proučavajte povijest neuspjeha, analizirajte EOC, označite ih i klasificirajte prema "radijusu pogotka"—ili točnije, broju pogođenih kupaca—a zatim potražite uzorke. Zapitajte se je li se to moglo predvidjeti i spriječiti unošenjem problema. Provjeri svoj odgovor.
Zatim prijeđite na najčešće uzorke s najvećim rasponom.
2. Izradite mapu ovisnosti
Odvojite trenutak da razmislite o svojoj prijavi. Postoji li jasna karta njegovih ovisnosti? Znate li kakav će učinak imati ako dođe do kvara?
Ako niste dobro upoznati s kodom svoje aplikacije ili je postao jako velik, može biti teško razumjeti što kod radi i koje su njegove ovisnosti. Razumijevanje ovih ovisnosti i njihovog mogućeg utjecaja na aplikaciju i korisnike ključno je za saznanje odakle započeti s inženjeringom kaosa: početna točka je komponenta s najvećim radijusom utjecaja.
Identificiranje i dokumentiranje ovisnosti naziva se "izrada karte ovisnosti» (mapiranje ovisnosti). To se obično radi za aplikacije s velikom bazom koda pomoću alata za profiliranje koda. (profiliranje koda) i instrumentacija (instrumentacija). Također možete izraditi kartu praćenjem mrežnog prometa.
Međutim, nisu sve ovisnosti iste (što dodatno komplicira proces). Neki kritično, drugi - sekundarni (barem u teoriji, budući da se rušenja često događaju zbog problema s ovisnostima koje se smatraju nekritičnim).
Bez kritičnih ovisnosti usluga ne može raditi. Nekritične ovisnosti "ne bi trebao» utjecati na servis u slučaju pada. Da biste razumjeli ovisnosti, morate jasno razumjeti API-je koje koristi vaša aplikacija. Ovo može biti puno teže nego što se čini - barem za velike aplikacije.
Započnite prolaskom kroz sve API-je. Istaknite najviše značajan i kritičan... Uzeti ovisno o iz repozitorija koda, provjerite dnevnici povezivanja, zatim pogledajte dokumentacija (naravno, ako postoji - inače još uvijek imateоveći problemi). Koristite alate za profiliranje i trasiranje, filtrira vanjske pozive.
Možete koristiti programe poput netstat - uslužni program naredbenog retka koji prikazuje popis svih mrežnih veza (aktivnih utičnica) u sustavu. Na primjer, za popis svih trenutnih veza upišite:
❯ netstat -a | more
U AWS-u možete koristiti (zapisi protoka) VPC je metoda koja vam omogućuje prikupljanje informacija o IP prometu koji ide do ili od mrežnih sučelja u VPC-u. Takvi dnevnici mogu pomoći i u drugim zadacima – na primjer, traženju odgovora na pitanje zašto određeni promet ne dolazi do instance.
Također možete koristiti . X-zraka vam omogućuje detaljan, "ultimativan" (od kraja do kraja) pregled zahtjeva dok se kreću kroz aplikaciju, a također gradi mapu temeljnih komponenti aplikacije. Vrlo prikladno ako trebate identificirati ovisnosti.
AWS X-Ray konzola
Karta mrežne ovisnosti samo je djelomično rješenje. Da, pokazuje koja aplikacija s kojom komunicira, ali postoje i druge ovisnosti.
Mnoge aplikacije koriste DNS za povezivanje sa ovisnostima, dok druge mogu koristiti otkrivanje usluga ili čak tvrdo kodirane IP adrese u konfiguracijskim datotekama (npr. /etc/hosts).
Na primjer, možete stvoriti uz pomoć iptables i vidjeti što se lomi. Da biste to učinili, unesite sljedeću naredbu:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS crna rupa
Ako /etc/hosts ili druge konfiguracijske datoteke, pronaći ćete IP adrese o kojima ne znate ništa (da, nažalost, i to se događa), možete ponovno priskočiti u pomoć iptables. Recimo da ste otkrili 8.8.8.8 i ne znaju da je ovo Googleova javna adresa DNS poslužitelja. Pomoću iptables Možete blokirati dolazni i odlazni promet na ovu adresu pomoću sljedećih naredbi:
❯ 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"
Zatvaranje pristupa
Prvo pravilo ispušta sve pakete iz Googleovog javnog DNS-a: ping radi, ali se paketi ne vraćaju. Drugo pravilo ispušta sve pakete koji potječu iz vašeg sustava prema Googleovom javnom DNS-u - kao odgovor na ping dobivamo Operacija nije dopuštena.
Napomena: u ovom konkretnom slučaju bilo bi bolje koristiti whois 8.8.8.8, ali ovo je samo primjer.
Možemo ići još dublje u zečju rupu, jer sve što koristi TCP i UDP zapravo ovisi i o IP-u. U većini slučajeva IP je povezan s ARP-om. Ne zaboravite na vatrozid...
Ako uzmeš crvenu pilulu, ostat ćeš u zemlji čudesa, a ja ću ti pokazati koliko je duboka zečja rupa.”
Radikalniji pristup je da se odspojiti automobile jedan po jedan i vidite što je pokvareno... postanite "majmun kaosa." Naravno, mnogi proizvodni sustavi nisu dizajnirani za takav brutalni napad, ali barem se može isprobati u testnom okruženju.
Izrada karte ovisnosti često je vrlo dugotrajan pothvat. Nedavno sam razgovarao s klijentom koji je proveo gotovo 2 godine razvijajući alat koji poluautomatski generira karte ovisnosti za stotine mikroservisa i naredbi.
Rezultat je, međutim, iznimno zanimljiv i koristan. Naučit ćete mnogo o svom sustavu, njegovim ovisnostima i operacijama. Još jednom, budite strpljivi: najvažnije je samo putovanje.
3. Čuvajte se pretjeranog samopouzdanja
“Tko što sanja, u to i vjeruje.” — Demosten
Jeste li ikada čuli za učinak pretjeranog samopouzdanja?
Prema Wikipediji, učinak pretjeranog samopouzdanja je “kognitivna pristranost u kojoj je povjerenje osobe u svoje postupke i odluke znatno veće od objektivne točnosti tih prosudbi, osobito kada je razina povjerenja relativno visoka.”
Na temelju instinkta i iskustva...
Po mom iskustvu, ova distorzija je izvrstan savjet odakle započeti s inženjeringom kaosa.
Čuvajte se previše samouvjerenog operatera:
Charlie: "Ova stvar nije pala pet godina, sve je u redu!"
Crash: "Čekaj... Dolazim uskoro!"
Pristranost kao posljedica pretjeranog samopouzdanja podmukla je, pa čak i opasna stvar zbog raznih čimbenika koji na nju utječu. To je osobito istinito kada su članovi tima uložili srce u tehnologiju ili proveli puno vremena "popravljajući" je.
Sumirati
Potraga za polazištem za inženjering kaosa uvijek donosi više rezultata od očekivanih, a timovi koji prebrzo počnu razbijati stvari gube iz vida globalniju i zanimljiviju bit (kaosa-)inženjering - kreativna uporaba znanstvene metode и empirijski dokazi za dizajn, razvoj, rad, održavanje i poboljšanje (softverskih) sustava.
Ovim je drugi dio završen. Napišite recenzije, podijelite mišljenja ili samo pljesnite rukama . U sljedećem dijelu I stvarno Razmotrit ću alate i metode za uvođenje kvarova u sustave. Do!
PS od prevoditelja
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «".
Izvor: www.habr.com