Bilješka. transl.: Ovaj članak nastavlja sjajnu seriju članaka evanđeliste AWS tehnologije Adriana Hornsbyja, koji pokušava na jednostavan i jasan način objasniti važnost eksperimentiranja za ublažavanje posljedica kvarova u IT sistemima.
“Ako ne uspijete pripremiti plan, onda planirate neuspjeh.” - Benjamin Franklin
В U ovoj seriji članaka uveo sam koncept haos inženjeringa i objasnio kako pomaže da se pronađu i isprave nedostaci u sistemu prije nego što dovedu do kvarova u proizvodnji. Takođe se raspravljalo o tome kako haos inženjering promoviše pozitivne kulturne promjene unutar organizacija.
Na kraju prvog dijela obećao sam da ću govoriti o “alatima i metodama za uvođenje kvarova u sisteme”. Jao, moja glava je imala svoje planove u vezi s tim, a u ovom članku pokušat ću odgovoriti na najpopularnije pitanje koje se postavlja među ljudima koji žele ući u haos inženjering: Šta prvo razbiti?
Odlično pitanje! Međutim, čini se da mu ova panda ne smeta posebno...
Ne petljajte se sa pandom haosa!
Kratak odgovor: Ciljajte kritične usluge duž putanje zahtjeva.
Duži ali jasniji odgovor: Da biste razumjeli odakle početi eksperimentirati s haosom, obratite pažnju na tri područja:
- Pogledaj istorija sudara i identificirati obrasce;
- Odlučite se kritične zavisnosti;
- Koristite tzv efekat preteranog samopouzdanja.
Smiješno je, ali ovaj dio bi se isto tako lako mogao nazvati "Putovanje ka samootkrivanju i prosvetljenju". U njemu ćemo početi da se "sviramo" sa nekim cool instrumentima.
1. Odgovor leži u prošlosti
Ako se sjećate, u prvom dijelu sam predstavio koncept ispravljanja grešaka (COE) – metodu pomoću koje analiziramo naše greške – greške u tehnologiji, procesu ili organizaciji – kako bismo razumjeli njihov uzrok(e) i spriječili ponavljanje u budućnosti. Uopšteno govoreći, ovdje treba početi.
“Da biste razumjeli sadašnjost, morate znati prošlost.” — Carl Sagan
Pogledajte istoriju neuspjeha, označite ih u COE ili obdukcijama i klasificirajte ih. Identifikujte uobičajene obrasce koji često dovode do problema i za svaki COE postavite sebi sljedeće pitanje:
“Da li se ovo moglo predvidjeti i stoga spriječiti ubrizgavanjem greške?”
Sjećam se jednog neuspjeha na početku karijere. To se moglo lako spriječiti da smo izveli nekoliko jednostavnih eksperimenata kaosa:
U normalnim uslovima, pozadinske instance reaguju na zdravstvene provjere iz ). ELB koristi ove provjere za preusmjeravanje zahtjeva na zdrave instance. Kada se ispostavi da je instanca “nezdrava”, ELB prestaje da joj šalje zahtjeve. Jednog dana, nakon uspješne marketinške kampanje, obim prometa se povećao i backendovi su počeli da reagiraju na zdravstvene preglede sporije nego inače. Treba reći da su te zdravstvene kontrole bile , odnosno provjereno je stanje zavisnosti.
Međutim, neko vrijeme je sve bilo u redu.
Tada je, već pod prilično stresnim uslovima, jedna od instanci počela da izvršava nekritičan, regularan ETL cron zadatak. Kombinacija velikog prometa i cronjob-a povećala je iskorištenost CPU-a na skoro 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 na njega, što je zauzvrat dovelo do povećanja opterećenja na preostalim instancama u grupi.
Odjednom su i sve druge instance počele da propadaju na zdravstvenoj kontroli.
Pokretanje nove instance zahtijevalo je preuzimanje i instaliranje paketa i trajalo je mnogo duže nego što je bilo potrebno ELB-u da ih onesposobi – jednog po jednog – u grupi za automatsko skaliranje. Jasno je da je ubrzo cijeli proces dostigao kritičnu tačku i aplikacija je pala.
Tada smo zauvek razumeli sledeće tačke:
- Instaliranje softvera prilikom kreiranja nove instance traje dugo; bolje je dati prednost nepromjenjivom pristupu i .
- U složenim situacijama, odgovori na zdravstvene preglede i ELB-e trebali bi imati prioritet - posljednje što želite je da zakomplikujete život preostalim slučajevima.
- Lokalno keširanje zdravstvenih provjera puno pomaže (čak i na nekoliko sekundi).
- U teškoj situaciji nemojte pokretati cron zadatke i druge nekritične procese - uštedite resurse za najvažnije zadatke.
- Prilikom automatskog skaliranja koristite manje instance. Grupa od 10 malih primjeraka je bolja od grupe od 4 velika; ako jedna instanca ne uspe, u prvom slučaju 10% saobraćaja će biti raspoređeno na 9 tačaka, u drugom - 25% saobraćaja na tri tačke.
Tako da li se to moglo predvideti, pa samim tim i sprečiti uvođenjem problema?
Da, i to na nekoliko načina.
Prvo, simuliranjem velike upotrebe CPU-a pomoću alata kao što su ili :
❯ stress-ng --matrix 1 -t 60s
stres
Drugo, preopterećenjem instance sa i drugi slični uslužni programi:
❯ 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 pravog neuspjeha.
Međutim, nemoj stati tu. Pokušajte reproducirati pad u testnom okruženju i provjerite svoj odgovor na pitanje "Da li se to moglo predvidjeti i stoga spriječiti unošenjem kvara?" Ovo je mini eksperiment kaosa unutar eksperimenta kaosa za testiranje pretpostavki, ali počinje neuspjehom.
Da li je to bio san, ili se zaista dogodilo?
Zato proučite istoriju neuspjeha, analizirajte EOC, označite ih i klasificirajte prema "radijusu pogotka" - ili tačnije, broju pogođenih kupaca - a zatim potražite obrasce. Zapitajte se da li se to moglo predvidjeti i spriječiti uvođenjem problema. Provjerite svoj odgovor.
Zatim se prebacite na najčešće uzorke s najvećim rasponom.
2. Napravite mapu zavisnosti
Odvojite trenutak da razmislite o svojoj prijavi. Postoji li jasna mapa njegovih zavisnosti? Znate li kakav će uticaj imati ako dođe do neuspjeha?
Ako niste baš upoznati s kodom svoje aplikacije ili je postao jako velik, može biti teško razumjeti šta kod radi i koje su njegove zavisnosti. Razumijevanje ovih ovisnosti i njihovog mogućeg utjecaja na aplikaciju i korisnike je ključno za saznanje odakle početi s haos inženjeringom: početna tačka je komponenta s najvećim radijusom udara.
Identifikacija i dokumentovanje zavisnosti naziva se "pravljenje mape zavisnosti» (mapiranje zavisnosti). Ovo se obično radi za aplikacije sa velikom bazom koda koristeći alate za profilisanje koda. (profiliranje koda) i instrumentacija (instrumentacija). Također možete napraviti mapu praćenjem mrežnog prometa.
Međutim, nisu sve zavisnosti iste (što dodatno komplikuje proces). Neki kritičan, ostalo - sekundarno (barem u teoriji, budući da se kvarovi često događaju zbog problema s ovisnostima koje se smatraju nekritičnim).
Bez kritičnih zavisnosti, usluga ne može raditi. Nekritične zavisnosti "ne treba» da utiče na servis u slučaju pada. Da biste razumjeli zavisnosti, morate imati jasno razumijevanje API-ja koje koristi vaša aplikacija. Ovo može biti mnogo teže nego što se čini - barem za velike aplikacije.
Počnite tako što ćete proći kroz sve API-je. Istaknite najviše značajno i kritično. Uzmi zavisnosti iz skladišta kodova, provjerite evidencije veza, zatim pogledajte dokumentaciju (naravno, ako postoji - inače još uvijek imateоvećih problema). Koristite alate da profiliranje i praćenje, filtriranje eksternih poziva.
Možete koristiti programe poput netstat - uslužni program komandne linije koji prikazuje listu svih mrežnih veza (aktivnih utičnica) u sistemu. Na primjer, za popis svih trenutnih veza upišite:
❯ netstat -a | more
U AWS-u možete koristiti (Dnevnici toka) VPC je metoda koja vam omogućava da prikupite informacije o IP saobraćaju koji ide na ili sa mrežnih interfejsa u VPC-u. Takvi zapisnici mogu pomoći i kod drugih zadataka - na primjer, pronalaženje odgovora na pitanje zašto određeni promet ne stiže do instance.
Također možete koristiti . X-Ray vam omogućava da dobijete detaljan, "ultimatan" (s kraja na kraj) pregled zahtjeva dok se kreću kroz aplikaciju, a također gradi mapu osnovnih komponenti aplikacije. Vrlo zgodno ako trebate identificirati ovisnosti.
AWS X-Ray konzola
Mapa mrežne zavisnosti je samo djelomično rješenje. Da, pokazuje koja aplikacija komunicira s kojom, ali postoje i druge zavisnosti.
Mnoge aplikacije koriste DNS za povezivanje sa zavisnostima, dok druge mogu koristiti otkrivanje usluga ili čak tvrdo kodirane IP adrese u konfiguracionim datotekama (npr. /etc/hosts).
Na primjer, možete kreirati uz pomoć iptables i vidi šta se pokvari. 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
If in /etc/hosts ili druge konfiguracijske datoteke, naći ćete IP adrese o kojima ništa ne znate (da, nažalost, i to se dešava), možete ponovo priskočiti u pomoć iptables. Recimo da ste otkrili 8.8.8.8 i ne znam da je ovo Googleova javna adresa DNS servera. Korišćenjem iptables Možete blokirati dolazni i odlazni saobraćaj na ovu adresu koristeći sljedeće naredbe:
❯ 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 sa Googleovog javnog DNS-a: ping radi, ali se paketi ne vraćaju. Drugo pravilo ispušta sve pakete koji potiču iz vašeg sistema prema Googleovom javnom DNS-u - kao odgovor na ping dobijamo Rad nije dozvoljen.
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 zavisi i od IP-a. U većini slučajeva, IP je vezan za ARP. Ne zaboravite na firewall...
Ako uzmeš crvenu pilulu, ostaćeš u zemlji čuda, a ja ću ti pokazati koliko duboko ide zečja rupa."
Radikalniji pristup je da prekinuti vezu automobile jedan po jedan i vidite šta je pokvareno... postanite "majmun haosa." Naravno, mnogi proizvodni sistemi nisu dizajnirani za takav napad grubom silom, ali se barem može isprobati u test okruženju.
Izrada mape zavisnosti je često veoma dugotrajan poduhvat. Nedavno sam razgovarao sa klijentom koji je proveo skoro 2 godine razvijajući alat koji poluautomatski generiše mape zavisnosti za stotine mikroservisa i komandi.
Rezultat je, međutim, izuzetno zanimljiv i koristan. Naučit ćete mnogo o svom sistemu, njegovim ovisnostima i operacijama. Opet, budite strpljivi: samo putovanje je najvažnije.
3. Čuvajte se prevelikog samopouzdanja
"Ko o čemu sanja, u to vjeruje." — Demosten
Jeste li ikada čuli za efekat preteranog samopouzdanja?
Prema Wikipediji, efekat pretjeranog samopouzdanja je „kognitivna pristrasnost u kojoj je povjerenje osobe u svoje postupke i odluke znatno veće od objektivne tačnosti tih prosudbi, posebno kada je nivo samopouzdanja relativno visok.”
Na osnovu instinkta i iskustva...
Iz svog iskustva, mogu reći da je ovo izobličenje odličan nagovještaj o tome odakle početi sa inženjeringom haosa.
Čuvajte se previše samouvjerenog operatera:
Čarli: "Ova stvar nije pala pet godina, sve je u redu!"
Crash: "Čekaj... Dolazim uskoro!"
Pristrasnost kao posljedica pretjeranog samopouzdanja je podmukla, pa čak i opasna stvar zbog različitih faktora koji na nju utiču. Ovo je posebno tačno kada su članovi tima uložili svoje srce u tehnologiju ili su potrošili mnogo vremena na "popravljanje" iste.
Sažimanje
Potraga za početnom tačkom za inženjering haosa uvijek donosi više rezultata nego što se očekivalo, a timovi koji prebrzo počnu razbijati stvari gube iz vida globalniju i zanimljiviju suštinu (haosa-)inženjering - kreativna upotreba naučne metode и empirijski dokazi za projektovanje, razvoj, rad, održavanje i poboljšanje (softverskih) sistema.
Ovim je završen drugi dio. Napišite recenzije, podijelite mišljenja ili jednostavno pljesnite rukama . U narednom delu I stvarno Razmotriću alate i metode za uvođenje kvarova u sisteme. Do!
PS od prevodioca
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «".
izvor: www.habr.com