SRE (Site Reliability Engineering) web proiektuen erabilgarritasuna bermatzeko hurbilketa bat da. DevOps-en esparrutzat hartzen da eta DevOps praktikak aplikatzean arrakasta nola lortu buruz hitz egiten du. Itzulpena artikulu honetan liburuak Google-tik. Itzulpen hau neuk prestatu nuen eta jarraipen-prozesuak ulertzeko nire esperientzian oinarritu nintzen. Telegram kanalean ΠΈ Liburu bereko 4. kapituluaren itzulpenerako esteka bat ere argitaratu nuen zerbitzu-mailako helburuei buruz.
Katuaren itzulpena. Gozatu irakurtzen!
Google-ren SRE taldeek oinarrizko printzipioak eta jardunbide egokiak dituzte monitorizazio eta jakinarazpen sistema arrakastatsuak sortzeko. Kapitulu honek web-orriaren bisitariek zer arazo izan ditzakeen eta web-orriak bistaratzea zailtzen duten arazoak nola konpon ditzakeen orientazioa eskaintzen du.
define
Ez dago jarraipenarekin lotutako gaiak eztabaidatzeko hiztegi bakarra erabiltzen. Googlen ere, beheko terminoak ez dira erabili ohi, baina interpretazio ohikoenak zerrendatuko ditugu.
jarraipenaren
Sistemari buruzko datu kuantitatiboak biltzea, prozesatzea, agregatzea eta bistaratzea denbora errealean: eskaera kopurua eta eskaera mota, akats kopurua eta akats mota, eskaerak prozesatzeko denbora eta zerbitzariaren funtzionamendu-denbora.
Kutxa zurien jarraipena
Sistema barneko osagaiek bistaratzen dituzten neurketetan oinarritutako jarraipena, erregistroak, Java Virtual Machine profilaren neurketak edo barne-estatistikak sortzen dituzten HTTP kudeatzailearen neurketak barne.
Kutxa beltzaren jarraipena
Aplikazioen portaera probatzea erabiltzailearen ikuspuntutik.
Aginte-panela
Zerbitzuen osasun-adierazle nagusien ikuspegi orokorra eskaintzen duen interfazea (normalean weba). Aginte-panelak iragazkiak izan ditzake, erakutsitako adierazleak hautatzeko aukera, etab. Interfazea erabiltzaileentzat garrantzitsuenak diren adierazleak identifikatzeko diseinatuta dago. Arbelak laguntza teknikoko langileentzako informazioa ere bistara dezake: eskaeren ilara bat, lehentasun handiko akatsen zerrenda eta ardura-eremu jakin baterako esleitutako ingeniari bat.
Alerta (jakinarazpena)
Pertsona batek posta elektroniko bidez edo beste bide batzuen bidez jaso nahi dituen jakinarazpenak, akatsak edo eskaera-ilara handitzeak eragin ditzakeenak. Jakinarazpenak honela sailkatzen dira: sarrerak, posta elektronikoko alertak eta berehalako mezularitzako mezuak.
Arrazoi nagusia
Softwarearen akatsa edo giza akatsa, behin zuzenduta, berriro gertatu behar ez dena. Arazoak hainbat arrazoi nagusi izan ditzake: prozesuen automatizazio nahikoa eza, softwarearen akatsa, aplikazioaren logikaren lanketa eza. Faktore horietako bakoitza izan daiteke arrazoia, eta horietako bakoitza ezabatu behar da.
Nodoa eta makina (nodoa eta makina)
Termino trukagarriak zerbitzari fisiko, makina birtual edo edukiontzi batean exekutatzen ari den aplikazio baten instantzia bakar bati erreferentzia egiteko. Makina batek hainbat zerbitzu har ditzake. Zerbitzuak hauek izan daitezke:
- elkarren artean konektatuta: adibidez, caching zerbitzari bat eta web zerbitzari bat;
- zerikusirik ez duten zerbitzuak hardware bakarrean: adibidez, kode biltegi bat eta konfigurazio sistema baterako morroia, adibidez edo .
Bultza
Softwarearen konfigurazioan edozein aldaketa.
Zergatik behar da monitorizazioa?
Hainbat arrazoi daude aplikazioak kontrolatu behar direlako:
Epe luzerako joeren analisia
Zenbatekoa da datu-basea eta zenbateraino hazten ari da? Nola aldatzen da eguneroko erabiltzaile kopurua?
Errendimenduen alderaketa
Eskaerak azkarragoak al dira Acme Bucket of Bytes 2.72-n Ajax DB 3.14-rekin alderatuta? Zenbat hobeto gordetzen dira eskaerak nodo gehigarri bat agertu ondoren? Gunea motelagoa al da joan den astearekin alderatuta?
Alerta (jakinarazpenak)
Zerbait apurtuta dago eta norbaitek konpondu behar du. Edo zerbait apurtuko da laster eta norbaitek laster egiaztatu behar du.
Aginte-panelak sortzea
Aginte-panelek oinarrizko galderei erantzun behar diete eta zerbait sartu β atzerapenak (latentzia), trafikoa (trafikoa), akatsak (erroreak) eta kargaren tamaina (saturazioa).
Atzera begirako analisia egitea (araztea)
Eskaerak prozesatzeko atzerapena handitu egin da, baina zer gehiago gertatu da aldi berean?
Monitorizazio-sistemak baliagarriak dira business intelligence sistemetarako datu-iturri gisa eta segurtasun-intzidentziaren azterketa errazteko. Liburu honek SREek esperientzia duten ingeniaritza arloetan zentratzen denez, ez dugu hemen monitorizazio teknikak eztabaidatuko.
Monitorizazioak eta alertak sistemak apurtu den edo matxura dagoenean esan dezake. Sistema batek bere burua automatikoki konpondu ezin duenean, gizaki batek alerta aztertzea nahi dugu, arazoa oraindik aktibo dagoen ala ez zehaztea, konpontzea eta arrazoi nagusia zehaztea. Sistemaren osagaiak ikuskatzen ez badituzu, ez duzu inoiz alertarik jasoko "zerbait arraro samarra dirudielako".
Pertsona bati jakinarazpenez zamatzea langilearen denbora nahiko garestia da. Langilea lanean ari bada, alertak lan-prozesua eten egiten du. Langilea etxean badago, alertak denbora pertsonala eten egiten du eta baliteke lo egitea. Alertak maizegi gertatzen direnean, langileek haiek zeharkatu, atzeratu edo sarrerako alertak baztertu egiten dituzte. Noizean behin benetako alerta baztertzen dute, zarata-gertakariek estaltzen dutena. Zerbitzu-etenek denbora luzez iraun dezakete, zarata-gertaerek arazoa azkar diagnostikatu eta zuzentzea eragozten baitute. Abisu sistema eraginkorrak seinale-zarata erlazio ona dute.
Jarraipen-sistemarako arrazoizko itxaropenak ezartzea
Aplikazio konplexu baten monitorizazioa konfiguratzea ingeniaritza-zeregin konplexua da berez. Nahiz eta bilketa, bistaratzeko eta alerta-tresnen azpiegitura nabarmena izan, 10-12 kidez osatutako Google SRE talde batek normalean pertsona bat edo bi izaten ditu, eta haien helburu nagusia monitorizazio-sistemak sortzea eta mantentzea da. Kopuru hori gutxitu egin da denborarekin monitorizazio-azpiegitura finkatu eta zentralizatzen dugun heinean, baina SRE talde bakoitzak normalean monitorizaziora soilik dedikatzen duen pertsona bat izaten du gutxienez. Esan behar dugu sistemaren aginte-panelak ikusteko nahiko interesgarriak diren arren, SRE taldeek arreta handiz saihesten dutela norbaitek pantaila bat begiratzea arazoak kontrolatzeko eskatzen duten egoerak.
Orokorrean, Google monitorizazio-sistema sinple eta azkarrera joan da, gertakarien ondorengo analisirako tresna optimoekin. Atalaseak iragartzen edo kausa automatikoki detektatzen saiatzen diren sistema "magikoak" saihesten ditugu. Azken erabiltzaileen eskaeretan nahi gabeko edukia detektatzen duten sentsoreak dira kontraadibide bakarra; Sentsore hauek sinpleak izaten jarraitzen duten bitartean, anomalia larrien arrazoiak azkar hauteman ditzakete. Jarraipen-datuak erabiltzeko beste formatu batzuk, hala nola, ahalmenaren plangintza edo trafikoaren aurreikuspena, konplexuagoak dira. Laginketa-tasa baxuan (orduak edo egunak) oso epe luzean (hilabeteak edo urteak) behatzeak epe luzerako joera agerian utziko du.
Google SRE taldeak arrakasta nahasia izan du mendekotasun-hierarkia konplexuekin. Gutxitan erabiltzen ditugu arauak: "Datu-basea motela dela jakiten badut, datu-basea motela dela dioen alerta jasotzen dut, bestela gunea motela dela dioen alerta". Mendekotasunean oinarritutako arauek normalean gure sistemaren atal aldaezinak aipatzen dituzte, hala nola, erabiltzaileen trafikoa datu-zentrora iragazteko sistema. Adibidez, "datu-zentrorako trafiko-iragazkia konfiguratuta badago, ez iezadazu abisatu erabiltzaileen eskaerak prozesatzeko atzerapenei buruz" datu-zentroko abisuetarako arau orokor bat da. Google-ko talde gutxik onartzen dute mendekotasun-hierarkia konplexuak, gure azpiegiturak etengabeko birfactorizazio-tasa duelako.
Kapitulu honetan deskribatutako ideia batzuk oraindik garrantzitsuak dira: beti dago sintomatik kausa bizkorrago mugitzeko aukera, batez ere etengabe aldatzen ari diren sistemetan. Hori dela eta, kapitulu honetan monitorizazio-sistemen helburu batzuk eta helburu horiek nola lortu azaltzen diren arren, garrantzitsua da monitorizazio-sistemak sinpleak eta ulergarriak izatea taldeko guztientzat.
Era berean, zarata maila baxua eta seinale maila altua mantentzeko, alertatutako aktiboak monitorizatzeko planteamenduak oso sinpleak eta fidagarriak izan behar dira. Pertsonentzako abisuak sortzen dituzten arauek ulertzeko errazak izan behar dute eta arazo argia aurkeztu.
Sintomak versus kausak
Zure monitorizazio sistemak bi galdera erantzun beharko lituzke: "zer apurtu zen" eta "zergatik apurtu zen".
"Zer hautsi den" sintomaz hitz egiten du, eta "zergatik hautsi den" kausaz hitz egiten du. Beheko taulak horrelako konexioen adibideak erakusten ditu.
Sintoma bat
Eragin
HTTP errorea 500 edo 404 lortzea
Datu-baseen zerbitzariek konexioak baztertzen dituzte
Zerbitzariaren erantzun motelak
CPU erabilera handia edo Ethernet kable hondatua
Antartikako erabiltzaileek ez dute katu GIFrik jasotzen
Zure CDNk zientzialariak eta katuak gorrotatzen ditu, beraz, IP helbide batzuk zerrenda beltzean sartu ziren
Eduki pribatua edonondik eskuragarri egon da
Software-oharra berri baten inplementari esker, suebakiak ACL guztiak ahaztea eta denak sartzen utzi zituen
"Zer" eta "zergatik" dira seinalerik handiena eta gutxieneko zarata dituen monitorizazio-sistema on bat sortzeko elementu garrantzitsuenetako batzuk.
Kutxa beltza vs kutxa zuria
Kutxa zuriaren jarraipen zabala eta kutxa beltzaren jarraipen xumearekin konbinatzen ditugu neurri kritikoetarako. Black-box eta White-box alderatzeko modurik errazena Black-box sintometan zentratuta dagoela eta monitorizazio proaktiboa baino erreaktiboa da: "sistemak ez du behar bezala funtzionatzen une honetan". Kutxa zuria sistemen barne egiaztapen-gaitasunen araberakoa da: gertaeren erregistroak edo web zerbitzariak. Horrela, White-box-ek hurrengo arazoak, eskaera baten birtransmisioa diruditen akatsak, etab detektatzeko aukera ematen du.
Kontuan izan geruza anitzeko sistema batean, ingeniari baten ardura-eremuko sintoma bat beste ingeniari baten ardura-eremuko sintoma dela. Adibidez, datu-basearen errendimendua gutxitu egin da. Datu-baseen irakurketa motelak detektatzen dituen SRE datu-basearen sintoma dira. Hala ere, webgune motel bat behatzen duen frontend SRE batentzat, datu-base motelaren irakurketaren kausa datu-base motela da. Hori dela eta, kutxa zuriko monitorizazioa batzuetan sintometan zentratzen da eta beste batzuetan kausetan zentratzen da, zein zabala den.
Arazketarako telemetria biltzean, Kutxa Zuriaren monitorizazioa beharrezkoa da. Web zerbitzariak datu-basearen kontsultei erantzuten motelak badira, web zerbitzaria datu-basearekin zein azkar komunikatzen den eta zein azkar erantzuten duen jakin behar duzu. Bestela, ezingo duzu bereizi datu-basearen zerbitzari motel bat eta sareko arazo bat web zerbitzariaren eta datu-basearen artean.
Kutxa beltzen monitorizazioak abantaila nagusi bat du alertak bidaltzerakoan: hartzailearen jakinarazpena abiarazten diozu arazoak dagoeneko benetako sintomak eragin dituenean. Bestalde, monitorizazioak ez du ezertarako balio oraindik sortu ez den baina berehalako Kutxa Beltzaren arazo baterako.
Urrezko lau seinale
Urrezko lau monitorizazio seinaleak latentzia, trafikoa, akatsak eta saturazioa dira. Erabiltzaile-sistemako lau neurketa baino ezin badituzu neurtu, zentratu lau horietan.
atzerapenik
Eskaera izapidetzeko behar den denbora. Garrantzitsua da eskaera arrakastatsuen eta arrakastarik gabekoen latentzia bereiztea. Adibidez, datu-base batera edo beste backend baterako konexioa galtzeak eragindako HTTP 500 errore bat oso azkar diagnostikatu daiteke; hala ere, HTTP 500 errore batek huts egin duen eskaera adieraz dezake. 500 errore batek latentzia orokorrean duen eragina zehazteak ondorio okerrak ekar ditzake. Bestalde, errore motela errore azkarra ere bada! Hori dela eta, garrantzitsua da erroreen latentzia kontrolatzea akatsak iragaztea baino.
trafikoa
Zure sistemari egindako eskaera kopurua goi-mailako sistema-neurrietan neurtzen da. Web zerbitzu baterako, neurketa honek normalean segundoko HTTP eskaera kopurua adierazten du, eskaeren izaerarekin banatuta (adibidez, eduki estatikoa edo dinamikoa). Audio-streaming-sistema baterako, neurketa hau sareko I/O abiaduran edo aldibereko saio kopuruan zentratu daiteke. Gako-balioen biltegiratze-sistema baterako, neurketa hau segundoko transakzioak edo bilaketa-emaitzak izan daitezke.
Akatsak
Hau da, esplizituak (adibidez, HTTP 500), inplizituak (adibidez, HTTP 200 baina baliogabeko edukiarekin konbinatuta) edo politikak (adibidez, "Erantzun bat segundo batean harrapatu baduzu, segundo bat errore bat da") huts egin duten eskaeren tasa. HTTP erantzun-kodeak hutsegite-baldintza guztiak adierazteko nahikoak ez badira, baliteke bigarren mailako (barneko) protokoloak behar izatea huts partziala detektatzeko. Baliteke huts egin duten eskaera horien jarraipena egitea informatiboa ez izatea, eta sistemaren amaierako probak eduki okerra prozesatzen ari zarela hautematen lagunduko dizute.
Saturazioa
Neurri horrek zure zerbitzua zenbateraino erabiltzen den erakusten du. Hau sistemaren jarraipen-neurri bat da, mugarik handiena duten baliabideak identifikatzen dituena (adibidez, memoriak mugatutako sistema batean, memoria erakusten du, I/O-ko sistema batean, I/O-kopurua erakusten du). Kontuan izan sistema askok errendimendua murrizten duela % 100eko erabilerara iritsi aurretik, beraz, erabilera-helburu bat izatea garrantzitsua da.
Sistema konplexuetan, saturazioa maila altuagoko karga-neurketekin osa daiteke: zure zerbitzuak behar bezala kudeatu al dezake trafiko bikoitza, soilik %10 trafiko gehiago kudeatu edo are trafiko gutxiago kudeatu gaur egun baino? Eskaeraren konplexutasuna aldatzen duten parametrorik ez duten zerbitzu soiletarako (adibidez, "Eman ezer" edo "Oso monotoniko bakarra behar dut"), konfigurazioa oso gutxitan aldatzen dutenak, karga estatikoko probaren balio bat egokia izan daiteke. Hala ere, aurreko paragrafoan aipatu bezala, zerbitzu gehienek zeharkako seinaleak erabili behar dituzte, hala nola CPU erabilera edo sareko banda zabalera, goiko muga ezaguna dutenak. Latentzia handitzea saturazioaren adierazle nagusia izaten da. 99. pertzentilaren erantzun-denbora leiho txiki batean (adibidez, minutu batean) neurtzeak saturazio-seinale goiztiarra eman dezake.
Azkenik, saturazioa hurrengo saturazioari buruzko iragarpenekin ere lotzen da, adibidez: "Badirudi zure datu-baseak zure disko gogorra beteko duela 4 ordutan".
Urrezko lau seinaleak neurtzen badituzu eta metrikaren batekin arazoren bat dagoenean (edo, saturazioaren kasuan, hurbileko arazoren bat), pertsona bati abisatzen badiozu, zure zerbitzua monitorizazioak gutxi gorabehera estaliko du.
"Buztana" (edo instrumentazioari eta errendimenduari buruzko kezkak)
Hutsetik monitorizazio sistema bat sortzean, batez besteko balioetan oinarritutako sistema bat garatzeko tentazioa dago: batez besteko latentzia, nodoen batez besteko CPU erabilera edo datu-basearen batez besteko betetasuna. Azken bi adibideen arriskua begien bistakoa da: prozesadoreak eta datu-baseak oso modu ezustekoan ezabatzen dira. Berdin gertatzen da atzerapenarekin. Batez beste 100 ms-ko latentzia duen web-zerbitzu bat exekutatzen baduzu, segundoko 1000 eskaerarekin, eskaeren % 1ek 5 segundo behar izan ditzake. Erabiltzaileak horrelako web-zerbitzu ugariren menpe badaude, backend baten 99. pertzentilea frontend-aren erantzun-denboraren mediana erraz bihur daiteke.
Eskaeren batez besteko motela eta oso motela eskaeren artean bereizteko modurik errazena estatistiketan adierazitako eskaeren neurketak biltzea da (bistaratzeko tresna ona histogramak dira) benetako latentzia baino gehiago: zerbitzuak zerbitzatu dituen zenbat eskaerak 0 ms artean hartu zuten. eta 10 ms, 10 ms eta 30 ms artean, 30 ms eta 100 ms artean, 100 ms eta 300 ms artean, etab. Histogramaren mugak gutxi gorabehera esponentzialki zabaltzea (gutxi gorabehera 3ko faktorearekin) banaketa ikusteko modu erraz bat izan ohi da. eskaeren.
Neurketetarako xehetasun-maila egokia hautatzea
Sistemaren elementu desberdinak xehetasun-maila desberdinetan neurtu behar dira. Adibidez:
- Denbora-tarte batean PUZaren erabilera kontrolatzeak ez du latentzia handiak ekartzen dituzten epe luzerako pikorik erakutsiko.
- Bestalde, urtean 9 orduko geldialdi-denbora baino gehiago helburu duen web-zerbitzu baterako (urteko % 99,9ko funtzionamendu-denbora), HTTP 200-ren erantzuna minutuko behin edo bitan baino gehiagotan egiaztatzea litekeena da alferrikako maiz izatea.
- Era berean, 99,9-1 minuturo behin baino gehiagotan egiaztatzea disko gogorreko tokia %2ko erabilgarritasuna ziurrenik ez da beharrezkoa.
Kontuz ibili zure neurketen granulartasuna nola egituratzen duzun. PUZaren karga segundoan behin biltzeak datu interesgarriak eman ditzake, baina halako maiz egiten diren neurketak oso garestia izan daitezke biltzea, gordetzea eta aztertzea. Zure monitorizazio-helburuak granulartasun handia behar badu eta ez badu erantzun handirik behar, kostu horiek murri ditzakezu zerbitzarian metrika-bilketa konfiguratuz eta, ondoren, metrika horiek biltzeko eta batzeko kanpoko sistema bat konfiguratuz. Ahalko zenuke:
- Neurtu PUZaren karga segundo bakoitzean.
- Murriztu xehetasunak %5era.
- Bilatu neurketak minuturo.
Estrategia honek datuak granularitate handian biltzeko aukera emango dizu analisi eta biltegiratze gastu handirik eragin gabe.
Ahalik eta sinpleena, baina ez sinpleagoa
Baldintza desberdinak bata bestearen gainean gainjartzeak kontrol-sistema oso konplexua sor dezake. Adibidez, zure sistemak elementu konplikatu hauek izan ditzake:
- Eskaerak prozesatzeko latentziaren atalase ezberdinen araberako alertak, pertzentil ezberdinetan, adierazle ezberdin mota guztietarako.
- Kode gehigarria idaztea arrazoi posibleak detektatzeko eta identifikatzeko.
- Sortu erlazionatutako aginte-panelak arazoen arrazoi posibleetako bakoitzerako.
Balizko konplikazioen iturriak ez dira inoiz amaitzen. Software-sistema guztiak bezala, monitorizazioa hain konplexua izan daiteke, non hauskorra eta zaila da aldatzea eta mantentzea.
Hori dela eta, diseinatu zure monitorizazio sistema ahalik eta gehien sinplifikatzeko. Jarraitu beharrekoa aukeratzerakoan, kontuan izan honako hauek:
- Gertakari errealak gehien harrapatzen dituzten arauek ahalik eta errazenak, aurreikusgarriak eta fidagarriak izan behar dute.
- Gutxitan egiten den datu-bilketa, batuketa eta alerta-konfigurazioa (adibidez, hiruhileko baino gutxiago SRE talde batzuentzat) kendu behar da.
- Ezabatzeko aukerak dira bildutako baina aurrebista-paneletan erakusten ez diren edo alertak erabiltzen ez dituen neurketak.
Googlen, oinarrizko neurketak biltzea eta agregazioa, alertak eta aginte-panelekin konbinatuta, sistema nahiko autonomo gisa funtzionatzen dute (Google-ren jarraipen-sistema, egia esan, hainbat azpisistematan banatzen da, baina jendeak normalean azpisistema horien alderdi guztiak ezagutzen ditu). Tentagarria izan daiteke monitorizazioa sistema konplexuak aztertzeko beste teknika batzuekin konbinatzea: sistemaren profil zehatza, prozesuen arazketa, salbuespenei edo hutsegiteei buruzko xehetasunen jarraipena, karga-probak, erregistro-bilketa eta azterketa edo trafikoaren ikuskapena. Gauza horietako gehienek oinarrizko monitorizazioarekin komunztadurak dituzten arren, elkarrekin nahasteak emaitza gehiegi ekarriko ditu eta sistema konplexu eta hauskorra sortuko du. Softwarearen garapenaren beste hainbat alderdirekin gertatzen den bezala, sistema desberdinak integrazio-puntu argi, erraz eta akoplatuekin bateratzea da estrategiarik onena (adibidez, web API bat erabiltzea denbora-tarte luzean koherentea izan daitekeen formatu batean bildutako datuak berreskuratzeko. ).
Printzipioak elkarrekin lotzea
Kapitulu honetan aztertzen diren printzipioak Google SRE taldeek onartzen eta jarraitzen duten jarraipen- eta alerta-filosofia batean konbina daitezke. Jarraipen-filosofia horri eustea komeni da, abiapuntu ona da alerta-metodologia sortzeko edo berrikusteko, eta zure eragiketen funtzioaren galdera egokiak egiten lagun zaitzake, zure erakundearen tamaina edo zerbitzuaren edo sistemaren konplexutasuna edozein dela ere.
Jarraipen- eta alerta-arauak sortzean, galdera hauek egiteak positibo faltsuak eta alferrikako alertak saihesten lagunduko dizu:
- Arau honek detektatzen al du sistemaren egoera bestela hautemanezin bat, premiazkoa dena, ekintzara deitzen duena eta erabiltzaileari ezinbestean eragiten diona?
- Ez ikusi egin dezaket abisu hau ona dela jakinda? Noiz eta zergatik baztertu dezaket abisu hau eta nola saihes dezaket eszenatoki hau?
- Alerta honek esan nahi al du erabiltzaileek kalte negatiboak izaten ari direla? Ba al dago erabiltzaileek kalte negatiborik jasan ez duten egoerak, adibidez, trafikoa iragaztearen bidez edo alertak iragazi behar diren proba sistemak erabiltzean?
- Alerta honi erantzuteko neurriak har ditzaket? Neurri hauek premiazkoak dira ala goizera arte itxaron dezakete? Ekintza bat modu seguruan automatizatu al daiteke? Ekintza hau epe luzerako konponbidea edo epe laburreko konponbidea izango al da?
- Pertsona batzuk hainbat alerta jasotzen ari dira arazo honengatik, beraz, ba al dago alerta kopurua murrizteko modurik?
Galdera hauek alerta eta abisu sistemen oinarrizko filosofia islatzen dute:
- Alerta bat sartzen den bakoitzean berehala erreakzionatu behar dut. Egunean hainbat aldiz erreakzionatu dezaket nekatu baino lehen.
- Alerta bakoitzak garrantzitsua izan behar du.
- Alerta baten erantzun bakoitzak gizakiaren esku-hartzea behar du. Jakinarazpena automatikoki prozesatu badaiteke, ez luke iritsi behar.
- Alertak lehen existitzen ez zen arazo edo gertaera berri bati buruzkoak izan behar dira.
Ikuspegi honek bereizketa batzuk lausotzen ditu: alertak aurreko lau baldintzak betetzen baditu, berdin du alerta White-Box edo Black-Box monitorizazio-sistema batetik bidali den. Ikuspegi honek zenbait desberdintasun ere indartzen ditu: hobe da sintomak identifikatzen arrazoietan baino askoz esfortzu handiagoa egitea; arrazoiei dagokienez, ezinbesteko arrazoiez bakarrik kezkatu behar duzu.
Epe luzeko jarraipena
Gaur egungo produktibitate-inguruneetan, monitorizazio-sistemek etengabe eboluzionatzen ari den ekoizpen-sistema kontrolatzen dute, software-arkitektura, lan-kargaren ezaugarriak eta errendimendu-helburuak aldatzen dituena. Gaur egun automatizatzen zailak diren alertak ohikoak bihur daitezke, agian bideratzea merezi dutenak. Une honetan, norbaitek arazoaren oinarriak aurkitu eta ezabatu behar ditu; ebazpen hori ezinezkoa bada, alertari erantzunak automatizazio osoa eskatzen du.
Garrantzitsua da jarraipen-erabakiak epe luzerako helburuak kontuan hartuta hartzea. Gaur exekutatzen den alerta bakoitzak biharko sistema hobetzetik aldentzen du pertsona bat, beraz, sarritan, sistema produktibo baten erabilgarritasuna edo errendimendua murrizten da epe luzera monitorizazio sistema hobetzeko behar den denborarako. Ikus ditzagun bi adibide fenomeno hau argitzeko.
Bigtable SRE: A Tale of Over-Alert
Google-ren barne-azpiegitura normalean hornitu eta zerbitzu-mailaren (SLO) arabera neurtzen da. Duela urte asko, Bigtable-ren SLO zerbitzua zuzeneko bezero bat simulatzen zuen transakzio sintetiko baten batez besteko errendimenduan oinarritzen zen. Bigtablen eta biltegiratze-pilaren maila baxuagoen arazoen ondorioz, batez besteko errendimendua buztan "handi" batek bultzatu zuen: kontsulten % 5 okerrenak gainerakoak baino nabarmen motelagoak izan ziren askotan.
Posta elektronikoko jakinarazpenak bidali ziren SLO atalasea hurbildu ahala, eta mezularien alertak bidali ziren SLO gainditzen zenean. Bi alerta motak sarritan bidaltzen ziren, ingeniaritza-denbora onartezinak kontsumituz: taldeak denbora asko eman zuen alertak ordenatzen benetan garrantzitsuak ziren gutxi batzuk aurkitzeko. Askotan erabiltzaileei eragiten zien arazoren bat galdu genuen, alerta batzuk soilik arazo zehatz horretarako zirelako. Alerta asko ez ziren premiagarriak azpiegituraren arazo ulergarriengatik eta modu estandarrean prozesatu ziren, edo ez ziren batere prozesatu.
Egoera konpontzeko, taldeak hiru ikuspegi bat hartu zuen: Bigtable-ren errendimendua hobetzeko gogor lan egiten genuen bitartean, gure SLO helburua aldi baterako ezarri genuen kontsultaren erantzunaren latentziaren 75. pertzentila izatea. Posta elektronikoko alertak ere desaktibatu genituen, asko baitziren, ezinezkoa zelako diagnostikatzen denbora pasatzea.
Estrategia horri esker, arnasguneak epe luzerako arazoak konpontzen hasteko aukera eman zigun Bigtablen eta biltegiratze-pilaren beheko geruzetan, arazo taktikoak etengabe konpondu beharrean. Ingeniariek lana egin dezakete denbora guztian alertekin bonbardatu gabe. Azken finean, alerta prozesatzea aldi baterako atzeratzeak gure zerbitzuaren kalitatea hobetu ahal izan digu.
Gmail: aurreikus daitezkeen giza erantzun algoritmikoak
Bere sorreran, Gmail bilaketa-indize baten zatiak prozesatzeko diseinatutako WorkQueue prozesuen kudeaketa-sistema aldatu batean eraiki zen. Workqueue iraupen luzeko prozesuetara egokitu zen eta gero Gmail-era aplikatu zen, baina programatzaile opakuaren kodeko akats batzuk oso zailak izan ziren konpontzen.
Garai hartan, Gmail-en jarraipena egituratu zen, lan-ilara erabiliz banakako zereginak bertan behera uzten zirenean alertak abiarazteko. Planteamendu hau ez zen aproposa, garai hartan ere Gmail-ek milaka zeregin egiten baitzituen, eta horietako bakoitza gure erabiltzaileen ehuneko baten zati bati ematen zitzaien. Oso kezkatuta geunden Gmail-eko erabiltzaileei erabiltzailearen esperientzia ona eskaintzeak, baina hainbeste alerta kudeatzea ez zegoen eskura.
Arazo honi aurre egiteko, Gmail SRE-k tresna bat sortu zuen programatzailea ahalik eta hobekien arazketan laguntzeko, erabiltzaileen eragina gutxitzeko. Taldeak eztabaida batzuk izan zituen arazoen aurkikuntzatik konponbidearen bidez epe luzeko irtenbide bat aurkitu arte ziklo osoa automatizatzeari buruz, baina batzuk kezkatuta zeuden irtenbide horrek arazoa benetan konpontzea atzeratuko zuelako.
Tentsio hori ohikoa zen taldean eta askotan autodiziplinarekiko konfiantza eza islatzen zuen: taldekide batzuek konponketa zuzena egiteko denbora utzi nahi duten bitartean, beste batzuk kezkatzen dira azken konponketa ahaztu egingo dela eta behin-behineko konponketak betiko iraungo duelako. Arazo honek arreta merezi du, egoera iraunkor bihurtu beharrean arazoak aldi baterako konpontzea errazegia delako. Kudeatzaileek eta langile teknikoek funtsezko eginkizuna dute epe luzerako konponketak ezartzeko, epe luzeko konponketak potentzialki lagunduz eta lehenetsiz, hasierako "mina" desagertu ondoren ere.
Alerta erregularrak eta errepikakorrak eta erantzun algoritmikoak bandera gorria izan behar dute. Zure taldeak alerta hauek automatizatzeko gogorik ez izateak esan nahi du taldeak ez duela ziurtasunik algoritmoetan fidagarri izango dela. Hau konpondu beharreko arazo larria da.
Epe luzera
Gai arrunt batek Bigtable eta Gmail adibideak lotzen ditu: epe laburreko eta epe luzerako erabilgarritasunaren arteko lehia. Askotan, ahalegin handi batek sistema hauskor bati erabilgarritasun handia lortzen lagundu diezaioke, baina bide hau laburra izaten da normalean, talde erreduraz eta talde heroiko bereko kide kopuru txiki baten menpekotasunaz josia.
Epe laburreko erabilgarritasunaren murrizketa kontrolatua mingarria izan ohi da, baina estrategikoki garrantzitsua da sistemaren epe luzerako egonkortasunerako. Garrantzitsua da alerta bakoitza modu isolatuan ez ikustea, baizik eta kontuan hartzea alerta-bolumen-maila orokorrak ea sistema osasuntsu eta behar bezala irisgarri batera ekartzen duen talde bideragarri batekin eta pronostiko onarekin. Alerta-maiztasunaren estatistikak (normalean txanda bakoitzeko intzidentzia gisa adierazten dira, non gorabehera bat erlazionatutako hainbat gorabehera izan daitekeen) kudeaketari hiru hileroko txostenetan aztertzen ditugu, erabakiak hartzen dituztenek alerta-sistemaren kargaren eta taldearen osasun orokorraren ikuspegi etengabea izan dezaten.
Ondorioa
Jarraipen eta alerta osasuntsurako bidea erraza eta argia da. Alertak abiarazten dituzten arazoaren sintometan zentratzen da, eta kausa kontrolatzeak arazoen arazketarako laguntza gisa balio du. Sintomak kontrolatzea errazagoa da kontrolatzen duzun pilan zenbat eta gorago egon, nahiz eta datu-basearen karga eta errendimendua kontrolatzea datu-basean bertan egin behar den. Posta elektronikoaren jakinarazpenek oso erabilgarritasun mugatua dute eta erraz zarata bihurtu ohi dira; horren ordez, posta elektronikoko alertak eragiten dituzten egungo arazo guztiak kontrolatzen dituen aginte-panela erabili beharko zenuke. Aginte-panela gertaeren erregistro batekin ere parekatu daiteke korrelazio historikoak aztertzeko.
Epe luzera, sintomen eta berehalako benetako arazoei buruzko alerten txanda arrakastatsua lortu behar da, helburuak egokituz monitorizazioak diagnostiko azkarra onartzen duela ziurtatzeko.
Eskerrik asko itzulpena amaiera arte irakurtzeagatik. Harpidetu nire telegram kanalera monitorizazioari buruz ΠΈ .
Iturria: www.habr.com