Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2

Note. iwwersat.: Dësen Artikel setzt eng grouss Serie vun Artikelen vum AWS Technologie Evangelist Adrian Hornsby weider, deen op eng einfach a kloer Manéier d'Wichtegkeet vun Experimenter erklärt fir d'Konsequenze vu Feeler an IT Systemer ze reduzéieren.

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2

"Wann Dir net e Plang virbereet, da plangt Dir ze versoen." - Benjamin Franklin

В éischten Deel An dëser Serie vun Artikelen hunn ech d'Konzept vum Chaos Engineering agefouert an erkläert wéi et hëlleft Mängel am System ze fannen an ze korrigéieren ier se zu Produktiounsfehler féieren. Et huet och diskutéiert wéi Chaos Engineering positiv kulturell Verännerung bannent Organisatiounen fördert.

Um Enn vum éischten Deel hunn ech versprach iwwer "Tools a Methoden fir Feeler an Systemer aféieren." Leider, mäi Kapp hat seng eege Pläng an dëser Hisiicht, an an dësem Artikel probéieren ech déi populärste Fro ze beäntweren, déi ënner de Leit entstinn, déi an de Chaos-Ingenieur wëllen kommen: Wat fir d'éischt ze briechen?

Flott Fro! Wéi och ëmmer, hien schéngt net besonnesch vun dëser Panda gestéiert ze sinn ...

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2
Maacht net mat der Chaos Panda!

Kuerz Äntwert: Zil kritesch Servicer laanscht d'Ufro Wee.

Méi laang awer méi kloer Äntwert: Fir ze verstoen wou mat Chaos ze experimentéieren ufänken, oppassen op dräi Beräicher:

  1. Kuckt Crash Geschicht an Identifikatioun Mustere;
  2. Entscheed op kritesch Ofhängegkeeten;
  3. Benotzt de sougenannte overconfidence Effekt.

Et ass witzeg, mä dësen Deel kéint grad esou einfach genannt ginn "Eng Rees an d'Selbst Entdeckung an d'Aufklärung". Dobäi fänken mer mat flotten Instrumenter un ze "spillen".

1. D'Äntwert läit an der Vergaangenheet

Wann Dir Iech drun erënnert, hunn ech am éischten Deel d'Konzept vun der Correction-of-Errors (COE) agefouert - eng Method mat där mir eis Feeler analyséieren - Feeler an der Technologie, Prozess oder Organisatioun - fir hir Ursaach(en) ze verstoen an ze vermeiden Widderhuelung an Zukunft. Am Allgemengen, dëst ass wou Dir sollt ufänken.

"Fir d'Presentatioun ze verstoen, musst Dir d'Vergaangenheet kennen." - Carl Sagan

Kuckt d'Geschicht vu Feeler, markéiert se an COE oder Postmortems a klasséiert se. Identifizéiere gemeinsam Musteren déi dacks zu Probleemer féieren, a fir all COE, stellt Iech déi folgend Fro:

"Konnt dëst virausgesot ginn an dofir duerch Feelerinjektioun verhënnert ginn?"

Ech erënnere mech un ee Feeler fréi a menger Carrière. Et kéint einfach verhënnert ginn wa mir e puer einfache Chaos Experimenter gemaach hätten:

Ënner normalen Bedéngungen äntweren Backend Instanzen op Gesondheetschecken aus Load Balancer (ELB)). ELB benotzt dës Kontrollen fir Ufroen op gesond Instanzen ze redirectéieren. Wann et sech erausstellt, datt eng Instanz "ongesond" ass, hält d'ELB op d'Ufroen un et ze schécken. Enges Daags, no enger erfollegräicher Marketingkampagne, ass de Volume vum Traffic eropgaang an d'Backends hunn ugefaang op d'Gesondheetskontrolle méi lues ze reagéieren wéi soss. Et soll gesot ginn, datt dës Gesondheetskontrolle waren déif, dat heescht, den Zoustand vun den Ofhängegkeeten gouf gepréift.

Allerdéngs war alles gutt fir eng Zäit.

