SRE (Site Reliability Engineering) je pristop k zagotavljanju dostopnosti spletnih projektov. Velja za okvir za DevOps in pove, kako uspeti pri uporabi praks DevOps. Ta članek je prevod knjige od Googla. Ta prevod sem pripravil sam in se oprl na lastne izkušnje pri razumevanju procesov spremljanja. V telegram kanalu и Objavil sem tudi povezavo do prevoda 4. poglavja iste knjige o ciljih ravni storitev.
Prevod kat. Uživajte v branju!
Skupine Google SRE imajo osnovna načela in najboljše prakse za izgradnjo uspešnih sistemov za spremljanje in obveščanje. V tem poglavju so podana priporočila o tem, na kakšne težave lahko naleti obiskovalec spletne strani in kako rešiti težave, ki otežujejo prikazovanje spletnih strani.
Opredelitve
Za razpravo o temah, povezanih s spremljanjem, ni enotnega besedišča. Tudi na Googlu spodnji izrazi niso v splošni rabi, vendar bomo navedli najpogostejše interpretacije.
Spremljanje
Zbiranje, obdelava, združevanje in prikaz kvantitativnih podatkov o sistemu v realnem času: število zahtevkov in vrste zahtevkov, število napak in tipi napak, čas obdelave zahtevkov in čas delovanja strežnika.
Nadzor bele skrinjice
Spremljanje, ki temelji na metrikah, ki jih prikazuje notranji sistem, vključno z meritvami profiliranja dnevnikov, JVM ali obdelovalnika HTTP, ki ustvarjajo notranjo statistiko.
Spremljanje črne skrinjice
Testiranje obnašanja aplikacije z vidika uporabnika.
Nadzorna plošča (nadzorne plošče)
Vmesnik (običajno spletni vmesnik), ki nudi pregled ključnih indikatorjev zdravja storitev. Nadzorna plošča ima lahko filtre, možnost izbire meritev za prikaz itd. Vmesnik je zasnovan tako, da identificira najpomembnejše meritve za uporabnike. Nadzorna plošča lahko prikaže tudi informacije za osebje tehnične podpore: čakalno vrsto zahtev, seznam napak z visoko prioriteto, dodeljenega inženirja za določeno področje odgovornosti.
Opozorilo (obvestilo)
Obvestila, ki naj bi jih oseba prejela po elektronski pošti ali kako drugače, ki se lahko sprožijo zaradi napak ali povečanja čakalne vrste zahtevkov. Obvestila so kategorizirana kot: vstopnice, e-poštna opozorila in sporočila messengerja.
Temeljni vzrok (glavni vzrok)
Napaka programske opreme ali človeška napaka, ki se po odpravi ne bi smela ponoviti. Težava ima lahko več glavnih razlogov: nezadostna avtomatizacija procesa, napaka programske opreme, nezadostna študija logike aplikacije. Vsak od teh dejavnikov je lahko temeljni vzrok in vsakega od njih je treba odpraviti.
Vozlišče in stroj (vozlišče in stroj)
Zamenljivi izrazi za sklicevanje na posamezen primerek delujoče aplikacije na fizičnem strežniku, virtualnem stroju ali vsebniku. Na enem stroju je lahko več storitev. Storitve so lahko:
- medsebojno povezani: na primer predpomnilnik in spletni strežnik;
- nepovezane storitve na isti strojni opremi: na primer repozitorij kode in čarovnik za konfiguracijski sistem, kot je npr. ali .
Push
Vsaka sprememba konfiguracije programske opreme.
Zakaj je potrebno spremljanje
Obstaja več razlogov, zakaj je treba aplikacije spremljati:
Analiza dolgoročnih trendov
Kako velika je zbirka podatkov in kako hitro raste? Kako se spreminja dnevno število uporabnikov?
Primerjava zmogljivosti
Ali so poizvedbe hitrejše pri Acme Bucket of Bytes 2.72 kot pri Ajax DB 3.14? Koliko bolje so zahteve predpomnjene po pojavu dodatnega vozlišča? Je spletno mesto postalo počasnejše kot prejšnji teden?
Opozorilo (obvestila)
Nekaj je pokvarjeno in nekdo mora to popraviti. Ali pa se bo kaj kmalu pokvarilo in mora nekdo kmalu preveriti.
Ustvarjanje nadzornih plošč
Nadzorne plošče morajo odgovarjati na osnovna vprašanja in vključevati nekaj iz - zamude (zakasnitev), promet (promet), napake (napake) in vrednost obremenitve (nasičenost).
Izvajanje retrospektivne analize (odpravljanje napak)
Zakasnitev obdelave zahteve se je povečala. Kaj se je še zgodilo ob istem času?
Sistemi za spremljanje so uporabni kot vir podatkov za sisteme poslovne inteligence in za lažjo analizo varnostnih incidentov. Ker se ta knjiga osredotoča na inženirska področja, na katerih imajo SRE strokovno znanje, tukaj ne bomo razpravljali o tehnikah spremljanja.
Spremljanje in opozorila omogočajo sistemu, da pove, kdaj se je pokvaril ali se bo kmalu pokvaril. Kadar se sistem ne more samodejno popraviti, želimo, da človek analizira opozorilo, ugotovi, ali je težava še vedno prisotna, jo odpravi in ugotovi vzrok zanjo. Če ne nadzirate komponent sistema, ne boste nikoli prejeli opozorila samo zato, ker se "nekaj zdi malo čudno."
Nalaganje človeških opozoril je precej draga poraba časa zaposlenega. Če zaposleni dela, opozorilo prekine potek dela. Če je zaposleni doma, opozorilo prekine osebni čas in morda spanje. Ko se opozorila pojavljajo prepogosto, zaposleni preletijo, odložijo ali ignorirajo dohodna opozorila. Občasno prezrejo pravo opozorilo, ki ga prikrijejo hrupni dogodki. Prekinitve storitev lahko trajajo dlje časa, saj hrup preprečuje hitro diagnozo in rešitev težave. Učinkoviti sistemi za obveščanje potnikov imajo dobro razmerje med signalom in šumom.
Ugotavljanje razumnih pričakovanj od sistema spremljanja
Nastavitev nadzora za kompleksno aplikacijo je sama po sebi kompleksna inženirska naloga. Tudi s pomembno infrastrukturo orodij za zbiranje, prikazovanje in opozarjanje skupina Google SRE, ki šteje 10–12 članov, običajno vključuje eno ali dve osebi, katerih glavni namen je izgradnja in vzdrževanje sistemov za spremljanje. To število se je sčasoma zmanjšalo, ko posplošujemo in centraliziramo infrastrukturo za spremljanje, vendar ima vsaka ekipa SRE običajno vsaj enega člana osebja, ki je samo za spremljanje. Povedati je treba, da čeprav je precej zanimivo gledati nadzorne plošče sistema za spremljanje, se ekipe SRE skrbno izogibajo situacijam, v katerih mora nekdo gledati na zaslon za spremljanje težav.
Na splošno je Google prešel na preproste in hitre sisteme spremljanja z optimalnimi orodji za naknadno analizo. Izogibamo se "čarobnim" sistemom, ki poskušajo predvideti pragove ali samodejno odkriti glavni vzrok. Senzorji, ki zaznajo nenamerno vsebino v zahtevah končnih uporabnikov, so edini protiprimer; dokler so ti senzorji preprosti, lahko hitro zaznajo vzroke resnih nepravilnosti. Drugi formati za uporabo podatkov spremljanja, kot je načrtovanje zmogljivosti ali napoved prometa, so zahtevnejši. Opazovanje v zelo dolgem času (meseci ali leta) pri nizki stopnji vzorčenja (ure ali dnevi) bo razkrilo dolgoročni trend.
Skupina Google SRE je z različnimi stopnjami uspeha delala s kompleksnimi hierarhijami odvisnosti. Redko uporabljamo pravila, kot je "če izvem, da je baza podatkov postala počasna, dobim opozorilo o upočasnitvi baze podatkov, sicer dobim opozorilo o počasnem spletnem mestu." Pravila, ki temeljijo na odvisnosti, se običajno nanašajo na nespremenljive dele našega sistema, kot je sistem za filtriranje uporabniškega prometa do podatkovnega centra. Na primer, "če je konfigurirano filtriranje prometa podatkovnega centra, me ne opozarjaj na zamude pri obdelavi uporabniških zahtev" je eno od pogostih pravil za opozorila podatkovnega centra. Nekaj ekip v Googlu podpira zapletene hierarhije odvisnosti, ker ima naša infrastruktura stalno stopnjo neprekinjenega preoblikovanja.
Nekatere ideje, predstavljene v tem poglavju, še vedno držijo: vedno obstaja način, kako se hitreje premakniti od simptoma k temeljnemu vzroku, zlasti v sistemih, ki se nenehno spreminjajo. Čeprav to poglavje opisuje nekatere cilje sistemov za spremljanje in kako te cilje doseči, je pomembno, da so sistemi za spremljanje preprosti in razumljivi vsem v ekipi.
Prav tako morajo biti pristopi k spremljanju objektov, ki jih alarmiramo, zelo preprosti in zanesljivi, da ohranimo nizko raven hrupa in visoko raven signala. Pravila, ki ustvarjajo opozorila za ljudi, bi morala biti lahko razumljiva in predstavljati jasno težavo.
Simptomi proti vzrokom
Vaš nadzorni sistem bi moral odgovoriti na dve vprašanji: "kaj je pokvarjeno" in "zakaj je pokvarjeno".
»Kaj se je zlomilo« se nanaša na simptom, »zakaj se je zlomilo« pa na vzrok. Spodnja tabela prikazuje primere takih povezav.
Simptom
razlog
Prejemanje napake HTTP 500 ali 404
Strežniki baz podatkov zavračajo povezave
Počasni odzivi strežnika
Visoka izkoriščenost procesorja ali poškodovan ethernetni kabel
Uporabniki na Antarktiki ne dobijo mačjih GIF-ov
Vaš CDN sovraži znanstvenike in mačke, zato so nekateri IP-ji na črni listi
Zasebna vsebina je na voljo povsod
Z izdajo nove izdaje programske opreme je požarni zid pozabil vse ACL-je in spustil vse
"Kaj" in "zakaj" sta eden najpomembnejših gradnikov za ustvarjanje dobrega nadzornega sistema z največjim signalom in minimalnim šumom.
Črna skrinjica proti beli skrinjici
Združujemo obsežno spremljanje bele skrinjice s skromnim spremljanjem črne skrinjice za kritične meritve. Najlažji način za primerjavo črne skrinjice z belo skrinjico je ta, da je črna skrinjica osredotočena na simptome in je bolj reaktivna kot proaktivna spremljava: "sistem trenutno ne deluje pravilno." White-box je odvisen od notranjih zmožnosti preverjanja sistemov: dnevnikov dogodkov ali spletnih strežnikov. Tako vam White-box omogoča zaznavanje prihajajočih težav, okvar, ki so videti kot ponovni prenos zahteve itd.
Upoštevajte, da je v večplastnem sistemu simptom v območju odgovornosti enega inženirja simptom v območju odgovornosti drugega inženirja. Zmanjšala se je na primer zmogljivost baze podatkov. Počasno branje baze podatkov je simptom SRE baze podatkov, ki jih zazna. Vendar pa je za sprednji SRE, ki gleda počasno spletno mesto, razlog za isto počasno branje baze podatkov ta, da je baza podatkov počasna. Zato je spremljanje bele škatle včasih osredotočeno na simptome in včasih na vzroke, odvisno od tega, kako obsežno je.
Pri zbiranju telemetrije za odpravljanje napak je potrebno spremljanje bele škatle. Če se spletni strežniki počasi odzivajo na poizvedbe baze podatkov, morate vedeti, kako hitro spletni strežnik komunicira z bazo podatkov in kako hitro se odziva. V nasprotnem primeru ne boste mogli ugotoviti razlike med počasnim strežnikom baze podatkov in omrežno težavo med spletnim strežnikom in bazo podatkov.
Nadzor črne skrinjice ima ključno prednost pri pošiljanju opozoril: sprožite obvestilo prejemniku, ko je težava že povzročila dejanske simptome. Po drugi strani pa je za problem črne skrinjice, ki še ni nastal, a prihaja, spremljanje neuporabno.
Štirje zlati signali
Štirje zlati nadzorni signali so zakasnitev, promet, napake in nasičenost. Če lahko merite le štiri meritve uporabniškega sistema, se osredotočite na te štiri.
Zamuda
Čas, potreben za obdelavo zahteve. Pomembno je razlikovati med zakasnitvijo uspešnih in neuspešnih zahtevkov. Na primer, napako HTTP 500, ki jo povzroči izgubljena povezava z bazo podatkov ali drugim zaledjem, je mogoče diagnosticirati zelo hitro, vendar lahko napaka HTTP 500 nakazuje neuspešno zahtevo. Iskanje vpliva napake 500 na celotno zakasnitev lahko vodi do napačnih zaključkov. Po drugi strani pa je počasna napaka celo hitra napaka! Zato je pomembno, da sledite zakasnitvi napak, namesto da samo filtrirate napake.
promet
Število zahtev za vaš sistem, izmerjeno v sistemskih meritvah na visoki ravni. Za spletno storitev ta meritev običajno predstavlja število zahtev HTTP na sekundo, deljeno z naravo zahtev (na primer statična ali dinamična vsebina). Za sistem za pretakanje zvoka je lahko ta meritev osredotočena na omrežno I/O hitrost ali število sočasnih sej. Za sistem za shranjevanje ključev in vrednosti so lahko te meritve transakcije ali iskanja na sekundo.
Napake
To je stopnja neuspelih zahtev, bodisi eksplicitno (na primer HTTP 500), implicitno (na primer HTTP 200, vendar v kombinaciji s slabo vsebino) ali na podlagi pravilnika (na primer, "Če zajamete odgovor v eni sekundi, kateri koli ena sekunda je napaka"). Če ni dovolj odzivnih kod HTTP za izražanje vseh pogojev napake, bodo morda potrebni sekundarni (notranji) protokoli za odkrivanje delne napake. Spremljanje vseh takšnih napačnih zahtev je lahko neinformativno, medtem ko vam lahko sistemski testi od konca do konca pomagajo ugotoviti, da obdelujete napačno vsebino.
Nasičenost
Meritev prikazuje, kako pogosto se uporablja vaša storitev. To je ukrep za spremljanje sistema, ki identificira vire, ki so najbolj omejeni (na primer v sistemu z omejenim pomnilnikom prikazuje pomnilnik, v sistemu z omejenim V/I pa prikazuje število V/I). Upoštevajte, da se številni sistemi poslabšajo, preden dosežejo 100-odstotno uporabo, zato je ciljna uporaba bistvena.
V zapletenih sistemih je nasičenost mogoče dopolniti z merjenjem obremenitve na višji ravni: ali lahko vaša storitev pravilno obravnava dvojni promet, samo 10 % več prometa ali celo manj prometa, kot ga lahko trenutno? Za preproste storitve, ki nimajo parametrov, ki spreminjajo kompleksnost zahteve (npr. »Ne daj mi ničesar« ali »Potrebujem eno edinstveno eno monotono celo število«), ki redko spremenijo konfiguracijo, je lahko ustrezna vrednost preizkusa statične obremenitve. kot je razloženo v prejšnjem odstavku, bi morala večina storitev uporabljati posredne signale, kot sta izkoriščenost procesorja ali pasovna širina omrežja, ki imajo znano zgornjo mejo. Naraščajoča zakasnitev je pogosto glavni pokazatelj nasičenosti. Merjenje 99. percentila odzivnega časa v majhnem oknu (npr. ena minuta) lahko da zelo zgodnji signal nasičenosti.
Končno je nasičenost povezana tudi z napovedmi bližajoče se nasičenosti, kot je: "Videti je, da bo vaša baza podatkov v 4 urah napolnila vaš trdi disk."
Če izmerite vse štiri zlate signale in ko pride do težave z eno od metrik (ali v primeru zasičenosti skoraj do težave), osebo obvestite, bo vaša storitev bolj ali manj pokrita z monitoringom.
Skrbi za rep (ali instrumente in zmogljivost)
Ko sistem za spremljanje gradimo iz nič, je skušnjava razviti sistem, ki temelji na povprečjih: povprečna zakasnitev, povprečna izkoriščenost procesorja vozlišča ali povprečna zasedenost baze podatkov. Nevarnost zadnjih dveh primerov je očitna: procesorji in baze podatkov so odstranjeni na zelo nepredvidljiv način. Enako velja za zamudo. Če uporabljate spletno storitev s povprečno zakasnitvijo 100 ms pri 1000 zahtevah na sekundo, lahko 1 % zahtev traja 5 sekund. Če so uporabniki odvisni od več takih spletnih storitev, lahko 99. percentil posameznega zaledja zlahka postane srednji odzivni čas vmesnika.
Najenostavnejši način za razlikovanje med počasnim povprečjem in zelo počasnim repom zahtevkov je zbiranje meritev zahtevkov, izraženih v statistiki (histogrami so primerno orodje za prikaz), namesto dejanskih zamud: koliko zahtevkov je postregla storitev, ki je med 0 ms in 10 ms, med 10 ms in 30 ms, med 30 ms in 100 ms, med 100 ms in 300 ms itd. Razširitev meja histograma približno eksponentno (za faktor približno 3) je pogosto preprost način za vizualizacijo porazdelitve poizvedb.
Izbira prave zrnatosti za meritve
Različne elemente sistema je treba meriti z različnimi stopnjami podrobnosti. Na primer:
- Opazovanje izkoriščenosti procesorja v določenem časovnem obdobju ne bo pokazalo dolgih skokov, ki bi povzročili visoke zakasnitve.
- Po drugi strani pa bi bilo preverjanje odziva HTTP 9 več kot enkrat ali dvakrat na minuto verjetno nepotrebno pogosto za spletno storitev, ki cilja na največ 99,9 ur nedelovanja na leto (200 % letni čas delovanja).
- Podobno je verjetno nepotrebno preverjanje prostega prostora na trdem disku za 99,9-odstotno razpoložljivost več kot enkrat na 1-2 minuti.
Pazite, kako strukturirate razdrobljenost dimenzij. Stopnja izkoriščenosti procesorja 1 na sekundo lahko zagotovi zanimive podatke, vendar so tako pogoste meritve lahko zelo drage za zbiranje, shranjevanje in analizo. Če vaš cilj spremljanja zahteva visoko razdrobljenost in ne zahteva visoke odzivnosti, lahko te stroške zmanjšate tako, da na strežniku nastavite zbiranje meritev in nato konfigurirate zunanji sistem za zbiranje in združevanje teh meritev. Bi lahko:
- Izmerite porabo procesorja vsako sekundo.
- Zmanjšajte podrobnosti na 5 %.
- Združite meritve vsako minuto.
Ta strategija vam bo omogočila zbiranje zelo razdrobljenih podatkov brez velikih stroškov analize in shranjevanja.
Čim bolj preprosto, vendar ne lažje
Zlaganje različnih zahtev ena na drugo lahko vodi do zelo zapletenega sistema spremljanja. Vaš sistem ima lahko na primer naslednje zapletene elemente:
- Opozorila glede na različne pragove za zakasnitev zahteve, v različnih percentilih, za vse vrste različnih meritev.
- Pisanje dodatne kode za odkrivanje in prepoznavanje možnih vzrokov.
- Ustvarite povezane nadzorne plošče za vsakega od možnih vzrokov težav.
Viri možnih zapletov nikoli ne končajo. Tako kot vsi sistemi programske opreme lahko tudi spremljanje postane tako zapleteno, da postane krhko, težko ga je spreminjati in vzdrževati.
Zato načrtujte svoj nadzorni sistem tako, da bo čim bolj poenostavljen. Ko izbirate, čemu slediti, upoštevajte naslednje:
- Pravila, ki najpogosteje ujamejo resnične incidente, morajo biti čim bolj preprosta, predvidljiva in zanesljiva.
- Konfiguracijo za zbiranje podatkov, združevanje in opozarjanje, ki se izvaja redko (na primer manj kot četrtletno za nekatere ekipe SRE), je treba odstraniti.
- Meritve, ki so zbrane, vendar niso prikazane v nobeni plošči za predogled ali uporabljene v nobenem opozorilu, so kandidati za izbris.
Pri Googlu osnovno zbiranje in združevanje meritev v kombinaciji z opozorili in nadzornimi ploščami dobro deluje kot razmeroma samostojen sistem (Googlov nadzorni sistem je dejansko razdeljen na več podsistemov, vendar se ljudje običajno zavedajo vseh vidikov teh podsistemov). Lahko je skušnjava združiti spremljanje z drugimi metodami testiranja kompleksnih sistemov: podrobnim profiliranjem sistema, odpravljanjem napak v procesu, sledenjem izjemam ali podrobnostim napak, testiranjem obremenitve, zbiranjem in analizo dnevnikov ali pregledom prometa. Čeprav ima večina teh stvari skupne značilnosti z osnovnim spremljanjem, bo njihovo mešanje povzročilo preveč rezultatov in ustvarilo zapleten in krhek sistem. Tako kot pri mnogih drugih vidikih razvoja programske opreme je podpora različnim sistemom z jasnimi, preprostimi, ohlapno povezanimi integracijskimi točkami najboljša strategija (na primer uporaba spletnega API-ja za pridobivanje povzetkov podatkov v obliki, ki lahko ostane nespremenjena v daljšem časovnem obdobju ).
Povezovanje načel skupaj
Načela, obravnavana v tem poglavju, je mogoče združiti v filozofijo spremljanja in opozarjanja, ki jo podpirajo in upoštevajo ekipe Google SRE. Upoštevanje te filozofije spremljanja je zaželeno, je dobro izhodišče za ustvarjanje ali revizijo metodologije opozarjanja in vam lahko pomaga postaviti prava vprašanja operacijam ne glede na velikost vaše organizacije ali kompleksnost storitve ali sistema.
Pri ustvarjanju pravil za spremljanje in opozarjanje se lahko z naslednjimi vprašanji izognete lažnim pozitivnim rezultatom in nepotrebnim opozorilom:
- Ali to pravilo zazna sicer nezaznavno stanje sistema, ki je nujno, kliče k dejanju in neizogibno vpliva na uporabnika?
- Ali lahko prezrem to opozorilo, če vem, da je benigno? Kdaj in zakaj lahko prezrem to opozorilo in kako se lahko izognem temu scenariju?
- Ali to opozorilo pomeni, da to negativno vpliva na uporabnike? Ali obstajajo situacije, kjer uporabniki niso negativno prizadeti, na primer zaradi filtriranja prometa ali pri uporabi testnih sistemov, opozorila o katerih je treba filtrirati?
- Ali lahko ukrepam kot odgovor na to opozorilo? So ti ukrepi nujni ali lahko počakajo do jutra? Ali je varno avtomatizirati dejanje? Ali bo ta ukrep dolgoročna rešitev ali kratkoročna rešitev?
- Nekateri ljudje prejmejo več opozoril za to težavo, ali je torej mogoče zmanjšati število?
Ta vprašanja odražajo temeljno filozofijo o opozorilih in sistemih za opozarjanje:
- Vsakič, ko pride opozorilo, se moram nujno odzvati. Lahko hitim večkrat na dan, preden se utrudim.
- Vsako opozorilo mora biti posodobljeno.
- Vsak odziv na opozorilo mora zahtevati človeško posredovanje. Če je obvestilo mogoče obdelati samodejno, ne bi smelo priti.
- Opozorila naj se nanašajo na novo težavo ali dogodek, ki se še ni zgodil.
Ta pristop zabriše nekatere razlike: če opozorilo izpolnjuje prejšnje štiri pogoje, ni pomembno, ali je opozorilo poslano iz nadzornega sistema bele skrinjice ali črne skrinjice. Ta pristop krepi tudi nekatere razlike: bolje je vložiti veliko več truda v prepoznavanje simptomov kot v vzroke; ko gre za vzroke, vas mora skrbeti le neizogibni vzroki.
Dolgoročno spremljanje
V današnjih produkcijskih okoljih nadzorni sistemi spremljajo nenehno razvijajoč se produkcijski sistem s spreminjajočo se arhitekturo programske opreme, karakteristikami obremenitve in cilji zmogljivosti. Opozorila, ki jih je trenutno težko avtomatizirati, bodo morda postala pogosta in morda celo vredna obravnave. Na tej točki mora nekdo najti in odpraviti temeljne vzroke težave; če taka rešitev ni mogoča, zahteva odziv na opozorilo popolno avtomatizacijo.
Pomembno je, da se odločitve o spremljanju sprejemajo ob upoštevanju dolgoročnih ciljev. Vsako opozorilo, ki se zažene danes, človeka oddalji od jutrišnjega izboljšanja sistema, zato pogosto pride do zmanjšanja razpoložljivosti ali zmogljivosti produktivnega sistema za čas, ki je potreben za dolgoročno izboljšanje sistema spremljanja. Poglejmo si dva primera, ki ponazarjata ta pojav.
Bigtable SRE: zgodba o pretirani pripravljenosti
Googlova notranja infrastruktura je običajno zagotovljena in merjena glede na raven storitev (SLO). Pred leti je SLO storitve Bigtable temeljil na povprečni zmogljivosti sintetične transakcije, ki je simulirala delujočega odjemalca. Zaradi težav v Bigtable in nižjih ravneh sklada za shranjevanje je povprečna zmogljivost vplivala na "velik" rep: najslabših 5 % poizvedb je bilo pogosto znatno počasnejših od ostalih.
Obvestila po e-pošti so bila poslana, ko se je približal prag SLO, opozorila prek messengerja pa so bila poslana, ko je bil SLO presežen. Obe vrsti opozoril sta bili poslani dokaj pogosto, kar je vzelo nesprejemljivo veliko inženirskega časa: ekipa je porabila veliko časa za razčlenjevanje opozoril, da bi našla nekaj dejansko ustreznih. Pogosto smo zamudili težavo, ki je dejansko prizadela uporabnike, ker je bilo le nekaj opozoril za to posebno težavo. Številna opozorila niso bila nujna zaradi razumljivih infrastrukturnih težav in so bila obravnavana na standarden način ali pa sploh niso bila obravnavana.
Da bi popravili situacijo, je ekipa uporabila tristranski pristop: med trdim delom za izboljšanje zmogljivosti Bigtable smo začasno nastavili 75. percentil zakasnitve odgovora na poizvedbo kot naš cilj SLO. Izklopili smo tudi e-poštna opozorila, saj jih je bilo toliko, da ni bilo mogoče izgubljati časa z diagnosticiranjem.
Ta strategija nam je omogočila oddih, da začnemo odpravljati dolgoročne težave v Bigtable in nižjih ravneh sklada za shranjevanje, namesto da nenehno odpravljamo taktične težave. Inženirji bi dejansko lahko opravili delo, če ne bi bili ves čas bombardirani z opozorili. Končno nam je začasna zamuda pri obdelavi opozoril omogočila izboljšanje kakovosti storitev.
Gmail: predvidljivi, algoritmični človeški odzivi
Na samem začetku je bil Gmail zgrajen na spremenjenem sistemu za nadzor procesa Workqueue, ki je bil ustvarjen za paketno obdelavo delov iskalnega indeksa. Delovna čakalna vrsta je bila prilagojena dolgotrajnim procesom in nato uporabljena v Gmailu, vendar se je izkazalo, da je nekatere napake v nepregledni kodi razporejevalnika zelo težko popraviti.
Takrat je bilo spremljanje Gmaila strukturirano tako, da so se opozorila sprožila, ko so bila posamezna opravila preklicana z uporabo Workqueue. Ta pristop ni bil idealen, saj je že takrat Gmail izvajal več tisoč nalog, od katerih je bila vsaka dodeljena delčkom odstotka naših uporabnikov. Zelo smo skrbeli, da bi imeli uporabniki Gmaila dobro uporabniško izkušnjo, vendar obravnavanje toliko opozoril ni prišlo v poštev.
Da bi rešil to težavo, je Gmail SRE ustvaril orodje za čim boljše odpravljanje napak v razporejevalniku za zmanjšanje vpliva na uporabnike. Skupina je imela več razprav o tem, ali naj preprosto avtomatizira celoten cikel od iskanja težave do njene odprave, dokler ne najdemo dolgoročne rešitve, vendar so bili nekateri zaskrbljeni, da bi taka rešitev odložila dejansko odpravo težave.
Takšna napetost je bila pogosta v ekipi in je pogosto odražala nezaupanje v samodisciplino: medtem ko nekateri člani ekipe želijo dati čas za ustrezno rešitev, druge skrbi, da bo končna rešitev pozabljena in bo začasna rešitev trajala večno. Ta težava si zasluži pozornost, saj je prelahko začasno odpraviti težave, namesto da bi jih trajno odpravili. Vodje in tehnično osebje igrajo ključno vlogo pri izvajanju dolgoročnih popravkov, tako da podpirajo in dajejo prednost potencialno dolgoročnim dolgoročnim popravkom, tudi ko začetna bolečina popusti.
Redna ponavljajoča se opozorila in algoritemske reakcije bi morale biti rdeča zastava. Nepripravljenost vaše ekipe za avtomatizacijo teh opozoril pomeni, da ekipa nima zaupanja, da lahko zaupa algoritmom. To je resen problem, ki ga je treba obravnavati.
Dolgoročno
Skupna tema povezuje primera Bigtable in Gmail: tekmovanje med kratkoročno in dolgoročno razpoložljivostjo. Pogosto lahko močno prizadevanje pomaga krhkemu sistemu doseči visoko razpoložljivost, vendar je ta pot običajno kratkotrajna, polna izgorelosti ekipe in odvisnosti od majhnega števila članov te iste junaške ekipe.
Nadzorovan, kratkoročni upad razpoložljivosti je pogosto boleč, a strateško pomemben za dolgoročno stabilnost sistema. Pomembno je, da ne obravnavate vsakega opozorila ločeno, ampak da razmislite, ali skupna stopnja opozoril vodi do zdravega, ustrezno dostopnega sistema z uspešno ekipo in ugodno prognozo. Analiziramo statistiko stopnje opozoril (običajno izraženo kot incidenti na izmeno, kjer je incident lahko sestavljen iz več povezanih incidentov) v četrtletnih poročilih z vodstvom, kar omogoča nosilcem odločanja, da nenehno predstavljajo obremenitev sistema za opozarjanje in splošno zdravje ekipe.
Zaključek
Pot do zdravega spremljanja in opozoril je preprosta in enostavna. Osredotoča se na simptome težave, za katero se ustvarijo opozorila, spremljanje vzroka pa služi kot pomoč pri odpravljanju napak. Spremljanje simptomov je lažje, čim višje ste v skladu, ki ga nadzirate, čeprav je treba spremljanje obremenitve baze podatkov in zmogljivosti izvajati neposredno v sami bazi podatkov. E-poštna obvestila so zelo omejeno uporabna in zlahka prerastejo v hrup; namesto tega bi morali uporabiti nadzorno ploščo, ki spremlja vse trenutne težave, ki so opozorjene po e-pošti. Nadzorno ploščo je mogoče združiti tudi z dnevnikom dogodkov za analizo zgodovinskih korelacij.
Dolgoročno je treba doseči uspešno izmenjavo med opozorili o simptomih in neizbežnimi resničnimi težavami ter prilagoditi cilje, da se zagotovi, da spremljanje podpira hitro diagnozo.
Hvala, ker ste prebrali prevod do konca. Naročite se na moj telegram kanal o spremljanju и .
Vir: www.habr.com