Tandaan. transl.: Ang artikulong ito ay nagpatuloy ng isang mahusay na serye ng mga artikulo mula sa AWS technology evangelist na si Adrian Hornsby, na naglalayong ipaliwanag sa simple at malinaw na paraan ang kahalagahan ng pag-eeksperimento upang mabawasan ang mga kahihinatnan ng mga pagkabigo sa mga IT system.
"Kung nabigo kang maghanda ng isang plano, plano mong mabigo." - Benjamin Franklin
В Sa seryeng ito ng mga artikulo, ipinakilala ko ang konsepto ng chaos engineering at ipinaliwanag kung paano ito nakakatulong upang mahanap at itama ang mga bahid sa system bago sila humantong sa mga pagkabigo sa produksyon. Tinalakay din nito kung paano itinataguyod ng chaos engineering ang positibong pagbabago sa kultura sa loob ng mga organisasyon.
Sa pagtatapos ng unang bahagi, ipinangako kong pag-usapan ang tungkol sa "mga tool at pamamaraan para sa pagpapakilala ng mga pagkabigo sa mga system." Sa kasamaang palad, ang aking ulo ay may sariling mga plano sa bagay na ito, at sa artikulong ito ay susubukan kong sagutin ang pinakasikat na tanong na lumitaw sa mga taong gustong pumasok sa chaos engineering: Ano ang unang i-break?
Mahusay na tanong! Gayunpaman, mukhang hindi siya partikular na nababahala sa panda na ito...
Huwag pakialaman ang kaguluhan panda!
Maikling sagot: Mag-target ng mga kritikal na serbisyo kasama ang landas ng kahilingan.
Mas mahaba ngunit mas malinaw na sagot: Upang maunawaan kung saan magsisimulang mag-eksperimento sa kaguluhan, bigyang-pansin ang tatlong bahagi:
- Tignan kasaysayan ng pag-crash at tukuyin ang mga pattern;
- Magpasya sa kritikal na dependencies;
- Gamitin ang tinatawag na epekto ng sobrang kumpiyansa.
Ito ay nakakatawa, ngunit ang bahaging ito ay madaling tawagin "Isang Paglalakbay sa Pagtuklas sa Sarili at Kaliwanagan". Sa loob nito magsisimula kaming "paglalaro" gamit ang ilang mga cool na instrumento.
1. Ang sagot ay nasa nakaraan
Kung naaalala mo, sa unang bahagi ay ipinakilala ko ang konsepto ng Correction-of-Errors (COE) - isang paraan kung saan sinusuri natin ang ating mga pagkakamali - mga pagkakamali sa teknolohiya, proseso o organisasyon - upang maunawaan ang kanilang (mga) dahilan at maiwasan ang pag-ulit sa hinaharap. Sa pangkalahatan, dito ka dapat magsimula.
"Upang maunawaan ang kasalukuyan, kailangan mong malaman ang nakaraan." — Carl Sagan
Tingnan ang kasaysayan ng mga pagkabigo, i-tag ang mga ito sa COE o postmortems at uriin ang mga ito. Tukuyin ang mga karaniwang pattern na kadalasang humahantong sa mga problema, at para sa bawat COE, tanungin ang iyong sarili ng sumusunod na tanong:
"Maaaring ito ay hinulaan at samakatuwid ay napigilan ng fault injection?"
Naaalala ko ang isang kabiguan sa unang bahagi ng aking karera. Madali itong napigilan kung nagsagawa kami ng ilang simpleng eksperimento sa kaguluhan:
Sa ilalim ng normal na mga kondisyon, ang mga backend na pagkakataon ay tumutugon sa mga pagsusuri sa kalusugan mula sa ). Ginagamit ng ELB ang mga pagsusuring ito upang i-redirect ang mga kahilingan sa mga malulusog na pagkakataon. Kapag lumabas na ang isang instance ay "hindi malusog", hihinto ang ELB sa pagpapadala ng mga kahilingan dito. Isang araw, pagkatapos ng matagumpay na kampanya sa marketing, tumaas ang dami ng trapiko at nagsimulang tumugon ang mga backend sa mga pagsusuri sa kalusugan nang mas mabagal kaysa karaniwan. Dapat sabihin na ang mga pagsusuring ito sa kalusugan ay , ibig sabihin, nasuri ang estado ng mga dependency.
Gayunpaman, ang lahat ay maayos sa ilang sandali.
Pagkatapos, sa ilalim na ng medyo nakababahalang mga kondisyon, ang isa sa mga pagkakataon ay nagsimulang magsagawa ng isang hindi kritikal, regular na gawain ng ETL cron. Ang kumbinasyon ng mataas na trapiko at cronjob ay nagtulak sa paggamit ng CPU sa halos 100%. Ang sobrang karga ng CPU ay lalong nagpabagal sa mga tugon sa mga pagsusuri sa kalusugan, kaya't nagpasya ang ELB na ang instance ay nakakaranas ng mga problema sa pagganap. Tulad ng inaasahan, ang balancer ay huminto sa pamamahagi ng trapiko dito, na, sa turn, ay humantong sa pagtaas ng pag-load sa mga natitirang pagkakataon sa grupo.
Biglang, lahat ng iba pang mga pagkakataon ay nagsimulang mabigo sa pagsusuri sa kalusugan.
Ang pagsisimula ng bagong instance ay nangangailangan ng pag-download at pag-install ng mga package at mas matagal kaysa sa ELB na hindi paganahin ang mga ito - isa-isa - sa autoscaling group. Ito ay malinaw na sa lalong madaling panahon ang buong proseso ay umabot sa isang kritikal na punto at ang aplikasyon ay nag-crash.
Pagkatapos ay naunawaan namin magpakailanman ang mga sumusunod na punto:
- Ang pag-install ng software kapag lumilikha ng isang bagong pagkakataon ay tumatagal ng mahabang panahon; mas mainam na bigyan ng kagustuhan ang hindi nababagong diskarte at .
- Sa mga kumplikadong sitwasyon, dapat unahin ang mga tugon sa mga pagsusuri sa kalusugan at ELB - ang huling bagay na gusto mo ay gawing kumplikado ang buhay para sa mga natitirang pagkakataon.
- Malaki ang naitutulong ng lokal na pag-cache ng mga pagsusuri sa kalusugan (kahit sa loob ng ilang segundo).
- Sa isang mahirap na sitwasyon, huwag magpatakbo ng mga gawain ng cron at iba pang hindi kritikal na proseso - mag-save ng mga mapagkukunan para sa pinakamahalagang gawain.
- Kapag nag-autoscale, gumamit ng mas maliliit na pagkakataon. Ang isang pangkat ng 10 maliliit na ispesimen ay mas mahusay kaysa sa isang pangkat ng 4 na malalaking; kung nabigo ang isang pagkakataon, sa unang kaso, 10% ng trapiko ang ibabahagi sa 9 puntos, sa pangalawa - 25% ng trapiko sa tatlong puntos.
Kaya, maaaring ito ay nahulaan, at samakatuwid ay napigilan sa pamamagitan ng pagpapakilala ng problema?
Oo, at sa maraming paraan.
Una, sa pamamagitan ng pagtulad sa mataas na paggamit ng CPU gamit ang mga tool tulad ng o :
❯ stress-ng --matrix 1 -t 60s
stress-ng
Pangalawa, sa pamamagitan ng pag-overload ng instance sa at iba pang katulad na mga kagamitan:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Ang mga eksperimento ay medyo simple, ngunit maaaring magbigay ng ilang magandang pagkain para sa pag-iisip nang hindi kinakailangang dumaan sa stress ng isang tunay na kabiguan.
Pero wag ka tumigil dyan. Subukang kopyahin ang pag-crash sa isang pagsubok na kapaligiran at suriin ang iyong sagot sa tanong na "Maaaring ito ay nahulaan at samakatuwid ay napigilan sa pamamagitan ng pagpapakilala ng isang pagkakamali?" Ito ay isang maliit na eksperimento sa kaguluhan sa loob ng isang eksperimento sa kaguluhan upang subukan ang mga pagpapalagay, ngunit nagsisimula sa isang pagkabigo.
Panaginip ba ito, o talagang nangyari?
Kaya pag-aralan ang kasaysayan ng mga pagkabigo, pag-aralan EOC, i-tag at uriin ang mga ito ayon sa “hit radius”—o mas tumpak, ang bilang ng mga customer na apektado—at pagkatapos ay maghanap ng mga pattern. Tanungin ang iyong sarili kung ito ay maaaring hinulaan at napigilan sa pamamagitan ng pagpapakilala ng problema. Suriin ang iyong sagot.
Pagkatapos ay lumipat sa pinakakaraniwang mga pattern na may pinakamalaking hanay.
2. Bumuo ng isang dependency map
Maglaan ng ilang sandali upang isipin ang tungkol sa iyong aplikasyon. Mayroon bang malinaw na mapa ng mga dependency nito? Alam mo ba kung ano ang magiging epekto nito kung may kabiguan?
Kung hindi ka masyadong pamilyar sa code ng iyong application o naging napakalaki nito, maaaring mahirap maunawaan kung ano ang ginagawa ng code at kung ano ang mga dependency nito. Ang pag-unawa sa mga dependency na ito at ang posibleng epekto nito sa application at mga user ay kritikal sa pag-alam kung saan magsisimula sa chaos engineering: ang panimulang punto ay ang bahaging may pinakamalaking impact radius.
Ang pagkilala at pagdodokumento ng mga dependency ay tinatawag na "pagbuo ng dependency map» (dependency mapping). Karaniwan itong ginagawa para sa mga application na may malaking code base gamit ang mga tool sa pag-profile ng code. (pag-profile ng code) at instrumentasyon (instrumentasyon). Maaari ka ring bumuo ng isang mapa sa pamamagitan ng pagsubaybay sa trapiko ng network.
Gayunpaman, hindi lahat ng mga dependency ay pareho (na higit pang nagpapalubha sa proseso). Ang ilan mapanganib, iba - pangalawa (hindi bababa sa teorya, dahil madalas na nangyayari ang mga pag-crash dahil sa mga problema sa mga dependency na itinuturing na hindi kritikal).
Kung walang mga kritikal na dependency, hindi gagana ang serbisyo. Mga hindi kritikal na dependencies "hindi dapat» upang maimpluwensyahan ang serbisyo kung sakaling mahulog. Upang maunawaan ang mga dependency, kailangan mong magkaroon ng malinaw na pag-unawa sa mga API na ginagamit ng iyong application. Ito ay maaaring maging mas mahirap kaysa sa tila - hindi bababa sa para sa malalaking aplikasyon.
Magsimula sa pamamagitan ng pagdaan sa lahat ng mga API. I-highlight ang pinaka makabuluhan at kritikal. Kunin dependencies mula sa imbakan ng code, tingnan ito mga log ng koneksyon, pagkatapos ay tingnan dokumentasyon (siyempre, kung mayroon - kung hindi, mayroon ka pa rinоmas malalaking problema). Gamitin ang mga kasangkapan upang pag-profile at pagsubaybay, i-filter ang mga panlabas na tawag.
Maaari kang gumamit ng mga programa tulad ng netstat - isang command line utility na nagpapakita ng listahan ng lahat ng mga koneksyon sa network (mga aktibong socket) sa system. Halimbawa, para ilista ang lahat ng kasalukuyang koneksyon, i-type ang:
❯ netstat -a | more
Sa AWS maaari mong gamitin (mga flow log) Ang VPC ay isang paraan na nagbibigay-daan sa iyong mangolekta ng impormasyon tungkol sa trapiko ng IP na papunta o mula sa mga interface ng network sa isang VPC. Makakatulong din ang mga naturang log sa iba pang mga gawain - halimbawa, paghahanap ng sagot sa tanong kung bakit hindi naaabot ng ilang trapiko ang instance.
Maaari mo ring gamitin . Pinapayagan ka ng X-Ray na makakuha ng detalyadong, "ultimate" (end-to-end) pangkalahatang-ideya ng mga kahilingan habang lumilipat ang mga ito sa application, at bumubuo rin ng mapa ng mga pinagbabatayan na bahagi ng application. Tunay na maginhawa kung kailangan mong tukuyin ang mga dependencies.
AWS X-Ray Console
Ang isang network dependency map ay isang bahagyang solusyon lamang. Oo, ipinapakita nito kung aling application ang nakikipag-ugnayan kung saan, ngunit may iba pang mga dependency.
Maraming mga application ang gumagamit ng DNS upang kumonekta sa mga dependency, habang ang iba ay maaaring gumamit ng pagtuklas ng serbisyo o kahit na mga hard-coded na IP address sa mga configuration file (hal. /etc/hosts).
Halimbawa, maaari kang lumikha sa tulong iptables at tingnan kung ano ang nasira. Upang gawin ito, ipasok ang sumusunod na command:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS black hole
Kung nasa /etc/hosts o iba pang mga configuration file, makakahanap ka ng mga IP address na hindi mo alam (oo, sa kasamaang-palad, nangyayari rin ito), maaari kang sumagip muli iptables. Sabihin nating natuklasan mo 8.8.8.8 at hindi alam na ito ang pampublikong DNS server address ng Google. Sa pamamagitan ng paggamit iptables Maaari mong harangan ang papasok at papalabas na trapiko sa address na ito gamit ang mga sumusunod na command:
❯ 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"
Pagsasara ng access
Ibinabagsak ng unang panuntunan ang lahat ng packet mula sa pampublikong DNS ng Google: ping gumagana, ngunit ang mga packet ay hindi ibinalik. Ibinabagsak ng pangalawang panuntunan ang lahat ng packet na nagmula sa iyong system patungo sa pampublikong DNS ng Google - bilang tugon sa ping nakukuha namin Hindi pinahihintulutan ang operasyon.
Tandaan: sa partikular na kaso ito ay mas mahusay na gamitin whois 8.8.8.8, ngunit ito ay isang halimbawa lamang.
Maaari tayong pumunta nang mas malalim sa butas ng kuneho, dahil lahat ng gumagamit ng TCP at UDP ay talagang nakadepende rin sa IP. Sa karamihan ng mga kaso, ang IP ay nakatali sa ARP. Huwag kalimutan ang tungkol sa mga firewall...
Kung uminom ka ng pulang tableta, manatili ka sa Wonderland, at ipapakita ko sa iyo kung gaano kalalim ang butas ng kuneho."
Ang isang mas radikal na diskarte ay ang idiskonekta mga kotse isa-isa at tingnan kung ano ang nasira... maging isang "chaos monkey." Siyempre, maraming mga sistema ng produksyon ay hindi idinisenyo para sa isang malupit na puwersa na pag-atake, ngunit hindi bababa sa maaari itong subukan sa isang pagsubok na kapaligiran.
Ang pagbuo ng isang dependency map ay kadalasang napakahabang gawain. Nakipag-usap ako kamakailan sa isang kliyente na gumugol ng halos 2 taon sa pagbuo ng isang tool na semi-awtomatikong bumubuo ng mga mapa ng dependency para sa daan-daang microservice at command.
Ang resulta, gayunpaman, ay lubhang kawili-wili at kapaki-pakinabang. Marami kang matututunan tungkol sa iyong system, mga dependency at pagpapatakbo nito. Muli, maging mapagpasensya: ang paglalakbay mismo ang pinakamahalaga.
3. Mag-ingat sa labis na pagtitiwala
"Ang sinumang nangangarap ng kung ano, naniniwala dito." — Demosthenes
Narinig mo na ba ang epekto ng sobrang kumpiyansa?
Ayon sa Wikipedia, ang epekto ng sobrang kumpiyansa ay "isang cognitive bias kung saan ang tiwala ng isang tao sa kanilang mga aksyon at desisyon ay higit na malaki kaysa sa layunin na katumpakan ng mga paghatol na iyon, lalo na kapag ang antas ng kumpiyansa ay medyo mataas."
Batay sa instinct at karanasan...
Sa aking karanasan, ang pagbaluktot na ito ay isang magandang pahiwatig kung saan magsisimula sa chaos engineering.
Mag-ingat sa sobrang kumpiyansa na operator:
Charlie: "Ang bagay na ito ay hindi nahulog sa loob ng limang taon, lahat ay maayos!"
Crash: “Teka... Pupunta na ako diyan!”
Ang pagkiling bilang resulta ng labis na kumpiyansa ay isang mapanlinlang at mapanganib na bagay dahil sa iba't ibang mga kadahilanan na nakakaimpluwensya dito. Ito ay totoo lalo na kapag ang mga miyembro ng koponan ay nagbuhos ng kanilang mga puso sa isang teknolohiya o gumugol ng maraming oras sa "pag-aayos" nito.
Summing up
Ang paghahanap para sa isang panimulang punto para sa chaos engineering ay palaging nagdudulot ng mas maraming resulta kaysa sa inaasahan, at ang mga team na nagsimulang sirain ang mga bagay-bagay ay masyadong mabilis na nalilimutan ang mas pandaigdigan at kawili-wiling esensya ng (chaos-)engineering - malikhaing paggamit siyentipikong pamamaraan и empirikal na ebidensya para sa disenyo, pagpapaunlad, pagpapatakbo, pagpapanatili at pagpapahusay ng (software) system.
Ito ang nagtatapos sa ikalawang bahagi. Mangyaring magsulat ng mga review, magbahagi ng mga opinyon o pumalakpak lamang . Sa susunod na bahagi I talaga Isasaalang-alang ko ang mga tool at pamamaraan para sa pagpapakilala ng mga pagkabigo sa mga system. Hanggang!
PS mula sa tagasalin
Basahin din sa aming blog:
- «";
- «";
- «";
- «'.
Pinagmulan: www.habr.com