Athugið. þýð.: Þessi grein heldur áfram frábærri greinaröð frá AWS tækniboðskapnum Adrian Hornsby, sem ætlar sér að útskýra á einfaldan og skýran hátt mikilvægi tilrauna til að draga úr afleiðingum bilana í upplýsingatæknikerfum.
"Ef þér tekst ekki að undirbúa áætlun, þá ætlarðu að mistakast." - Benjamín Franklín
В Í þessari greinaröð kynnti ég hugmyndina um óreiðuverkfræði og útskýrði hvernig það hjálpar að finna og leiðrétta galla í kerfinu áður en þeir leiða til framleiðslubilunar. Einnig var fjallað um hvernig glundroðaverkfræði stuðlar að jákvæðum menningarbreytingum innan stofnana.
Í lok fyrri hlutans lofaði ég að tala um „verkfæri og aðferðir til að koma bilunum inn í kerfi“. Því miður, höfuð mitt hafði sínar eigin áætlanir í þessu sambandi, og í þessari grein mun ég reyna að svara vinsælustu spurningunni sem vaknar meðal fólks sem vill komast í glundroðaverkfræði: Hvað á að brjóta fyrst?
Frábær spurning! Hins vegar virðist hann ekkert vera að trufla þessa pöndu...
Ekki skipta þér af óreiðupöndunni!
Stutt svar: Miðaðu á mikilvæga þjónustu eftir beiðnileiðinni.
Lengra en skýrara svar: Til að skilja hvar á að byrja að gera tilraunir með glundroða skaltu fylgjast með þremur sviðum:
- Horfðu á hrunsaga og bera kennsl á mynstur;
- Ákveða mikilvægar ósjálfstæðir;
- Notaðu svokallaða oftrúaráhrif.
Það er fyndið en það mætti alveg eins kalla þennan þátt "Ferð til sjálfsuppgötvunar og uppljómunar". Í henni munum við byrja að „leika“ með flott hljóðfæri.
1. Svarið liggur í fortíðinni
Ef þú manst, í fyrri hlutanum kynnti ég hugtakið Correction-of-Errors (COE) - aðferð þar sem við greinum mistök okkar - mistök í tækni, ferli eða skipulagi - til að skilja orsök þeirra og koma í veg fyrir endurtekning í framtíðinni. Almennt séð er þetta þar sem þú ættir að byrja.
"Til að skilja nútíðina þarftu að þekkja fortíðina." — Carl Sagan
Skoðaðu sögu bilana, merktu þær í COE eða postmortems og flokkaðu þær. Þekkja algeng mynstur sem oft leiða til vandamála og fyrir hvern COE skaltu spyrja sjálfan þig eftirfarandi spurningar:
„Hefði verið hægt að spá fyrir um þetta og því koma í veg fyrir þetta með bilunarsprautun?
Ég man eftir einni bilun snemma á ferlinum. Það hefði auðveldlega verið hægt að koma í veg fyrir það ef við hefðum gert nokkrar einfaldar glundroðatilraunir:
Við venjulegar aðstæður bregðast bakendatilvik við heilsufarsskoðun frá ). ELB notar þessar athuganir til að beina beiðnum til heilbrigðra tilvika. Þegar það kemur í ljós að tilvik er „óhollt“ hættir ELB að senda beiðnir til þess. Dag einn, eftir vel heppnaða markaðsherferð, jókst umferðarmagnið og bakendarnir fóru að bregðast hægar við heilsufarsskoðunum en venjulega. Það skal tekið fram að þessar heilsufarsskoðanir voru það , það er að segja að ástand ósjálfstæðis var athugað.
Hins vegar var allt í lagi um tíma.
Síðan, þegar við frekar streituvaldandi aðstæður, byrjaði eitt tilvikanna að framkvæma ó- mikilvægt, reglulegt ETL cron verkefni. Sambland af mikilli umferð og cronjob ýtti CPU nýtingu niður í næstum 100%. Ofhleðsla CPU hægði enn á svörum við heilsufarsskoðunum, svo mikið að ELB ákvað að tilvikið ætti í frammistöðuvandamálum. Eins og við var að búast hætti jafnvægisaðilinn að dreifa umferð til hans, sem aftur leiddi til aukins álags á þau tilvik sem eftir voru í hópnum.
Skyndilega fóru öll önnur tilvik líka að mistakast í heilbrigðisskoðuninni.
Til að byrja á nýju tilviki þurfti að hlaða niður og setja upp pakka og tók miklu lengri tíma en það tók ELB að slökkva á þeim - einn í einu - í sjálfvirka mælikvarðahópnum. Það er ljóst að fljótlega náði allt ferlið að mikilvægum punkti og forritið hrundi.
Þá skildum við að eilífu eftirfarandi atriði:
- Að setja upp hugbúnað þegar nýtt tilvik er búið til tekur langan tíma; það er betra að velja óbreytanlega nálgun og .
- Við erfiðar aðstæður ættu viðbrögð við heilsufarsskoðun og ELB að hafa forgang - það síðasta sem þú vilt er að flækja lífið fyrir þau tilvik sem eftir eru.
- Staðbundin skyndiminni heilsuskoðunar hjálpar mikið (jafnvel í nokkrar sekúndur).
- Í erfiðum aðstæðum skaltu ekki keyra cron verkefni og önnur ekki mikilvæg ferli - sparaðu fjármagn fyrir mikilvægustu verkefnin.
- Notaðu smærri tilvik þegar þú stækkar sjálfvirkt. Hópur 10 lítilla eintaka er betri en hópur 4 stórra; ef eitt tilvik mistekst, í fyrra tilvikinu dreifast 10% umferðarinnar á 9 punkta, í öðru tilvikinu - 25% umferðarinnar á þremur punktum.
Svo, hefði verið hægt að sjá þetta fyrir og því koma í veg fyrir það með því að koma vandanum áleiðis?
Já, og á nokkra vegu.
Í fyrsta lagi með því að líkja eftir mikilli CPU notkun með því að nota verkfæri eins og eða :
❯ stress-ng --matrix 1 -t 60s
streita-ng
Í öðru lagi með því að ofhlaða dæminu með og önnur sambærileg tól:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Tilraunirnar eru tiltölulega einfaldar en geta veitt gott umhugsunarefni án þess að þurfa að ganga í gegnum álagið sem fylgir raunverulegri bilun.
En ekki hætta þar. Reyndu að endurskapa hrunið í prófunarumhverfi og athugaðu svar þitt við spurningunni "Hefði verið hægt að sjá þetta fyrir og þar af leiðandi koma í veg fyrir með því að koma á bilun?" Þetta er lítil glundroðatilraun innan glundroðatilraunar til að prófa forsendur, en byrjar á bilun.
Var þetta draumur eða gerðist það í alvörunni?
Svo rannsakaðu sögu bilana, greindu EOC, merktu og flokkaðu þau eftir „hitradíus“ – eða réttara sagt, fjölda viðskiptavina sem verða fyrir áhrifum – og leitaðu síðan að mynstrum. Spyrðu sjálfan þig hvort hægt hefði verið að spá fyrir um þetta og koma í veg fyrir þetta með því að kynna vandamálið. Athugaðu svarið þitt.
Skiptu síðan yfir í algengustu mynstrin með stærsta úrvalið.
2. Byggðu upp ávanakort
Gefðu þér smá stund til að hugsa um umsókn þína. Er til skýrt kort yfir ósjálfstæði þess? Veistu hvaða áhrif þau munu hafa ef bilun verður?
Ef þú ert ekki mjög kunnugur kóða forritsins þíns eða hann er orðinn mjög stór getur verið erfitt að skilja hvað kóðinn gerir og hvað hann er háður. Skilningur á þessum ósjálfstæði og möguleg áhrif þeirra á forritið og notendur er mikilvægt til að vita hvar á að byrja með óreiðuverkfræði: upphafspunkturinn er íhluturinn með stærsta áhrifaradíusinn.
Að bera kennsl á og skjalfesta ósjálfstæði er kallað "byggja upp ávanakort» (kortlagning á ósjálfstæði). Þetta er venjulega gert fyrir forrit með stóran kóðagrunn með því að nota kóðaprófunartæki. (kóðasnið) og tækjabúnaði (hljóðfæri). Þú getur líka smíðað kort með því að fylgjast með netumferð.
Hins vegar eru ekki allar ósjálfstæðir eins (sem flækir ferlið enn frekar). Sumir gagnrýninn, annað - aukaatriði (að minnsta kosti í orði, þar sem hrun eiga sér stað oft vegna vandamála með ósjálfstæði sem voru talin ekki mikilvæg).
Án mikilvægra ósjálfstæðis getur þjónustan ekki virkað. Ómikilvægar ósjálfstæði“ætti ekki» að hafa áhrif á þjónustuna við fall. Til að skilja ósjálfstæði þarftu að hafa skýran skilning á API sem forritið þitt notar. Þetta getur verið miklu erfiðara en það virðist - að minnsta kosti fyrir stór forrit.
Byrjaðu á því að fara í gegnum öll API. Lýstu mest mikilvæg og gagnrýnin... Taktu ósjálfstæði úr kóðageymslunni, skoðaðu það tengingarskrár, þá skoða skjöl (auðvitað, ef það er til - annars hefurðu ennоstærri vandamál). Notaðu tækin til að prófílgreiningu og rakningu, sía út ytri símtöl.
Þú getur notað forrit eins og netstat - skipanalínuforrit sem sýnir lista yfir allar nettengingar (virkar innstungur) í kerfinu. Til dæmis, til að skrá allar núverandi tengingar skaltu slá inn:
❯ netstat -a | more
Í AWS er hægt að nota (flæðisskrár) VPC er aðferð sem gerir þér kleift að safna upplýsingum um IP umferð sem fer til eða frá netviðmótum í VPC. Slíkir annálar geta einnig hjálpað við önnur verkefni - til dæmis að finna svar við spurningunni um hvers vegna ákveðin umferð nær ekki tilvikinu.
Þú getur líka notað . Röntgengeisli gerir þér kleift að fá nákvæma, „fullkomna“ (enda til enda) yfirlit yfir beiðnir þegar þær fara í gegnum forritið og byggir einnig kort af undirliggjandi íhlutum forritsins. Mjög þægilegt ef þú þarft að bera kennsl á ósjálfstæði.
AWS X-Ray Console
Netfíknikort er aðeins lausn að hluta. Já, það sýnir hvaða forrit hefur samskipti við hvaða, en það eru önnur ósjálfstæði.
Mörg forrit nota DNS til að tengjast ósjálfstæði, á meðan önnur geta notað þjónustuuppgötvun eða jafnvel harðkóða IP-tölur í stillingarskrám (t.d. /etc/hosts).
Til dæmis getur þú búið til með hjálpinni iptables og sjá hvað brotnar. Til að gera þetta skaltu slá inn eftirfarandi skipun:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS svarthol
Ef í /etc/hosts eða aðrar stillingarskrár, þú munt finna IP tölur sem þú veist ekkert um (já, því miður, þetta gerist líka), þú getur komið til bjargar aftur iptables. Segjum að þú hafir uppgötvað 8.8.8.8 og veit ekki að þetta er opinbert DNS netfang Google. Með því að nota iptables Þú getur lokað á komandi og sendandi umferð á þetta heimilisfang með því að nota eftirfarandi skipanir:
❯ 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"
Lokar aðgangi
Fyrsta reglan sleppir öllum pökkum úr opinberu DNS Google: ping virkar, en pökkum er ekki skilað. Önnur reglan sleppir öllum pökkum sem koma frá kerfinu þínu í opinbera DNS Google - til að bregðast við ping við fáum Rekstur óheimill.
Athugið: í þessu tiltekna tilviki væri betra að nota whois 8.8.8.8, en þetta er bara dæmi.
Við getum farið enn dýpra niður í kanínuholið, því allt sem notar TCP og UDP fer í raun líka eftir IP. Í flestum tilfellum er IP bundið við ARP. Ekki gleyma eldveggjum...
Ef þú tekur rauðu pilluna, dvelur þú í Undralandi og ég skal sýna þér hversu djúpt kanínuholið fer.“
Róttækari nálgun er að aftengja bílar einn af öðrum og sjá hvað er bilað... orðið að "kaos api." Auðvitað eru mörg framleiðslukerfi ekki hönnuð fyrir svona brute force árás, en að minnsta kosti er hægt að prófa það í prófunarumhverfi.
Að byggja upp ávanakort er oft mjög langt verkefni. Ég talaði nýlega við viðskiptavin sem eyddi næstum 2 árum í að þróa tól sem framleiðir hálfsjálfvirkt ávanakort fyrir hundruð örþjónustu og skipana.
Niðurstaðan er hins vegar ákaflega áhugaverð og gagnleg. Þú munt læra mikið um kerfið þitt, ósjálfstæði þess og starfsemi. Aftur, vertu þolinmóður: það er ferðin sjálf sem skiptir mestu máli.
3. Varist oftrú
"Hver sem dreymir um hvað, trúir á það." — Demosþenes
Hefur þú einhvern tíma heyrt um oftrúaráhrif?
Samkvæmt Wikipedia eru oftraustsáhrifin „vitræn hlutdrægni þar sem traust einstaklings á gjörðum sínum og ákvörðunum er verulega meira en hlutlæg nákvæmni þessara dóma, sérstaklega þegar sjálfstraustið er tiltölulega hátt.
Byggt á eðlishvöt og reynslu...
Mín reynsla er sú að þessi brenglun er frábær vísbending um hvar eigi að byrja með óreiðuverkfræði.
Varist oföruggan rekstraraðila:
Charlie: "Þessi hlutur hefur ekki fallið í fimm ár, allt er í lagi!"
Crash: "Bíddu... ég kem bráðum!"
Hlutdrægni vegna oftrausts er skaðlegur og jafnvel hættulegur hlutur vegna hinna ýmsu þátta sem hafa áhrif á hana. Þetta á sérstaklega við þegar liðsmenn hafa hellt hjörtum sínum í tækni eða eytt miklum tíma í að „laga“ hana.
Leggja saman
Leitin að upphafspunkti fyrir glundroðaverkfræði skilar alltaf meiri árangri en búist var við og lið sem byrja að brjóta hlutina of fljótt missa sjónar á hnattrænni og áhugaverðari kjarna (óreiðu-)verkfræði - skapandi notkun vísindalegum aðferðum и reynslusönnun fyrir hönnun, þróun, rekstur, viðhald og endurbætur á (hugbúnaðar)kerfum.
Þar með lýkur seinni hlutanum. Vinsamlegast skrifaðu umsagnir, deildu skoðunum eða klappaðu bara saman . Í næsta hluta I virkilega Ég mun skoða verkfæri og aðferðir til að koma bilunum inn í kerfi. Þangað til!
PS frá þýðanda
Lestu líka á blogginu okkar:
- «»;
- «»;
- «»;
- «'.
Heimild: www.habr.com