Noat. transl.: Dit artikel ferfolget in geweldige searje artikels fan AWS technology evangelist Adrian Hornsby, dy't besiket te ferklearjen op in ienfâldige en dúdlike manier it belang fan eksperimintearjen om de gefolgen fan mislearrings yn IT-systemen te ferminderjen.
"As jo gjin plan meitsje, dan binne jo fan plan te mislearjen." - Benjamin Franklin
В Yn dizze searje artikels yntrodusearre ik it konsept fan chaos-engineering en útlein hoe't it helpt om gebreken yn it systeem te finen en te reparearjen foardat se liede ta produksjefouten. It besprutsen ek hoe't chaos-engineering positive kulturele feroaring binnen organisaasjes befoardert.
Oan 'e ein fan it earste diel beloofde ik te praten oer "ark en metoaden foar it ynfieren fan flaters yn systemen." Och, myn holle hie syn eigen plannen yn dit ferbân, en yn dit artikel sil ik besykje de meast populêre fraach te beantwurdzjen dy't ûntstiet ûnder minsken dy't yn 'e gaostechnyk wolle komme: Wat earst brekke?
Geweldige fraach! Hy liket lykwols net spesjaal lêst te hawwen fan dizze panda ...
Ferjit net mei de chaos-panda!
Koart antwurd: Target krityske tsjinsten lâns it fersykpaad.
Langer mar dúdliker antwurd: Om te begripen wêr't jo begjinne te eksperimintearjen mei gaos, jouwe oandacht oan trije gebieten:
- Sjoch op crash skiednis en identifisearje patroanen;
- Beslúte op krityske ôfhinklikens;
- Brûk de saneamde overconfidence effekt.
It is grappich, mar dit diel koe likegoed neamd wurde "In reis nei selsûntdekking en ferljochting". Dêryn sille wy begjinne te "spylje" mei wat koele ynstruminten.
1. It antwurd leit yn it ferline
As jo it ûnthâlde, haw ik yn it earste diel it konsept fan Correction-of-Errors (COE) yntrodusearre - in metoade wêrmei't wy ús flaters analysearje - flaters yn technology, proses of organisaasje - om har oarsaak(s) te begripen en foar te kommen werhelling yn 'e takomst. Yn it algemien, dit is wêr't jo moatte begjinne.
"Om it hjoed te begripen, moatte jo it ferline kennen." - Carl Sagan
Sjoch nei de skiednis fan mislearrings, tag se yn COE as postmortems en klassifisearje se. Identifisearje mienskiplike patroanen dy't faak liede ta problemen, en foar elke COE, freegje josels de folgjende fraach:
"Koe dit wurde foarsizze en dêrom foarkommen troch foutynjeksje?"
Ik herinner my ien mislearring betiid yn myn karriêre. It koe maklik foarkommen wurde as wy in pear ienfâldige gaoseksperiminten hiene útfierd:
Under normale omstannichheden reagearje backend-eksimplaren op sûnenskontrôles fan ). ELB brûkt dizze kontrôles om fersiken troch te lieden nei sûne gefallen. As bliken docht dat in eksimplaar "ûnsûn" is, hâldt ELB op mei it ferstjoeren fan fersiken nei it. Ien dei, nei in suksesfolle marketingkampanje, naam it folume fan ferkear ta en de backends begûnen te reagearjen op sûnenskontrôles stadiger as gewoanlik. It moat sein wurde dat dizze sûnenskontrôles wiene , dat is, de steat fan 'e ôfhinklikens waard kontrolearre.
Lykwols, alles wie in skoft goed.
Doe, al ûnder nochal stressfolle omstannichheden, begon ien fan 'e gefallen in net-krityske, reguliere ETL cron-taak út te fieren. De kombinaasje fan hege ferkear en cronjob skood CPU-gebrûk nei hast 100%. CPU-oerlêst fertrage de reaksjes op sûnenskontrôles fierder, sa folle dat de ELB besleat dat it eksimplaar prestaasjesproblemen ûnderfûn. Lykas ferwachte, stopte de balancer it fersprieden fan ferkear nei it, wat op syn beurt late ta in tanimming fan 'e lading op' e oerbleaune eksimplaren yn 'e groep.
Ynienen begûnen ek alle oare gefallen de sûnenskontrôle te mislearjen.
It begjinnen fan in nije eksimplaar easke it ynladen en ynstallearjen fan pakketten en duorre folle langer dan it duorre foar de ELB om se - ien foar ien - út te skeakeljen yn 'e autoscaling-groep. It is dúdlik dat al gau it hiele proses in kritysk punt berikte en de applikaasje crashte.
Dan hawwe wy de folgjende punten foar altyd begrepen:
- It ynstallearjen fan software by it meitsjen fan in nij eksimplaar duorret in lange tiid it is better om foarkar te jaan oan de ûnferoarlike oanpak en .
- Yn drege situaasjes moatte antwurden op sûnenskontrôles en ELB's prioriteit krije - it lêste wat jo wolle is it libben komplisearje foar de oerbleaune gefallen.
- Lokale caching fan sûnenskontrôles helpt in protte (sels foar in pear sekonden).
- Rin yn in drege situaasje gjin cron-taken en oare net-krityske prosessen - bewarje boarnen foar de wichtichste taken.
- As jo autoskaalje, brûke lytsere eksimplaren. In groep fan 10 lytse eksimplaren is better as in groep fan 4 grutte; as ien eksimplaar mislearret, wurdt yn it earste gefal 10% fan it ferkear ferdield oer 9 punten, yn it twadde - 25% fan it ferkear oer trije punten.
En sa, koe dit foarsjoen wurde, en dêrom foarkommen wurde troch it yntrodusearjen fan it probleem?
dat, en op ferskate manieren.
Earst, troch it simulearjen fan hege CPU-gebrûk mei help fan ark lykas of :
❯ stress-ng --matrix 1 -t 60s
stress-fan
Twadder, troch it eksimplaar te oerladen mei en oare ferlykbere nutsbedriuwen:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
De eksperiminten binne relatyf ienfâldich, mar kinne soargje foar wat goed iten foar tinken sûnder te gean troch de stress fan in echte mislearring.
Mar, stopje dêr net. Besykje de crash te reprodusearjen yn in testomjouwing en kontrolearje jo antwurd op 'e fraach "Hie dit foarsjoen en dus foarkommen wurde kinnen troch it ynfieren fan in steuring?" Dit is in mini-gaos-eksperimint binnen in gaos-eksperimint om oannames te testen, mar begjinnend mei in mislearring.
Wie it in dream, of barde it echt?
Dus studearje de skiednis fan mislearrings, analysearje EOC, tag en klassifisearje se troch "hit radius" - of krekter, it oantal klanten beynfloede - en dan sykje patroanen. Freegje josels ôf oft dit koe wurde foarsizze en foarkommen troch it yntrodusearjen fan it probleem. Kontrolearje jo antwurd.
Skeakelje dan nei de meast foarkommende patroanen mei it grutste berik.
2. Bouwe in ôfhinklikens map
Nim efkes de tiid om nei te tinken oer jo applikaasje. Is d'r in dúdlike kaart fan har ôfhinklikens? Witte jo hokker ynfloed se sille hawwe as d'r in mislearring is?
As jo net heul bekend binne mei de koade fan jo applikaasje of it is heul grut wurden, kin it lestich wêze om te begripen wat de koade docht en wat de ôfhinklikens binne. It begripen fan dizze ôfhinklikens en har mooglike ynfloed op 'e applikaasje en brûkers is kritysk om te witten wêr't te begjinnen mei chaos-technyk: it útgongspunt is de komponint mei de grutste ynfloedradius.
It identifisearjen en dokumintearjen fan ôfhinklikens wurdt "it bouwen fan in ôfhinklikenskaart» (ôfhinklikens mapping). Dit wurdt typysk dien foar applikaasjes mei in grutte koadebasis mei help fan ark foar profilearjen fan koade. (koade profilearring) en ynstrumintaasje (ynstrumintaasje). Jo kinne ek in kaart bouwe troch netwurkferkear te kontrolearjen.
Net alle ôfhinklikens binne lykwols itselde (wat it proses fierder komplisearret). Guon kritysk, oar - sekundêr (op syn minst yn teory, om't crashes faak foarkomme fanwege problemen mei ôfhinklikens dy't as net-kritysk waarden beskôge).
Sûnder krityske ôfhinklikens kin de tsjinst net wurkje. Net-krityske ôfhinklikens"soe net» om de tsjinst te beynfloedzjen yn gefal fan in fal. Om ôfhinklikens te begripen, moatte jo in dúdlik begryp hawwe fan 'e API's brûkt troch jo applikaasje. Dit kin folle dreger wêze dan it liket - teminsten foar grutte applikaasjes.
Begjin troch alle API's troch te gean. Markearje it meast wichtich en kritysk. Nimme ôfhinklikens út de koade repository, check it út ferbining logs, dan besjen dokumintaasje (fansels, as it bestiet - oars hawwe jo nochоgruttere problemen). Brûk de ark om profilearring en tracing, filterje eksterne petearen.
Jo kinne gebrûk meitsje fan programma's lykas netstat - in kommandorigelprogramma dat in list toant fan alle netwurkferbiningen (aktive sockets) yn it systeem. Om bygelyks alle aktuele ferbiningen te listjen, typ:
❯ netstat -a | more
Yn AWS kinne jo brûke (flow logs) VPC is in metoade wêrmei jo te sammeljen ynformaasje oer IP ferkear nei of fan netwurk ynterfaces yn in VPC. Sokke logs kinne ek helpe by oare taken - bygelyks it finen fan in antwurd op 'e fraach wêrom't bepaald ferkear de eksimplaar net berikt.
Jo kinne ek brûke . X-Ray lit jo detaillearre, "ultime" krije (ein-oan-ein) oersjoch fan oanfragen as se troch de applikaasje bewege, en bout ek in kaart fan de ûnderlizzende komponinten fan 'e applikaasje. Hiel handich as jo ôfhinklikens moatte identifisearje.
AWS X-Ray Console
In netwurkôfhinklikenskaart is mar in parsjele oplossing. Ja, it lit sjen hokker applikaasje mei hokker kommunisearret, mar d'r binne oare ôfhinklikens.
In protte applikaasjes brûke DNS om te ferbinen mei ôfhinklikens, wylst oaren tsjinstûntdekking of sels hurdkodearre IP-adressen kinne brûke yn konfiguraasjebestannen (bgl. /etc/hosts).
Jo kinne bygelyks meitsje troch iptables en sjoch wat brekt. Om dit te dwaan, fier it folgjende kommando yn:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS swart gat
As yn /etc/hosts of oare konfiguraasjetriemmen, jo sille IP-adressen fine wêrfan jo neat witte (ja, spitigernôch, dit bart ek), kinne jo wer ta de rêding komme iptables. Litte wy sizze dat jo ûntdutsen hawwe 8.8.8.8 en wit net dat dit Google's iepenbiere DNS-tsjinneradres is. Troch te brûken iptables Jo kinne ynkommende en útgeande ferkear nei dit adres blokkearje mei de folgjende kommando's:
❯ 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"
Slút tagong
De earste regel falt alle pakketten fan Google's iepenbiere DNS: ping wurket, mar pakketten wurde net weromjûn. De twadde regel falt alle pakketten dy't fan jo systeem ôfkomstich binne nei Google's iepenbiere DNS - as antwurd op ping Wy krije Operaasje net tastien.
Opmerking: yn dit bysûndere gefal soe it better wêze om te brûken whois 8.8.8.8, mar dit is mar in foarbyld.
Wy kinne noch djipper yn it konijngat gean, om't alles dat TCP en UDP brûkt, eins ek hinget fan IP. Yn 'e measte gefallen is IP bûn oan ARP. Ferjit net oer firewalls ...
As jo de reade pil nimme, bliuw jo yn Wûnderlân, en ik sil jo sjen litte hoe djip it konijngat giet."
In mear radikale oanpak is om ôfbrekke auto's ien foar ien en sjoch wat kapot is ... wurden in "gaos aap." Fansels, in protte produksje systemen binne net ûntwurpen foar sa'n brute krêft oanfal, mar op syn minst it kin wurde besocht yn in test omjouwing.
It bouwen fan in ôfhinklikenskaart is faaks in heul lange ûndernimming. Ik spruts koartlyn mei in klant dy't hast 2 jier bestege oan it ûntwikkeljen fan in ark dat semi-automatysk ôfhinklikheidskaarten genereart foar hûnderten mikrotsjinsten en kommando's.
It resultaat is lykwols ekstreem nijsgjirrich en nuttich. Jo sille in protte leare oer jo systeem, syn ôfhinklikens en operaasjes. Wês nochris geduld: it is de reis sels dy't it wichtichste is.
3. Pas op foar oermoed
"Wa't wat dreamt, leaut der yn." — Demosthenes
Ha jo ea heard fan overconfidence effekt?
Neffens Wikipedia is it oerbetrouwen-effekt "in kognitive bias wêryn it fertrouwen fan in persoan yn har aksjes en besluten signifikant grutter is dan de objektive krektens fan dy oardielen, foaral as it nivo fan fertrouwen relatyf heech is."
Op grûn fan ynstinkt en ûnderfining ...
Yn myn ûnderfining is dizze ferfoarming in geweldige hint fan wêr't te begjinnen mei chaos-technyk.
Pas op foar de oermoedige operator:
Charlie: "Dit ding is net yn fiif jier fallen, alles is goed!"
Crash: "Wachtsje ... ik sil der gau wêze!"
Bias as gefolch fan tefolle fertrouwen is in ferrifeljend en sels gefaarlik ding troch de ferskate faktoaren dy't it beynfloedzje. Dit is foaral wier as teamleden har hert yn in technyk útstutsen hawwe of in protte tiid bestege oan it "fêstigjen".
Gearfetting
It sykjen nei in útgongspunt foar chaos-engineering bringt altyd mear resultaten dan ferwachte, en teams dy't dingen te fluch begjinne te brekken ferlieze it mear globale en nijsgjirrige essinsje fan (chaos-)engineering - kreative applikaasje wittenskiplike metoaden и empirysk bewiis foar it ûntwerp, ûntwikkeling, eksploitaasje, ûnderhâld en ferbettering fan (software)systemen.
Dit konkludearret it twadde diel. Skriuw asjebleaft resinsjes, diel mieningen of klap gewoan yn 'e hannen . Yn it folgjende diel I echt Ik sil ark en metoaden beskôgje foar it ynfieren fan flaters yn systemen. Oant!
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «";
- «".
Boarne: www.habr.com