Let wel. vertaal.: Hierdie artikel gaan voort met 'n groot reeks artikels van AWS-tegnologie-evangelis Adrian Hornsby, wat daarop gemik is om op 'n eenvoudige en duidelike manier die belangrikheid van eksperimentering te verduidelik om die gevolge van mislukkings in IT-stelsels te versag.
"As jy nie daarin slaag om 'n plan voor te berei nie, dan beplan jy om te misluk." - Benjamin Franklin
В In hierdie reeks artikels het ek die konsep van chaos-ingenieurswese bekendgestel en verduidelik hoe dit help om foute in die stelsel op te spoor en reg te stel voordat dit tot produksiefoute lei. Dit het ook bespreek hoe chaos-ingenieurswese positiewe kulturele verandering binne organisasies bevorder.
Aan die einde van die eerste deel het ek belowe om te praat oor "nutsmiddels en metodes om foute in stelsels in te voer." Helaas, my kop het sy eie planne in hierdie verband gehad, en in hierdie artikel sal ek probeer om die gewildste vraag te beantwoord wat ontstaan onder mense wat in chaos-ingenieurswese wil beland: Wat om eerste te breek?
Goeie vraag! Dit lyk egter nie of hy veral deur hierdie panda gepla is nie ...
Moenie met die chaos-panda mors nie!
Kort antwoord: Teiken kritieke dienste langs die versoekpad.
Langer maar duideliker antwoord: Om te verstaan waar om met chaos te begin eksperimenteer, let op drie areas:
- Kyk na ongeluk geskiedenis en patrone te identifiseer;
- Besluit oor kritieke afhanklikhede;
- Gebruik die sg oorvertroue effek.
Dis snaaks, maar hierdie deel kan net so maklik genoem word "'n Reis na selfontdekking en verligting". Daarin sal ons met 'n paar oulike instrumente begin "speel".
1. Die antwoord lê in die verlede
As jy onthou, in die eerste deel het ek die konsep van Correction-of-Errors (COE) bekendgestel - 'n metode waardeur ons ons foute - foute in tegnologie, proses of organisasie - ontleed om die oorsaak(e) daarvan te verstaan en te voorkom herhaling in die toekoms. Oor die algemeen is dit waar jy moet begin.
"Om die hede te verstaan, moet jy die verlede ken." — Carl Sagan
Kyk na die geskiedenis van mislukkings, merk dit in COE of nadoodse ondersoeke en klassifiseer dit. Identifiseer algemene patrone wat dikwels tot probleme lei, en vra jouself die volgende vraag vir elke COE:
"Kon dit voorspel gewees het en dus deur foutinspuiting voorkom word?"
Ek onthou een mislukking vroeg in my loopbaan. Dit kon maklik voorkom gewees het as ons 'n paar eenvoudige chaos-eksperimente uitgevoer het:
Onder normale omstandighede reageer backend-gevalle op gesondheidsondersoeke van ). ELB gebruik hierdie tjeks om versoeke na gesonde gevalle te herlei. Wanneer dit blyk dat 'n instansie "ongesond" is, hou ELB op om versoeke daaraan te stuur. Op 'n dag, na 'n suksesvolle bemarkingsveldtog, het die volume verkeer toegeneem en die backends het stadiger as gewoonlik op gesondheidsondersoeke begin reageer. Daar moet gesê word dat hierdie gesondheidsondersoeke was , dit wil sê, die toestand van die afhanklikhede is nagegaan.
Alles was egter vir 'n rukkie reg.
Toe, reeds onder taamlik stresvolle toestande, het een van die gevalle 'n nie-kritiese, gereelde ETL cron-taak begin uitvoer. Die kombinasie van hoë verkeer en cronjob het SVE-benutting tot byna 100% opgestoot. SVE-oorlading het reaksies op gesondheidsondersoeke verder vertraag, soveel so dat die ELB besluit het dat die instansie prestasieprobleme ondervind. Soos verwag, het die balanseerder opgehou om verkeer na hom te versprei, wat op sy beurt gelei het tot 'n toename in die las op die oorblywende gevalle in die groep.
Skielik het alle ander gevalle ook die gesondheidsondersoek begin misluk.
Om 'n nuwe instansie te begin, het die aflaai en installering van pakkette vereis en het baie langer geneem as wat dit die ELB geneem het om hulle - een vir een - in die outoskaalgroep te deaktiveer. Dit is duidelik dat die hele proses gou 'n kritieke punt bereik het en die toepassing het verongeluk.
Dan het ons vir altyd die volgende punte verstaan:
- Die installering van sagteware wanneer 'n nuwe instansie geskep word, neem 'n lang tyd om voorkeur te gee aan die onveranderlike benadering en .
- In moeilike situasies moet reaksies op gesondheidsondersoeke en ELB's prioriteit geniet - die laaste ding wat jy wil hê, is om die lewe vir die oorblywende gevalle te kompliseer.
- Plaaslike kas van gesondheidsondersoeke help baie (selfs vir 'n paar sekondes).
- In 'n moeilike situasie, moenie cron-take en ander nie-kritiese prosesse uitvoer nie - spaar hulpbronne vir die belangrikste take.
- Wanneer outoskaal, gebruik kleiner gevalle. 'n Groep van 10 klein eksemplare is beter as 'n groep van 4 grotes; as een geval misluk, sal in die eerste geval 10% van die verkeer oor 9 punte verdeel word, in die tweede - 25% van die verkeer oor drie punte.
So, kon dit voorsien gewees het, en dus voorkom word deur die probleem bekend te stel?
Ja, en op verskeie maniere.
Eerstens, deur hoë SVE-gebruik te simuleer met behulp van gereedskap soos of :
❯ stress-ng --matrix 1 -t 60s
spanning-ng
Tweedens, deur die instansie te oorlaai met en ander soortgelyke hulpmiddels:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Die eksperimente is relatief eenvoudig, maar kan goeie stof tot nadenke verskaf sonder om deur die spanning van 'n werklike mislukking te gaan.
Maar moenie daar stop nie. Probeer om die ongeluk in 'n toetsomgewing te reproduseer en kontroleer jou antwoord op die vraag "Kon dit voorsien gewees het en dus voorkom word deur 'n fout in te voer?" Dit is 'n mini-chaos-eksperiment binne 'n chaos-eksperiment om aannames te toets, maar begin met 'n mislukking.
Was dit 'n droom, of het dit regtig gebeur?
Bestudeer dus die geskiedenis van mislukkings, ontleed EOC, merk en klassifiseer hulle volgens "trefferradius" - of meer akkuraat, die aantal kliënte wat geraak word - en soek dan patrone. Vra jouself af of dit voorspel en voorkom kon word deur die probleem bekend te stel. Kontroleer jou antwoord.
Skakel dan oor na die mees algemene patrone met die grootste reeks.
2. Bou 'n afhanklikheidskaart
Neem 'n oomblik om na te dink oor jou aansoek. Is daar 'n duidelike kaart van sy afhanklikhede? Weet jy watter impak hulle sal hê as daar 'n mislukking is?
As jy nie baie vertroud is met jou toepassing se kode of dit baie groot geword het nie, kan dit moeilik wees om te verstaan wat die kode doen en wat die afhanklikhede daarvan is. Om hierdie afhanklikhede en hul moontlike impak op die toepassing en gebruikers te verstaan, is van kritieke belang om te weet waar om met chaos-ingenieurswese te begin: die beginpunt is die komponent met die grootste impakradius.
Die identifisering en dokumentasie van afhanklikhede word genoem "bou van 'n afhanklikheidskaart» (afhanklikheidskartering). Dit word tipies gedoen vir toepassings met 'n groot kodebasis met behulp van kodeprofielinstrumente. (kode profilering) en instrumentasie (instrumentasie). Jy kan ook 'n kaart bou deur netwerkverkeer te monitor.
Nie alle afhanklikhede is egter dieselfde nie (wat die proses verder bemoeilik). Sommige krities, ander - sekondêr (ten minste in teorie, aangesien ineenstortings dikwels voorkom as gevolg van probleme met afhanklikhede wat as nie-kritiek beskou is).
Sonder kritieke afhanklikhede kan die diens nie werk nie. Nie-kritiese afhanklikhede "moet nie» om die diens te beïnvloed in geval van 'n val. Om afhanklikhede te verstaan, moet jy 'n duidelike begrip hê van die API's wat deur jou toepassing gebruik word. Dit kan baie moeiliker wees as wat dit lyk - ten minste vir groot toepassings.
Begin deur al die API's te gaan. Lig die meeste uit betekenisvol en krities. Neem afhangende van van die kodebewaarplek, kyk daarna verbinding logs, kyk dan dokumentasie (natuurlik, as dit bestaan - anders het jy nog steedsоgroter probleme). Gebruik die gereedskap om profilering en opsporing, filter eksterne oproepe uit.
Jy kan programme gebruik soos netstat - 'n opdragreëlhulpmiddel wat 'n lys van alle netwerkverbindings (aktiewe voetstukke) in die stelsel vertoon. Byvoorbeeld, om alle huidige verbindings te lys, tik:
❯ netstat -a | more
In AWS kan jy gebruik (vloei logs) VPC is 'n metode wat jou toelaat om inligting in te samel oor IP-verkeer wat na of van netwerkkoppelvlakke in 'n VPC gaan. Sulke logs kan ook help met ander take - byvoorbeeld om 'n antwoord te vind op die vraag waarom sekere verkeer nie die instansie bereik nie.
Jy kan ook gebruik . X-straal laat jou toe om gedetailleerde, "uiteindelike" te kry (end-tot-end) oorsig van versoeke soos hulle deur die toepassing beweeg, en bou ook 'n kaart van die toepassing se onderliggende komponente. Baie gerieflik as jy afhanklikhede moet identifiseer.
AWS X-straalkonsole
'n Netwerkafhanklikheidskaart is slegs 'n gedeeltelike oplossing. Ja, dit wys watter toepassing met watter kommunikeer, maar daar is ander afhanklikhede.
Baie toepassings gebruik DNS om aan afhanklikhede te koppel, terwyl ander diensontdekking of selfs hardgekodeerde IP-adresse in konfigurasielêers kan gebruik (bv. /etc/hosts).
Byvoorbeeld, jy kan skep met die hulp iptables en kyk wat breek. Om dit te doen, voer die volgende opdrag in:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS swart gat
As in /etc/hosts of ander konfigurasielêers, sal jy IP-adresse vind waarvan jy niks weet nie (ja, dit gebeur ongelukkig ook), jy kan weer tot die redding kom iptables. Kom ons sê jy het ontdek 8.8.8.8 en weet nie dat dit Google se publieke DNS-bedieneradres is nie. Deur die gebruik van iptables Jy kan inkomende en uitgaande verkeer na hierdie adres blokkeer deur die volgende opdragte te gebruik:
❯ 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"
Toegang sluit
Die eerste reël laat val alle pakkies van Google se publieke DNS af: ping werk, maar pakkies word nie teruggestuur nie. Die tweede reël laat val alle pakkies wat van jou stelsel afkomstig is na Google se publieke DNS - in reaksie op ping ons kry Operasie word nie toegelaat nie.
Let wel: in hierdie spesifieke geval sal dit beter wees om te gebruik whois 8.8.8.8, maar dit is net 'n voorbeeld.
Ons kan selfs dieper in die konyngat afgaan, want alles wat TCP en UDP gebruik, hang eintlik ook van IP af. In die meeste gevalle is IP gekoppel aan ARP. Moenie van firewalls vergeet nie...
As jy die rooi pil drink, bly jy in Wonderland, en ek sal jou wys hoe diep die konyngat gaan."
'n Meer radikale benadering is om ontkoppel karre een vir een en kyk wat is stukkend... word 'n "chaos aap." Natuurlik is baie produksiestelsels nie ontwerp vir so 'n brute kragaanval nie, maar dit kan ten minste in 'n toetsomgewing probeer word.
Die bou van 'n afhanklikheidskaart is dikwels 'n baie lang onderneming. Ek het onlangs met 'n kliënt gepraat wat byna 2 jaar spandeer het om 'n instrument te ontwikkel wat semi-outomaties afhanklikheidskaarte genereer vir honderde mikrodienste en opdragte.
Die resultaat is egter uiters interessant en nuttig. Jy sal baie leer oor jou stelsel, sy afhanklikhede en bedrywighede. Weereens, wees geduldig: dit is die reis self wat die belangrikste is.
3. Pasop vir oormoed
“Wie van wat droom, glo daarin.” — Demosthenes
Het jy al ooit gehoor van oorvertroue effek?
Volgens Wikipedia is die oorvertroue-effek "'n kognitiewe vooroordeel waarin 'n persoon se vertroue in hul optrede en besluite aansienlik groter is as die objektiewe akkuraatheid van daardie oordele, veral wanneer die vlak van vertroue relatief hoog is."
Gebaseer op instink en ervaring...
In my ervaring is hierdie vervorming 'n goeie wenk van waar om met chaos-ingenieurswese te begin.
Pasop vir die selfversekerde operateur:
Charlie: "Hierdie ding het nie in vyf jaar geval nie, alles is reg!"
Crash: "Wag ... ek sal binnekort daar wees!"
Vooroordeel as gevolg van oormoed is 'n verraderlike en selfs gevaarlike ding as gevolg van die verskeie faktore wat dit beïnvloed. Dit is veral waar wanneer spanlede hul harte in 'n tegnologie gestort het of baie tyd daaraan bestee het om dit te "regmaak".
Opsomming
Die soeke na 'n beginpunt vir chaos-ingenieurswese bring altyd meer resultate as wat verwag is, en spanne wat dinge te vinnig begin breek, verloor die meer globale en interessante wese van (chaos-) uit die oog.ingenieurswese - kreatiewe toepassing wetenskaplike metodes и empiriese bewyse vir die ontwerp, ontwikkeling, bedryf, instandhouding en verbetering van (sagteware) stelsels.
Dit sluit die tweede deel af. Skryf asseblief resensies, deel menings of klap net jou hande . In die volgende deel I werklik Ek sal gereedskap en metodes oorweeg om foute in stelsels in te voer. Tot!
PS van vertaler
Lees ook op ons blog:
- «»;
- «»;
- «»;
- «".
Bron: will.com