Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa

PiezÄ«me. tulk.: Å is raksts turpina AWS tehnoloÄ£iju evaņģēlista Adriana Hornsbija lielisko rakstu sēriju, kura mērÄ·is ir vienkārŔā un skaidrā veidā izskaidrot eksperimentu nozÄ«mi, lai mazinātu IT sistēmu kļūmju sekas.

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa

"Ja jums neizdodas sagatavot plānu, jūs plānojat neizdoties." - Bendžamins Franklins

Š’ pirmā daļa Å ajā rakstu sērijā es iepazÄ«stināju ar haosa inženierijas jēdzienu un paskaidroju, kā tas palÄ«dz atrast un labot sistēmas trÅ«kumus, pirms tie noved pie ražoÅ”anas kļūmēm. Tajā arÄ« tika apspriests, kā haosa inženierija veicina pozitÄ«vas kultÅ«ras pārmaiņas organizācijās.

Pirmās daļas beigās es apsolÄ«ju runāt par "rÄ«kiem un metodēm kļūmju ievieÅ”anai sistēmās". Diemžēl manai galvai Å”ajā ziņā bija savi plāni, un Å”ajā rakstā es mēģināŔu atbildēt uz populārāko jautājumu, kas rodas starp cilvēkiem, kuri vēlas iekļūt haosa inženierijā: Ko vispirms lauzt?

Lielisks jautājums! Tomēr Ŕķiet, ka viņu Ŕī panda Ä«paÅ”i neuztrauc...

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa
Nejaucieties ar haosa pandu!

ÄŖsā atbilde: atlasiet kritiskos pakalpojumus pieprasÄ«juma ceļā.

Garāka, bet skaidrāka atbilde: Lai saprastu, kur sākt eksperimentēt ar haosu, pievērsiet uzmanību trim jomām:

  1. Paskaties avāriju vēsture un identificēt modeļus;
  2. Izlemt kritiskās atkarības;
  3. Izmantojiet tā saukto pārmērīgas pārliecības efekts.

Tas ir smieklÄ«gi, bet Å”o daļu tikpat viegli varētu nosaukt "Ceļojums uz sevis izzināŔanu un apgaismÄ«bu". Tajā sāksim ā€œspēlētiesā€ ar dažiem forÅ”iem instrumentiem.

1. Atbilde slēpjas pagātnē

Ja atceraties, pirmajā daļā es iepazÄ«stināju ar kļūdu laboÅ”anas (COE) jēdzienu - metodi, ar kuras palÄ«dzÄ«bu mēs analizējam savas kļūdas - kļūdas tehnoloÄ£ijā, procesā vai organizācijā -, lai izprastu to cēloni(s) un novērstu. atkārtoÅ”anās nākotnē. Kopumā tas ir tas, kur jums vajadzētu sākt.

"Lai saprastu tagadni, jums jāzina pagātne." ā€” Kārlis Sagans

Apskatiet kļūmju vēsturi, atzÄ«mējiet tās COE vai pēcnāves un klasificējiet tās. Nosakiet izplatÄ«tākos modeļus, kas bieži rada problēmas, un par katru COE uzdodiet sev Ŕādu jautājumu:

"Vai to varēja paredzēt un tāpēc novērst ar defektu injekciju?"

Es atceros vienu neveiksmi savas karjeras sākumā. To varēja viegli novērst, ja mēs bÅ«tu veikuÅ”i pāris vienkārÅ”us haosa eksperimentus:

Normālos apstākļos aizmugursistēmas instances reaģē uz veselÄ«bas pārbaudēm no slodzes balansētājs (ELB)). ELB izmanto Ŕīs pārbaudes, lai novirzÄ«tu pieprasÄ«jumus uz veseliem gadÄ«jumiem. Kad izrādās, ka instance ir ā€œneveselÄ«gaā€, ELB pārtrauc tai sÅ«tÄ«t pieprasÄ«jumus. Kādu dienu pēc veiksmÄ«gas mārketinga kampaņas satiksmes apjoms pieauga, un aizmugursistēmas sāka reaģēt uz veselÄ«bas pārbaudēm lēnāk nekā parasti. Jāsaka, ka Ŕīs veselÄ«bas pārbaudes bija dziļi, tas ir, tika pārbaudÄ«ts atkarÄ«bu stāvoklis.

Tomēr kādu laiku viss bija kārtībā.

