SRE (Site Reliability Engineering) pristup je pristupačnosti web projekata. Smatra se okvirom za DevOps i govori kako uspjeti u primjeni DevOps praksi. Ovaj članak prevodi knjige od Googlea. Sam sam pripremio ovaj prijevod i oslonio se na vlastito iskustvo u razumijevanju procesa praćenja. U telegram kanalu и Također sam objavio poveznicu na prijevod poglavlja 4 iste knjige o ciljevima razine usluge.
Prijevod kat. Uživaj čitajući!
Google SRE timovi imaju osnovna načela i najbolje prakse za izgradnju uspješnih sustava praćenja i obavijesti. Ovo poglavlje daje preporuke o problemima s kojima se posjetitelj web stranice može susresti i kako riješiti probleme koji otežavaju prikazivanje web stranica.
definirati
Ne postoji jedinstveni rječnik koji se koristi za raspravu o temama vezanim uz praćenje. Čak ni na Googleu niže navedeni izrazi nisu u uobičajenoj upotrebi, ali ćemo navesti najčešća tumačenja.
nadgledanje
Prikupljanje, obrada, agregacija i prikaz kvantitativnih podataka o sustavu u stvarnom vremenu: broj zahtjeva i tipovi zahtjeva, broj grešaka i tipovi grešaka, vrijeme obrade zahtjeva i vrijeme rada poslužitelja.
Praćenje bijele kutije
Praćenje na temelju metrike koju prikazuju interni sustavi, uključujući zapise, JVM ili metriku profila rukovatelja HTTP-a koja generira internu statistiku.
Monitoring crne kutije
Testiranje ponašanja aplikacije sa stajališta korisnika.
Nadzorna ploča (kontrolne ploče)
Sučelje (obično web sučelje) koje pruža pregled ključnih pokazatelja zdravlja usluga. Nadzorna ploča može imati filtre, mogućnost odabira mjernih podataka za prikaz itd. Sučelje je dizajnirano za prepoznavanje najvažnijih mjernih podataka za korisnike. Nadzorna ploča također može prikazati informacije za osoblje tehničke podrške: red zahtjeva, popis pogrešaka visokog prioriteta, dodijeljenog inženjera za određeno područje odgovornosti.
Upozorenje (obavijest)
Obavijesti koje osoba namjerava primiti putem e-pošte ili na neki drugi način, a koje se mogu aktivirati kao rezultat pogrešaka ili povećanja u redu čekanja zahtjeva. Obavijesti su kategorizirane kao: ulaznice, upozorenja e-poštom i poruke putem glasnika.
Glavni uzrok (glavni uzrok)
Softverski kvar ili ljudska pogreška koja se, kada se ispravi, više ne bi trebala pojaviti. Problem može imati nekoliko glavnih razloga: nedovoljna automatizacija procesa, nedostatak softvera, nedovoljno proučavanje logike aplikacije. Svaki od ovih čimbenika može biti temeljni uzrok i svaki se od njih mora eliminirati.
Čvor i stroj (čvor i stroj)
Zamjenjivi izrazi koji se odnose na jednu instancu pokrenute aplikacije na fizičkom poslužitelju, virtualnom stroju ili spremniku. Na jednom stroju može postojati nekoliko usluga. Usluge mogu biti:
- međusobno povezani: na primjer, cache poslužitelj i web poslužitelj;
- nepovezane usluge na istom hardveru: na primjer, spremište koda i čarobnjak za konfiguracijski sustav, kao što je ili .
Gurati
Svaka promjena konfiguracije softvera.
Zašto je potrebno praćenje
Postoji nekoliko razloga zašto bi se aplikacije trebale pratiti:
Analiza dugoročnih trendova
Kolika je baza podataka i koliko brzo raste? Kako se mijenja dnevni broj korisnika?
Usporedba performansi
Jesu li upiti brži na Acme Bucket of Bytes 2.72 nego na Ajax DB 3.14? Koliko su zahtjevi bolje predmemorirani nakon pojave dodatnog čvora? Je li stranica postala sporija nego prošli tjedan?
Upozorenje (obavijesti)
Nešto je pokvareno i netko to mora popraviti. Ili će se nešto uskoro pokvariti i netko to uskoro mora provjeriti.
Izrada nadzornih ploča
Nadzorne ploče trebale bi odgovarati na osnovna pitanja i uključivati nešto od - kašnjenja (latencija), promet (promet), greške (greške) i vrijednost opterećenja (zasićenje).
Provođenje retrospektivne analize (otklanjanje pogrešaka)
Kašnjenje obrade zahtjeva se povećalo, što se još dogodilo otprilike u isto vrijeme?
Sustavi za praćenje korisni su kao izvor podataka za sustave poslovne inteligencije i za olakšavanje analize sigurnosnih incidenata. Budući da se ova knjiga fokusira na inženjerska područja u kojima SRE imaju stručnost, ovdje nećemo raspravljati o tehnikama praćenja.
Praćenje i upozorenja omogućuju sustavu da kaže kada se pokvario ili će se pokvariti. Kada se sustav ne može automatski popraviti, želimo da čovjek analizira upozorenje, utvrdi je li problem još uvijek prisutan, popravi ga i utvrdi njegov glavni uzrok. Ako ne revidirate komponente sustava, nikada nećete dobiti upozorenje samo zato što se "nešto čini malo čudnim".
Učitavanje ljudskih upozorenja prilično je skupo trošenje vremena zaposlenika. Ako zaposlenik radi, upozorenje prekida tijek rada. Ako je zaposlenik kod kuće, upozorenje prekida osobno vrijeme i eventualno san. Kada se upozorenja pojavljuju prečesto, zaposlenici letimično prelaze, odgađaju ili ignoriraju dolazna upozorenja. S vremena na vrijeme ignoriraju pravu uzbunu, koja je maskirana bukom. Prekidi usluge mogu trajati dugo jer događaji buke sprječavaju brzo dijagnosticiranje i rješavanje problema. Učinkoviti razglasni sustavi imaju dobar omjer signala i šuma.
Utvrđivanje razumnih očekivanja od sustava praćenja
Postavljanje nadzora za složenu aplikaciju složen je inženjerski zadatak sam po sebi. Čak i uz značajnu infrastrukturu alata za prikupljanje, prikaz i uzbunjivanje, Google SRE tim od 10-12 članova obično uključuje jednu ili dvije osobe čija je glavna svrha izgradnja i održavanje sustava za nadzor. Taj se broj s vremenom smanjio kako generaliziramo i centraliziramo infrastrukturu za nadzor, ali svaki SRE tim obično ima barem jednog člana osoblja koji se bavi samo nadzorom. Mora se reći da iako je vrlo zanimljivo gledati nadzorne ploče sustava za nadzor, SRE timovi pažljivo izbjegavaju situacije koje zahtijevaju da netko gleda u ekran kako bi pratio probleme.
Općenito, Google je prešao na jednostavne i brze sustave praćenja s optimalnim alatima za naknadnu analizu. Izbjegavamo "magične" sustave koji pokušavaju predvidjeti pragove ili automatski otkriti glavni uzrok. Senzori koji otkrivaju neželjeni sadržaj u zahtjevima krajnjih korisnika jedini su protuprimjer; sve dok su ti senzori jednostavni, mogu brzo otkriti uzroke ozbiljnih anomalija. Drugi formati za korištenje podataka praćenja, kao što je planiranje kapaciteta ili predviđanje prometa, izazovniji su. Promatranje tijekom vrlo dugog vremena (mjeseci ili godine) pri niskoj stopi uzorkovanja (sati ili dani) otkrit će dugoročni trend.
Tim Google SRE radio je s različitim stupnjevima uspjeha sa složenim hijerarhijama ovisnosti. Rijetko koristimo pravila poput "ako saznam da je baza podataka postala spora, dobivam upozorenje o usporavanju baze podataka, inače dobivam upozorenje o sporoj web stranici." Pravila koja se temelje na ovisnosti obično se odnose na nepromjenjive dijelove našeg sustava, kao što je sustav za filtriranje korisničkog prometa prema podatkovnom centru. Na primjer, "ako je konfigurirano filtriranje prometa podatkovnog centra, nemoj me upozoravati o kašnjenjima u obradi korisničkih zahtjeva" jedno je uobičajeno pravilo za upozorenja podatkovnog centra. Nekoliko timova u Googleu podržava složene hijerarhije ovisnosti jer naša infrastruktura ima stalnu stopu kontinuiranog refaktoriranja.
Neke od ideja navedenih u ovom poglavlju i dalje su istinite: uvijek postoji način da se brže prijeđe od simptoma do temeljnog uzroka, osobito u sustavima koji se stalno mijenjaju. Stoga, iako ovo poglavlje opisuje neke ciljeve za sustave nadzora i kako postići te ciljeve, važno je da sustavi nadzora budu jednostavni i razumljivi svima u timu.
Isto tako, kako bi razina buke bila niska, a razina signala visoka, pristupi nadzoru objekata koji se uzbunjuju moraju biti vrlo jednostavni i pouzdani. Pravila koja generiraju upozorenja za ljude trebala bi biti laka za razumijevanje i predstavljati jasan problem.
Simptomi nasuprot uzrocima
Vaš sustav nadzora trebao bi odgovoriti na dva pitanja: "što je pokvareno" i "zašto je pokvareno".
"Što je puklo" odnosi se na simptom, a "zašto je puklo" na uzrok. Donja tablica prikazuje primjere takvih veza.
Simptom
razlog
Primanje HTTP pogreške 500 ili 404
Poslužitelji baze podataka odbijaju veze
Spori odgovori poslužitelja
Visoka iskorištenost procesora ili oštećeni Ethernet kabel
Korisnici na Antarktici ne dobivaju GIF-ove mačaka
Vaš CDN mrzi znanstvenike i mačke, pa su neke IP adrese na crnoj listi
Privatni sadržaj dostupan je posvuda
Izlaskom novog softvera vatrozid je zaboravio sve ACL-ove i pustio sve unutra
"Što" i "zašto" jedan su od najvažnijih sastavnih dijelova za stvaranje dobrog nadzornog sustava s maksimalnim signalom i minimalnim šumom.
Crna kutija protiv bijele kutije
Kombiniramo opsežno praćenje bijele kutije sa skromnim praćenjem crne kutije za kritične metrike. Najlakši način za usporedbu crne kutije s bijelom kutijom je da je crna kutija usmjerena na simptome i reaktivno je, a ne proaktivno praćenje: "sustav trenutno ne radi ispravno." White-box ovisi o internim mogućnostima provjere sustava: zapisnicima događaja ili web poslužiteljima. Dakle, White-box vam omogućuje otkrivanje nadolazećih problema, kvarova koji izgledaju kao ponovni prijenos zahtjeva itd.
Imajte na umu da je u višeslojnom sustavu simptom u području odgovornosti jednog inženjera simptom u području odgovornosti drugog inženjera. Na primjer, performanse baze podataka su se smanjile. Sporo čitanje baze podataka simptom je SRE baze podataka koja ih otkriva. Međutim, za front-end SRE koji gleda sporu web stranicu, razlog za isto sporo čitanje baze podataka je taj što je baza podataka spora. Stoga je nadzor bijele kutije ponekad usmjeren na simptome, a ponekad na uzroke, ovisno o tome koliko je opsežan.
Prilikom prikupljanja telemetrije za otklanjanje pogrešaka, potreban je nadzor bijele kutije. Ako web poslužitelji sporo odgovaraju na upite baze podataka, morate znati koliko brzo web poslužitelj komunicira s bazom podataka i koliko brzo odgovara. U protivnom nećete moći razlikovati spor poslužitelj baze podataka i mrežni problem između web poslužitelja i baze podataka.
Praćenje crne kutije ima ključnu prednost pri slanju upozorenja: primatelju šaljete obavijest kada je problem već izazvao stvarne simptome. S druge strane, za problem crne kutije koji još nije nastao, ali nadolazi, praćenje je beskorisno.
Četiri zlatna signala
Četiri zlatna signala praćenja su latencija, promet, pogreške i zasićenje. Ako možete mjeriti samo četiri metrike korisničkog sustava, usredotočite se na te četiri.
kašnjenje
Vrijeme potrebno za obradu zahtjeva. Važno je razlikovati latenciju uspješnih i neuspješnih zahtjeva. Na primjer, pogreška HTTP 500 uzrokovana gubitkom veze s bazom podataka ili drugom pozadinom može se vrlo brzo dijagnosticirati, međutim, pogreška HTTP 500 može ukazivati na neuspjeli zahtjev. Pronalaženje utjecaja pogreške 500 na ukupnu latenciju može dovesti do pogrešnih zaključaka. S druge strane, spora pogreška je čak i brza pogreška! Stoga je važno pratiti kašnjenje pogreške, a ne samo filtrirati pogreške.
Promet
Broj zahtjeva prema vašem sustavu, mjeren sistemskom metrikom visoke razine. Za web uslugu ovo mjerenje obično predstavlja broj HTTP zahtjeva u sekundi podijeljen prirodom zahtjeva (na primjer, statički naspram dinamičkog sadržaja). Za sustav strujanja zvuka, ovo mjerenje može biti usmjereno na mrežnu I/O brzinu ili broj istodobnih sesija. Za sustav pohrane ključ-vrijednosti, ovo mjerenje može biti transakcija ili traženje po sekundi.
Pogreške
Ovo je stopa neuspjelih zahtjeva, bilo eksplicitno (na primjer, HTTP 500), implicitno (na primjer, HTTP 200, ali u kombinaciji s lošim sadržajem), ili prema pravilima (na primjer, "Ako snimite odgovor u jednoj sekundi, bilo koji jedna sekunda je greška"). Ako nema dovoljno HTTP kodova odgovora za izražavanje svih uvjeta kvara, možda će biti potrebni sekundarni (interni) protokoli za otkrivanje djelomičnog kvara. Praćenje svih takvih pogrešnih zahtjeva može biti neinformativno, dok vam end-to-end testovi sustava mogu pomoći da otkrijete da obrađujete krivi sadržaj.
Zasićenost
Mjerni podatak pokazuje koliko se intenzivno koristi vaša usluga. Ovo je mjera nadzora sustava koja identificira resurse koji su najograničeniji (na primjer, u sustavu s ograničenom memorijom, prikazuje memoriju, u sustavu s ograničenim I/O, prikazuje broj I/O). Imajte na umu da se mnogi sustavi degradiraju prije nego što dosegnu 100% upotrebe, stoga je važno imati ciljanu upotrebu.
U složenim sustavima, zasićenje se može nadopuniti mjerenjem opterećenja na višoj razini: može li vaša usluga ispravno podnijeti dvostruki promet, podnijeti samo 10% više prometa ili podnijeti još manje prometa nego što trenutno može? Za jednostavne usluge koje nemaju parametre koji mijenjaju složenost zahtjeva (npr. "Ne daj mi ništa" ili "Trebam jedinstveni jedan monotoni cijeli broj") koje rijetko mijenjaju konfiguraciju, vrijednost testa statičkog opterećenja može biti odgovarajuća. Međutim, kao što je objašnjeno u prethodnom odlomku, većina usluga treba koristiti neizravne signale kao što su iskorištenost procesora ili propusnost mreže koji imaju poznatu gornju granicu. Rastuća latencija često je glavni pokazatelj zasićenja. Mjerenje vremena odgovora 99. percentila u malom prozoru (npr. jedna minuta) može dati vrlo rani signal zasićenja.
Konačno, zasićenje je također povezano s predviđanjima nadolazećeg zasićenja, kao što je: "Izgleda da će vaša baza podataka napuniti vaš tvrdi disk za 4 sata."
Ako mjerite sva četiri zlatna signala i kada postoji problem s nekom od metrika (ili, u slučaju zasićenja, gotovo problem), obavijestite osobu, vaša će usluga biti više-manje pokrivena monitoringom.
Brinite o repu (ili instrumentima i izvedbi)
Kada se sustav za nadzor gradi od nule, primamljivo je razviti sustav temeljen na prosjecima: prosječnoj latenciji, prosječnom korištenju procesora čvora ili prosječnoj popunjenosti baze podataka. Opasnost posljednja dva primjera je očita: procesorima i bazama podataka raspolaže se na vrlo nepredvidiv način. Isto vrijedi i za kašnjenje. Ako izvodite web uslugu s prosječnom latencijom od 100 ms pri 1000 zahtjeva u sekundi, 1% zahtjeva može trajati 5 sekundi. Ako korisnici ovise o više takvih web-usluga, 99. percentil jedne pozadine može lako postati srednje vrijeme odziva sučelja.
Najjednostavniji način razlikovanja između sporog prosjeka i vrlo sporog repa zahtjeva je prikupljanje mjerenja zahtjeva izraženih u statistici (histogrami su prikladan alat za prikaz), a ne stvarnih kašnjenja: koliko je zahtjeva poslužila usluga koja je uzela između 0 ms i 10 ms, između 10 ms i 30 ms, između 30 ms i 100 ms, između 100 ms i 300 ms itd. Približno eksponencijalno proširenje granica histograma (faktorom od oko 3) često je jednostavan način za vizualizaciju distribucije zahtjeva.
Odabir prave granularnosti za mjerenja
Različite elemente sustava treba mjeriti s različitim razinama detalja. Na primjer:
- Promatranje iskorištenosti CPU-a tijekom određenog vremenskog razdoblja neće pokazati duge skokove koji rezultiraju velikim kašnjenjima.
- S druge strane, za web uslugu koja ne cilja na više od 9 sati prekida rada godišnje (99,9% godišnje neprekidnog rada), provjera HTTP 200 odgovora više od jednom ili dva puta u minuti vjerojatno bi bila nepotrebno česta.
- Slično tome, provjera slobodnog prostora na tvrdom disku za 99,9% dostupnosti više od jednom svake 1-2 minute vjerojatno je nepotrebna.
Pazite kako strukturirate granularnost dimenzija. Stopa iskorištenja CPU-a od 1 po sekundi može dati zanimljive podatke, ali takva česta mjerenja mogu biti vrlo skupa za prikupljanje, pohranu i analizu. Ako vaš cilj praćenja zahtijeva visoku granularnost i ne zahtijeva visoku odzivnost, možete smanjiti te troškove postavljanjem prikupljanja metrika na poslužitelju, a zatim konfiguriranjem vanjskog sustava za prikupljanje i agregiranje tih metrika. Možeš li:
- Mjerite upotrebu procesora svake sekunde.
- Smanjite detalje na 5%.
- Skupna metrika svake minute.
Ova strategija će vam omogućiti prikupljanje vrlo granularnih podataka bez velikih troškova za analizu i pohranu.
Najjednostavnije moguće, ali ne i lakše
Slaganje različitih zahtjeva jednog na drugi može dovesti do vrlo složenog sustava nadzora. Na primjer, vaš sustav može imati sljedeće komplicirane elemente:
- Upozorenja prema različitim pragovima za kašnjenje zahtjeva, u različitim percentilima, kroz sve vrste različitih metrika.
- Pisanje dodatnog koda za otkrivanje i prepoznavanje mogućih uzroka.
- Stvorite povezane nadzorne ploče za svaki od mogućih uzroka problema.
Izvorima mogućih komplikacija nikad kraja. Kao i svi softverski sustavi, praćenje može postati toliko složeno da postane krhko, teško ga je mijenjati i održavati.
Stoga dizajnirajte svoj sustav nadzora tako da bude što je moguće više pojednostavljen. Kada birate što ćete pratiti, imajte na umu sljedeće:
- Pravila koja najčešće hvataju stvarne incidente trebaju biti što jednostavnija, predvidljivija i pouzdanija.
- Konfiguraciju za prikupljanje podataka, agregaciju i upozoravanje koja se izvodi rijetko (na primjer, manje od tromjesečno za neke SRE timove) treba ukloniti.
- Mjerni podaci koji su prikupljeni, ali nisu prikazani ni na jednoj ploči pregleda niti korišteni u bilo kojem upozorenju kandidati su za brisanje.
U Googleu, osnovno prikupljanje i agregacija mjernih podataka, u kombinaciji s upozorenjima i nadzornim pločama, funkcionira dobro kao relativno samostalan sustav (Googleov sustav praćenja zapravo je podijeljen na nekoliko podsustava, ali obično su ljudi svjesni svih aspekata tih podsustava). Može biti primamljivo kombinirati nadzor s drugim metodama testiranja složenih sustava: detaljnim profiliranjem sustava, otklanjanjem pogrešaka procesa, praćenjem detalja o iznimkama ili kvarovima, testiranjem opterećenja, prikupljanjem i analizom dnevnika ili inspekcijom prometa. Iako većina ovih stvari ima sličnosti s osnovnim nadzorom, njihovo miješanje rezultirat će s previše rezultata i stvoriti složen i krhki sustav. Kao i kod mnogih drugih aspekata razvoja softvera, podržavanje različitih sustava s jasnim, jednostavnim, labavo povezanim točkama integracije najbolja je strategija (na primjer, korištenje web API-ja za dohvaćanje sažetih podataka u formatu koji može ostati konstantan tijekom dugog vremenskog razdoblja ).
Povezivanje načela zajedno
Načela o kojima se govori u ovom poglavlju mogu se kombinirati u filozofiju praćenja i upozoravanja koju podržavaju i slijede Google SRE timovi. Pridržavanje ove filozofije praćenja je poželjno, to je dobra polazna točka za stvaranje ili revidiranje metodologije upozorenja i može vam pomoći da postavite prava pitanja operacijama bez obzira na veličinu vaše organizacije ili složenost usluge ili sustava.
Kada stvarate pravila nadzora i upozorenja, postavljanje sljedećih pitanja može vam pomoći da izbjegnete lažno pozitivne rezultate i nepotrebna upozorenja:
- Otkriva li ovo pravilo stanje sustava koje se inače ne može detektirati, a koje je hitno, poziva na akciju i neizbježno utječe na korisnika?
- Mogu li zanemariti ovo upozorenje znajući da je benigno? Kada i zašto mogu zanemariti ovo upozorenje i kako mogu izbjeći ovaj scenarij?
- Znači li ovo upozorenje da to negativno utječe na korisnike? Postoje li situacije u kojima korisnici nisu negativno pogođeni, na primjer, zbog filtriranja prometa ili pri korištenju testnih sustava, upozorenja na kojima bi se trebala filtrirati?
- Mogu li nešto poduzeti kao odgovor na ovo upozorenje? Jesu li ove mjere hitne ili se može čekati do jutra? Je li sigurno automatizirati radnju? Hoće li ova radnja biti dugoročno rješenje ili kratkoročno zaobilazno rješenje?
- Neki ljudi dobivaju više upozorenja za ovaj problem, pa je li moguće smanjiti broj?
Ova pitanja odražavaju temeljnu filozofiju o upozorenjima i sustavima uzbunjivanja:
- Svaki put kad dođe dojava, moram hitno reagirati. Mogu žuriti nekoliko puta dnevno prije nego što se umorim.
- Svako upozorenje mora biti ažurno.
- Svaki odgovor na uzbunu mora zahtijevati ljudsku intervenciju. Ako se obavijest može automatski obraditi, ne bi trebala doći.
- Upozorenja bi se trebala odnositi na novi problem ili događaj koji se prije nije dogodio.
Ovaj pristup zamagljuje određene razlike: ako upozorenje zadovoljava prethodna četiri uvjeta, nije bitno je li upozorenje poslano iz nadzornog sustava bijele kutije ili crne kutije. Ovaj pristup također pojačava određene razlike: bolje je uložiti mnogo više truda u identifikaciju simptoma nego u uzroke; kada je riječ o uzrocima, trebate se brinuti samo o neizbježnim uzrocima.
Dugoročno praćenje
U današnjim proizvodnim okruženjima, nadzorni sustavi nadziru proizvodni sustav koji se neprestano razvija s promjenjivom arhitekturom softvera, karakteristikama opterećenja i ciljevima performansi. Upozorenja, koja je trenutno teško automatizirati, mogla bi postati uobičajena, a možda čak i zaslužuju da se njima pozabavimo. U ovom trenutku, netko mora pronaći i popraviti uzroke problema; ako takvo rješenje nije moguće, reakcija na uzbunu zahtijeva potpunu automatizaciju.
Važno je da se odluke o praćenju donose imajući na umu dugoročne ciljeve. Svako upozorenje koje se pokrene danas udaljava osobu od sutrašnjeg poboljšanja sustava, tako da često dolazi do smanjenja dostupnosti ili performansi produktivnog sustava za vrijeme koje je potrebno za dugoročno poboljšanje sustava nadzora. Pogledajmo dva primjera koji ilustriraju ovaj fenomen.
Bigtable SRE: priča o pretjeranom oprezu
Googleova interna infrastruktura obično se pruža i mjeri u smislu razine usluge (SLO). Prije mnogo godina, SLO usluge Bigtable temeljio se na prosječnoj izvedbi sintetičke transakcije koja simulira pokrenutog klijenta. Zbog problema u Bigtableu i nižim razinama skladišta za pohranu, prosječna izvedba bila je vođena "velikim" repom: najgorih 5% upita često je bilo značajno sporije od ostalih.
Obavijesti putem e-pošte slale su se kada se približavao SLO prag, a slala su se upozorenja putem glasnika kada je SLO bio premašen. Obje vrste upozorenja slane su prilično često, oduzimajući neprihvatljive količine inženjerskog vremena: tim je proveo značajnu količinu vremena analizirajući upozorenja kako bi pronašao nekoliko stvarno relevantnih. Često smo propustili problem koji je zapravo utjecao na korisnike jer se samo nekoliko upozorenja odnosilo na taj problem. Mnoga upozorenja nisu bila hitna zbog razumljivih infrastrukturnih problema i s njima se postupalo na standardni način ili se uopće nije postupalo.
Kako bi popravio situaciju, tim je koristio trostruki pristup: dok smo naporno radili na poboljšanju performansi Bigtablea, privremeno smo postavili 75. percentil za kašnjenje odgovora na upit kao naš SLO cilj. Isključili smo i upozorenja e-poštom, jer ih je bilo toliko da je bilo nemoguće gubiti vrijeme na njihovu dijagnostiku.
Ova nam je strategija omogućila odušak da počnemo rješavati dugoročne probleme u Bigtableu i nižim slojevima skladišta za pohranu, umjesto da stalno popravljamo taktičke probleme. Inženjeri bi zapravo mogli obaviti posao kad ne bi bili cijelo vrijeme bombardirani upozorenjima. U konačnici, privremena odgoda u obradi upozorenja omogućila nam je da poboljšamo kvalitetu usluge.
Gmail: Predvidljivi, algoritamski ljudski odgovori
Na samom početku, Gmail je izgrađen na modificiranom sustavu kontrole procesa Workqueue koji je stvoren za skupnu obradu dijelova indeksa pretraživanja. Workqueue je prilagođen dugotrajnim procesima i naknadno primijenjen na Gmail, ali pokazalo se da je neke greške u neprozirnom kodu planera vrlo teško popraviti.
U to je vrijeme nadzor Gmaila bio strukturiran tako da bi se upozorenja aktivirala kada bi se pojedinačni zadaci otkazali pomoću Workqueuea. Ovaj pristup nije bio idealan, jer čak iu to vrijeme Gmail je obavljao mnogo tisuća zadataka, od kojih je svaki bio dan djelićima postotka naših korisnika. Jako smo pazili da korisnici Gmaila imaju dobro korisničko iskustvo, ali nije dolazilo u obzir rukovanje tolikom količinom upozorenja.
Kako bi riješio ovaj problem, Gmail SRE stvorio je alat koji će pomoći u otklanjanju pogrešaka planera što je moguće bolje kako bi se smanjio utjecaj na korisnike. Tim je nekoliko puta raspravljao o tome treba li jednostavno automatizirati cijeli ciklus od pronalaženja problema do njegovog rješavanja dok se ne pronađe dugoročno rješenje, ali neki su bili zabrinuti da bi takvo rješenje odgodilo stvarno rješavanje problema.
Takva je napetost bila uobičajena unutar tima i često je odražavala nepovjerenje u samodisciplinu: dok neki članovi tima žele dati vremena za pravi popravak, drugi se brinu da će konačni popravak biti zaboravljen i da će privremeni popravak trajati zauvijek. Ovaj problem zaslužuje pozornost jer je prelako privremeno riješiti probleme umjesto da ih trajno riješite. Menadžeri i tehničko osoblje igraju ključnu ulogu u implementaciji dugoročnih popravaka podržavajući i dajući prioritet potencijalno dugoročnim dugoročnim popravcima čak i kada početna bol nestane.
Redovita ponavljajuća upozorenja i algoritamske reakcije trebale bi biti crvena zastavica. Nespremnost vašeg tima da automatizira ova upozorenja znači da tim nema povjerenja da može vjerovati algoritmima. Ovo je ozbiljan problem koji treba riješiti.
Dugoročno
Zajednička tema povezuje primjere Bigtablea i Gmaila: natjecanje između kratkoročne i dugoročne dostupnosti. Često veliki napor može pomoći krhkom sustavu da postigne visoku dostupnost, ali taj je put obično kratkotrajan, prepun izgaranja tima i ovisnosti o malom broju članova tog istog herojskog tima.
Kontrolirano, kratkoročno smanjenje dostupnosti često je bolno, ali strateški važno za dugoročnu stabilnost sustava. Važno je ne razmatrati svako upozorenje zasebno, već razmotriti dovodi li ukupna stopa upozorenja do zdravog, pravilno dostupnog sustava s održivim timom i povoljnom prognozom. Analiziramo statistiku stope upozorenja (obično izraženu kao incidenti po smjeni, gdje se incident može sastojati od više povezanih incidenata) u tromjesečnim izvješćima s upravom, omogućujući donositeljima odluka da kontinuirano prikazuju opterećenje sustava upozorenja i cjelokupno zdravlje tima.
Zaključak
Put do zdravog nadzora i upozorenja je jednostavan i jasan. Usredotočuje se na simptome problema za koje se generiraju upozorenja, a praćenje uzroka služi kao pomoć pri otklanjanju pogrešaka. Praćenje simptoma je lakše što ste viši u nizu koji kontrolirate, iako bi se opterećenje baze podataka i praćenje performansi trebalo provoditi izravno na samoj bazi podataka. Obavijesti e-poštom imaju vrlo ograničenu upotrebu i lako mogu prerasti u buku; umjesto toga, trebali biste koristiti nadzornu ploču koja prati sve trenutne probleme koji su upozoreni e-poštom. Nadzorna ploča također se može upariti s zapisnikom događaja za analizu povijesnih korelacija.
Dugoročno gledano, potrebno je postići uspješnu izmjenu između upozorenja o simptomima i neposrednih stvarnih problema, te prilagoditi ciljeve kako bi se osiguralo da praćenje podržava brzu dijagnozu.
Hvala vam što ste pročitali prijevod do kraja. Pretplatite se na moj telegram kanal o praćenju и .
Izvor: www.habr.com