Ohar. itzul.: Artikulu honek Adrian Hornsby AWS teknologiako ebanjelariaren artikulu sorta handi bati jarraitzen dio, zeinak modu erraz eta argian azaltzeari ekin dio IT sistemetan hutsegiteen ondorioak arintzeko esperimentazioaren garrantzia.
"Plan bat prestatzen ez baduzu, huts egiteko asmoa duzu". - Benjamin Franklin
В Artikulu sorta honetan, kaosaren ingeniaritza kontzeptua aurkeztu nuen eta sisteman akatsak aurkitzen eta zuzentzen nola laguntzen duen azaldu nuen ekoizpen-hutsak eragin aurretik. Era berean, kaosaren ingeniaritza nola sustatzen duen kultur aldaketa positiboa erakundeetan eztabaidatu zen.
Lehenengo zatiaren amaieran, "sistemetan hutsegiteak sartzeko tresnei eta metodoei buruz" hitz egingo nuela agindu nuen. Ai, nire buruak bere planak zituen zentzu honetan, eta artikulu honetan kaosaren ingeniaritzan sartu nahi duten pertsonen artean sortzen den galderarik ezagunena erantzuten saiatuko naiz: Zer hautsi lehenik?
Galdera bikaina! Hala ere, ez dirudi panda honek bereziki kezkatzen duenik...
Ez nahastu kaos pandarekin!
Erantzun laburra: Eskaeraren bidetik zerbitzu kritikoak bideratu.
Erantzun luzeagoa baina argiagoa: Kaosarekin esperimentatzen nondik hasi ulertzeko, jarri arreta hiru arlotan:
- Begiratu kraskaduraren historia eta ereduak identifikatzea;
- Erabaki mendekotasun kritikoak;
- Erabili deiturikoa gehiegizko konfiantza efektua.
Dibertigarria da, baina zati hau bezain erraz deitu liteke "Norberaren Aurkikuntzarako eta Ilustraziorako Bidaia". Bertan instrumentu polit batzuekin “jotzen” hasiko gara.
1. Erantzuna iraganean dago
Gogoratzen baduzu, lehen zatian Akatsen Zuzenketa (COE) kontzeptua aurkeztu nuen - gure akatsak -teknologia, prozesu edo antolakuntzako akatsak- aztertzen ditugun metodoa, haien kausa(k) ulertzeko eta prebenitzeko. etorkizunean errepikatzea. Oro har, hemen hasi beharko zenuke.
"Oraina ulertzeko, iragana ezagutu behar duzu". - Carl Sagan
Begiratu hutsegiteen historia, etiketatu COE edo postmortemetan eta sailkatu. Identifikatu askotan arazoak sortzen dituzten eredu arruntak, eta COE bakoitzeko, egin galdera hau zure buruari:
"Hau aurreikusi eta, beraz, akatsen injekzio bidez saihestu zitekeen?"
Porrot bat gogoratzen dut nire karrera hasieran. Erraz saihestu zitekeen kaosaren esperimentu sinple pare bat burutu izan bagenu:
Baldintza normaletan, backend-en instantziek osasun-kontrolei erantzuten diete ). ELBk egiaztapen hauek erabiltzen ditu eskaerak instantzia osasuntsuetara birbideratzeko. Instantzia bat "osasuntsugarria" dela ikusten denean, ELBk eskaerak bidaltzeari uzten dio. Egun batean, marketin-kanpaina arrakastatsu baten ondoren, trafiko-bolumena handitu zen eta backendek ohi baino astiroago erantzuten hasi ziren osasun-kontrolei. Esan beharra dago osasun-kontrol horiek izan zirela , hau da, mendekotasunen egoera egiaztatu zen.
Hala ere, dena ondo egon zen pixka batean.
Orduan, egoera estresagarri samarretan, instantziaetako bat ETL cron zeregin arrunt eta ez-kritikoa exekutatzen hasi zen. Trafiko handia eta cronjob-aren konbinazioak CPUaren erabilera ia% 100era bultzatu zuen. PUZaren gainkargak are gehiago moteldu zituen osasun-kontrolen erantzunak, hainbesteraino non ELBk instantzia errendimendu arazoak zituela erabaki zuen. Espero zen bezala, orekatzaileak hari trafikoa banatzeari utzi zion, eta horrek, aldi berean, taldeko gainerako instantzien karga handitzea ekarri zuen.
Bat-batean, beste kasu guztiak ere osasun-kontrolean huts egiten hasi ziren.
Instantzia berri bat abiarazteko paketeak deskargatu eta instalatu behar ziren eta ELBk behar izan zuena baino askoz ere denbora gehiago behar izan zuen autoeskalatze taldean banan-banan desgaitzeko. Argi dago laster prozesu osoa puntu kritiko batera iritsi zela eta aplikazioa huts egin zuela.
Orduan, betiko puntu hauek ulertu genituen:
- Instantzia berri bat sortzean softwarea instalatzeak denbora asko behar du; hobe da ikuspegi aldaezina hobestea eta .
- Egoera zailetan, osasun-kontrolei eta ELBei emandako erantzunek lehentasuna izan beharko lukete; nahi duzun azken gauza bizitza zailtzea da gainerako kasuetarako.
- Osasun-kontrolen tokiko cacheak asko laguntzen du (baita segundo batzuetan ere).
- Egoera zail batean, ez exekutatu cron zereginak eta beste prozesu ez-kritikoak - gorde baliabideak zeregin garrantzitsuenetarako.
- Autoeskalatzean, erabili instantzia txikiagoak. 10 ale txikiko taldea hobe da 4 handiz osatutako taldea baino; instantzia batek huts egiten badu, lehenengo kasuan trafikoaren % 10 9 puntutan banatuko da, bigarrenean - trafikoaren % 25 hiru puntutan.
Horrela, hori aurreikus zitekeen, eta, beraz, arazoa sartuz prebenitu?
Bai, eta hainbat modutan.
Lehenik eta behin, PUZaren erabilera handia simulatuz, esaterako, tresnak erabiliz edo :
❯ stress-ng --matrix 1 -t 60s
estresa-ng
Bigarrenik, instantzia gainkargatuz eta antzeko beste utilitate batzuk:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Esperimentuak nahiko sinpleak dira, baina pentsamendu on bat eman dezakete benetako porrot baten estresa pasatu beharrik gabe.
Baina ez gelditu hor. Saiatu hutsegitea proba-ingurune batean erreproduzitzen eta egiaztatu "galderaren erantzuna"Hau aurreikusi eta, beraz, saihestu zitekeen matxura bat sartuz?" Kaosaren esperimentu txiki bat da, hipotesiak probatzeko, baina porrot batekin hasita.
Amets bat izan zen, ala benetan gertatu zen?
Beraz, aztertu porroten historia, aztertu COE, etiketatu eta sailkatu "hit-erradioaren" arabera —edo zehatzago esanda, kaltetutako bezero kopuruaren arabera— eta, ondoren, ereduak bilatu. Galdetu zeure buruari ea arazoa sartuz hori aurreikusi eta prebenitu zitekeen. Egiaztatu zure erantzuna.
Ondoren, aldatu gamarik handiena duten eredu ohikoenetara.
2. Eraiki mendekotasun mapa
Hartu une bat zure aplikazioari buruz hausnartzeko. Ba al dago bere mendekotasunen mapa argirik? Ba al dakizu zer eragin izango duten porrot bat izanez gero?
Zure aplikazioaren kodea oso ezagutzen ez baduzu edo oso handia bihurtu bada, zaila izan daiteke kodea zer egiten duen eta zeintzuk diren bere menpekotasunak ulertzea. Mendekotasun horiek eta aplikazioan eta erabiltzaileengan izan dezaketen eragina ulertzea funtsezkoa da kaosaren ingeniaritzarekin nondik hasi jakiteko: abiapuntua inpaktu-erradio handiena duen osagaia da.
Mendekotasunak identifikatzea eta dokumentatzeari " deitzen zaiomendekotasun mapa eraikitzea» (mendekotasun mapak). Hau kode-oinarri handia duten aplikazioetarako egiten da normalean kodea profilatzeko tresnak erabiliz. (kode profila) eta tresneria (tresneria). Mapa bat ere eraiki dezakezu sareko trafikoa kontrolatuz.
Hala ere, menpekotasun guztiak ez dira berdinak (prozesua are gehiago zailtzen du). Batzuk kritikoa, beste - bigarren mailakoa (teorian behintzat, ez-kritikotzat jotzen ziren menpekotasunen arazoengatik gertatu ohi baitira kraskatzeak).
Mendekotasun kritikorik gabe, zerbitzuak ezin du funtzionatu. Mendekotasun ez-kritikoak "behar ez» erorketa gertatuz gero zerbitzuan eragiteko. Mendekotasunak ulertzeko, zure aplikazioak erabiltzen dituen APIak argi izan behar dituzu. Hau dirudiena baino askoz zailagoa izan daiteke - aplikazio handietarako behintzat.
Hasi API guztiak zeharkatuz. Nabarmendu gehien esanguratsua eta kritikoa. Hartu arabera kode biltegitik, begiratu konexioen erregistroak, gero ikusi dokumentazioa (noski, existitzen bada - bestela oraindik ere baduzuоarazo handiagoak). Erabili tresnak profila eta trazadura, iragazi kanpoko deiak.
bezalako programak erabil ditzakezu netstat - Sistemako sare-konexio guztien (entxufe aktiboak) zerrenda bistaratzen duen komando-lerroko utilitate bat. Adibidez, uneko konexio guztiak zerrendatzeko, idatzi:
❯ netstat -a | more
AWS-n erabil dezakezu (fluxuen erregistroak) VPC VPC bateko sare-interfazeetara doan IP trafikoari buruzko informazioa biltzeko aukera ematen duen metodo bat da. Erregistro horiek beste zeregin batzuetan ere lagun dezakete; adibidez, trafiko jakin bat instantziara zergatik ez iristen den galderari erantzuna aurkitzeko.
Erabili ere egin dezakezu . X-Ray-k zehatza, "azkena" lortzeko aukera ematen du (muturretik muturrera) Eskaeren ikuspegi orokorra aplikazioan zehar mugitzen diren heinean, eta aplikazioaren azpiko osagaien mapa ere eraikitzen du. Oso erosoa mendekotasunak identifikatu behar badituzu.
AWS X-Ray kontsola
Sarearen mendekotasun mapa irtenbide partziala baino ez da. Bai, zein aplikazio zeinekin komunikatzen den erakusten du, baina badaude beste menpekotasun batzuk.
Aplikazio askok DNS erabiltzen dute mendekotasunetara konektatzeko, beste batzuek zerbitzuen aurkikuntza edo baita gogor kodetutako IP helbideak ere erabil ditzakete konfigurazio fitxategietan (adibidez. /etc/hosts).
Adibidez, sor dezakezu laguntzarekin iptables eta ea zer apurtzen den. Horretarako, sartu komando hau:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS zulo beltza
Bada /etc/hosts edo beste konfigurazio-fitxategi batzuk, ezer ezagutzen ez dituzun IP helbideak aurkituko dituzu (bai, zoritxarrez, hau ere gertatzen da), berriro erreskatera etor zaitezke iptables. Demagun aurkitu duzula 8.8.8.8 eta ez dakit hau Google-ren DNS zerbitzariaren helbide publikoa denik. Erabiliz iptables Helbide honetara sarrerako eta irteerako trafikoa blokeatu dezakezu komando hauek erabiliz:
❯ 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"
Sarbidea ixten
Lehenengo arauak pakete guztiak kentzen ditu Google-ren DNS publikotik: ping funtzionatzen du, baina paketeak ez dira itzultzen. Bigarren arauak zure sistematik sortzen diren pakete guztiak Google-ren DNS publikora erortzen ditu - horri erantzuteko ping lortzen dugu Eragiketa ez da onartzen.
Oharra: kasu zehatz honetan hobe litzateke erabiltzea whois 8.8.8.8, baina hau adibide bat besterik ez da.
Are gehiago sakondu dezakegu untxi-zuloan, TCP eta UDP erabiltzen duen guztia IP-aren araberakoa baita. Kasu gehienetan, IP ARP-ri lotuta dago. Ez ahaztu suebakiez...
Pilula gorria hartzen baduzu, herrialde miresgarrian geratuko zara, eta untxi-zuloa zein sakona den erakutsiko dizut».
Ikuspegi erradikalagoa da deskonektatu kotxeak banan-banan eta ikusi zer apurtuta dagoen... bihurtu "kaos tximino". Jakina, ekoizpen-sistema asko ez daude halako indar gordinaren erasorako diseinatuta, baina gutxienez proba-ingurunean probatu daiteke.
Mendekotasun-mapa eraikitzea oso lan luzea da askotan. Duela gutxi, ia 2 urte eman zituen bezero batekin hitz egin nuen ehunka mikrozerbitzu eta komandoren mendekotasun-mapak erdi-automatikoki sortzen dituen tresna bat garatzen.
Emaitza, ordea, oso interesgarria eta erabilgarria da. Zure sistemari, bere menpekotasunei eta eragiketei buruz asko ikasiko duzu. Berriz ere, izan pazientzia: bidaia bera da garrantzitsuena.
3. Kontuz gehiegizko konfiantzarekin
"Zerrekin amesten duenak, horretan sinesten du". - Demostenes
Entzun al duzu inoiz gehiegizko konfiantza efektua?
Wikipediaren arabera, gehiegizko konfiantza efektua "alborapen kognitibo bat da, non pertsona batek bere ekintzetan eta erabakietan duen konfiantza epai horien zehaztasun objektiboa baino nabarmen handiagoa den, batez ere konfiantza maila nahiko altua denean".
Senean eta esperientzian oinarrituta...
Nire esperientziaren arabera, distortsio hau kaosaren ingeniaritzarekin hasteko argibide bikaina da.
Kontuz gehiegi konfiantza duen operadorearekin:
Charlie: "Gauza hau ez da bost urtetan erori, dena ondo dago!"
Crash: "Itxaron... laster egongo naiz!"
Gehiegizko konfiantzaren ondoriozko alborapena gauza maltzurra eta are arriskutsua da horretan eragiten duten faktore ezberdinengatik. Hau bereziki egia da taldekideek teknologia batean bihotza bota dutenean edo denbora asko "konpontzen" eman dutenean.
Laburbilduz
Kaosaren ingeniaritzarako abiapuntu baten bilaketak espero baino emaitza gehiago ekartzen ditu beti, eta gauzak azkarregi hausten hasten diren taldeek (kaos-) esentzia globalagoa eta interesgarriagoa bistaratzen dute.ingeniaritza - Sormen erabilera metodo zientifikoak и froga enpirikoak (software) sistemen diseinu, garapen, funtzionamendu, mantentze eta hobekuntzarako.
Honek amaitzen du bigarren zatia. Mesedez, idatzi iritziak, partekatu iritziak edo txalotu besterik ez . Hurrengo zatian I benetan Sistemetan hutsegiteak sartzeko tresnak eta metodoak kontuan hartuko ditut. Arte!
PS itzultzailetik
Irakurri ere gure blogean:
- «»;
- «»;
- «»;
- «'.
Iturria: www.habr.com