Tad jau diezgan saspringtos apstākļos viens no gadÄ«jumiem sāka izpildÄ«t nekritisku, regulāru ETL cron uzdevumu. Liela trafika un cronjob kombinācija palielināja CPU noslogojumu lÄ«dz gandrÄ«z 100%. CPU pārslodze vēl vairāk palēnināja reakcijas uz veselÄ«bas pārbaudēm, tik ļoti, ka ELB nolēma, ka instancē ir veiktspējas problēmas. Kā gaidÄ«ts, balansētājs pārtrauca tam sadalÄ«t trafiku, kas, savukārt, palielināja atlikuÅ”o grupas gadÄ«jumu slodzi.

PēkŔņi arÄ« visas pārējās instances sāka izgāzties veselÄ«bas pārbaudē.

Jaunas instances palaiÅ”anai bija nepiecieÅ”ama pakotņu lejupielāde un instalÄ“Å”ana, un tas prasÄ«ja daudz ilgāku laiku, nekā vajadzēja ELB, lai tās pa vienam atspējotu automātiskās mērogoÅ”anas grupā. Skaidrs, ka drÄ«z vien viss process sasniedza kritisko punktu un aplikācija avarēja.

Tad mēs uz visiem laikiem sapratām Ŕādus punktus:

  • ProgrammatÅ«ras instalÄ“Å”ana, veidojot jaunu gadÄ«jumu, labāk ir dot priekÅ”roku nemainÄ«gai pieejai Zelta AMI.
  • Sarežģītās situācijās atbildēm uz veselÄ«bas pārbaudēm un ELB ir jābÅ«t prioritārām ā€” pēdējā lieta, ko vēlaties, ir sarežģīt dzÄ«vi atlikuÅ”ajiem gadÄ«jumiem.
  • Ä»oti palÄ«dz lokāla veselÄ«bas pārbaužu keÅ”atmiņa (pat uz dažām sekundēm).
  • Sarežģītā situācijā nepalaidiet cron uzdevumus un citus nekritiskus procesus - taupiet resursus svarÄ«gākajiem uzdevumiem.
  • Veicot automātisko mērogoÅ”anu, izmantojiet mazākus gadÄ«jumus. 10 mazu Ä«patņu grupa ir labāka nekā 4 lielu Ä«patņu grupa; ja viena instance neizdodas, pirmajā gadÄ«jumā 10% trafika tiks sadalÄ«ti pa 9 punktiem, otrajā - 25% trafika pa trim punktiem.

Tātad, vai to varēja paredzēt un tādējādi novērst, ievieÅ”ot problēmu?

Jā, un vairākos veidos.

Pirmkārt, simulējot augstu CPU izmantoÅ”anu, izmantojot tādus rÄ«kus kā stress-ng vai cpuburn:

āÆ stress-ng --matrix 1 -t 60s

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa
stress-ng

Otrkārt, pārslogojot instanci ar wrk un citi līdzīgi komunālie pakalpojumi:

āÆ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa

Eksperimenti ir salīdzinoŔi vienkārŔi, taču tie var sniegt labu vielu pārdomām, nepārdzīvojot patiesas neveiksmes radīto stresu.

Bet neapstājieties pie tā. Mēģiniet atveidot avāriju testa vidē un pārbaudiet savu atbildi uz jautājumu "Vai to varēja paredzēt un tāpēc novērst, ievieÅ”ot kļūdu?" Å is ir neliels haosa eksperiments haosa eksperimenta ietvaros, lai pārbaudÄ«tu pieņēmumus, taču sākot ar neveiksmi.

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa
Vai tas bija sapnis, vai tas tieŔām notika?

Tāpēc izpētiet neveiksmju vēsturi, analizējiet ĒD, atzÄ«mējiet un klasificējiet tos pēc ā€œtrāpÄ«juma rādiusaā€ jeb, precÄ«zāk, ietekmēto klientu skaita, un pēc tam meklējiet modeļus. Pajautājiet sev, vai to varēja paredzēt un novērst, iepazÄ«stinot ar problēmu. Pārbaudiet savu atbildi.

Pēc tam pārejiet uz visizplatītākajiem modeļiem ar lielāko diapazonu.

2. Izveidojiet atkarÄ«bas karti

Veltiet brīdi, lai pārdomātu savu pieteikumu. Vai ir skaidra tā atkarību karte? Vai jūs zināt, kāda būs to ietekme, ja notiks neveiksme?

Ja neesat ļoti iepazinies ar savas lietojumprogrammas kodu vai tas ir kļuvis ļoti liels, var bÅ«t grÅ«ti saprast, ko kods dara un kādas ir tā atkarÄ«bas. Izpratne par Ŕīm atkarÄ«bām un to iespējamo ietekmi uz lietojumprogrammu un lietotājiem ir ļoti svarÄ«ga, lai zinātu, kur sākt ar haosa inženieriju: sākumpunkts ir komponents ar lielāko trieciena rādiusu.