Dunn, schonn ënner zimlech stresseg Konditiounen, huet ee vun de Fäll ugefaang eng net kritesch, reegelméisseg ETL Cron Aufgab auszeféieren. D'Kombinatioun vum héije Traffic a Cronjob huet d'CPU-Notzung op bal 100% gedréckt. CPU-Iwwerlaaschtung huet d'Äntwerten op d'Gesondheetskontrolle weider verlangsamt, sou vill datt d'ELB decidéiert huet datt d'Instanz Leeschtungsproblemer erliewt. Wéi erwaart huet de Balancer gestoppt de Verkéier ze verdeelen, wat am Tour zu enger Erhéijung vun der Belaaschtung op déi verbleiwen Instanzen am Grupp gefouert huet.

Op eemol hunn all aner Instanzen och ugefaang de Gesondheetscheck ze versoen.

Eng nei Instanz unzefänken erfuerdert d'Downloaden an d'Installatioun vun Paketen an huet vill méi laang gedauert wéi et den ELB gedauert huet fir se ze deaktivéieren - een nom aneren - an der Autoskaléierungsgrupp. Et ass kloer datt geschwënn de ganze Prozess e kritesche Punkt erreecht huet an d'Applikatioun erofgefall ass.

Dann hu mir fir ëmmer déi folgend Punkte verstanen:

  • D'Installatioun vun Software wann Dir eng nei Instanz erstellt, dauert eng laang Zäit, et ass besser fir déi onverännerbar Approche ze ginn Golden AMI.
  • A komplexe Situatiounen, Äntwerten op Gesondheetschecken an ELBs sollten Prioritéit hunn - dat lescht wat Dir wëllt ass d'Liewen fir déi verbleiwen Instanzen ze komplizéieren.
  • Lokal Caching vu Gesondheetskontrollen hëlleft vill (och fir e puer Sekonnen).
  • An enger schwiereger Situatioun lafen keng Cron Aufgaben an aner net kritesch Prozesser - späichert Ressourcen fir déi wichtegst Aufgaben.
  • Wann Autoscaling, benotzt méi kleng Instanzen. Eng Grupp vun 10 kleng Exemplare ass besser wéi eng Grupp vu 4 grousser; wann eng Instanz feelt, ginn am éischte Fall 10% vum Verkéier iwwer 9 Punkten verdeelt, an der zweeter - 25% vum Verkéier iwwer dräi Punkten.

An dofir, konnt dat virausgesi ginn, an dofir verhënnert ginn, andeems de Problem agefouert gouf?

datt, an op verschidde Manéieren.

Als éischt, andeems Dir héich CPU Notzung simuléiert mat Tools wéi stress-ng oder cpuburn:

❯ stress-ng --matrix 1 -t 60s

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2
Stress-ng

Zweetens, andeems Dir d'Instanz iwwerlaascht mat wrk an aner ähnlech Utilities:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2

D'Experimenter si relativ einfach, awer kënnen e puer gutt Iesse fir Gedanken ubidden ouni de Stress vun engem richtegen Echec ze goen.

Awer, net do ophalen. Probéiert de Crash an engem Testëmfeld ze reproduzéieren a kontrolléiert Är Äntwert op d'Fro "Konnt dat virausgesi sinn an dofir verhënnert ginn duerch d'Aféierung vun engem Feeler?" Dëst ass e Mini Chaos Experiment bannent engem Chaos Experiment fir Viraussetzungen ze testen, awer mat engem Echec unzefänken.

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2
War et en Dram, oder ass et wierklech geschitt?

Also studéiert d'Geschicht vu Feeler, analyséiert EOC, markéiert a klassifizéieren se duerch "Schlagradius" - oder méi genee, d'Zuel vun de betraffene Clienten - a kuckt dann no Musteren. Frot Iech selwer ob dëst kéint virausgesot a verhënnert ginn duerch d'Aféierung vum Problem. Check Är Äntwert.

Dann wiesselen op déi allgemeng Mustere mat der gréisster Palette.

2. Bauen eng Ofhängegkeet Kaart

Huelt e Moment fir iwwer Är Demande ze denken. Gëtt et eng kloer Kaart vu sengen Ofhängegkeeten? Wësst Dir wéi en Impakt se wäerten hunn wann et e Feeler ass?

