SRE (Site Reliability Engineering) on lähenemine veebiprojektide kättesaadavuse tagamiseks. Seda peetakse DevOpsi raamistikuks ja see räägib sellest, kuidas saavutada edu DevOpsi praktikate rakendamisel. Tõlge selles artiklis raamatud Google'ilt. Selle tõlke koostasin ise ja tuginesin oma kogemustele seireprotsesside mõistmisel. Telegrammi kanalis и Avaldasin ka lingi sama raamatu teenindustaseme eesmärke käsitleva 4. peatüki tõlkele.
Kassi tõlge. Nautige lugemist!
Google'i SRE tiimidel on edukate jälgimis- ja teavitussüsteemide loomise põhiprintsiibid ja parimad tavad. See peatükk annab juhiseid selle kohta, millised probleemid võivad veebilehe külastajal tekkida ja kuidas lahendada probleeme, mis muudavad veebilehtede kuvamise keeruliseks.
Mõisted
Seirega seotud teemade arutamiseks ei kasutata ühtset sõnavara. Isegi Google'is ei kasutata allolevaid termineid tavaliselt, kuid loetleme kõige levinumad tõlgendused.
Jälgimine
Kvantitatiivsete andmete kogumine, töötlemine, koondamine ja kuvamine reaalajas süsteemi kohta: päringute arv ja päringute tüübid, vigade arv ja veatüübid, päringu töötlemise aeg ja serveri tööaeg.
Valge kasti jälgimine
Jälgimine, mis põhineb sisemiste süsteemikomponentide kuvatavatel mõõdikutel, sealhulgas logidel, Java virtuaalmasina profiilimõõdikutel või sisemist statistikat genereerivatel HTTP-käsitleja mõõdikutel.
Musta kasti jälgimine
Rakenduse käitumise testimine kasutaja vaatenurgast.
Armatuurlaud
Liides (tavaliselt veeb), mis annab ülevaate teenuste peamistest tervisenäitajatest. Armatuurlaual võivad olla filtrid, kuvatavate indikaatorite valimise võimalus jne. Liides on loodud kasutajate jaoks kõige olulisemate näitajate tuvastamiseks. Armatuurlaud võib kuvada ka teavet tehnilise toe personali jaoks: päringute järjekord, kõrge prioriteediga vigade loend ja teatud vastutusvaldkonna jaoks määratud insener.
Hoiatus (teavitus)
Teatised, mis on mõeldud isikule e-posti või muul viisil vastuvõtmiseks, mis võivad vallandada vead või päringujärjekorra suurenemine. Märguanded liigitatakse järgmiselt: piletid, e-posti märguanded ja kiirsõnumid.
Peamine põhjus
Tarkvaraviga või inimlik viga, mis pärast parandamist ei tohiks enam korduda. Probleemil võib olla mitu peamist põhjust: protsesside ebapiisav automatiseerimine, tarkvaraviga, rakendusloogika ebapiisav läbitöötamine. Kõik need tegurid võivad olla algpõhjused ja igaüks neist tuleb kõrvaldada.
Sõlm ja masin (sõlm ja masin)
Vahetatavad terminid, mis viitavad füüsilises serveris, virtuaalmasinas või konteineris töötava rakenduse ühele eksemplarile. Üks masin võib majutada mitut teenust. Teenused võivad olla:
- omavahel ühendatud: näiteks vahemällu salvestav server ja veebiserver;
- mitteseotud teenused ühel riistvaraosal: näiteks koodihoidla ja konfiguratsioonisüsteemi viisard, nt või .
Lükkama
Kõik muudatused tarkvara konfiguratsioonis.
Miks on jälgimine vajalik?
On mitu põhjust, miks rakendusi on vaja jälgida:
Pikaajaliste trendide analüüs
Kui suur on andmebaas ja kui kiiresti see kasvab? Kuidas muutub igapäevane kasutajate arv?
Toimivuse võrdlus
Kas Acme Bucket of Bytes 2.72 puhul on päringud kiiremad kui Ajax DB 3.14? Kui palju paremini on taotlused pärast täiendava sõlme ilmumist vahemällu salvestatud? Kas sait töötab eelmise nädalaga võrreldes aeglasemalt?
Hoiatus (teavitused)
Midagi on katki ja keegi peab selle parandama. Või läheb varsti midagi katki ja keegi peab seda varsti kontrollima.
Armatuurlaudade loomine
Armatuurlauad peaksid vastama põhiküsimustele ja sisaldama midagi — viivitused (latentsus), liiklus (liiklus), vead (vead) ja koormuse suurus (küllastus).
Retrospektiivse analüüsi läbiviimine (silumine)
Taotluse töötlemise viivitus on suurenenud, kuid mis samal ajal veel juhtus?
Seiresüsteemid on kasulikud äriteabe süsteemide andmeallikana ja turvaintsidentide analüüsi hõlbustamiseks. Kuna see raamat keskendub insenerivaldkondadele, milles SRE-d omavad teadmisi, ei käsitle me siin seiretehnikaid.
Seire ja hoiatused võimaldavad süsteemil teile teada anda, kui see on rikkis või hakkab rikki minema. Kui süsteem ei saa ennast automaatselt parandada, tahame, et inimene analüüsiks hoiatust, teeks kindlaks, kas probleem on endiselt aktiivne, lahendaks selle ja määraks algpõhjuse. Kui te süsteemikomponente ei auditeeri, ei saa te kunagi hoiatust lihtsalt sellepärast, et "midagi tundub veidi imelik".
Inimese teadetega koormamine on üsna kulukas töötaja ajakasutus. Kui töötaja töötab, katkestab häire tööprotsessi. Kui töötaja on kodus, katkestab hoiatus isikliku aja ja võib-olla ka magamise. Kui hoiatused ilmuvad liiga sageli, sirvivad töötajad neid läbi, lükkavad need edasi või ignoreerivad sissetulevaid hoiatusi. Aeg-ajalt ignoreerivad nad tõelist hoiatust, mida varjavad mürasündmused. Teenuse katkestused võivad kesta pikka aega, kuna mürasündmused takistavad probleemi kiiret diagnoosimist ja parandamist. Tõhusatel hoiatussüsteemidel on hea signaali-müra suhe.
Järelevalvesüsteemile mõistlike ootuste seadmine
Kompleksse rakenduse monitooringu seadistamine on omaette keerukas inseneriülesanne. Isegi märkimisväärse kogumis-, kuvamis- ja hoiatustööriistade infrastruktuuri korral kuulub 10–12-liikmelisse Google'i SRE meeskonda tavaliselt üks või kaks inimest, kelle peamine eesmärk on seiresüsteemide loomine ja hooldamine. See arv on aja jooksul vähenenud, kuna me koondame ja tsentraliseerime seireinfrastruktuuri, kuid igas SRE meeskonnas on tavaliselt vähemalt üks inimene, kes on pühendunud ainult jälgimisele. Peame ütlema, et kuigi seiresüsteemide armatuurlaudu on üsna huvitav vaadata, väldivad SRE meeskonnad hoolikalt olukordi, mis nõuavad probleemide jälgimiseks ekraani vaatamist.
Üldiselt on Google üle läinud lihtsatele ja kiiretele jälgimissüsteemidele, millel on optimaalsed järelanalüüsi tööriistad. Väldime "maagilisi" süsteeme, mis püüavad ennustada lävesid või tuvastada automaatselt algpõhjuse. Ainus vastunäide on andurid, mis tuvastavad lõppkasutajate päringutes soovimatu sisu; Kuni need andurid on lihtsad, suudavad nad kiiresti tuvastada tõsiste kõrvalekallete põhjused. Muud seireandmete kasutamise vormingud, nagu läbilaskevõime planeerimine või liikluse prognoosimine, on keerulisemad. Vaatlus väga pika aja jooksul (kuud või aastad) madala proovivõtusagedusega (tunnid või päevad) näitab pikaajalist suundumust.
Google'i SRE meeskonnal on olnud segane edu keerukate sõltuvushierarhiatega. Kasutame harva selliseid reegleid nagu "Kui saan teada, et andmebaas on aeglane, saan hoiatuse, et andmebaas on aeglane, vastasel juhul saan hoiatuse, et sait on aeglane." Sõltuvuspõhised reeglid viitavad tavaliselt meie süsteemi muutumatutele osadele, näiteks andmekeskusesse suunduva kasutajaliikluse filtreerimise süsteemile. Näiteks „kui andmekeskusesse suunduva liikluse filtreerimine on konfigureeritud, ära hoiata mind viivituste eest kasutaja päringute töötlemisel” on andmekeskusest tulevate hoiatuste üldreegel. Vähesed Google'i meeskonnad toetavad keerulisi sõltuvushierarhiaid, kuna meie infrastruktuuril on pidev pidev ümberkujundamine.
Mõned selles peatükis kirjeldatud ideed on endiselt aktuaalsed: alati on võimalus liikuda kiiremini sümptomite juurest algpõhjuseni, eriti pidevalt muutuvates süsteemides. Seetõttu, kuigi selles peatükis on välja toodud mõned seiresüsteemide eesmärgid ja nende saavutamise viisid, on oluline, et seiresüsteemid oleksid lihtsad ja arusaadavad kõigile meeskonnaliikmetele.
Samuti peavad hoiatatud varade jälgimise meetodid olema väga lihtsad ja usaldusväärsed, et hoida müratasemeid madalal ja signaalitasemeid kõrgel. Reeglid, mis tekitavad inimestele hoiatusi, peaksid olema kergesti mõistetavad ja kujutama endast selget probleemi.
Sümptomid versus põhjused
Teie seiresüsteem peaks vastama kahele küsimusele: "mis purunes" ja "miks see purunes".
"Mis purunes" räägib sümptomist ja "miks see purunes" räägib põhjusest. Allolevas tabelis on selliste ühenduste näited.
Sümptom
põhjus
HTTP vea 500 või 404 saamine
Andmebaasiserverid keelduvad ühendustest
Aeglased serveri vastused
Protsessori kõrge kasutuskoormus või kahjustatud Etherneti kaabel
Antarktika kasutajad ei saa kassi GIF-e
Teie CDN vihkab teadlasi ja kasse, mistõttu mõned IP-aadressid sattusid musta nimekirja
Privaatne sisu on muutunud kättesaadavaks kõikjal
Uue tarkvaraväljaande kasutuselevõtt pani tulemüüri unustama kõik ACL-id ja laskma kõik sisse
“Mis” ja “miks” on ühed kõige olulisemad ehitusplokid hea maksimaalse signaali ja minimaalse müraga seiresüsteemi loomiseks.
Must kast vs valge kast
Kriitiliste mõõdikute jaoks ühendame ulatusliku valge kasti jälgimise tagasihoidliku Black-boxi jälgimisega. Lihtsaim viis Black-boxi ja White-boxi võrdlemiseks on see, et Black-box keskendub sümptomitele ja on pigem reageeriv kui ennetav jälgimine: "süsteem ei tööta praegu õigesti." Valge kast sõltub süsteemide sisemisest kontrollimisvõimalustest: sündmuste logidest või veebiserveritest. Seega võimaldab White-box tuvastada eelseisvaid probleeme, tõrkeid, mis näivad olevat päringu uuesti saatmine jne.
Pange tähele, et mitmekihilises süsteemis on ühe inseneri vastutusala sümptom sümptom teise inseneri vastutusalas. Näiteks andmebaasi jõudlus on vähenenud. Aeglane andmebaasi lugemine on neid tuvastava andmebaasi SRE sümptom. Aeglast veebisaiti jälgiva esiotsa SRE puhul on sama aeglase andmebaasi lugemise põhjuseks aga aeglane andmebaas. Seetõttu on valge kasti jälgimine mõnikord sümptomitele ja mõnikord põhjustele keskendunud, sõltuvalt sellest, kui ulatuslik see on.
Silumiseks telemeetria kogumisel on vajalik valge kasti jälgimine. Kui veebiserverid reageerivad andmebaasipäringutele aeglaselt, peate teadma, kui kiiresti veebiserver andmebaasiga suhtleb ja kui kiiresti vastab. Vastasel juhul ei saa te aeglasel andmebaasiserveril ja veebiserveri ja andmebaasi vahelisel võrguprobleemil vahet teha.
Musta kasti jälgimisel on hoiatuste saatmisel peamine eelis: käivitate adressaadile teatise, kui probleem on juba põhjustanud tõelisi sümptomeid. Teisest küljest on jälgimine kasutu Black-boxi probleemi puhul, mida pole veel tekkinud, kuid mis on peatne.
Neli kuldset signaali
Neli kuldset jälgimissignaali on latentsusaeg, liiklus, vead ja küllastus. Kui saate mõõta ainult nelja kasutajasüsteemi mõõdikut, keskenduge neile neljale.
Viivitus
Taotluse töötlemiseks kuluv aeg. Oluline on eristada edukate ja ebaõnnestunud taotluste latentsust. Näiteks saab väga kiiresti diagnoosida HTTP 500 viga, mis on põhjustatud ühenduse katkemisest andmebaasi või muu taustaprogrammiga, kuid HTTP 500 tõrge võib viidata ebaõnnestunud päringule. Vea 500 mõju määramine üldisele latentsusajale võib viia ekslike järeldusteni. Teisest küljest on aeglane viga isegi kiire viga! Seetõttu on oluline jälgida vea latentsust, mitte lihtsalt vigu välja filtreerida.
liiklus
Teie süsteemile saadetavate päringute arvu mõõdetakse kõrgetasemeliste süsteemimõõdikutega. Veebiteenuse puhul näitab see mõõtmine tavaliselt HTTP-päringute arvu sekundis, jagatuna päringute olemusega (nt staatiline või dünaamiline sisu). Heli voogedastussüsteemi puhul võib see mõõtmine keskenduda võrgu I/O kiirusele või samaaegsete seansside arvule. Võtmeväärtuste salvestussüsteemi puhul võib see mõõtmine hõlmata tehinguid või otsingutulemusi sekundis.
Vead
See on selgesõnaliste (nt HTTP 500), kaudsete (nt HTTP 200, kuid kombineeritud kehtetu sisuga) või eeskirjadega (nt "Kui jäädvustasite vastuse ühe sekundiga, siis iga sekund on viga") ebaõnnestunud päringute määr. Kui HTTP-vastuskoodidest ei piisa kõigi tõrketingimuste väljendamiseks, võib osalise tõrke tuvastamiseks vaja minna sekundaarseid (sisemisi) protokolle. Kõigi selliste ebaõnnestunud päringute jälgimine ei pruugi olla informatiivne, samas kui täielikud süsteemitestid aitavad tuvastada, et töötlete vale sisu.
Küllastus
Mõõdik näitab, kui intensiivselt teie teenust kasutatakse. See on süsteemi jälgimise meede, mis tuvastab ressursid, mis on enim piiratud (näiteks mälupiiranguga süsteemis näitab mälu, I/O-piiranguga süsteemis näitab I/O-de arvu). Pange tähele, et paljud süsteemid halvendavad jõudlust enne, kui nad jõuavad 100% -ni, seega on kasutuseesmärgi seadmine oluline.
Keerulistes süsteemides saab küllastumist täiendada kõrgema taseme koormuse mõõtmisega: kas teie teenus suudab korralikult toime tulla topeltliiklusega, ainult 10% rohkem liiklust või isegi vähem liiklust kui praegu? Lihtsate teenuste puhul, millel ei ole päringu keerukust muutvaid parameetreid (nt "Ära andke mulle midagi" või "ma vajan ainulaadset monotoonset täisarvu"), mis muudavad konfiguratsiooni harva, võib staatilise koormustesti väärtus olla piisav. Kuid nagu eelmises lõigus kirjeldatud, peavad enamik teenuseid kasutama kaudseid signaale, nagu protsessori kasutus või võrgu ribalaius, millel on teadaolev ülempiir. Pidev latentsusaeg on sageli küllastumise juhtiv näitaja. 99. protsentiili reaktsiooniaja mõõtmine väikeses aknas (nt üks minut) võib anda väga varajase küllastussignaali.
Lõpuks seostatakse küllastumist ka ennustustega eelseisva küllastumise kohta, näiteks: "Tundub, et teie andmebaas täidab teie kõvaketta 4 tunni jooksul."
Kui mõõdate kõiki nelja kuldset signaali ja kui mõne mõõdikuga on probleem (või küllastuse korral peaaegu probleem), hoiatate inimest, teie teenus on enam-vähem seirega kaetud.
Mure "saba" (või instrumentide ja jõudluse pärast)
Jälgimissüsteemi nullist loomisel tekib kiusatus välja töötada süsteem, mis põhineb keskmistel väärtustel: keskmine latentsusaeg, sõlmede keskmine protsessori kasutus või andmebaasi keskmine täitus. Kahe viimase näite oht on ilmne: protsessorid ja andmebaasid hävitatakse väga ettearvamatult. Sama kehtib ka hilinemise kohta. Kui kasutate veebiteenust, mille keskmine latentsusaeg on 100 ms ja 1000 päringut sekundis, võib 1% päringutest kuluda 5 sekundit. Kui kasutajad sõltuvad mitmest sellisest veebiteenusest, võib ühe taustaprogrammi 99. protsentiil kergesti muutuda kasutajaliidese keskmiseks reageerimisajaks.
Lihtsaim viis päringute aeglase keskmise ja väga aeglase saba eristamiseks on koguda statistikas väljendatud päringute mõõtmisi (hea tööriist kuvamiseks on histogrammid), mitte tegelike latentsusaegadega: mitu päringut teenindas teenus, mis võttis aega vahemikus 0 ms. ja 10 ms, 10 ms kuni 30 ms, 30 ms kuni 100 ms, 100 ms kuni 300 ms jne. Histogrammi piiride ligikaudu eksponentsiaalne laiendamine (ligikaudse teguriga 3) on sageli lihtne viis jaotuse visualiseerimiseks taotlustest.
Mõõtmiste jaoks sobiva detailsuse taseme valimine
Süsteemi erinevaid elemente tuleb mõõta erinevatel detailsustasemetel. Näiteks:
- Protsessori kasutamise jälgimine teatud aja jooksul ei näita pikaajalisi hüppeid, mis viivad kõrge latentsusaega.
- Teisest küljest on veebiteenuse puhul, mis ei sihiks rohkem kui 9 tundi seisakuid aastas (99,9% aastane tööaeg), HTTP 200 vastuse kontrollimine rohkem kui üks või kaks korda minutis tõenäoliselt tarbetult sagedane.
- Samuti ei ole tõenäoliselt vaja kontrollida kõvakettaruumi 99,9% saadavust rohkem kui üks kord iga 1–2 minuti järel.
Jälgige, kuidas struktureerite oma mõõtmiste detailsuse. Protsessori koormuse kogumine üks kord sekundis võib anda huvitavaid andmeid, kuid selliste sagedaste mõõtmiste kogumine, salvestamine ja analüüsimine võib olla väga kulukas. Kui teie jälgimiseesmärk nõuab suurt detailsust ega vaja suurt reageerimisvõimet, saate neid kulusid vähendada, seadistades serveris mõõdikute kogumise ja seadistades seejärel nende mõõdikute kogumiseks ja koondamiseks välise süsteemi. Kas sa saaksid:
- Mõõtke protsessori koormust iga sekundi järel.
- Vähendage detaili 5% -ni.
- Koondmõõdikud iga minut.
See strateegia võimaldab teil koguda andmeid suure detailsusega, ilma et teil tekiks suuri analüüsi- ja salvestamiskulusid.
Nii lihtne kui võimalik, kuid mitte lihtsam
Erinevate nõuete kattumine üksteisele võib põhjustada väga keeruka seiresüsteemi. Näiteks võivad teie süsteemis olla järgmised komplitseerivad elemendid:
- Märguanded vastavalt päringu töötlemise latentsuse eri lävedele, erinevates protsentiilides, igat tüüpi erinevate indikaatorite jaoks.
- Võimalike põhjuste tuvastamiseks ja tuvastamiseks lisakoodi kirjutamine.
- Looge seotud armatuurlauad iga võimaliku probleemide põhjuse jaoks.
Võimalike tüsistuste allikad ei lõpe kunagi. Nagu kõik tarkvarasüsteemid, võib monitooring muutuda nii keeruliseks, et muutub hapraks ning seda on raske muuta ja hooldada.
Seetõttu kujundage oma seiresüsteem seda nii palju kui võimalik. Valides, mida jälgida, pidage meeles järgmist.
- Reeglid, mis kõige sagedamini tabavad tõelisi intsidente, peaksid olema võimalikult lihtsad, etteaimatavad ja usaldusväärsed.
- Andmete kogumise, koondamise ja hoiatuste andmise konfiguratsioon, mida tehakse harva (näiteks mõne SRE meeskonna puhul harvem kui kord kvartalis), tuleks eemaldada.
- Mõõdikud, mis on kogutud, kuid mida ei kuvata ühelgi eelvaate armatuurlaual või mida ei kasuta ükski hoiatus, võidakse kustutada.
Google'is toimib põhimõõdikute kogumine ja koondamine koos hoiatuste ja armatuurlaudadega suhteliselt eraldiseisva süsteemina (Google'i jälgimissüsteem on tegelikult jagatud mitmeks alamsüsteemiks, kuid inimesed on tavaliselt nende alamsüsteemide kõigist aspektidest teadlikud). Võib tekkida kiusatus kombineerida jälgimist muude keerukate süsteemide uurimise tehnikatega: üksikasjalik süsteemiprofiil, protsesside silumine, erandite või tõrgete üksikasjade jälgimine, koormustestimine, logide kogumine ja analüüs või liikluskontroll. Kuigi enamikul neist asjadest on ühiseid jooni põhiseirega, annab nende segamine liiga palju tulemusi ning loob keerulise ja hapra süsteemi. Nagu paljude muude tarkvaraarenduse aspektide puhul, on erinevate süsteemide toetamine selgete, lihtsate ja lõdvalt seotud integratsioonipunktidega parim strateegia (näiteks veebi API kasutamine koondatud andmete toomiseks vormingus, mis võib püsida järjepidevana pika aja jooksul ).
Põhimõtete sidumine
Selles peatükis käsitletud põhimõtteid saab ühendada jälgimis- ja hoiatusfilosoofiaks, mida Google'i SRE meeskonnad toetavad ja järgivad. Selle jälgimisfilosoofia järgimine on soovitav, see on hea lähtepunkt hoiatusmetoodika loomiseks või ülevaatamiseks ning aitab teil esitada õigeid küsimusi oma tegevusfunktsiooni kohta, olenemata teie organisatsiooni suurusest või teenuse või süsteemi keerukusest.
Järelevalve- ja hoiatusreeglite loomisel võib järgmiste küsimuste esitamine aidata vältida valepositiivseid tulemusi ja tarbetuid hoiatusi.
- Kas see reegel tuvastab süsteemi muidu tuvastamatu oleku, mis on kiireloomuline, kutsub üles tegevusele ja mõjutab kasutajat paratamatult?
- Kas ma saan seda hoiatust ignoreerida, teades, et see on healoomuline? Millal ja miks saan seda hoiatust ignoreerida ja kuidas seda stsenaariumi vältida?
- Kas see hoiatus tähendab, et kasutajatele avaldatakse negatiivset mõju? Kas on olukordi, kus kasutajatele ei avaldata negatiivset mõju, näiteks liikluse filtreerimine või testsüsteemide kasutamine, mille puhul tuleks hoiatusi filtreerida?
- Kas ma saan sellele hoiatusele vastuseks midagi ette võtta? Kas need meetmed on kiireloomulised või võivad need hommikuni oodata? Kas toimingut saab turvaliselt automatiseerida? Kas see tegevus on pikaajaline lahendus või lühiajaline lahendus?
- Mõned inimesed saavad selle probleemi kohta mitu hoiatust, seega kas on võimalik hoiatuste arvu vähendada?
Need küsimused peegeldavad hoiatus- ja hoiatussüsteemide põhifilosoofiat:
- Iga kord, kui saabub hoiatus, pean kohe reageerima. Võin kiiresti reageerida mitu korda päevas, enne kui väsin.
- Iga hoiatus peab olema asjakohane.
- Iga hoiatusele reageerimine peab nõudma inimese sekkumist. Kui teatist saab automaatselt töödelda, ei tohiks see kohale jõuda.
- Hoiatused peaksid puudutama uut probleemi või sündmust, mida varem polnud.
Selline lähenemine hägustab teatud erinevusi: kui hoiatus vastab neljale eelmisele tingimusele, ei ole vahet, kas hoiatus saadetakse valge kasti või musta kasti seiresüsteemist. Selline lähenemine tugevdab ka teatud erinevusi: parem on kulutada palju rohkem vaeva sümptomite tuvastamisele kui põhjustele; kui rääkida põhjustest, peate muretsema ainult vältimatute põhjuste pärast.
Pikaajaline jälgimine
Tänapäeva tootlikkuskeskkondades jälgivad seiresüsteemid pidevalt arenevat tootmissüsteemi koos muutuva tarkvaraarhitektuuri, töökoormuse omaduste ja jõudluseesmärkidega. Märguanded, mida on praegu raske automatiseerida, võivad muutuda tavaliseks, võib-olla isegi nendega tegelemist väärt. Siinkohal peab keegi leidma ja kõrvaldama probleemi algpõhjused; kui selline lahendus ei ole võimalik, nõuab hoiatusele reageerimine täielikku automatiseerimist.
Oluline on, et järelevalveotsused tehakse pikaajalisi eesmärke silmas pidades. Iga täna ilmuv hoiatus segab inimese tähelepanu süsteemi homsest täiustamisest, mistõttu sageli väheneb tootliku süsteemi saadavus või jõudlus aja jooksul, mis on vajalik seiresüsteemi pikas perspektiivis täiustamiseks. Vaatame selle nähtuse illustreerimiseks kahte näidet.
Bigtable SRE: ülevalve lugu
Google'i sisemine infrastruktuur on tavaliselt ette nähtud ja seda mõõdetakse teenusetaseme (SLO) alusel. Palju aastaid tagasi põhines Bigtable'i teenus SLO reaalajas klienti simuleeriva sünteetilise tehingu keskmisel jõudlusel. Bigtable'i probleemide ja salvestusvirna madalamate tasemete tõttu ajendas keskmist jõudlust "suur" saba: halvimad 5% päringuid olid sageli teistest oluliselt aeglasemad.
SLO läve lähenedes saadeti meiliteateid ja SLO ületamise korral saadeti Messengeri teated. Mõlemat tüüpi hoiatusi saadeti üsna sageli, kulutades lubamatult palju projekteerimisaega: meeskond kulutas märkimisväärselt palju aega hoiatuste sorteerimisele, et leida need vähesed, mis tegelikult olid olulised. Meil jäi sageli märkamata mõni probleem, mis tegelikult kasutajaid mõjutas, sest ainult osa hoiatusi puudutas seda konkreetset probleemi. Paljud hoiatused ei olnud kiireloomulised infrastruktuuri arusaadavate probleemide tõttu ja neid töödeldi tavapärasel viisil või ei töödeldud üldse.
Olukorra parandamiseks kasutas meeskond kolmepoolset lähenemisviisi: tehes kõvasti tööd Bigtable'i jõudluse parandamiseks, seadsime ajutiselt oma SLO-eesmärgiks päringu vastuse latentsuse 75. protsentiili. Samuti lülitasime meiliteated välja, kuna neid oli nii palju, et nende diagnoosimisele ei olnud võimalik aega kulutada.
See strateegia andis meile võimaluse alustada pikaajaliste probleemide lahendamist Bigtable'is ja salvestusruumi madalamatel tasemetel, selle asemel, et pidevalt taktikalisi probleeme parandada. Insenerid saaksid tegelikult töö tehtud ilma, et neid pidevalt hoiatustega pommitaks. Lõppkokkuvõttes võimaldas hoiatuste töötlemise ajutine edasilükkamine meil oma teenuse kvaliteeti parandada.
Gmail: etteaimatavad, algoritmilised inimreaktsioonid
Gmail põhines oma loomisel modifitseeritud Workqueue protsessihaldussüsteemil, mis oli mõeldud otsinguindeksi tükkide paketttöötluseks. Workqueue kohandati pikaealiste protsessidega ja rakendati hiljem Gmailis, kuid läbipaistmatu planeerija koodi mõningaid vigu osutus väga raske parandada.
Sel ajal oli Gmaili jälgimine üles ehitatud nii, et kui üksikud ülesanded tööjärjekorra abil tühistati, käivituksid hoiatused. Selline lähenemine ei olnud ideaalne, sest isegi sel ajal täitis Gmail tuhandeid ülesandeid, millest igaüks anti murdosale protsendile meie kasutajatest. Olime väga mures Gmaili kasutajatele hea kasutuskogemuse pakkumise pärast, kuid nii paljude märguannete käsitlemine oli kättesaamatus.
Selle probleemi lahendamiseks lõi Gmail SRE tööriista, mis aitab planeerijat võimalikult hästi siluda, et minimeerida mõju kasutajatele. Meeskonnal oli mõningaid arutelusid selle üle, kas lihtsalt automatiseerida kogu tsükkel probleemi avastamisest kuni parandamiseni kuni pikaajalise lahenduse leidmiseni, kuid mõned olid mures, et selline lahendus lükkab probleemi tegeliku parandamise edasi.
See pinge oli meeskonnas tavaline ja peegeldas sageli usalduse puudumist enesedistsipliini vastu: kui mõned meeskonnaliikmed tahavad õigeks paranduseks aega anda, siis teised muretsevad, et lõplik parandus ununeb ja ajutine parandamine võtab igaviku. See probleem väärib tähelepanu, sest olukorra püsivaks muutmise asemel on liiga lihtne ajutiselt probleeme lahendada. Juhtidel ja tehnilistel töötajatel on võtmeroll pikaajaliste paranduste rakendamisel, potentsiaalselt pikaajaliste paranduste toetamisel ja prioriseerimisel isegi pärast esialgse "valu" vaibumist.
Regulaarsed korduvad hoiatused ja algoritmilised vastused peaksid olema punase lipuga. Teie meeskonna vastumeelsus neid hoiatusi automatiseerida tähendab, et meeskonnal puudub kindlus, et nad saavad algoritme usaldada. See on tõsine probleem, millega tuleb tegeleda.
Pikaajaline
Ühine teema seob Bigtable'i ja Gmaili näiteid: konkurents lühi- ja pikaajalise kättesaadavuse vahel. Sageli võib tugev pingutus aidata habras süsteemil saavutada kõrget kättesaadavust, kuid see tee on tavaliselt lühiajaline, täis meeskonna läbipõlemist ja sõltuvust sama kangelasliku meeskonna väikesest arvust liikmetest.
Kontrollitud, lühiajaline kättesaadavuse vähenemine on sageli valus, kuid süsteemi pikaajalise stabiilsuse seisukohalt strateegiliselt oluline. Oluline on mitte vaadelda iga hoiatust eraldi, vaid kaaluda, kas hoiatuste helitugevuse üldine tase toob kaasa terve, korralikult juurdepääsetava süsteemi koos elujõulise meeskonnaga ja soodsa prognoosiga. Analüüsime hoiatuste sageduse statistikat (tavaliselt väljendatakse vahejuhtumitena vahetuse kohta, kus intsident võib koosneda mitmest seotud intsidentist) juhtkonnale esitatavates kvartaliaruannetes, mis võimaldab otsustajatel saada pidevat ülevaadet hoiatussüsteemi koormuse ja meeskonna üldise tervise kohta.
Järeldus
Tervisliku jälgimise ja hoiatamise tee on lihtne ja selge. See keskendub probleemi sümptomitele, mis käivitavad hoiatusi, ja põhjuse jälgimine on abiks silumisprobleemide lahendamisel. Sümptomite jälgimine on seda lihtsam, mida kõrgemal asute kontrollitavas virnas, kuigi andmebaasi koormuse ja jõudluse jälgimine peaks toimuma otse andmebaasis endas. Meilimärguannete kasulikkus on väga piiratud ja kipub kergesti muutuma müraks; selle asemel peaksite kasutama armatuurlauda, mis jälgib kõiki praeguseid probleeme, mis käivitavad meiliteateid. Ajalooliste korrelatsioonide analüüsimiseks saab armatuurlaua siduda ka sündmuste logiga.
Pikemas perspektiivis on vaja saavutada sümptomite ja peatsete tõeliste probleemide hoiatuste edukas vaheldumine, kohandades eesmärke tagamaks, et jälgimine toetab kiiret diagnoosimist.
Täname, et lugesite tõlke lõpuni. Tellige minu telegrammi kanal jälgimise kohta и .
Allikas: www.habr.com