AtkarÄ«bu identificÄ“Å”ana un dokumentÄ“Å”ana tiek saukta par "atkarÄ«bas kartes izveideĀ» (atkarÄ«bas kartÄ“Å”ana). Parasti tas tiek darÄ«ts lietojumprogrammām ar lielu kodu bāzi, izmantojot kodu profilÄ“Å”anas rÄ«kus. (koda profilÄ“Å”ana) un instrumentācija (instrumenti). Varat arÄ« izveidot karti, uzraugot tÄ«kla trafiku.

Tomēr ne visas atkarības ir vienādas (kas vēl vairāk sarežģī procesu). Dažas kritisks, cits - sekundārais (vismaz teorētiski, jo avārijas bieži notiek tādu atkarību problēmu dēļ, kuras tika uzskatītas par nekritiskām).

Bez kritiskām atkarÄ«bām pakalpojums nevar darboties. Nekritiskas atkarÄ«bas "nevajadzētuĀ» ietekmēt pakalpojumu kritiena gadÄ«jumā. Lai izprastu atkarÄ«bas, jums ir jābÅ«t skaidrai izpratnei par jÅ«su lietojumprogrammas izmantotajām API. Tas var bÅ«t daudz grÅ«tāk, nekā Ŕķiet ā€“ vismaz lieliem lietojumiem.

Sāciet, izpētot visas API. Izcelt visvairāk nozÄ«mÄ«gs un kritisks... Ņem atkarÄ«bas no kodu krātuves, pārbaudiet to savienojumu žurnāli, pēc tam skatiet dokumentācija (protams, ja tas pastāv - pretējā gadÄ«jumā jums joprojām irŠ¾lielākas problēmas). Izmantojiet rÄ«kus, lai profilÄ“Å”ana un izsekoÅ”ana, filtrējiet ārējos zvanus.

Varat izmantot tādas programmas kā netstat - komandrindas utilÄ«ta, kas parāda visu sistēmas tÄ«kla savienojumu (aktÄ«vās ligzdas) sarakstu. Piemēram, lai uzskaitÄ«tu visus paÅ”reizējos savienojumus, ierakstiet:

āÆ netstat -a | more 

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa

AWS varat izmantot plÅ«smas žurnāli (plÅ«smas žurnāli) VPC ir metode, kas ļauj apkopot informāciju par IP trafiku, kas iet uz vai no VPC tÄ«kla saskarnēm. Šādi žurnāli var palÄ«dzēt arÄ« citos uzdevumos ā€“ piemēram, meklējot atbildi uz jautājumu, kāpēc noteikta trafika nesasniedz instanci.

Varat arÄ« izmantot AWS rentgens. X-Ray ļauj iegÅ«t detalizētu, "galÄ«go" (no gala lÄ«dz galam) pārskatu par pieprasÄ«jumiem, kad tie pārvietojas lietojumprogrammā, kā arÄ« izveido lietojumprogrammas pamatā esoÅ”o komponentu karti. Ä»oti ērti, ja nepiecieÅ”ams noteikt atkarÄ«bas.

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa
AWS rentgena konsole

Tīkla atkarības karte ir tikai daļējs risinājums. Jā, tas parāda, kura lietojumprogramma ar kuru sazinās, taču ir arī citas atkarības.

Daudzas lietojumprogrammas izmanto DNS, lai izveidotu savienojumu ar atkarÄ«bām, savukārt citas var izmantot pakalpojumu atklāŔanu vai pat cieti kodētas IP adreses konfigurācijas failos (piem., /etc/hosts).

Piemēram, jÅ«s varat izveidot DNS melnais caurums via iptables un paskaties, kas saplÄ«st. Lai to izdarÄ«tu, ievadiet Ŕādu komandu:

āÆ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa
DNS melnais caurums

Ja /etc/hosts vai citus konfigurācijas failus, jÅ«s atradÄ«sit IP adreses, par kurām jÅ«s neko nezināt (jā, diemžēl, tā arÄ« notiek), varat atkal nākt palÄ«gā iptables. Pieņemsim, ka esat atklājis 8.8.8.8 un nezina, ka Ŕī ir Google publiskā DNS servera adrese. Izmantojot iptables Varat bloķēt ienākoÅ”o un izejoÅ”o trafiku uz Å”o adresi, izmantojot Ŕādas komandas:

āÆ 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"

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa
Tiek slēgta piekļuve

