SRE (Site Reliability Engineering) er aðferð til að tryggja framboð á vefverkefnum. Það er talið ramma fyrir DevOps og talar um hvernig á að ná árangri í að beita DevOps starfsháttum. Þýðing í þessari grein bækur frá Google. Ég útbjó þessa þýðingu sjálfur og treysti á eigin reynslu til að skilja eftirlitsferla. Í símskeyti rásinni и Ég birti líka hlekk á þýðingu 4. kafla sömu bókar um þjónustustigsmarkmið.
Þýðing eftir kött. Njóttu þess að lesa!
SRE teymi Google hafa grunnreglur og bestu starfsvenjur til að búa til árangursríkt eftirlits- og tilkynningakerfi. Þessi kafli veitir leiðbeiningar um hvaða vandamál vefsíðugestur gæti lent í og hvernig á að leysa vandamál sem gera vefsíður erfiðar að birta.
Skilgreiningar
Það er enginn einn orðaforði notaður til að ræða efni sem tengjast vöktun. Jafnvel á Google eru hugtökin hér að neðan ekki almennt notuð, en við munum telja upp algengustu túlkanirnar.
Eftirlit
Söfnun, vinnsla, samansöfnun og birting megindlegra gagna í rauntíma um kerfið: fjöldi beiðna og tegunda beiðna, fjöldi villna og tegunda villna, vinnslutími beiðna og spenntur miðlara.
White-box eftirlit
Vöktun byggt á mælingum sem birtar eru af innri kerfishlutum, þar á meðal annálum, Java Virtual Machine prófílmælingum eða HTTP meðhöndlunarmælingum sem búa til innri tölfræði.
Black-box eftirlit
Að prófa hegðun forrita frá sjónarhóli notandans.
Mælaborð
Viðmót (venjulega vefur) sem veitir yfirsýn yfir helstu heilsufarsvísa þjónustu. Mælaborðið getur verið með síum, möguleika á að velja vísana sem sýndir eru o.s.frv. Viðmótið er hannað til að bera kennsl á þá vísbendingar sem eru mikilvægastir fyrir notendur. Mælaborðið getur einnig birt upplýsingar fyrir tæknilega aðstoð: biðröð af beiðnum, lista yfir forgangsvillur og úthlutaðan verkfræðing fyrir tiltekið ábyrgðarsvið.
Viðvörun (tilkynning)
Tilkynningar sem ætlað er að berast einstaklingi með tölvupósti eða á annan hátt, sem geta komið af stað vegna villna eða aukinnar biðröð. Tilkynningar eru flokkaðar sem: miðar, tölvupósttilkynningar og spjallskilaboð.
Grunnorsök
Hugbúnaðargalli eða mannleg mistök sem, þegar leiðrétt hefur verið, ætti ekki að koma fram aftur. Vandamálið getur átt sér nokkrar helstu orsakir: ófullnægjandi sjálfvirkni ferlisins, galli í hugbúnaði, ófullnægjandi útfærsla á rökfræði forritsins. Hver þessara þátta getur verið undirrótin og hver þeirra verður að útrýma.
Hnútur og vél (hnút og vél)
Skiptanleg hugtök sem vísa til einstaks tilviks af keyrandi forriti á líkamlegum netþjóni, sýndarvél eða íláti. Ein vél getur hýst nokkrar þjónustur. Þjónusta getur verið:
- tengd hvort öðru: til dæmis skyndiminnisþjónn og vefþjónn;
- ótengd þjónusta á einu stykki af vélbúnaði: til dæmis kóðageymsla og töframaður fyrir uppsetningarkerfi, eins og eða .
Ýttu
Allar breytingar á uppsetningu hugbúnaðar.
Hvers vegna þarf eftirlit?
Það eru nokkrar ástæður fyrir því að fylgjast þarf með forritum:
Greining á langtímaþróun
Hversu stór er gagnagrunnurinn og hversu hratt vex hann? Hvernig breytist daglegur fjöldi notenda?
Samanburður á frammistöðu
Eru beiðnir hraðari á Acme Bucket of Bytes 2.72 samanborið við Ajax DB 3.14? Hversu miklu betri eru beiðnir í skyndiminni eftir að viðbótarhnút birtist? Er síðan að keyra hægar miðað við síðustu viku?
Viðvörun (tilkynningar)
Eitthvað er bilað og einhver þarf að laga það. Eða eitthvað brotnar fljótlega og einhver þarf að athuga það fljótlega.
Að búa til mælaborð
Mælaborð ættu að svara grunnspurningum og innihalda eitthvað frá — tafir (leynd), umferð (umferð), villur (villur) og álagsstærð (mettun).
Framkvæma afturskyggna greiningu (kembiforrit)
Töfin á afgreiðslu beiðna hefur aukist, en hvað gerðist meira á sama tíma?
Vöktunarkerfi eru gagnleg sem uppspretta gagna fyrir viðskiptagreindarkerfi og til að auðvelda greiningu á öryggisatvikum. Vegna þess að þessi bók fjallar um verkfræðisvið þar sem SREs hafa sérfræðiþekkingu, munum við ekki ræða vöktunartækni hér.
Vöktun og viðvaranir gera kerfinu kleift að segja þér þegar það hefur bilað eða er að fara að bila. Þegar kerfi getur ekki lagað sjálfkrafa sjálfkrafa, viljum við að manneskjan greini viðvörunina, ákvarðar hvort vandamálið sé enn virkt, leysi það og greini undirrót. Ef þú endurskoðar ekki kerfishluta færðu aldrei viðvörun einfaldlega vegna þess að "eitthvað virðist svolítið skrítið."
Að íþyngja mann með tilkynningum er nokkuð dýr nýting á tíma starfsmanns. Ef starfsmaðurinn er að vinna truflar viðvörunin vinnuferlið. Ef starfsmaðurinn er heima truflar viðvörunin persónulegan tíma og mögulega svefn. Þegar viðvaranir koma of oft, renna starfsmenn í gegnum þær, fresta þeim eða hunsa tilkynningar sem berast. Af og til hunsa þeir hina raunverulegu viðvörun, sem er hulin hávaðaviðburðum. Þjónustutruflanir geta varað í langan tíma þar sem hávaðatilvik koma í veg fyrir að vandamálið sé fljótt greint og leiðrétt. Árangursrík viðvörunarkerfi hafa gott merki/suð.
Að gera eðlilegar væntingar til eftirlitskerfisins
Að setja upp vöktun fyrir flókið forrit er flókið verkfræðilegt verkefni í sjálfu sér. Jafnvel með umtalsverðan innviði söfnunar-, birtingar- og viðvörunarverkfæra, inniheldur Google SRE teymi 10–12 meðlima venjulega einn eða tvo einstaklinga sem hafa það að megintilgangi að byggja og viðhalda vöktunarkerfum. Þessi tala hefur minnkað með tímanum þar sem við treystum og miðstýrum vöktunarinnviðum, en hvert SRE teymi hefur venjulega að minnsta kosti einn einstakling sem er eingöngu tileinkaður eftirliti. Við verðum að segja að þótt mælaborð vöktunarkerfis séu nokkuð áhugaverð að skoða, forðast SRE teymi vandlega aðstæður sem krefjast þess að einhver horfi á skjá til að fylgjast með vandamálum.
Á heildina litið hefur Google fært sig yfir í einföld og hröð eftirlitskerfi með ákjósanlegum greiningarverkfærum eftir á. Við forðumst „töfrakerfi“ sem reyna að spá fyrir um þröskulda eða greina sjálfkrafa undirrót. Skynjarar sem greina óviljandi efni í beiðnum notenda eru eina mótdæmið; Svo lengi sem þessir skynjarar eru einfaldir geta þeir fljótt greint orsakir alvarlegra frávika. Önnur snið til að nota vöktunargögn, eins og afkastagetuáætlun eða umferðarspá, eru flóknari. Athugun yfir mjög langan tíma (mánuði eða ár) á lágu sýnatökutíðni (klukkutímar eða dagar) mun leiða í ljós langtímaþróun.
Google SRE teymið hefur náð misjöfnum árangri með flóknu stigveldi ósjálfstæðis. Við notum sjaldan reglur eins og „ef ég kemst að því að gagnagrunnurinn er hægur fæ ég viðvörun um að gagnagrunnurinn sé hægur, annars fæ ég viðvörun um að vefsvæðið sé hægt. Reglur sem byggja á ósjálfstæði vísa venjulega til óbreytanlegra hluta kerfisins okkar, eins og kerfisins til að sía notendaumferð að gagnaverinu. Til dæmis, "ef umferðarsía til gagnaversins er stillt, ekki láta mig vita um tafir á vinnslu notendabeiðna" er ein almenn regla fyrir viðvaranir frá gagnaverinu. Fá teymi hjá Google styðja flókið stigveldi ósjálfstæðis vegna þess að innviðir okkar eru með stöðuga endurstillingu.
Sumar af þeim hugmyndum sem lýst er í þessum kafla eiga enn við: Það er alltaf tækifæri til að fara hraðar frá einkennum til undirrótar, sérstaklega í stöðugum breytingum á kerfum. Þess vegna er mikilvægt að eftirlitskerfin séu einföld og skiljanleg öllum í teyminu, þótt þessi kafli lýsir nokkrum markmiðum fyrir vöktunarkerfi og hvernig eigi að ná þeim markmiðum.
Sömuleiðis, til að halda hávaðastigi lágu og merkjastigi háu, verða aðferðir við að fylgjast með eignum sem hafa verið viðvörun að vera mjög einfaldar og áreiðanlegar. Reglur sem búa til viðvaranir fyrir fólk ættu að vera auðskiljanlegar og setja fram skýrt vandamál.
Einkenni á móti orsökum
Vöktunarkerfið þitt ætti að svara tveimur spurningum: "hvað bilaði" og "af hverju það bilaði."
„Hvað bilaði“ talar um einkennin og „af hverju það brotnaði“ talar um orsökina. Taflan hér að neðan sýnir dæmi um slík tengsl.
Einkenni
Orsök
Að fá HTTP Villa 500 eða 404
Gagnagrunnsþjónar hafna tengingum
Hæg svör netþjóns
Mikil CPU nýting eða skemmd Ethernet snúru
Notendur á Suðurskautslandinu fá ekki GIF fyrir katta
CDN þinn hatar vísindamenn og ketti, svo sumar IP tölur enduðu á svörtum lista
Einkaefni hefur orðið aðgengilegt alls staðar
Uppsetning nýrrar hugbúnaðarútgáfu varð til þess að eldveggurinn gleymdi öllum ACL og hleypti öllum inn
„Hvað“ og „af hverju“ eru nokkrar af mikilvægustu byggingareiningunum til að búa til gott eftirlitskerfi með hámarksmerki og lágmarks hávaða.
Svartur kassi vs hvítur kassi
Við sameinum víðtæka White-box eftirlit með hóflegu Black-box eftirliti fyrir mikilvægar mælingar. Auðveldasta leiðin til að bera Black-box saman við White-box er að Black-box er einkennismiðuð og er viðbragðsvirk frekar en fyrirbyggjandi eftirlit: „kerfið virkar ekki rétt núna. White-box fer eftir innri sannprófunargetu kerfa: atburðaskrám eða vefþjónum. Þannig gerir White-box þér kleift að greina yfirvofandi vandamál, bilanir sem virðast vera endursending á beiðni o.s.frv.
Athugaðu að í fjöllaga kerfi er einkenni á ábyrgðarsviði eins verkfræðings einkenni á ábyrgðarsviði annars verkfræðings. Til dæmis hefur árangur gagnagrunns minnkað. Hægur lestur gagnagrunns er einkenni gagnagrunnsins SRE sem greinir þá. Hins vegar, fyrir framhlið SRE sem fylgist með hægri vefsíðu, er orsök sama hæga lestrar gagnagrunns hægur gagnagrunnur. Því er eftirlit með hvítum kassa stundum einkennismiðað og stundum orsök, allt eftir því hversu umfangsmikið það er.
Þegar safnað er fjarmælingum til villuleitar er þörf á White-box eftirliti. Ef vefþjónar bregðast seint við gagnagrunnsfyrirspurnum þarftu að vita hversu hratt vefþjónninn hefur samskipti við gagnagrunninn og hversu hratt hann bregst við. Annars muntu ekki geta greint á milli hægs gagnagrunnsþjóns og netvandamála milli vefþjónsins og gagnagrunnsins.
Vöktun á svörtum kassa hefur lykilkosti þegar tilkynningar eru sendar: þú kveikir á tilkynningunni til viðtakandans þegar vandamálið hefur þegar leitt til raunverulegra einkenna. Á hinn bóginn er eftirlit gagnslaust fyrir Black-box vandamál sem hefur ekki enn komið upp en er yfirvofandi.
Fjögur gullmerki
Fjögur gullnu eftirlitsmerkin eru leynd, umferð, villur og mettun. Ef þú getur aðeins mælt fjóra notendakerfismælikvarða skaltu einbeita þér að þeim fjórum.
Töf
Tíminn sem þarf til að afgreiða beiðnina. Mikilvægt er að gera greinarmun á biðtíma vel heppnuðu og misheppnuðu beiðna. Til dæmis er hægt að greina HTTP 500 villa af völdum tengingarleysis við gagnagrunn eða annan bakenda mjög fljótt, en HTTP 500 villa gæti bent til misheppnaðrar beiðni. Að ákvarða áhrif 500 villu á heildar leynd getur leitt til rangra ályktana. Aftur á móti er hæg villa jafnvel hröð villa! Þess vegna er mikilvægt að fylgjast með villuleynd frekar en að sía bara út villur.
umferð
Fjöldi beiðna til kerfisins þíns er mældur í kerfismælingum á háu stigi. Fyrir vefþjónustu táknar þessi mæling venjulega fjölda HTTP beiðna á sekúndu, deilt með eðli beiðnanna (til dæmis kyrrstætt eða kraftmikið efni). Fyrir hljóðstraumskerfi gæti þessi mæling einbeitt sér að I/O hraða netsins eða fjölda samtímis lota. Fyrir lykilgildi geymslukerfi gæti þessi mæling verið færslur eða leitarniðurstöður á sekúndu.
Villur
Þetta er hlutfall misheppnaðra beiðna sem eru skýrar (td HTTP 500), óbeina (td HTTP 200 en ásamt ógildu efni) eða stefnu (td "Ef þú náðir svari á einni sekúndu, hver einasta sekúnda er villa"). Ef HTTP-svörunarkóðar duga ekki til að tjá öll bilunarskilyrði, gæti þurft auka (innri) samskiptareglur til að greina bilun að hluta. Vöktun á öllum slíkum röngum beiðnum gæti ekki verið upplýsandi, en end-to-end kerfispróf munu hjálpa til við að greina að þú sért að vinna úr rangt efni.
Mettun
Mælingin sýnir hversu mikið þjónustan þín er notuð. Þetta er kerfisvöktunarmælikvarði sem auðkennir tilföngin sem eru mest þvinguð (td á minnisbundnu kerfi, sýnir minni, á I/O-takmörkuðu kerfi, sýnir fjölda I/Os). Athugaðu að mörg kerfi skerða frammistöðu áður en þau ná 100% nýtingu, þannig að það er mikilvægt að hafa nýtingarmarkmið.
Í flóknum kerfum er hægt að bæta mettun með álagsmælingum á hærra stigi: getur þjónustan þín séð almennilega um tvöfalda umferð, aðeins 10% meiri umferð eða jafnvel minni umferð en hún gerir núna? Fyrir einfaldar þjónustur sem eru ekki með færibreytur sem breyta margbreytileika beiðninnar (til dæmis „Gefðu mér ekkert“ eða „Ég þarf einstaka eintóna heiltölu“), sem sjaldan breyta stillingum, gæti kyrrstöðuprófunargildi verið fullnægjandi. Hins vegar, eins og fjallað var um í fyrri málsgrein, verða flestar þjónustur að nota óbein merki eins og CPU nýtingu eða netbandbreidd, sem hafa þekkt efri mörk. Aukin leynd er oft leiðandi vísbending um mettun. Að mæla 99. hundraðshluta svartíma í litlum glugga (t.d. einni mínútu) getur gefið mjög snemma merki um mettun.
Að lokum er mettun einnig tengd spám um yfirvofandi mettun, til dæmis: „Það lítur út fyrir að gagnagrunnurinn þinn muni fylla harða diskinn þinn eftir 4 klukkustundir.
Ef þú mælir öll fjögur gullmerkin og þegar vandamál er með einhverja mælikvarða (eða, ef um mettun er að ræða, nánast vandamál), lætur þú mann vita, þjónustan þín verður meira og minna undir eftirliti.
Áhyggjur af "halanum" (eða tækjabúnaði og frammistöðu)
Þegar búið er til eftirlitskerfi frá grunni er freistingin að þróa kerfi sem byggir á meðalgildum: meðaltöf, meðaltal CPU nýtingar hnúta eða meðalfyllingu gagnagrunnsins. Hættan við síðustu tvö dæmin er augljós: örgjörvum og gagnagrunnum er fargað á mjög ófyrirsjáanlegan hátt. Sama gildir um seinkun. Ef þú rekur vefþjónustu með að meðaltali 100 ms biðtíma með 1000 beiðnum á sekúndu gæti 1% beiðna tekið 5 sekúndur. Ef notendur eru háðir mörgum slíkum vefþjónustum getur 99. hundraðshluti eins bakenda auðveldlega orðið miðgildi viðbragðstíma framenda.
Einfaldasta leiðin til að greina á milli hæga meðaltals og mjög hægs hala beiðna er að safna mælingum á beiðnum sem eru birtar í tölfræði (gott tól til að birta eru súlurit) frekar en raunverulegar töf: hversu margar beiðnir þjónustan þjónaði sem tók á milli 0 ms. og 10 ms, á milli 10 ms og 30 ms, á milli 30 ms og 100 ms, á milli 100 ms og 300 ms, o.s.frv. Að stækka landamæri súluritsins um það bil veldisvísis (með áætluðum stuðli 3) er oft einföld leið til að sjá dreifinguna fyrir sér. af beiðnum.
Velja viðeigandi smáatriði fyrir mælingar
Mæla þarf mismunandi þætti kerfisins á mismunandi smáatriðum. Til dæmis:
- Eftirlit með CPU nýtingu yfir ákveðinn tíma mun ekki sýna langtíma toppa sem leiða til mikillar töf.
- Á hinn bóginn, fyrir vefþjónustu sem miðar að ekki meira en 9 klukkustundum af niðritíma á ári (99,9% árlegur spenntur), er líklegt að það sé óþarflega oft að athuga með HTTP 200 svar oftar en einu sinni eða tvisvar á mínútu.
- Sömuleiðis er líklega ekki nauðsynlegt að athuga pláss á harða disknum fyrir 99,9% framboð oftar en einu sinni á 1-2 mínútna fresti.
Gættu þess hvernig þú skipuleggur nákvæmni mælinga þinna. Að safna CPU álagi einu sinni á sekúndu getur veitt áhugaverð gögn, en svo tíðar mælingar geta verið mjög dýrar að safna, geyma og greina. Ef vöktunarmarkmið þitt krefst mikillar nákvæmni og krefst ekki mikillar svörunar geturðu dregið úr þessum kostnaði með því að setja upp mælikvarðasöfnun á þjóninum og setja síðan upp ytra kerfi til að safna og safna þessum mæligildum saman. Gætir þú:
- Mældu CPU álag á hverri sekúndu.
- Minnka smáatriði í 5%.
- Safna saman mæligildi á hverri mínútu.
Þessi stefna gerir þér kleift að safna gögnum með mikilli nákvæmni án þess að þurfa að hafa mikla greiningu og geymslukostnað.
Eins einfalt og mögulegt er, en ekki einfaldara
Það að leggja mismunandi kröfur ofan á aðra getur leitt til mjög flókins eftirlitskerfis. Til dæmis gæti kerfið þitt verið með eftirfarandi flóknandi þætti:
- Viðvaranir samkvæmt mismunandi þröskuldum fyrir biðtíma í vinnslu, í mismunandi hundraðshlutum, fyrir allar tegundir mismunandi vísbendinga.
- Að skrifa viðbótarkóða til að greina og bera kennsl á mögulegar orsakir.
- Búðu til tengd mælaborð fyrir hverja mögulegu orsakir vandamála.
Upptök hugsanlegra fylgikvilla eru aldrei að taka enda. Eins og öll hugbúnaðarkerfi getur eftirlit orðið svo flókið að það verður viðkvæmt og erfitt að breyta og viðhalda því.
Hannaðu því eftirlitskerfið þitt til að einfalda það eins mikið og mögulegt er. Þegar þú velur hvað á að fylgjast með skaltu hafa eftirfarandi í huga:
- Reglurnar sem oftast ná raunverulegum atvikum ættu að vera eins einfaldar, fyrirsjáanlegar og áreiðanlegar og hægt er.
- Fjarlægja ætti stillingar fyrir gagnasöfnun, söfnun og viðvörun sem eru framkvæmdar sjaldan (til dæmis sjaldnar en ársfjórðungslega fyrir sum SRE teymi).
- Mælingar sem eru safnað en ekki sýndar á neinu forskoðunarborði eða notaðar af einhverri viðvörun koma til greina til eyðingar.
Hjá Google virkar grunnmælingasöfnun og samansöfnun, ásamt viðvörunum og mælaborðum, vel sem tiltölulega sjálfstætt kerfi (eftirlitskerfi Google er í raun sundurliðað í nokkur undirkerfi, en fólk er venjulega meðvitað um alla þætti þessara undirkerfa). Það getur verið freistandi að sameina vöktun með öðrum aðferðum til að skoða flókin kerfi: nákvæma kerfislýsingu, ferli villuleit, rekja upplýsingar um undantekningar eða bilanir, álagsprófun, annálasöfnun og greiningu eða umferðarskoðun. Þó að flestir af þessum hlutum eigi sameiginlegt með grunnvöktun, mun blanda þeim leiða til of margra niðurstaðna og búa til flókið og viðkvæmt kerfi. Eins og með marga aðra þætti hugbúnaðarþróunar er stuðningur við mismunandi kerfi með skýrum, einföldum, lauslega tengdum samþættingarpunktum besta aðferðin (til dæmis að nota vef-API til að sækja samansafn gögn á sniði sem getur verið stöðugt í langan tíma ).
Að tengja meginreglurnar saman
Hægt er að sameina meginreglurnar sem fjallað er um í þessum kafla í vöktunar- og viðvörunarhugmynd sem er studd og fylgt eftir af Google SRE teymum. Að fylgja þessari eftirlitsheimspeki er æskilegt, er góður upphafspunktur til að búa til eða endurskoða viðvörunaraðferðafræði þína, og getur hjálpað þér að spyrja réttu spurninganna um starfsemi þína, óháð stærð fyrirtækis þíns eða hversu flókin þjónustan eða kerfið er.
Þegar þú býrð til eftirlits- og viðvörunarreglur getur það hjálpað þér að koma í veg fyrir rangar jákvæðar og óþarfa viðvaranir með því að spyrja eftirfarandi spurninga:
- Greinir þessi regla annars ógreinanlegt ástand kerfisins sem er brýnt, kallar á aðgerð og hefur óhjákvæmilega áhrif á notandann?
- Get ég hunsað þessa viðvörun vitandi að hún er góðkynja? Hvenær og hvers vegna get ég hunsað þessa viðvörun og hvernig get ég forðast þessa atburðarás?
- Þýðir þessi viðvörun að notendur séu fyrir neikvæðum áhrifum? Eru aðstæður þar sem notendur verða ekki fyrir neikvæðum áhrifum, svo sem í gegnum umferðarsíun eða þegar þú notar prófunarkerfi sem ætti að sía viðvaranir fyrir?
- Get ég gripið til aðgerða til að bregðast við þessari viðvörun? Eru þessar ráðstafanir aðkallandi eða geta þær beðið til morguns? Er hægt að gera aðgerð sjálfvirkan á öruggan hátt? Mun þessi aðgerð vera langtímalausn eða skammtímalausn?
- Sumir fá margar viðvaranir vegna þessa vandamáls, svo er einhver leið til að fækka viðvörunum?
Þessar spurningar endurspegla grundvallarhugmyndina um viðvörunar- og viðvörunarkerfi:
- Í hvert skipti sem viðvörun kemur inn þarf ég að bregðast strax við. Ég get brugðist brýnt nokkrum sinnum á dag áður en ég verð þreytt.
- Hver viðvörun verður að vera viðeigandi.
- Sérhver viðbrögð við viðvörun verða að krefjast mannlegrar íhlutunar. Ef hægt er að vinna úr tilkynningunni sjálfkrafa ætti hún ekki að berast.
- Viðvaranir ættu að vera um nýtt vandamál eða atburði sem var ekki til áður.
Þessi nálgun þokar ákveðnum aðgreiningum: ef viðvörunin uppfyllir fyrri fjögur skilyrði skiptir ekki máli hvort viðvörunin er send frá White-box eða Black-Box eftirlitskerfi. Þessi nálgun styrkir einnig ákveðinn mun: það er betra að eyða miklu meiri fyrirhöfn í að greina einkenni en orsakir; þegar kemur að orsökum þarftu aðeins að hafa áhyggjur af óumflýjanlegum orsökum.
Langtíma eftirlit
Í framleiðniumhverfi nútímans fylgjast eftirlitskerfi með framleiðslukerfi í sífelldri þróun með breyttum hugbúnaðararkitektúr, vinnuálagseiginleikum og frammistöðumarkmiðum. Viðvaranir sem nú er erfitt að gera sjálfvirkar geta orðið algengar, jafnvel þess virði að bregðast við. Á þessum tímapunkti verður einhver að finna og útrýma rótum vandans; ef slík úrlausn er ekki möguleg krefst svörun við viðvöruninni fullri sjálfvirkni.
Mikilvægt er að eftirlitsákvarðanir séu teknar með langtímamarkmið í huga. Sérhver viðvörun sem keyrir í dag dregur athygli manns frá því að bæta kerfið á morgun, þannig að það er oft minnkun á framboði eða afköstum framleiðslukerfis í þann tíma sem þarf til að bæta eftirlitskerfið til lengri tíma litið. Við skulum skoða tvö dæmi til að sýna þetta fyrirbæri.
Bigtable SRE: A Tale of Of Alert
Innri innviði Google er venjulega útvegaður og mældur á móti þjónustustigi (SLO). Fyrir mörgum árum var SLO þjónusta Bigtable byggð á meðalframmistöðu gerviviðskipta sem líkir eftir lifandi viðskiptavinum. Vegna vandamála í Bigtable og lægri stigum geymslustafla var meðalafköst knúin áfram af „stórum“ hala: verstu 5% fyrirspurna voru oft verulega hægari en hinar.
Tölvupóststilkynningar voru sendar þegar nálgaðist SLO þröskuldinn og boðberaviðvaranir voru sendar þegar farið var yfir SLO. Báðar tegundir viðvarana voru sendar nokkuð oft og eyddu óviðunandi magni af verkfræðitíma: teymið eyddi verulegum tíma í að flokka viðvaranirnar til að finna þær fáu sem áttu í raun við. Við misstum oft af vandamáli sem hafði í raun áhrif á notendur vegna þess að aðeins sumar viðvarananna voru fyrir það tiltekna mál. Margar viðvarananna voru ekki aðkallandi vegna skiljanlegra vandamála í innviðum og voru unnar á staðlaðan hátt, eða voru alls ekki unnar.
Til að ráða bót á ástandinu fór teymið í þríþætta nálgun: Á meðan unnið var hörðum höndum að því að bæta frammistöðu Bigtable, settum við SLO markmiðið okkar tímabundið að vera 75. hundraðshluti fyrir svörun fyrirspurna. Við slökktum líka á tilkynningum í tölvupósti vegna þess að þær voru svo margar að það var ómögulegt að eyða tíma í að greina þær.
Þessi stefna leyfði okkur öndunarrýmið til að byrja að laga langtímavandamál í Bigtable og neðri lögum geymslustafla, frekar en að laga sífellt taktísk vandamál. Verkfræðingar gætu í raun unnið verk án þess að verða fyrir sprengjum með viðvörunum allan tímann. Að lokum, tímabundið frestun viðvörunarvinnslu gerði okkur kleift að bæta gæði þjónustu okkar.
Gmail: Fyrirsjáanleg, reiknirit mannleg svör
Við upphaf þess var Gmail byggt á breyttu Workqueue ferlistjórnunarkerfi sem var hannað til að vinna úr bitum af leitarvísitölu. Workqueue var aðlöguð að langlífum ferlum og síðan beitt í Gmail, en nokkrar villur í ógegnsæjum tímaáætlunarkóða reyndust mjög erfitt að laga.
Á þeim tíma var Gmail eftirlit byggt upp þannig að viðvaranir myndu koma af stað þegar einstökum verkefnum var hætt með Workqueue. Þessi nálgun var ekki tilvalin, því jafnvel á þeim tíma sinnti Gmail mörg þúsund verk, sem hvert um sig var veitt til brots úr prósenti notenda okkar. Okkur var mjög umhugað um að veita Gmail notendum góða notendaupplifun, en meðhöndlun svo margar tilkynningar var utan seilingar.
Til að bregðast við þessu vandamáli bjó Gmail SRE til tól til að hjálpa til við að kemba tímaáætlunina eins vel og hægt er til að lágmarka áhrifin á notendur. Teymið hafði nokkrar umræður um hvort einfaldlega ætti að gera sjálfvirkan alla hringrásina frá því að vandamál uppgötvast til úrbóta þar til langtímalausn fannst, en sumir höfðu áhyggjur af því að slík lausn myndi seinka því að leysa vandamálið í raun.
Þessi spenna var algeng í liðinu og endurspeglaði oft skort á trausti á sjálfsaga: á meðan sumir liðsmenn vilja gefa sér tíma fyrir rétta lagfæringu, hafa aðrir áhyggjur af því að lokaleiðréttingin gleymist og tímabundin lagfæring taki að eilífu. Þetta mál á skilið athygli vegna þess að það er of auðvelt að laga vandamál tímabundið í stað þess að gera ástandið varanlegt. Stjórnendur og tæknifólk gegnir lykilhlutverki við að innleiða langtíma lagfæringar, styðja við og forgangsraða hugsanlega langtíma lagfæringum, jafnvel eftir að upphaflegi „sársauki“ minnkar.
Reglulegar, endurteknar viðvaranir og reiknirit svör ættu að vera rauður fáni. Tregða liðsins þíns við að gera þessar viðvaranir sjálfvirkar þýðir að liðið skortir traust á að það geti treyst reikniritunum. Þetta er alvarlegt vandamál sem þarf að bregðast við.
Langtíma
Algengt þema tengir saman Bigtable og Gmail dæmin: samkeppnin milli skammtíma og langtíma framboðs. Oft getur öflugt átak hjálpað viðkvæmu kerfi að ná háu framboði, en þessi leið er venjulega skammvinn, full af kulnun í liðinu og háð fáum meðlimum sama hetjuteymisins.
Stýrð, skammtíma minnkun á framboði er oft sársaukafull, en hernaðarlega mikilvæg fyrir langtímastöðugleika kerfisins. Mikilvægt er að líta ekki á hverja viðvörun fyrir sig, heldur að huga að því hvort heildarstig viðvörunarmagns leiði til heilbrigt, rétt aðgengilegt kerfi með lífvænlegu teymi og hagstæðum horfum. Við greinum tölfræði viðvörunartíðni (venjulega gefið upp sem atvik á hverri vakt, þar sem atvik geta samanstandið af mörgum tengdum atvikum) í ársfjórðungslegum skýrslum til stjórnenda, sem gerir ákvarðanatökumönnum kleift að hafa áframhaldandi yfirsýn yfir álag viðvörunarkerfis og heildarheilsu teymisins.
Ályktun
Leiðin að heilbrigðu eftirliti og viðvörun er einföld og skýr. Það beinist að einkennum vandamálsins sem kallar á viðvaranir og eftirlit með orsökinni þjónar sem hjálp við að kemba vandamál. Eftirlit með einkennum er auðveldara því hærra sem þú ert í staflanum sem þú stjórnar, þó að eftirlit með álagi og frammistöðu gagnagrunnsins ætti að vera beint á gagnagrunninum sjálfum. Tilkynningar í tölvupósti hafa mjög takmarkað notagildi og eiga það til að verða auðveldlega hávaði; í staðinn ættir þú að nota mælaborð sem fylgist með öllum núverandi vandamálum sem kalla á tölvupóstviðvaranir. Einnig er hægt að para mælaborðið við atburðaskrá til að greina sögulega fylgni.
Til lengri tíma litið er nauðsynlegt að ná farsælum breytingum á viðvörunum um einkenni og yfirvofandi raunveruleg vandamál, aðlaga markmið til að tryggja að eftirlit styðji við hraða greiningu.
Þakka þér fyrir að lesa þýðinguna til enda. Gerast áskrifandi að símskeyti rásinni minni um eftirlit и .
Heimild: www.habr.com