Wann Dir net ganz vertraut sidd mat Ärem Applikatiounscode oder et ass ganz grouss ginn, kann et schwéier sinn ze verstoen wat de Code mécht a wat seng Ofhängegkeete sinn. Dës Ofhängegkeeten an hire méiglechen Impakt op d'Applikatioun an d'Benotzer ze verstoen ass kritesch fir ze wëssen wou mat Chaos Engineering ufänken: de Startpunkt ass de Komponent mat dem gréissten Impaktradius.

D'Identifikatioun an d'Dokumentatioun vun Ofhängegkeete gëtt genannt "eng Ofhängegkeetskaart ze bauen» (Ofhängegkeetsmapping). Dëst gëtt typesch fir Uwendungen mat enger grousser Codebasis gemaach mat Hëllef vu Codeprofiling Tools. (Code Profiling) an Instrumenter (Instrumentatioun). Dir kënnt och eng Kaart bauen andeems Dir den Netzverkéier iwwerwaacht.

Wéi och ëmmer, net all Ofhängegkeete sinn déiselwecht (wat de Prozess weider komplizéiert). E puer kritesch, aner - sekundär (op d'mannst an der Theorie, well Crashen dacks optrieden wéinst Probleemer mat Ofhängegkeeten déi als net kritesch ugesi goufen).

Ouni kritesch Ofhängegkeeten kann de Service net funktionnéieren. Net-kritesch Ofhängegkeeten "soll net» de Service am Fall vun engem Fall ze beaflossen. Fir Ofhängegkeeten ze verstoen, musst Dir e kloert Verständnis vun den APIen hunn, déi vun Ärer Applikatioun benotzt ginn. Dëst ka vill méi schwéier sinn wéi et schéngt - op d'mannst fir grouss Uwendungen.

Fänkt un duerch all d'APIs ze goen. Highlight am meeschten bedeitend a kritesch. Huelt Ofhängegkeet aus dem Code Repository, kontrolléiert et Verbindung Logbicher, dann kucken Dokumentatioun (natierlech, wann et existéiert - soss hutt Dir nach ëmmerоméi grouss Problemer). Benotzt d'Tools fir Profiléieren an Tracing, Filter aus externen Uriff.

Dir kënnt Programmer benotzen wéi netstat - e Kommandozeil-Utility dat eng Lëscht vun all Netzwierkverbindungen (aktive Sockets) am System weist. Zum Beispill, fir all aktuell Verbindungen ze lëschten, gitt:

❯ netstat -a | more 

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2

An AWS kënnt Dir benotzen Flux Logbicher (Flow Logs) VPC ass eng Method déi Iech erlaabt Informatioun iwwer IP Traffic ze sammelen, déi op oder vun Netzwierkschnëttplazen an engem VPC geet. Esou Logbicher kënnen och mat aneren Aufgaben hëllefen - zum Beispill eng Äntwert op d'Fro ze fannen firwat e bestëmmte Traffic d'Instanz net erreecht.

Dir kënnt och benotzen AWS Röntgen. X-Ray erlaabt Iech detailléiert, "ultimate" ze kréien (End-zu-Enn) Iwwersiicht vun Ufroe wéi se duerch d'Applikatioun réckelen, a baut och eng Kaart vun den ënnerierdesche Komponenten vun der Applikatioun. Ganz praktesch wann Dir Ofhängegkeete muss identifizéieren.

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2
AWS X-Ray Konsol

Eng Netzwierkabhängegkeetskaart ass nëmmen eng deelweis Léisung. Jo, et weist wéi eng Applikatioun mat där kommunizéiert, awer et ginn aner Ofhängegkeeten.

Vill Applikatiounen benotzen DNS fir mat Ofhängegkeeten ze verbannen, anerer kënnen Service Entdeckung benotzen oder souguer schwéier kodéiert IP Adressen a Konfiguratiounsdateien (z. /etc/hosts).

Zum Beispill, kënnt Dir schafen DNS Blackhole mat der Hëllef vun iptables a kuckt wat brécht. Fir dëst ze maachen, gitt de folgende Kommando:

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2
DNS schwaarzt Lach

Wann an /etc/hosts oder aner Konfiguratiounsdateien, fannt Dir IP Adressen vun deenen Dir näischt wësst (jo, leider, dat geschitt och), Dir kënnt erëm zur Rettung kommen iptables. Loosst eis soen datt Dir entdeckt hutt 8.8.8.8 a weess net datt dëst dem Google seng ëffentlech DNS Server Adress ass. Duerch d'Benotzung iptables Dir kënnt den erakommen an erausginn Traffic op dës Adress blockéieren mat de folgende Kommandoen:

❯ 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"

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2
Zoumaachen Zougang

Déi éischt Regel fällt all Pakete vum Google ëffentlechen DNS erof: ping Wierker, mee Pakete ginn net zréck. Déi zweet Regel fällt all Pakete, déi aus Ärem System stamen, a Richtung Google's ëffentlechen DNS - als Äntwert op ping mir kréien Operatioun net erlaabt.

Notiz: an dësem bestëmmte Fall wier et besser ze benotzen whois 8.8.8.8, awer dëst ass just e Beispill.

Mir kënnen nach méi déif an d'Kanéngchen Lach goen, well alles wat TCP an UDP benotzt hänkt eigentlech och vun IP of. An de meeschte Fäll ass IP un ARP gebonnen. Vergiesst net iwwer Firewalls ...

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2
Wann Dir déi rout Pëll hëlt, bleift Dir am Wonnerland, an ech weisen Iech wéi déif d'Kanéngchen Lach geet."

Eng méi radikal Approche ass trennt Autoen een nom aneren a kucke wat futti ass... ginn e "Chaos Af." Natierlech, sinn vill Produktioun Systemer net fir esou engem brute Kraaft Attack entworf, mee op d'mannst kann et an engem Test Ëmfeld probéiert ginn.

Eng Ofhängegkeetskaart bauen ass dacks eng ganz laang Entreprise. Ech hunn viru kuerzem mat engem Client geschwat dee bal 2 Joer verbruecht huet en Tool z'entwéckelen dat semi-automatesch Ofhängegkeetskaarte fir Honnerte vu Mikroservicer a Kommandoen generéiert.

D'Resultat ass awer extrem interessant an nëtzlech. Dir léiert vill iwwer Äre System, seng Ofhängegkeeten an Operatiounen. Nach eng Kéier, sief Gedold: et ass d'Rees selwer déi wichteg ass.

3. Opgepasst vun overconfidence

"Wien vun deem dreemt, gleeft drun." — Demosthenes

Hutt Dir schons vun héieren overconfidence Effekt?

Laut Wikipedia ass den Iwwervertrauenseffekt "eng kognitiv Bias an där d'Vertrauen vun enger Persoun an hir Handlungen an Entscheedunge wesentlech méi grouss ass wéi déi objektiv Genauegkeet vun dësen Uerteeler, besonnesch wann den Niveau vum Vertrauen relativ héich ass."

Chaos Engineering: d'Konscht vun der bewosst Zerstéierung. Deel 2
Baséiert op Instinkt an Erfahrung ...

Aus menger Erfahrung kann ech soen datt dës Verzerrung e super Hiweis ass wou Dir mat Chaos Engineering ufänken.

Opgepasst op den iwwervertrauen Bedreiwer:

Charlie: "Dës Saach ass a fënnef Joer net gefall, alles ass gutt!"
Crash: "Waart ... ech wäert geschwënn do sinn!"

Bias als Konsequenz vun Iwwervertrauen ass eng lëschteg a souguer geféierlech Saach wéinst de verschiddene Faktoren déi et beaflossen. Dëst ass besonnesch wouer wann Teammemberen hir Häerzer an eng Technologie gegoss hunn oder vill Zäit verbruecht hunn ze "fixéieren".

Zesummefaassung

D'Sich no engem Startpunkt fir Chaos-Ingenieur bréngt ëmmer méi Resultater wéi erwaart, an Teams, déi d'Saachen ze séier briechen, verléieren déi méi global an interessant Essenz vu (Chaos-)Ingenieur - kreativ Applikatioun wëssenschaftlech Methoden и empiresch Beweiser fir den Design, Entwécklung, Operatioun, Ënnerhalt a Verbesserung vun (Software) Systemer.

Dëst schléisst den zweeten Deel. Schreift w.e.g. Rezensiounen, deelt Meenungen oder klappt einfach an den Hänn mëttel-. Am nächsten Deel I wierklech Ech wäert Tools a Methoden berücksichtegen fir Feeler a Systemer anzeféieren. Bis!

PS vum Iwwersetzer

Liest och op eisem Blog:

Source: will.com

Setzt e Commentaire