Pirmais noteikums noņem visas paketes no Google publiskā DNS: ping darbojas, bet paketes netiek atgrieztas. Otrais noteikums pamet visas paketes, kas nāk no jÅ«su sistēmas uz Google publisko DNS ā€” atbildot uz ping mēs saņemam DarbÄ«ba nav atļauta.

PiezÄ«me: Å”ajā konkrētajā gadÄ«jumā to bÅ«tu labāk izmantot whois 8.8.8.8, bet tas ir tikai piemērs.

Mēs varam iet vēl dziļāk truÅ”a bedrē, jo viss, kas izmanto TCP un UDP, faktiski ir atkarÄ«gs arÄ« no IP. Vairumā gadÄ«jumu IP ir piesaistÄ«ts ARP. Neaizmirstiet par ugunsmÅ«riem...

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa
Ja iedzersi sarkano tableti, tu paliksi BrÄ«numzemē, un es tev parādÄ«Å”u, cik dziļa ir truÅ”a bedre.

Radikālāka pieeja ir atvienot maŔīnas pa vienai un redzēt, kas salauzts... kļūsti par "haosa mērkaÄ·i". Protams, daudzas ražoÅ”anas sistēmas nav paredzētas Ŕādam brutāla spēka uzbrukumam, bet vismaz to var izmēģināt testa vidē.

AtkarÄ«bas kartes izveide bieži ir ļoti ilgstoÅ”s pasākums. Es nesen runāju ar klientu, kurÅ” gandrÄ«z divus gadus pavadÄ«ja, izstrādājot rÄ«ku, kas pusautomātiski Ä£enerē atkarÄ«bas kartes simtiem mikropakalpojumu un komandu.

Tomēr rezultāts ir ļoti interesants un noderīgs. Jūs uzzināsiet daudz par savu sistēmu, tās atkarībām un darbībām. Vēlreiz esiet pacietīgs: pats ceļojums ir vissvarīgākais.

3. Sargieties no pārmērÄ«gas paÅ”pārliecinātÄ«bas

"Kas par ko sapņo, tas tam tic." ā€” Dēmostens

Vai esat kādreiz dzirdējuÅ”i par pārmērÄ«gas pārliecÄ«bas efekts?

Saskaņā ar Vikipēdiju, pārmērÄ«gas paÅ”pārliecinātÄ«bas efekts ir "kognitÄ«va novirze, kurā personas pārliecÄ«ba par savām darbÄ«bām un lēmumiem ir ievērojami lielāka par Å”o spriedumu objektÄ«vo precizitāti, Ä«paÅ”i, ja pārliecÄ«bas lÄ«menis ir salÄ«dzinoÅ”i augsts."

Haosa inženierija: apzinātas iznīcināŔanas māksla. 2. daļa
Balstīts uz instinktu un pieredzi...

No savas pieredzes varu teikt, ka Ŕī kropļoŔana ir lielisks mājiens, kur sākt ar haosa inženieriju.

Uzmanieties no pārāk paŔpārliecināta operatora:

Čārlijs: "Šī lieta nav kritusi piecus gadus, viss ir kārtībā!"
Avārija: "Pagaidiet... Es drīz būŔu klāt!"

Neobjektivitāte kā pārmērÄ«gas paÅ”pārliecinātÄ«bas sekas ir mānÄ«ga un pat bÄ«stama lieta dažādu to ietekmējoÅ”o faktoru dēļ. Tas jo Ä«paÅ”i attiecas uz gadÄ«jumiem, kad komandas dalÄ«bnieki ir ielikuÅ”i sirdi tehnoloÄ£ijā vai veltÄ«juÅ”i daudz laika tās ā€œlaboÅ”anaiā€.

Summējot

Haosa inženierijas sākumpunkta meklÄ“Å”ana vienmēr sniedz vairāk rezultātu, nekā gaidÄ«ts, un komandas, kuras pārāk ātri sāk lauzt lietas, aizmirst par globālāko un interesantāko (haosa-) bÅ«tÄ«bu.inženierzinātnes - radoÅ”a izmantoÅ”ana zinātniskās metodes Šø empÄ«riski pierādÄ«jumi (programmatÅ«ras) sistēmu projektÄ“Å”anai, izstrādei, ekspluatācijai, uzturÄ“Å”anai un uzlaboÅ”anai.

Ar to noslēdzas otrā daļa. LÅ«dzu, rakstiet atsauksmes, dalieties viedokļos vai vienkārÅ”i uzsitiet plaukstas vidējs. Nākamajā daļā I tieŔām Es apsvērÅ”u rÄ«kus un metodes kļūmju ievieÅ”anai sistēmās. LÄ«dz!

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru