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 prijevod 6. poglavlja iste knjige o ciljevima razine usluge.
Prijevod kat. Uživaj čitajući!
Nemoguće je upravljati uslugom ako nema razumijevanja koji su pokazatelji zapravo važni i kako ih mjeriti i evaluirati. U tu svrhu definiramo i pružamo određenu razinu usluge našim korisnicima, bez obzira koriste li neki od naših internih API-ja ili javni proizvod.
Koristimo svoju intuiciju, iskustvo i razumijevanje želje korisnika da razumiju pokazatelje razine usluge (SLI), ciljeve razine usluge (SLO) i ugovore o razini usluge (SLA). Ove dimenzije opisuju glavne metrike koje želimo pratiti i na koje ćemo reagirati ako ne možemo pružiti očekivanu kvalitetu usluge. U konačnici, odabir pravih mjernih podataka pomaže u usmjeravanju pravih radnji ako nešto pođe po zlu, a također daje SRE timu povjerenje u ispravnost usluge.
Ovo poglavlje opisuje pristup koji koristimo u borbi protiv problema metričkog modeliranja, odabira metrike i analize metrike. Većina objašnjenja bit će bez primjera, pa ćemo koristiti uslugu Shakespeare opisanu u primjeru implementacije (pretraga Shakespeareovih djela) za ilustraciju glavnih točaka.
Terminologija razine usluge
Mnogi čitatelji vjerojatno su upoznati s konceptom SLA, ali pojmovi SLI i SLO zaslužuju pažljivu definiciju jer je općenito pojam SLA preopterećen i ima niz značenja ovisno o kontekstu. Radi jasnoće, želimo razdvojiti ove vrijednosti.
Pokazatelji
SLI je pokazatelj razine usluge—pažljivo definirana kvantitativna mjera jednog aspekta razine pružene usluge.
Za većinu usluga smatra se da je ključni SLI latencija zahtjeva - koliko dugo je potrebno da se odgovori na zahtjev. Drugi uobičajeni SLI-ovi uključuju stopu pogreške, često izraženu kao dio svih primljenih zahtjeva, i propusnost sustava, obično mjeren u zahtjevima po sekundi. Mjerenja se često agregiraju: prvo se prikupljaju neobrađeni podaci, a zatim pretvaraju u stopu promjene, srednju vrijednost ili percentil.
U idealnom slučaju, SLI izravno mjeri razinu usluge od interesa, ali ponekad je za mjerenje dostupna samo povezana metrika jer je izvornu teško dobiti ili interpretirati. Na primjer, kašnjenje na strani klijenta često je prikladnija metrika, ali postoje slučajevi kada se kašnjenje može mjeriti samo na poslužitelju.
Druga vrsta SLI-ja koja je važna za SRE je dostupnost ili dio vremena tijekom kojeg se usluga može koristiti. Često se definira kao stopa uspješnih zahtjeva, ponekad se naziva prinos. (Životni vijek—vjerojatnost da će podaci biti zadržani dulje vremensko razdoblje—također je važan za sustave za pohranu podataka.) Iako 100% dostupnost nije moguća, dostupnost blizu 100% često se može postići; vrijednosti dostupnosti izražavaju se kao broj "devetki" » postotak dostupnosti. Na primjer, dostupnost od 99% i 99,999% može biti označena kao "2 devetke" i "5 devetke". Trenutačni cilj dostupnosti Google Compute Enginea je "tri i pol devetke" ili 99,95%.
ciljevi
SLO je cilj razine usluge: ciljana vrijednost ili raspon vrijednosti za razinu usluge koju mjeri SLI. Normalna vrijednost za SLO je "SLI ≤ Cilj" ili "Donja granica ≤ SLI ≤ Gornja granica". Na primjer, mogli bismo odlučiti da ćemo "brzo" vratiti Shakespeareove rezultate pretraživanja postavljanjem SLO-a na prosječnu latenciju upita za pretraživanje manju od 100 milisekundi.
Odabir pravog ČVN-a složen je proces. Prvo, ne možete uvijek odabrati određenu vrijednost. Za vanjske dolazne HTTP zahtjeve vašoj usluzi, metrika upita po sekundi (QPS) primarno je određena željom vaših korisnika da posjete vašu uslugu i za to ne možete postaviti SLO.
S druge strane, možete reći da želite da prosječna latencija za svaki zahtjev bude manja od 100 milisekundi. Postavljanje takvog cilja može vas prisiliti da napišete svoje sučelje s niskom latencijom ili kupite opremu koja pruža takvu latenciju. (100 milisekundi je očito proizvoljan broj, ali bolje je imati još niže brojeve latencije. Postoje dokazi koji sugeriraju da su velike brzine bolje od sporih i da latencija u obradi korisničkih zahtjeva iznad određenih vrijednosti zapravo tjera ljude da se drže podalje iz vaše službe.)
Opet, ovo je dvosmislenije nego što se može činiti na prvi pogled: ne biste trebali potpuno isključiti QPS iz izračuna. Činjenica je da su QPS i latencija snažno povezani jedni s drugima: veći QPS često dovodi do viših latencija, a usluge obično doživljavaju oštro smanjenje performansi kada dosegnu određeni prag opterećenja.
Odabir i objavljivanje SLO-a postavlja očekivanja korisnika o tome kako će usluga funkcionirati. Ova strategija može smanjiti neutemeljene pritužbe protiv vlasnika usluge, poput sporog rada. Bez eksplicitnog SLO-a, korisnici često stvaraju vlastita očekivanja o željenoj izvedbi, koja možda nemaju nikakve veze s mišljenjima ljudi koji dizajniraju i upravljaju uslugom. Ova situacija može dovesti do prenapuhanih očekivanja od usluge, kada korisnici pogrešno vjeruju da će usluga biti dostupnija nego što zapravo jest, i izazvati nepovjerenje kada korisnici vjeruju da je sustav manje pouzdan nego što zapravo jest.
Ugovori
Ugovor o razini usluge eksplicitan je ili implicitni ugovor s vašim korisnicima koji uključuje posljedice ispunjavanja (ili neispunjavanja) SLO-a koje sadrže. Posljedice se najlakše prepoznaju kada su financijske - popust ili kazna - ali mogu imati i druge oblike. Jednostavan način da se govori o razlici između ČVN-a i SLA-a jest pitati se "što se događa ako se ČVN-ovi ne ispune?" Ako nema jasnih posljedica, gotovo sigurno gledate u ČVN-a.
SRE obično nije uključen u stvaranje SLA jer su SLA usko povezani s poslovnim odlukama i odlukama o proizvodima. SRE je, međutim, uključen u pomoć u ublažavanju posljedica neuspjelih ČVN-a. Oni također mogu pomoći u određivanju SLI: Očito, mora postojati objektivan način za mjerenje SLO u dogovoru ili će doći do neslaganja.
Google Search je primjer važne usluge koja nema javni SLA: želimo da svi koriste Search što učinkovitije, ali nismo potpisali ugovor sa svijetom. Međutim, i dalje postoje posljedice ako pretraživanje nije dostupno - nedostupnost rezultira padom našeg ugleda kao i smanjenjem prihoda od oglašavanja. Mnoge druge Googleove usluge, kao što je Google for Work, imaju izričite ugovore o razini usluge s korisnicima. Bez obzira na to ima li određena usluga SLA, važno je definirati SLI i SLO i koristiti ih za upravljanje uslugom.
Toliko teorije - sada na iskustvo.
Pokazatelji u praksi
S obzirom da smo zaključili da je važno odabrati odgovarajuću metriku za mjerenje razine usluge, kako sada znate koja je metrika važna za uslugu ili sustav?
Što vas i vaše korisnike zanima?
Ne morate koristiti svaku metriku kao SLI koju možete pratiti u sustavu za praćenje; Razumijevanje onoga što korisnici žele od sustava pomoći će vam da odaberete nekoliko metrika. Odabir previše indikatora otežava fokusiranje na važne indikatore, dok odabir malog broja može ostaviti velike dijelove vašeg sustava bez nadzora. Obično koristimo nekoliko ključnih pokazatelja za procjenu i razumijevanje zdravlja sustava.
Usluge se općenito mogu podijeliti u nekoliko dijelova u smislu SLI-a koji su za njih relevantni:
- Prilagođeni front-end sustavi, kao što su sučelja pretraživanja za uslugu Shakespeare iz našeg primjera. Moraju biti dostupni, nemaju kašnjenja i moraju imati dovoljnu propusnost. Sukladno tome, mogu se postaviti pitanja: možemo li odgovoriti na zahtjev? Koliko je vremena trebalo da se odgovori na zahtjev? Koliko se zahtjeva može obraditi?
- Sustavi skladištenja. Oni cijene nisko kašnjenje odgovora, dostupnost i trajnost. Povezana pitanja: Koliko je vremena potrebno za čitanje ili pisanje podataka? Možemo li pristupiti podacima na zahtjev? Jesu li podaci dostupni kada su nam potrebni? Pogledajte Poglavlje 26 Integritet podataka: Ono što čitate to pišete za detaljnu raspravu o ovim pitanjima.
- Sustavi velikih podataka kao što su cjevovodi za obradu podataka oslanjaju se na propusnost i kašnjenje obrade upita. Povezana pitanja: Koliko se podataka obrađuje? Koliko je vremena potrebno da podaci putuju od primitka zahtjeva do izdavanja odgovora? (Neki dijelovi sustava također mogu imati kašnjenja u određenim fazama.)
Zbirka pokazatelja
Mnogi indikatori razine usluge najprirodnije se prikupljaju na strani poslužitelja, korištenjem sustava za nadzor kao što je Borgmon (vidi dolje). ) ili Prometheus, ili jednostavno povremeno analizirati zapisnike, identificirajući HTTP odgovore sa statusom 500. Međutim, neki bi sustavi trebali biti opremljeni prikupljanjem metrike na strani klijenta, budući da nedostatak nadzora na strani klijenta može dovesti do propuštanja niza problema koji utječu korisnicima, ali ne utječu na metriku na strani poslužitelja. Na primjer, fokusiranje na kašnjenje pozadinskog odgovora naše Shakespeare aplikacije za testiranje pretraživanja može rezultirati kašnjenjem na strani korisnika zbog problema s JavaScriptom: u ovom slučaju, mjerenje koliko je vremena potrebno pregledniku da obradi stranicu bolja je metrika.
Agregacija
Radi jednostavnosti i lakoće upotrebe, često prikupljamo neobrađena mjerenja. To se mora učiniti pažljivo.
Neki se pokazatelji čine jednostavnima, poput zahtjeva u sekundi, ali čak i ovo naizgled jednostavno mjerenje implicitno prikuplja podatke tijekom vremena. Je li mjerenje primljeno jednom u sekundi ili je mjerenje prosječno prema broju zahtjeva u minuti? Potonja opcija može sakriti puno veći trenutni broj zahtjeva koji traju samo nekoliko sekundi. Razmotrite sustav koji poslužuje 200 zahtjeva u sekundi s parnim brojevima i 0 ostalo vrijeme. Konstanta u obliku prosječne vrijednosti od 100 zahtjeva u sekundi i dvostruko trenutno opterećenje nisu ista stvar. Slično tome, prosječna latencija upita može izgledati privlačno, ali skriva važan detalj: moguće je da će većina upita biti brza, ali će biti mnogo upita koji su spori.
Većinu pokazatelja bolje je promatrati kao distribucije nego kao prosjeke. Na primjer, za SLI latenciju, neki će se zahtjevi brzo obraditi, dok će nekima uvijek trebati duže, ponekad i puno dulje. Jednostavan prosjek može sakriti ta duga kašnjenja. Slika prikazuje primjer: iako tipičnom zahtjevu treba otprilike 50 ms da se posluži, 5% zahtjeva je 20 puta sporije! Praćenje i upozoravanje temeljeno samo na prosječnoj latenciji ne pokazuje promjene u ponašanju tijekom dana, dok su zapravo vidljive promjene u vremenu obrade nekih zahtjeva (najgornji red).
50, 85, 95 i 99 percentilna latencija sustava. Y os je u logaritamskom formatu.
Korištenje percentila za indikatore omogućuje vam da vidite oblik distribucije i njezine karakteristike: visoka razina percentila, poput 99 ili 99,9, pokazuje najgoru vrijednost, dok 50 percentila (također poznat kao medijan) pokazuje najčešće stanje metrika. Što je veća disperzija vremena odgovora, to dugotrajniji zahtjevi više utječu na korisničko iskustvo. Učinak se pojačava pod velikim opterećenjem i u prisutnosti čekanja. Istraživanje korisničkog iskustva pokazalo je da ljudi općenito preferiraju sporiji sustav s velikom varijacijom vremena odgovora, pa se neki SRE timovi usredotočuju samo na rezultate visokih postotaka, na temelju toga da ako je ponašanje mjernog podatka na postotku od 99,9 dobro, većina korisnika neće imati problema .
Napomena o statističkim pogreškama
Općenito radije radimo s percentilima nego sa srednjom (aritmetičkom sredinom) skupa vrijednosti. To nam omogućuje da razmotrimo više disperzirane vrijednosti, koje često imaju značajno drugačije (i zanimljivije) karakteristike od prosjeka. Zbog umjetne prirode računalnih sustava, metričke vrijednosti često su iskrivljene, na primjer, niti jedan zahtjev ne može dobiti odgovor u roku kraćem od 0 ms, a vremensko ograničenje od 1000 ms znači da ne može biti uspješnih odgovora s vrijednostima većim nego timeout. Kao rezultat toga, ne možemo prihvatiti da srednja vrijednost i medijan mogu biti isti ili blizu!
Bez prethodnog testiranja i ako ne vrijede određene standardne pretpostavke i aproksimacije, pazimo da ne zaključimo da su naši podaci normalno distribuirani. Ako distribucija nije prema očekivanjima, proces automatizacije koji rješava problem (na primjer, kada uoči odstupanja, ponovno pokreće poslužitelj s velikim kašnjenjem obrade zahtjeva) to možda radi prečesto ili nedovoljno često (oboje nije vrlo dobro).
Standardizirati pokazatelje
Preporučamo standardizaciju općih karakteristika za SLI kako ne biste morali svaki put nagađati o njima. Svaka značajka koja zadovoljava standardne obrasce može biti isključena iz specifikacije pojedinačnog SLI-a, na primjer:
- Intervali agregacije: "u prosjeku tijekom 1 minute"
- Područja agregacije: “Svi zadaci u klasteru”
- Koliko često se vrše mjerenja: "Svakih 10 sekundi"
- Koji su zahtjevi uključeni: "HTTP GET iz poslova praćenja crne kutije"
- Kako se dobivaju podaci: "Zahvaljujući našem nadzoru mjerenom na poslužitelju"
- Latencija pristupa podacima: "Vrijeme do posljednjeg bajta"
Kako biste uštedjeli trud, stvorite skup SLI predložaka koji se mogu ponovno koristiti za svaku uobičajenu metriku; oni također olakšavaju svima da razumiju što određeni SLI znači.
Ciljevi u praksi
Započnite tako da razmislite (ili saznate!) do čega je vašim korisnicima stalo, a ne do onoga što možete mjeriti. Često je ono do čega je vašim korisnicima stalo teško ili nemoguće izmjeriti, pa se na kraju približite njihovim potrebama. Međutim, ako samo počnete s onim što je lako izmjeriti, završit ćete s manje korisnim SLO-ovima. Kao rezultat toga, ponekad smo otkrili da inicijalno identificiranje željenih ciljeva, a zatim rad s određenim pokazateljima funkcionira bolje nego odabir pokazatelja i zatim postizanje ciljeva.
Definirajte svoje ciljeve
Radi najveće jasnoće, trebalo bi definirati kako se SLO mjere i uvjete pod kojima vrijede. Na primjer, mogli bismo reći sljedeće (drugi redak je isti kao prvi, ali koristi zadane SLI):
- 99% (u prosjeku tijekom 1 minute) Get RPC poziva završit će se za manje od 100 ms (mjereno na svim pozadinskim poslužiteljima).
- 99% Get RPC poziva završit će se za manje od 100 ms.
Ako je oblik krivulja izvedbe važan, možete odrediti više SLO-ova:
- 90% Get RPC poziva dovršeno je za manje od 1 ms.
- 99% Get RPC poziva dovršeno je za manje od 10 ms.
- 99.9% Get RPC poziva dovršeno je za manje od 100 ms.
Ako vaši korisnici generiraju heterogena radna opterećenja: skupnu obradu (za koju je propusnost važna) i interaktivnu obradu (za koju je latencija važna), možda bi bilo korisno definirati zasebne ciljeve za svaku klasu opterećenja:
- 95% zahtjeva kupaca zahtijeva propusnost. Postavite broj RPC poziva izvedenih <1 s.
- 99% klijenata brine o latenciji. Postavite broj RPC poziva s prometom <1 KB i trajanjem <10 ms.
Nerealno je i nepoželjno inzistirati na tome da će se SLO-i ispuniti 100% vremena: to može smanjiti tempo uvođenja novih funkcionalnosti i implementacije te zahtijevati skupa rješenja. Umjesto toga, bolje je dopustiti proračun pogreške - postotak dopuštenog prekida rada sustava - i pratiti ovu vrijednost dnevno ili tjedno. Viši menadžment možda želi mjesečne ili tromjesečne procjene. (Proračun pogreške jednostavno je SLO za usporedbu s drugim SLO-om.)
Postotak kršenja ČVN-a može se usporediti s proračunom pogreške (pogledajte Poglavlje 3 i odjeljak ), s vrijednošću razlike koja se koristi kao ulaz u proces koji odlučuje kada implementirati nova izdanja.
Odabir ciljanih vrijednosti
Odabir vrijednosti planiranja (SLO) nije čisto tehnička aktivnost zbog proizvoda i poslovnih interesa koji se moraju odražavati u odabranim SLI, SLO (i eventualno SLA). Isto tako, možda će trebati razmijeniti informacije u vezi s pitanjima koja se odnose na osoblje, vrijeme za izlazak na tržište, dostupnost opreme i financiranje. SRE bi trebao biti dio ovog razgovora i pomoći u razumijevanju rizika i održivosti različitih opcija. Smislili smo nekoliko pitanja koja bi mogla pomoći u osiguravanju produktivnije rasprave:
Ne birajte cilj na temelju trenutne izvedbe.
Iako je razumijevanje prednosti i ograničenja sustava važno, prilagođavanje metrike bez obrazloženja može vas spriječiti u održavanju sustava: zahtijevat će herojske napore za postizanje ciljeva koji se ne mogu postići bez značajnog redizajna.
Neka bude jednostavno
Složeni SLI izračuni mogu sakriti promjene u performansama sustava i otežati pronalaženje uzroka problema.
Izbjegavajte apsolute
Iako je primamljivo imati sustav koji može podnijeti neograničeno rastuće opterećenje bez povećanja latencije, ovaj zahtjev je nerealan. Sustav koji se približava takvim idealima vjerojatno će zahtijevati puno vremena za projektiranje i izgradnju, bit će skup za rad i bit će predobar za očekivanja korisnika koji bi radili s bilo čim manje.
Koristite što manje SLO-ova
Odaberite dovoljan broj SLO-ova kako biste osigurali dobru pokrivenost atributa sustava. Zaštitite SLO koje odaberete: Ako nikada ne možete pobijediti u raspravi o prioritetima navođenjem određenog ČVN-a, vjerojatno ne vrijedi razmatrati taj ČVN. Međutim, nisu svi atributi sustava podložni SLO-ima: teško je izračunati razinu oduševljenja korisnika korištenjem SLO-ova.
Ne jurite za savršenstvom
Uvijek možete poboljšati definicije i ciljeve SLO-ova tijekom vremena kako učite više o ponašanju sustava pod opterećenjem. Bolje je započeti s plutajućim ciljem koji ćete s vremenom poboljšati nego odabrati pretjerano strog cilj koji morate opustiti kada ustanovite da je nedostižan.
ČVN mogu i trebaju biti ključni pokretač u određivanju prioriteta rada za SRE i programere proizvoda jer odražavaju brigu za korisnike. Dobar SLO je koristan alat za provedbu za razvojni tim. No, loše osmišljen SLO može dovesti do rasipnog rada ako se tim herojski trudi postići preagresivan SLO, ili do lošeg proizvoda ako je SLO prenizak. ČVN je moćna poluga, koristite je mudro.
Kontrolirajte svoja mjerenja
SLI i SLO ključni su elementi koji se koriste za upravljanje sustavima:
- Pratite i mjerite SLI sustave.
- Usporedite SLI sa SLO i odlučite je li potrebno nešto poduzeti.
- Ako je potrebna akcija, shvatite što se treba dogoditi da bi se postigao cilj.
- Dovršite ovu radnju.
Na primjer, ako korak 2 pokazuje da zahtjev ističe i da će prekinuti SLO za nekoliko sati ako se ništa ne poduzme, korak 3 može uključivati testiranje hipoteze da su poslužitelji vezani za CPU i da će dodavanje više poslužitelja raspodijeliti opterećenje. Bez ČVN-a ne biste znali treba li (ili kada) nešto poduzeti.
Postavite SLO - tada će se postaviti očekivanja korisnika
Objavljivanje SLO-a postavlja očekivanja korisnika za ponašanje sustava. Korisnici (i potencijalni korisnici) često žele znati što mogu očekivati od usluge kako bi razumjeli je li prikladna za korištenje. Na primjer, ljudi koji žele koristiti web stranicu za dijeljenje fotografija možda bi željeli izbjeći korištenje usluge koja obećava dugotrajnost i nisku cijenu u zamjenu za nešto manju dostupnost, iako bi ista usluga mogla biti idealna za sustav upravljanja arhivskim zapisima.
Kako biste svojim korisnicima postavili realna očekivanja, upotrijebite jednu ili obje sljedeće taktike:
- Održavajte marginu sigurnosti. Koristite stroži interni SLO od onog koji se oglašava korisnicima. To će vam dati priliku da reagirate na probleme prije nego što postanu vanjski vidljivi. SLO međuspremnik također vam omogućuje da imate sigurnosnu granicu kada instalirate izdanja koja utječu na performanse sustava i osigurava da je sustav lako održavati bez frustriranja korisnika zastojem.
- Nemojte premašiti očekivanja korisnika. Korisnici se temelje na onome što nudite, a ne na onome što govorite. Ako je stvarna izvedba vaše usluge puno bolja od navedenog SLO-a, korisnici će se osloniti na trenutnu izvedbu. Pretjeranu ovisnost možete izbjeći namjernim isključivanjem sustava ili ograničavanjem performansi pod malim opterećenjima.
Razumijevanje toga koliko dobro sustav ispunjava očekivanja pomaže u odlučivanju treba li ulagati u ubrzanje sustava i učiniti ga pristupačnijim i otpornijim. Alternativno, ako usluga radi previše dobro, dio vremena osoblja treba potrošiti na druge prioritete, kao što je otplata tehničkog duga, dodavanje novih značajki ili uvođenje novih proizvoda.
Dogovori u praksi
Stvaranje SLA zahtjeva od poslovnih i pravnih timova da definiraju posljedice i kazne za njegovo kršenje. Uloga SRE-a je pomoći im da razumiju vjerojatne izazove u ispunjavanju ČVN-ova sadržanih u SLA. Većina preporuka za stvaranje SLO-ova također se odnosi na SLA-ove. Mudro je biti konzervativan u onome što obećavate korisnicima jer što više imate, to je teže promijeniti ili ukloniti SLA ugovore koji se čine nerazumnim ili teškim za ispunjavanje.
Hvala vam što ste pročitali prijevod do kraja. Pretplatite se na moj telegram kanal o praćenju и .
Izvor: www.habr.com