Kumbuka. tafsiri.: Makala haya yanaendelea na mfululizo mzuri wa makala kutoka kwa mwinjilisti wa teknolojia ya AWS Adrian Hornsby, ambaye anajitolea kueleza kwa njia rahisi na wazi umuhimu wa majaribio ili kupunguza matokeo ya kushindwa katika mifumo ya TEHAMA.
"Ikiwa utashindwa kuandaa mpango, basi unapanga kutofaulu." - Benjamin Franklin
В Katika mfululizo huu wa makala, nilianzisha dhana ya uhandisi wa machafuko na kuelezea jinsi inavyosaidia kupata na kurekebisha dosari katika mfumo kabla ya kusababisha kushindwa kwa uzalishaji. Pia ilijadili jinsi uhandisi wa machafuko unavyokuza mabadiliko chanya ya kitamaduni ndani ya mashirika.
Mwishoni mwa sehemu ya kwanza, niliahidi kuzungumza juu ya "zana na mbinu za kuanzisha kushindwa katika mifumo." Ole, kichwa changu kilikuwa na mipango yake katika suala hili, na katika makala hii nitajaribu kujibu swali maarufu zaidi ambalo linatokea kati ya watu ambao wanataka kuingia katika uhandisi wa machafuko: Nini cha kuvunja kwanza?
Swali kubwa! Walakini, haonekani kusumbuliwa haswa na panda hii ...
Usichanganye na machafuko panda!
Jibu fupi: Lenga huduma muhimu kwenye njia ya ombi.
Jibu refu lakini wazi zaidi: Ili kuelewa ni wapi pa kuanza kujaribu na machafuko, makini na maeneo matatu:
- Angalia katika historia ya ajali na kutambua mifumo;
- Amua utegemezi muhimu;
- Tumia kinachojulikana athari ya kujiamini kupita kiasi.
Inafurahisha, lakini sehemu hii inaweza kuitwa kwa urahisi "Safari ya Kujigundua na Kuelimika". Ndani yake tutaanza "kucheza" na vyombo vingine vya baridi.
1. Jibu liko katika siku za nyuma
Ikiwa unakumbuka, katika sehemu ya kwanza nilianzisha dhana ya Marekebisho-ya-Makosa (COE) - njia ambayo tunachambua makosa yetu - makosa katika teknolojia, mchakato au shirika - ili kuelewa sababu zao na kuzuia. kujirudia katika siku zijazo. Kwa ujumla, hapa ndipo unapaswa kuanza.
"Ili kuelewa sasa, unahitaji kujua yaliyopita." - Carl Sagan
Angalia historia ya kushindwa, weka alama kwenye COE au postmortems na uziainishe. Tambua mifumo ya kawaida ambayo mara nyingi husababisha matatizo, na kwa kila COE, jiulize swali lifuatalo:
"Je, hii inaweza kutabiriwa na kwa hivyo kuzuiwa kwa sindano ya makosa?"
Nakumbuka kushindwa moja mapema katika kazi yangu. Ingeweza kuzuiwa kwa urahisi ikiwa tungefanya majaribio kadhaa rahisi ya machafuko:
Katika hali ya kawaida, matukio ya nyuma hujibu ukaguzi wa afya kutoka ) ELB hutumia ukaguzi huu kuelekeza maombi kwenye hali nzuri. Inapobainika kuwa mfano "sio sawa", ELB huacha kutuma maombi kwake. Siku moja, baada ya kampeni ya uuzaji iliyofanikiwa, idadi ya trafiki iliongezeka na sehemu za nyuma zilianza kujibu ukaguzi wa afya polepole zaidi kuliko kawaida. Inapaswa kuwa alisema kuwa hundi hizi za afya zilikuwa , yaani, hali ya utegemezi iliangaliwa.
Walakini, kila kitu kilikuwa sawa kwa muda.
Halafu, tayari chini ya hali zenye mkazo, moja ya visa ilianza kutekeleza kazi isiyo ya muhimu, ya kawaida ya ETL cron. Mchanganyiko wa trafiki ya juu na cronjob ulisukuma utumiaji wa CPU hadi karibu 100%. Upakiaji mwingi wa CPU ulipunguza kasi ya majibu kwa ukaguzi wa afya, hivi kwamba ELB iliamua kuwa mfano huo ulikuwa na matatizo ya utendaji. Kama inavyotarajiwa, mratibu aliacha kusambaza trafiki kwake, ambayo, kwa upande wake, ilisababisha kuongezeka kwa mzigo kwenye matukio yaliyobaki kwenye kikundi.
Ghafla, matukio mengine yote pia yalianza kushindwa kuangalia afya.
Kuanzisha mfano mpya kulihitaji kupakua na kusakinisha vifurushi na ilichukua muda mrefu zaidi kuliko ilichukua ELB kuzima - moja baada ya nyingine - katika kikundi cha kuongeza kasi kiotomatiki. Ni wazi kwamba hivi karibuni mchakato mzima ulifikia hatua muhimu na maombi yakaanguka.
Kisha tulielewa mambo yafuatayo milele:
- Kufunga programu wakati wa kuunda mfano mpya huchukua muda mrefu; ni bora kutoa upendeleo kwa mbinu isiyobadilika na .
- Katika hali ngumu, majibu ya ukaguzi wa afya na ELB yanapaswa kupewa kipaumbele - jambo la mwisho unalotaka ni kutatiza maisha kwa matukio yaliyosalia.
- Uhifadhi wa ndani wa ukaguzi wa afya husaidia sana (hata kwa sekunde chache).
- Katika hali ngumu, usikimbie kazi za cron na michakato mingine isiyo muhimu - hifadhi rasilimali kwa kazi muhimu zaidi.
- Wakati wa kuongeza otomatiki, tumia matukio madogo. Kundi la vielelezo vidogo 10 ni bora kuliko kundi la 4 kubwa; ikiwa tukio moja litashindwa, katika kesi ya kwanza 10% ya trafiki itasambazwa zaidi ya pointi 9, kwa pili - 25% ya trafiki juu ya pointi tatu.
Hivyo, hii inaweza kutabiriwa, na kwa hivyo kuzuiwa kwa kuanzisha shida?
Да, na kwa njia kadhaa.
Kwanza, kwa kuiga matumizi ya juu ya CPU kwa kutumia zana kama vile au :
❯ stress-ng --matrix 1 -t 60s
dhiki-ng
Pili, kwa kupakia mfano na na huduma zingine zinazofanana:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Majaribio ni rahisi kiasi, lakini yanaweza kutoa chakula kizuri cha mawazo bila kulazimika kupitia mkazo wa kutofaulu kweli.
Lakini usiishie hapo. Jaribu kutoa tena ajali katika mazingira ya majaribio na uangalie jibu lako kwa swali "Je, hii inaweza kutabiriwa na hivyo kuzuiwa kwa kuanzisha kosa?" Hili ni jaribio la machafuko madogo ndani ya jaribio la machafuko ili kujaribu mawazo, lakini kwa kuanzia na kutofaulu.
Ilikuwa ni ndoto, au ilifanyika kweli?
Kwa hiyo soma historia ya kushindwa, kuchambua EOC, ziweke tagi na uziainishe kwa “radius ya kugonga”—au kwa usahihi zaidi, idadi ya wateja walioathiriwa—kisha utafute ruwaza. Jiulize kama hili lingeweza kutabiriwa na kuzuiwa kwa kuanzisha tatizo. Angalia jibu lako.
Kisha ubadilishe hadi mifumo inayojulikana zaidi iliyo na safu kubwa zaidi.
2. Jenga ramani ya utegemezi
Chukua muda kufikiria kuhusu ombi lako. Kuna ramani wazi ya utegemezi wake? Je, unajua watakuwa na athari gani iwapo kutakuwa na kushindwa?
Ikiwa hujui sana msimbo wa programu yako au imekuwa kubwa sana, inaweza kuwa vigumu kuelewa kanuni hufanya nini na utegemezi wake ni nini. Kuelewa tegemezi hizi na athari zake zinazowezekana kwa programu na watumiaji ni muhimu ili kujua wapi pa kuanzia na uhandisi wa machafuko: mahali pa kuanzia ni sehemu yenye radius kubwa zaidi ya athari.
Kutambua na kuweka kumbukumbu za utegemezi huitwa "kujenga ramani ya utegemezi» (ramani ya utegemezi). Hii kwa kawaida hufanywa kwa programu zilizo na msingi mkubwa wa nambari kwa kutumia zana za kuorodhesha za msimbo. (uwekaji wasifu wa msimbo) na vyombo (chombo). Unaweza pia kuunda ramani kwa kufuatilia trafiki ya mtandao.
Walakini, sio utegemezi wote ni sawa (ambayo inachanganya zaidi mchakato). Baadhi muhimu, nyingine - sekondari (angalau kinadharia, kwani ajali mara nyingi hutokea kwa sababu ya matatizo na utegemezi ambao ulionekana kuwa sio muhimu).
Bila utegemezi muhimu, huduma haiwezi kufanya kazi. Utegemezi usio muhimu "haipaswi»kushawishi huduma katika tukio la kuanguka. Ili kuelewa utegemezi, unahitaji kuwa na ufahamu wazi wa API zinazotumiwa na programu yako. Hii inaweza kuwa ngumu zaidi kuliko inavyoonekana - angalau kwa programu kubwa.
Anza kwa kupitia API zote. Angazia zaidi muhimu na muhimu. Chukua utegemezi kutoka kwa hazina ya nambari, angalia kumbukumbu za uunganisho, kisha tazama nyaraka (kwa kweli, ikiwa iko - vinginevyo bado unayoоmatatizo makubwa). Tumia zana kwa wasifu na ufuatiliaji, chuja simu za nje.
Unaweza kutumia programu kama vile netstat - matumizi ya mstari wa amri ambayo inaonyesha orodha ya viunganisho vyote vya mtandao (soketi zinazofanya kazi) kwenye mfumo. Kwa mfano, kuorodhesha miunganisho yote ya sasa, chapa:
❯ netstat -a | more
Katika AWS unaweza kutumia (logi za mtiririko) VPC ni njia inayokuruhusu kukusanya taarifa kuhusu trafiki ya IP kwenda au kutoka kwa violesura vya mtandao katika VPC. Kumbukumbu kama hizo zinaweza pia kusaidia kwa kazi zingine - kwa mfano, kutafuta jibu kwa swali la kwa nini trafiki fulani haifikii mfano.
Unaweza pia kutumia . X-Ray hukuruhusu kupata maelezo ya kina, "mwisho" (mwisho-mwisho) muhtasari wa maombi wanapopitia programu, na pia huunda ramani ya vipengele vya msingi vya programu. Inafaa sana ikiwa unahitaji kutambua utegemezi.
AWS X-Ray Console
Ramani ya utegemezi wa mtandao ni suluhisho la sehemu tu. Ndio, inaonyesha ni programu gani inawasiliana na ipi, lakini kuna vitegemezi vingine.
Programu nyingi hutumia DNS kuunganisha kwa vitegemezi, ilhali zingine zinaweza kutumia ugunduzi wa huduma au hata anwani za IP zenye msimbo mgumu katika faili za usanidi (k.m. /etc/hosts).
Kwa mfano, unaweza kuunda na msaada iptables na kuona nini mapumziko. Ili kufanya hivyo, ingiza amri ifuatayo:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS shimo nyeusi
Ikiwa ndani /etc/hosts au faili zingine za usanidi, utapata anwani za IP ambazo hujui chochote (ndio, kwa bahati mbaya, hii pia hufanyika), unaweza kuja kuwaokoa tena. iptables. Tuseme umegundua 8.8.8.8 na sijui kuwa hii ni anwani ya seva ya DNS ya umma ya Google. Kwa kutumia iptables Unaweza kuzuia trafiki inayoingia na kutoka kwa anwani hii kwa kutumia amri zifuatazo:
❯ 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"
Inafunga ufikiaji
Sheria ya kwanza hutupa pakiti zote kutoka kwa DNS ya umma ya Google: ping inafanya kazi, lakini pakiti hazirudishwi. Sheria ya pili inaangusha pakiti zote zinazotoka kwenye mfumo wako kuelekea DNS ya umma ya Google - kwa kujibu ping tunapata Uendeshaji hauruhusiwi.
Kumbuka: katika kesi hii itakuwa bora kutumia whois 8.8.8.8, lakini huu ni mfano tu.
Tunaweza kwenda chini zaidi kwenye shimo la sungura, kwa sababu kila kitu kinachotumia TCP na UDP kinategemea IP pia. Katika hali nyingi, IP imefungwa kwa ARP. Usisahau kuhusu firewalls ...
Ukimeza kidonge chekundu, ubaki Wonderland, na nitakuonyesha jinsi shimo la sungura linaingia ndani."
Mbinu kali zaidi ni kukatwa magari moja baada ya nyingine na kuona nini ni kuvunjwa ... kuwa "tumbili machafuko." Kwa kweli, mifumo mingi ya uzalishaji haijaundwa kwa shambulio kama hilo la nguvu, lakini angalau inaweza kujaribiwa katika mazingira ya majaribio.
Kujenga ramani tegemezi mara nyingi ni kazi ndefu sana. Hivi majuzi nilizungumza na mteja ambaye alitumia karibu miaka 2 kutengeneza zana ambayo nusu-otomatiki hutoa ramani za utegemezi kwa mamia ya huduma ndogo na amri.
Matokeo yake, hata hivyo, ni ya kuvutia sana na yenye manufaa. Utajifunza mengi kuhusu mfumo wako, utegemezi wake na uendeshaji. Tena, kuwa na subira: ni safari yenyewe ambayo ni muhimu zaidi.
3. Jihadhari na kujiamini kupita kiasi
"Yeyote anayeota nini, anaamini." - Demosthenes
Je, umewahi kusikia athari ya kujiamini kupita kiasi?
Kulingana na Wikipedia, athari ya kujiamini kupita kiasi ni "upendeleo wa utambuzi ambapo imani ya mtu katika matendo na maamuzi yake ni kubwa zaidi kuliko usahihi wa makusudi wa hukumu hizo, haswa wakati kiwango cha kujiamini ni cha juu."
Kulingana na silika na uzoefu...
Katika uzoefu wangu, upotoshaji huu ni wazo nzuri la wapi kuanza na uhandisi wa machafuko.
Jihadharini na mwendeshaji anayejiamini kupita kiasi:
Charlie: "Jambo hili halijaanguka kwa miaka mitano, kila kitu kiko sawa!"
Ajali: "Subiri ... nitafika hivi karibuni!"
Upendeleo kama matokeo ya kujiamini kupita kiasi ni jambo la siri na hata hatari kutokana na sababu mbalimbali zinazoiathiri. Hii ni kweli hasa wakati washiriki wa timu wamemimina mioyo yao kwenye teknolojia au walitumia muda mwingi "kuirekebisha".
Kwa muhtasari
Utafutaji wa mahali pa kuanzia kwa uhandisi wa machafuko daima huleta matokeo zaidi kuliko inavyotarajiwa, na timu zinazoanza kuvunja mambo haraka sana hupoteza mtazamo wa kiini cha kimataifa na cha kuvutia zaidi cha (machafuko-)Uhandisi - matumizi ya ubunifu mbinu za kisayansi и ushahidi wa kimajaribio kwa ajili ya kubuni, kuendeleza, uendeshaji, matengenezo na uboreshaji wa (programu) mifumo.
Hii inahitimisha sehemu ya pili. Tafadhali andika hakiki, shiriki maoni au piga tu mikono yako . Katika sehemu inayofuata I kweli Nitazingatia zana na mbinu za kuanzisha kushindwa katika mifumo. Mpaka!
PS kutoka kwa mtafsiri
Soma pia kwenye blogi yetu:
- «";
- «";
- «";
- «'.
Chanzo: mapenzi.com