SRE (Site Reliability Engineering) is in oanpak om de beskikberens fan webprojekten te garandearjen. It wurdt beskôge as in ramt foar DevOps en praat oer hoe't jo sukses kinne berikke by it tapassen fan DevOps-praktiken. Oerset yn dit artikel boeken fan Google. Ik haw dizze oersetting sels taret en fertroude op myn eigen ûnderfining by it begripen fan tafersjochprosessen. Yn it telegramkanaal и Ik haw ek in keppeling publisearre nei de oersetting fan haadstik 4 fan itselde boek oer doelen op tsjinstnivo.
Oersetting troch kat. Genietsje fan it lêzen!
De SRE-teams fan Google hawwe basisprinsipes en bêste praktiken foar it meitsjen fan suksesfolle tafersjoch- en notifikaasjesystemen. Dit haadstik jout begelieding oer hokker problemen in websidebesiker kin tsjinkomme en hoe't jo problemen kinne oplosse dy't websiden lestich meitsje om wer te jaan.
Definysjes
D'r wurdt gjin inkelde wurdskat brûkt om ûnderwerpen te besprekken yn ferbân mei monitoaring. Sels op Google wurde de betingsten hjirûnder net gewoan brûkt, mar wy sille de meast foarkommende ynterpretaasjes listje.
Monitoring
Sammelje, ferwurkjen, aggregaasje en werjaan fan kwantitative gegevens yn realtime oer it systeem: oantal oanfragen en soarten oanfragen, oantal flaters en soarten flaters, ferwurkingstiid fan oanfraach en tsjinner uptime.
Wite doaze tafersjoch
Monitoring basearre op metriken werjûn troch ynterne systeemkomponinten, ynklusyf logs, Java Virtual Machine-profileringsmetriken, of HTTP-hantermetriken dy't ynterne statistiken generearje.
Black-box tafersjoch
Applikaasjegedrach testen út it eachpunt fan 'e brûker.
Dashboard
In ynterface (meastal web) dy't in oersjoch jout fan wichtige sûnensyndikatoaren fan tsjinsten. It dashboard kin filters hawwe, de mooglikheid om de werjûn yndikatoaren te selektearjen, ensfh De ynterface is ûntwurpen om de yndikatoaren te identifisearjen dy't it wichtichste binne foar brûkers. It dashboard kin ek ynformaasje werjaan foar technyske stipepersoniel: in wachtrige fan oanfragen, in list mei flaters mei hege prioriteit, en in tawiisde yngenieur foar in bepaald gebiet fan ferantwurdlikens.
Alert (notifikaasje)
Notifikaasjes dy't bedoeld binne om te ûntfangen troch in persoan fia e-post of op oare middels, dy't kinne wurde oanjûn troch flaters of in ferheging fan 'e fersykwachtrige. Notifikaasjes wurde klassifisearre as: tickets, e-postalerts en instant messenger-berjochten.
Root oarsaak
In softwaredefekt of minsklike flater dy't, ienris korrizjearre, net wer foarkomme moat. It probleem kin ferskate haadoarsaken hawwe: ûnfoldwaande prosesautomatisearring, softwaredefekt, ûnfoldwaande útwurking fan 'e applikaasjelogika. Elk fan dizze faktoaren kin de oarsaak wêze, en elk fan har moat wurde elimineare.
Knooppunt en masine (knooppunt en masine)
Útwikselbere termen om te ferwizen nei ien eksimplaar fan in rinnende applikaasje op in fysike tsjinner, firtuele masine of kontener. Ien masine kin host ferskate tsjinsten. Tsjinsten kinne wêze:
- mei elkoar ferbûn: bygelyks in caching-tsjinner en in webserver;
- net-relatearre tsjinsten op ien stik hardware: bygelyks in koaderepository en in wizard foar in konfiguraasjesysteem, lykas of .
Triuwe
Elke feroaring yn software konfiguraasje.
Wêrom is tafersjoch nedich?
D'r binne ferskate redenen wêrom't applikaasjes moatte wurde kontrolearre:
Analyse fan lange-termyn trends
Hoe grut is de databank en hoe fluch groeit it? Hoe feroaret it deistige oantal brûkers?
Performance ferliking
Binne oanfragen rapper op Acme Bucket of Bytes 2.72 yn ferliking mei Ajax DB 3.14? Hoe folle better wurde oanfragen yn 't cache bewarre nei it ferskinen fan in ekstra knooppunt? Rint de side stadiger yn ferliking mei ferline wike?
Alerting
Der is wat stikken en ien moat it reparearje. Of der sil gau wat brekke en immen moat it gau kontrolearje.
Dashboards oanmeitsje
Dashboards moatte basisfragen beantwurdzje en wat fan befetsje - fertragingen (latency), ferkear (ferkear), flaters (flaters) en loadgrutte (ferzadiging).
Retrospektive analyze útfiere (debuggen)
De fertraging foar ferwurking fan fersyk is tanommen, mar wat barde der oars om deselde tiid hinne?
Tafersjochsystemen binne nuttich as in boarne fan gegevens foar systemen foar bedriuwsintelliginsje en om de analyse fan feiligensynsidinten te fasilitearjen. Om't dit boek him rjochtet op technykgebieten wêryn SRE's ekspertize hawwe, sille wy hjir gjin tafersjochtechniken besprekke.
Monitoring en warskôgings kinne it systeem jo fertelle wannear't it is ôfbrutsen of op it punt is te brekken. As in systeem himsels net automatysk reparearje kin, wolle wy dat in minske de warskôging analysearret, bepale as it probleem noch aktyf is, it oplost en de oarsaak bepale. As jo systeemkomponinten net kontrolearje, sille jo noait in warskôging krije, gewoan om't "iets in bytsje frjemd liket."
It beladen fan in persoan mei notifikaasjes is in frij djoer gebrûk fan 'e tiid fan in wurknimmer. As de meiwurker wurket, ûnderbrekt de warskôging it wurkproses. As de meiwurker thús is, ûnderbrekt de warskôging persoanlike tiid en mooglik sliep. As warskôgings te faak foarkomme, skimme meiwurkers der troch, sette se ôf, of negearje ynkommende warskôgings. Fan tiid ta tiid negearje se de echte warskôging, dy't maskere wurdt troch lûdseveneminten. Tsjinstûnderbrekkingen kinne langer duorje, om't lûdseveneminten foarkomme dat it probleem fluch diagnostearre en korrizjearre wurdt. Effektive warskôgingssystemen hawwe in goede sinjaal-to-lûd-ferhâlding.
It ynstellen fan ridlike ferwachtingen foar it tafersjochsysteem
It ynstellen fan tafersjoch foar in komplekse applikaasje is op himsels in komplekse yngenieurtaak. Sels mei in wichtige ynfrastruktuer fan ark foar sammeljen, werjaan en warskôgje, omfettet in Google SRE-team fan 10–12 leden typysk ien of twa minsken waans primêre doel is om tafersjochsystemen te bouwen en te ûnderhâlden. Dit oantal is yn 'e rin fan' e tiid ôfnommen, om't wy de tafersjochynfrastruktuer konsolidearje en sintralisearje, mar elk SRE-team hat typysk op syn minst ien persoan dy't allinich wijd is oan tafersjoch. Wy moatte sizze dat hoewol it kontrolearjen fan systeemdashboards frij nijsgjirrich binne om nei te sjen, SRE-teams foarsichtich foarkomme situaasjes dy't nedich binne dat ien nei in skerm sjocht om problemen te kontrolearjen.
Oer it algemien is Google ferhuze nei ienfâldige en rappe monitoringsystemen mei optimale nei-de-feit analyse-ark. Wy mije "magyske" systemen dy't besykje drompels te foarsizzen of automatysk de oarsaak te ûntdekken. Sensoren dy't ûnbedoelde ynhâld detectearje yn oanfragen fan ein-brûkers binne it ienige tsjinfoarbyld; Salang't dizze sensoren ienfâldich bliuwe, kinne se de oarsaken fan serieuze anomalies fluch ûntdekke. Oare formaten foar it brûken fan tafersjochgegevens, lykas kapasiteitsplanning of ferkearsfoarsizzing, binne komplekser. Observaasje oer in heul lange perioade (moannen as jierren) by in leech samplingrate (oeren of dagen) sil in lange termyn trend sjen litte.
It Google SRE-team hat mingd súkses hân mei komplekse ôfhinklikheidshiërargyen. Wy brûke komselden regels lykas "as ik útfine dat de databank traach is, krij ik in warskôging dat de databank traach is, oars krij ik in warskôging dat de side traach is." Regels basearre op ôfhinklikens ferwize typysk nei ûnferoarlike dielen fan ús systeem, lykas it systeem foar it filterjen fan brûkersferkear nei it datasintrum. Bygelyks, "as ferkearsfiltering nei it datasintrum is konfigureare, warskôgje my dan net oer fertragingen by it ferwurkjen fan brûkersoanfragen" is ien algemiene regel foar warskôgings fan it datasintrum. In pear teams by Google stypje komplekse ôfhinklikheidshiërargyen, om't ús ynfrastruktuer in konstante taryf fan kontinuere refactoring hat.
Guon fan 'e ideeën dy't yn dit haadstik beskreaun binne binne noch relevant: d'r is altyd in kâns om rapper fan symptoom nei root-oarsaak te bewegen, benammen yn hieltyd feroarjende systemen. Dêrom, wylst dit haadstik sketst guon doelen foar monitoaring systemen en hoe te berikken dy doelen, is it wichtich dat monitoaring systemen binne ienfâldich en begryplik foar elkenien op it team.
Likemin, om lûdsnivo's leech en sinjaalnivo's heech te hâlden, moatte oanpakken foar it kontrolearjen fan warskôge aktiva heul ienfâldich en betrouber wêze. Regels dy't warskôgings generearje foar minsken moatte maklik te begripen wêze en in dúdlik probleem presintearje.
Symptomen tsjin oarsaken
Jo tafersjochsysteem moat twa fragen beantwurdzje: "wat bruts" en "wêrom it bruts."
"Wat bruts" fertelt oer it symptoom, en "wêrom it bruts" fertelt oer de oarsaak. De tabel hjirûnder lit foarbylden fan sokke ferbinings sjen.
In symptoom
Reden
HTTP-flater 500 of 404 krije
Databanktsjinners wegerje ferbiningen
Trage tsjinner antwurden
Hege CPU-gebrûk as beskeadige Ethernet-kabel
Brûkers yn Antarktika ûntfange gjin kat GIF's
Jo CDN hat in hekel oan wittenskippers en katten, sadat guon IP-adressen úteinlik op 'e swarte list waarden
Privee ynhâld is fan oeral beskikber wurden
De útrol fan in nije softwarerelease makke dat de firewall alle ACL's fergeat en elkenien yn liet
"Wat" en "wêrom" binne guon fan 'e wichtichste boustiennen foar it meitsjen fan in goed tafersjochsysteem mei maksimale sinjaal en minimale lûd.
Black-box vs White-box
Wy kombinearje wiidweidige White-box-monitoring mei beskieden Black-box-monitoring foar krityske metriken. De maklikste manier om Black-box te fergelykjen mei White-box is dat Black-box symptoom-rjochte is en reaktyf is ynstee fan proaktive tafersjoch: "it systeem wurket op it stuit net goed." White-box hinget ôf fan 'e ynterne ferifikaasjemooglikheden fan systemen: barrenslogs of webservers. Sa lit White-box jo driigjende problemen opspoare, flaters dy't lykje te wêzen in werútstjoering fan in fersyk, ensfh.
Tink derom dat yn in systeem mei meardere lagen in symptoom yn it ferantwurdlikensgebiet fan ien yngenieur in symptoom is yn it ferantwurdlikensgebiet fan in oare yngenieur. Bygelyks, de prestaasjes fan databases binne ôfnommen. Trage databanklêzingen binne in symptoom fan de databank SRE dy't se detektearret. Lykwols, foar in front-end SRE observearjen fan in trage webside, de oarsaak fan deselde trage databank lêzen is in trage databank. Dêrom is monitoring fan wite doazen soms symptoom-rjochte en soms oarsaak-rjochte, ôfhinklik fan hoe wiidweidich it is.
By it sammeljen fan telemetry foar debuggen, is tafersjoch op White-box fereaske. As webservers traach binne om te reagearjen op databankfragen, moatte jo witte hoe fluch de webserver kommunisearret mei de databank en hoe fluch it reagearret. Oars kinne jo gjin ûnderskied meitsje tusken in trage databanktsjinner en in netwurkprobleem tusken de webtsjinner en de databank.
Black-box-monitoring hat in wichtich foardiel by it ferstjoeren fan warskôgings: jo trigger de notifikaasje oan 'e ûntfanger as it probleem al hat resultearre yn echte symptomen. Oan 'e oare kant is tafersjoch nutteloos foar in Black-box-probleem dat noch net ûntstien is, mar driigjend is.
Fjouwer gouden sinjalen
De fjouwer gouden monitoaringssinjalen binne latency, ferkear, flaters en sêding. As jo mar fjouwer metriken fan brûkerssysteem kinne mjitte, fokus dan op dy fjouwer.
Fertraagje
De tiid nedich om it fersyk te ferwurkjen. It is wichtich om te ûnderskieden tusken de latency fan suksesfolle en net-suksesfolle oanfragen. Bygelyks, in HTTP 500 flater feroarsake troch in ferlies fan ferbining mei in databank of oare backend kin wurde diagnostearre hiel fluch, lykwols, in HTTP 500 flater kin wize op in mislearre fersyk. It bepalen fan 'e ynfloed fan in 500-flater op' e totale latency kin liede ta ferkearde konklúzjes. Oan 'e oare kant is in trage flater sels in flugge flater! Dêrom is it wichtich om flaterlatinsje te kontrolearjen ynstee fan gewoan flaters út te filterjen.
Ferkear
It oantal oanfragen foar jo systeem wurdt mjitten yn systeemmetriken op heech nivo. Foar in webtsjinst fertsjintwurdiget dizze mjitting typysk it oantal HTTP-oanfragen per sekonde, dield troch de aard fan 'e oanfragen (bygelyks statyske of dynamyske ynhâld). Foar in audiostreamingsysteem kin dizze mjitting rjochtsje op netwurk I / O-snelheid as it oantal simultane sesjes. Foar in kaai-wearde opslachsysteem kin dizze mjitting transaksjes as sykresultaten per sekonde wêze.
Flater
Dit is it taryf fan mislearre oanfragen dy't eksplisyt binne (bgl. HTTP 500), ymplisyt (bgl. HTTP 200, mar kombinearre mei ûnjildige ynhâld) of belied (bgl. "As jo in antwurd yn ien sekonde fêstlein hawwe, is ien sekonde in flater"). As HTTP-antwurdkoades net genôch binne om alle mislearringsbetingsten út te drukken, kinne sekundêre (ynterne) protokollen ferplicht wurde om in part mislearring te detektearjen. It kontrolearjen fan al sokke mislearre oanfragen kin miskien net ynformatyf wêze, wylst systeemtests fan ein-oan-ein helpe te ûntdekken dat jo ferkearde ynhâld ferwurkje.
Saturation
De metryk lit sjen hoe yntinsyf jo tsjinst wurdt brûkt. Dit is in systeem monitoring maatregel dy't identifisearret de middels dy't meast beheind (Bygelyks, op in ûnthâld-beheind systeem, toant ûnthâld, op in I / O-beheind systeem, toant it oantal I / Os). Tink derom dat in protte systemen prestaasjes degradearje foardat se 100% gebrûk berikke, dus it hawwen fan in gebrûksdoel is wichtich.
Yn komplekse systemen kin sêding wurde oanfolle troch ladingsmjittingen op heger nivo: kin jo tsjinst dûbel ferkear goed behannelje, mar 10% mear ferkear behannelje, of noch minder ferkear behannelje as it no docht? Foar ienfâldige tsjinsten dy't gjin parameters hawwe dy't de kompleksiteit fan it fersyk feroarje (bygelyks "Jou my neat" of "Ik haw in unyk ien monotoanysk hiel getal nedich"), dy't komselden feroarje konfiguraasje, in statyske load test wearde kin adekwaat. Lykwols, lykas besprutsen yn 'e foarige paragraaf, moatte de measte tsjinsten yndirekte sinjalen brûke, lykas CPU-gebrûk of netwurkbânbreedte, dy't in bekende boppegrins hawwe. Ferheegjen fan latency is faaks in liedende yndikator fan sêding. It mjitten fan de reaksjetiid fan 'e 99e percentile yn in lyts finster (bygelyks ien minút) kin in heul betiid sinjaal fan sêding leverje.
Uteinlik wurdt sêding ek assosjearre mei foarsizzingen oer driigjende sêding, bygelyks: "It liket derop dat jo database jo hurde skiif yn 4 oeren sil folje."
As jo alle fjouwer gouden sinjalen mjitte en as d'r in probleem is mei ien fan 'e metriken (of, yn' t gefal fan sêding, in tichtby probleem), warskôgje jo in persoan, jo tsjinst sil min of mear dekt wurde troch tafersjoch.
Soargen oer de "sturt" (of ynstrumintaasje en prestaasjes)
By it meitsjen fan in tafersjochsysteem fanôf it begjin, is d'r in ferlieding om in systeem te ûntwikkeljen basearre op gemiddelde wearden: gemiddelde latency, gemiddelde CPU-gebrûk fan knopen, of gemiddelde databasefolheid. It gefaar fan de lêste twa foarbylden is fanselssprekkend: ferwurkers en databases wurde op in tige ûnfoarspelbere manier ôfset. Itselde jildt foar fertraging. As jo in webtsjinst útfiere mei in gemiddelde latency fan 100ms mei 1000 oanfragen per sekonde, kin 1% fan oanfragen 5 sekonden duorje. As brûkers ôfhinklik binne fan meardere soksoarte webtsjinsten, kin it 99e percentile fan ien backend maklik de mediane reaksjetiid fan 'e frontend wurde.
De ienfâldichste manier om ûnderskied te meitsjen tusken it stadige gemiddelde en de heul stadige sturt fan oanfragen is om mjittingen te sammeljen fan fersiken útdrukt yn statistiken (in goed ark om te werjaan is histogrammen) ynstee fan werklike latencies: hoefolle fersiken de tsjinst tsjinne dy't tusken 0 ms duorre en 10 ms, tusken 10 ms en 30 ms, tusken 30 ms en 100 ms, tusken 100 ms en 300 ms, ensfh. fan fersiken.
Selektearje it passende nivo fan detail foar mjittingen
Ferskillende eleminten fan it systeem moatte wurde mjitten op ferskate nivo's fan detail. Bygelyks:
- It kontrolearjen fan CPU-gebrûk oer in perioade fan tiid sil gjin lange-termyn piken sjen litte dy't liede ta hege latencies.
- Oan 'e oare kant, foar in webtsjinst dy't net mear as 9 oeren downtime yn't jier rjochtet (99,9% jierlikse uptime), is it kontrolearjen fan in HTTP 200-antwurd mear dan ien of twa kear yn 'e minút wierskynlik ûnnedich faak.
- Likemin is it kontrolearjen fan romte op hurde skiif foar 99,9% beskikberens mear dan ien kear elke 1-2 minuten wierskynlik net nedich.
Soargje foar hoe't jo de granulariteit fan jo mjittingen strukturearje. It sammeljen fan CPU-lading ien kear per sekonde kin ynteressante gegevens leverje, mar sokke faak mjittingen kinne heul djoer wêze om te sammeljen, op te slaan en te analysearjen. As jo monitoaringdoel in hege granulariteit fereasket en gjin hege responsiviteit fereasket, kinne jo dizze kosten ferminderje troch metrikensamling op 'e server op te stellen en dan in ekstern systeem op te stellen om dizze metriken te sammeljen en te aggregearjen. Kinsto:
- Meitsje CPU-lading elke sekonde.
- Ferminderje detail nei 5%.
- Aggregate metriken elke minút.
Dizze strategy lit jo gegevens sammelje mei in hege granulariteit sûnder hege analyse- en opslachoverhead te meitsjen.
Sa ienfâldich mooglik, mar net ienfâldiger
De oerlêst fan ferskate easken boppe-op elkoar kin resultearje yn in heul kompleks tafersjochsysteem. Jo systeem kin bygelyks de folgjende komplisearjende eleminten hawwe:
- Warskôgings neffens ferskate drompels foar fersykferwurkingslatens, yn ferskillende percentiles, foar alle soarten ferskillende yndikatoaren.
- Skriuwen fan ekstra koade om mooglike oarsaken te ûntdekken en te identifisearjen.
- Meitsje relatearre dashboards foar elk fan 'e mooglike oarsaken fan problemen.
De boarnen fan potinsjele komplikaasjes binne nea einigje. Lykas alle softwaresystemen kin tafersjoch sa kompleks wurde dat it kwetsber wurdt en dreech te feroarjen en te ûnderhâlden.
Untwerp dêrom jo tafersjochsysteem om it safolle mooglik te ferienfâldigjen. By it kiezen fan wat te folgjen, hâld it folgjende yn gedachten:
- De regels dy't meastentiids echte ynsidinten fange, moatte sa ienfâldich, foarsisber en betrouber mooglik wêze.
- Konfiguraasje foar gegevenssammeling, aggregaasje en warskôging dy't selden útfierd wurdt (bygelyks minder dan fearnsjier foar guon SRE-teams) moat fuortsmiten wurde.
- Metriken dy't wurde sammele, mar net werjûn yn in foarbylddashboard of brûkt troch in warskôging binne kandidaten foar wiskjen.
By Google wurket it sammeljen en aggregearjen fan basismetriken, kombinearre mei warskôgings en dashboards, goed as in relatyf standalone systeem (it tafersjochsysteem fan Google is eins opdield yn ferskate subsystemen, mar minsken binne gewoanlik bewust fan alle aspekten fan dizze subsystemen). It kin ferliedlik wêze om tafersjoch te kombinearjen mei oare techniken foar it ûndersiikjen fan komplekse systemen: detaillearre systeemprofilearring, proses-debuggen, folgjen fan details oer útsûnderings of mislearrings, loadtesten, logkolleksje en analyse, of ferkearsynspeksje. Wylst de measte fan dizze dingen mienskiplik hawwe mei basismonitoring, it mingjen sil resultearje yn te folle resultaten en meitsje in kompleks en kwetsber systeem. Lykas by in protte oare aspekten fan softwareûntwikkeling, is it stypjen fan ferskate systemen mei dúdlike, ienfâldige, los keppele yntegraasjepunten de bêste strategy (bygelyks it brûken fan in web API om aggregearre gegevens op te heljen yn in formaat dat oer in lange perioade konsekwint kin bliuwe ).
De prinsipes byinoar ferbine
De begjinsels besprutsen yn dit haadstik kinne wurde kombinearre yn in tafersjoch- en warskôgingsfilosofy dy't wurdt ûnderskreaun en folge troch Google SRE-teams. It folgjen fan dizze monitoaringfilosofy is winsklik, is in goed útgongspunt foar it meitsjen of bewurkjen fan jo warskôgingsmetoadyk, en kin jo helpe om de juste fragen te stellen fan jo operaasjefunksje, nettsjinsteande de grutte fan jo organisaasje of de kompleksiteit fan 'e tsjinst of systeem.
By it meitsjen fan regels foar tafersjoch en warskôging, kinne jo de folgjende fragen stelle kinne jo helpe om falske positiven en ûnnedige warskôgings te foarkommen:
- Detektearret dizze regel in oars net te detektearjen steat fan it systeem dat is driuwend, ropt ta aksje, en ûnûntkomber beynfloedet de brûker?
- Kin ik dizze warskôging negearje wittend dat it goedaardig is? Wannear en wêrom kin ik dizze warskôging negearje en hoe kin ik dit senario foarkomme?
- Betsjut dizze warskôging dat brûkers negatyf beynfloede wurde? Binne d'r situaasjes wêr't brûkers net negatyf beynfloede wurde, lykas troch ferkearsfiltering of by it brûken fan testsystemen wêrfoar warskôgings moatte wurde filtere?
- Kin ik aksje nimme yn reaksje op dizze warskôging? Binne dizze maatregels urgent of kinne se wachtsje oant de moarn? Kin in aksje feilich automatisearre wurde? Sil dizze aksje in oplossing op lange termyn wêze as in oplossing op koarte termyn?
- Guon minsken krije meardere warskôgings foar dit probleem, dus is d'r in manier om it oantal warskôgings te ferminderjen?
Dizze fragen wjerspegelje de fûnemintele filosofy oer warskôgings- en warskôgingssystemen:
- Elke kear as der in warskôging binnenkomt, moat ik daliks reagearje. Ik kin ferskate kearen deis driuwend reagearje foardat ik wurch wurd.
- Elke warskôging moat relevant wêze.
- Elke reaksje op in warskôging moat minsklike yntervinsje fereaskje. As de notifikaasje automatysk kin wurde ferwurke, moat it net komme.
- Alerts moatte gean oer in nij probleem of barren dat net earder bestie.
Dizze oanpak fervaagt bepaalde ûnderskiedingen: as de warskôging foldocht oan de foarige fjouwer betingsten, makket it net út oft de warskôging ferstjoerd wurdt fan in White-box of Black-Box-monitorsysteem. Dizze oanpak fersterket ek bepaalde ferskillen: it is better om folle mear muoite te besteegjen oan it identifisearjen fan symptomen as oan oarsaken; as it giet om oarsaken, jo moatte allinnich soargen oer de ûnûntkombere oarsaken.
Lange termyn tafersjoch
Yn hjoeddeistige produktiviteitsomjouwings kontrolearje tafersjochsystemen in hieltyd evoluearjend produksjesysteem mei feroarjende software-arsjitektuer, workload-kenmerken en prestaasjesdoelen. Alerts dy't op it stuit lestich te automatisearjen binne, kinne gewoanlik wurde, miskien sels it wurdich oan te pakken. Op dit punt, immen moat fine en elimineren de woartel oarsaken fan it probleem; as sa'n resolúsje net mooglik is, fereasket it antwurd op 'e warskôging folsleine automatisearring.
It is wichtich dat tafersjoch besluten wurde makke mei lange-termyn doelen yn gedachten. Elke warskôging dy't hjoed rint, liedt in persoan ôf fan it ferbetterjen fan it systeem moarn, sadat d'r faaks in reduksje is yn 'e beskikberens of prestaasjes fan in produktyf systeem foar de tiid dy't nedich is om it tafersjochsysteem op' e lange termyn te ferbetterjen. Litte wy nei twa foarbylden sjen om dit ferskynsel te yllustrearjen.
Bigtable SRE: A Tale of Over-Alert
De ynterne ynfrastruktuer fan Google wurdt typysk foarsjoen en mjitten tsjin in tsjinstnivo (SLO). In protte jierren lyn wie Bigtable's tsjinst SLO basearre op 'e gemiddelde prestaasjes fan in syntetyske transaksje dy't in live kliïnt simulearje. Troch problemen yn Bigtable en legere nivo's fan 'e opslachstapel, waarden gemiddelde prestaasjes oandreaun troch in "grutte" sturt: de minste 5% fan fragen wiene faak signifikant stadiger as de rest.
E-postnotifikaasjes waarden ferstjoerd doe't de SLO-drompel waard benadere, en messenger-alarms waarden stjoerd as de SLO oerschreden waard. Beide soarten warskôgings waarden frij faak ferstjoerd, en konsumeare ûnakseptabele hoemannichten technyske tiid: it team bestege in wichtige hoemannichte tiid troch de warskôgings te sortearjen om de pear te finen dy't eins relevant wiene. Wy misten faaks in probleem dat brûkers eins beynfloede, om't mar guon fan 'e warskôgings foar dat spesifike probleem wiene. In protte fan 'e warskôgings wiene net urgent fanwege begryplike problemen yn' e ynfrastruktuer en waarden ferwurke op in standert wize, of waarden net ferwurke.
Om de situaasje te ferhelpen naam it team in trijesidige oanpak: wylst wy hurd wurke om de prestaasjes fan Bigtable te ferbetterjen, sette wy ús SLO-doel tydlik yn om it 75e percentiel te wêzen foar query-antwurd-latinsje. Wy hawwe ek e-postwarskôgings útskeakele, om't d'r safolle fan har wiene dat it ûnmooglik wie om tiid te besteegjen oan 'e diagnoaze.
Dizze strategy stelde ús de sykheljen romte om te begjinnen mei it reparearjen fan problemen op lange termyn yn Bigtable en de legere lagen fan 'e opslachstapel, ynstee fan konstant taktyske problemen te reparearjen. Yngenieurs koene eins wurk dien krije sûnder de hiele tiid bombardearre te wurden mei warskôgings. Uteinlik koe it tydlik útstelle fan warskôgingsferwurking ús de kwaliteit fan ús tsjinst ferbetterje.
Gmail: Foarsisber, algoritmyske minsklike antwurden
By de oprjochting waard Gmail boud op in wizige Workqueue-prosesbehearsysteem dat is ûntworpen om brokken fan in sykyndeks te ferwurkjen. Workqueue waard oanpast oan lange libbene prosessen en waard dêrnei tapast op Gmail, mar guon bugs yn 'e opake plannerkoade die bliken heul lestich te reparearjen.
Destiids waard Gmail-monitoring sa strukturearre dat warskôgings wurde trigger as yndividuele taken waarden annulearre mei Workqueue. Dizze oanpak wie net ideaal, om't sels yn dy tiid Gmail in protte tûzenen taken útfierde, dy't elk levere oan in fraksje fan in persint fan ús brûkers. Wy wiene tige soargen oer it jaan fan Gmail-brûkers in goede brûkersûnderfining, mar it behanneljen fan safolle warskôgings wie bûten berik.
Om dit probleem oan te pakken hat Gmail SRE in ark makke om de planner sa goed mooglik te debuggen om de ynfloed op brûkers te minimalisearjen. It team hie wat diskusjes oer it gewoan automatisearjen fan de hiele syklus fan probleem ûntdekking fia sanearjen oant in lange-termyn oplossing waard fûn, mar guon wiene benaud dat sa'n oplossing soe fertrage it feitlik reparaasje fan it probleem.
Dizze spanning wie gewoan yn it team en wjerspegele faaks in gebrek oan fertrouwen yn selsdissipline: wylst guon teamleden tiid wolle tastean foar de juste fix, oaren meitsje har soargen dat de definitive fix fergetten wurdt en de tydlike fix foar altyd sil duorje. Dit probleem fertsjinnet omtinken, om't it te maklik is om problemen tydlik te reparearjen ynstee fan de situaasje permanint te meitsjen. Managers en technysk personiel spylje in wichtige rol by it ymplementearjen fan lange-termyn fixes, stypjen en prioritearje potinsjeel lange-termyn fixes sels nei de earste "pine" ferdwine.
Regelmjittige, repetitive warskôgings en algoritmyske antwurden moatte in reade flagge wêze. De ûnwilligens fan jo team om dizze warskôgings te automatisearjen betsjut dat it team gjin fertrouwen hat dat se de algoritmen kinne fertrouwe. Dit is in serieus probleem dat oanpakt wurde moat.
Lange termyn
In mienskiplik tema ferbynt de Bigtable- en Gmail-foarbylden: de konkurrinsje tusken koarte- en lange-termyn beskikberens. Faak kin in sterke ynspanning in kwetsber systeem helpe om hege beskikberens te berikken, mar dit paad is meastentiids koart, beladen mei team-burnout en ôfhinklikens fan in lyts oantal leden fan datselde heroyske team.
Kontrolearre, koarte termyn fermindering fan beskikberens is faak pynlik, mar strategysk wichtich foar de lange termyn stabiliteit fan it systeem. It is wichtich om net elke warskôging yn isolemint te besjen, mar te beskôgjen oft it algemiene nivo fan warskôgingsvolume liedt ta in sûn, goed tagonklik systeem mei in libbensfetbere ploech en in geunstige prognose. Wy analysearje alert frekwinsje statistiken (meastentiids útdrukt as ynsidinten per ferskowing, dêr't in ynsidint kin bestean út meardere besibbe ynsidinten) yn fearnsjier rapporten oan behear, sadat beslút makkers te hawwen in trochgeande werjefte fan warskôging systeem lading en totale team sûnens.
konklúzje
It paad nei sûn tafersjoch en warskôging is ienfâldich en dúdlik. It rjochtet him op 'e symptomen fan it probleem dat warskôgings trigger, en it kontrolearjen fan' e oarsaak tsjinnet as help foar it debuggen fan problemen. It kontrolearjen fan symptomen is makliker hoe heger jo binne yn 'e stapel dy't jo kontrolearje, hoewol it kontrolearjen fan lading en prestaasjes fan' e databank direkt op 'e databank sels moat dien wurde. E-postnotifikaasjes hawwe heul beheind nut en tendearje maklik lûd te wurden; ynstee moatte jo in dashboard brûke dat alle aktuele problemen kontrolearret dy't e-mailwarskôgings útlizze. It dashboard kin ek wurde keppele mei in barrenslog om histoaryske korrelaasjes te analysearjen.
Op 'e lange termyn is it nedich om in suksesfolle rotaasje fan warskôgings te berikken oer symptomen en driigjende echte problemen, oanpassen fan doelen om te soargjen dat tafersjoch stipet rappe diagnoaze.
Tankewol foar it lêzen fan de oersetting oant it ein. Abonnearje op myn telegramkanaal oer tafersjoch и .
Boarne: www.habr.com