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 prevod 6. poglavja iste knjige o ciljih na ravni storitev.
Prevod kat. Uživajte v branju!
Nemogoče je upravljati storitev, če ni razumevanja, kateri kazalniki so pravzaprav pomembni in kako jih meriti in ovrednotiti. V ta namen definiramo in zagotavljamo določeno raven storitev našim uporabnikom, ne glede na to, ali uporabljajo enega od naših internih API-jev ali javni izdelek.
Uporabljamo svojo intuicijo, izkušnje in razumevanje želje uporabnikov po razumevanju kazalnikov ravni storitev (SLI), ciljev ravni storitev (SLO) in sporazumov o ravni storitev (SLA). Te dimenzije opisujejo glavne metrike, ki jih želimo spremljati in na katere se bomo odzvali, če ne bomo mogli zagotoviti pričakovane kakovosti storitve. Navsezadnje izbira pravih meritev pomaga pri pravilnih dejanjih, če gre kaj narobe, ekipi SRE pa daje tudi zaupanje v zdravje storitve.
To poglavje opisuje pristop, ki ga uporabljamo za reševanje problemov metričnega modeliranja, izbire metrike in analize metrike. Večji del razlage bo brez primerov, zato bomo za ponazoritev glavnih poudarkov uporabili storitev Shakespeare, opisano v njenem primeru izvedbe (iskanje Shakespearovih del).
Terminologija na ravni storitve
Mnogi bralci verjetno poznajo koncept SLA, vendar izraza SLI in SLO zaslužita natančno opredelitev, ker je na splošno izraz SLA preobremenjen in ima več pomenov, odvisno od konteksta. Zaradi jasnosti želimo te vrednosti ločiti.
Kazalniki
SLI je kazalnik ravni storitve – skrbno opredeljeno kvantitativno merilo enega vidika ravni ponujene storitve.
Za večino storitev velja, da je ključni SLI zakasnitev zahteve – koliko časa traja vrnitev odgovora na zahtevo. Drugi pogosti SLI vključujejo stopnjo napak, ki je pogosto izražena kot del vseh prejetih zahtev, in sistemsko prepustnost, običajno merjeno v zahtevah na sekundo. Meritve so pogosto združene: neobdelani podatki se najprej zberejo in nato pretvorijo v stopnjo spremembe, povprečje ali percentil.
V idealnem primeru SLI neposredno meri želeno raven storitve, včasih pa je za merjenje na voljo samo sorodna metrika, ker je izvirno težko pridobiti ali interpretirati. Na primer, zakasnitev na strani odjemalca je pogosto primernejša metrika, včasih pa je zakasnitev mogoče izmeriti le na strežniku.
Druga vrsta SLI, ki je pomembna za SRE, je razpoložljivost ali del časa, v katerem se storitev lahko uporablja. Pogosto opredeljena kot stopnja uspešnih zahtev, včasih imenovana tudi donos. (Za sisteme za shranjevanje podatkov je pomembna tudi življenjska doba – verjetnost, da bodo podatki shranjeni dlje časa.) Čeprav 100-odstotna razpoložljivost ni mogoča, je razpoložljivost blizu 100-odstotna pogosto dosegljiva; vrednosti razpoložljivosti so izražene kot število "devetk" » odstotek razpoložljivosti. Na primer, 99 % in 99,999 % razpoložljivost sta lahko označeni kot "2 devetki" in "5 devetki". Trenutni navedeni cilj razpoložljivosti Google Compute Engine je "tri in pol devetke" ali 99,95 %.
Cilji
SLO je cilj ravni storitve: ciljna vrednost ali obseg vrednosti za raven storitve, ki se meri s SLI. Običajna vrednost za SLO je »SLI ≤ Target« ali »Lower Limit ≤ SLI ≤ Upper Limit«. Na primer, lahko se odločimo, da bomo rezultate iskanja Shakespeare vrnili "hitro", tako da nastavimo SLO na povprečno zakasnitev iskalne poizvedbe, manjšo od 100 milisekund.
Izbira pravega SLO je kompleksen proces. Prvič, ne morete vedno izbrati določene vrednosti. Za zunanje dohodne zahteve HTTP za vašo storitev je meritev Query Per Second (QPS) v prvi vrsti določena z željo vaših uporabnikov, da obiščejo vašo storitev, in za to ne morete nastaviti SLO.
Po drugi strani pa lahko rečete, da želite, da je povprečna zakasnitev za vsako zahtevo manjša od 100 milisekund. Postavitev takšnega cilja vas bo morda prisilila, da napišete svoj vmesnik z nizko zakasnitvijo ali kupite opremo, ki zagotavlja takšno zakasnitev. (100 milisekund je očitno poljubno število, vendar je bolje imeti še nižje številke zakasnitve. Obstajajo dokazi, ki kažejo, da so visoke hitrosti boljše od počasnih in da zakasnitev pri obdelavi uporabniških zahtev nad določenimi vrednostmi dejansko sili ljudi, da se izogibajo iz vaše službe.)
Še enkrat, to je bolj dvoumno, kot se morda zdi na prvi pogled: ne bi smeli popolnoma izključiti QPS iz izračuna. Dejstvo je, da sta QPS in zakasnitev med seboj močno povezani: višji QPS pogosto vodi do višjih zakasnitev in storitve običajno občutijo močno zmanjšanje zmogljivosti, ko dosežejo določen prag obremenitve.
Izbira in objava SLO določa pričakovanja uporabnikov o tem, kako bo storitev delovala. Ta strategija lahko zmanjša neutemeljene pritožbe proti lastniku storitve, kot je počasno delovanje. Brez izrecne SLO si uporabniki pogosto ustvarijo lastna pričakovanja o želeni uspešnosti, ki morda nimajo nobene zveze z mnenji ljudi, ki načrtujejo in upravljajo storitev. Ta situacija lahko privede do prenapihnjenih pričakovanj od storitve, ko uporabniki zmotno verjamejo, da bo storitev bolj dostopna, kot dejansko je, in povzroči nezaupanje, ko uporabniki verjamejo, da je sistem manj zanesljiv, kot je v resnici.
Dogovori
Sporazum o ravni storitev je izrecna ali implicitna pogodba z vašimi uporabniki, ki vključuje posledice izpolnjevanja (ali neizpolnjevanja) SLO, ki jih vsebujejo. Posledice je najlažje prepoznati, ko so finančne – popust ali globa –, lahko pa imajo tudi druge oblike. Enostaven način za pogovor o razlikah med SLO in SLA je, da se vprašate "kaj se zgodi, če SLO niso izpolnjeni?" Če ni jasnih posledic, skoraj zagotovo gledate na SLO.
SRE običajno ni vključen v ustvarjanje SLA, ker so SLA tesno povezani s poslovnimi odločitvami in odločitvami o izdelkih. SRE pa sodeluje pri pomoči pri blaženju posledic neuspelih SLO. Pomagajo lahko tudi pri določanju SLI: Očitno mora obstajati objektiven način za merjenje SLO v dogovoru, sicer bo prišlo do nesoglasja.
Google Iskanje je primer pomembne storitve, ki nima javne SLA: želimo, da vsi uporabljajo Iskanje čim bolj učinkovito, vendar nismo podpisali pogodbe s svetom. Še vedno pa obstajajo posledice, če iskanje ni na voljo – nedostopnost povzroči padec našega ugleda in zmanjšan prihodek od oglaševanja. Številne druge Googlove storitve, kot je Google for Work, imajo z uporabniki izrecne pogodbe o ravni storitev. Ne glede na to, ali ima določena storitev SLA, je pomembno definirati SLI in SLO ter ju uporabiti za upravljanje storitve.
Toliko teorije - zdaj pa na izkušnje.
Indikatorji v praksi
Glede na to, da smo ugotovili, da je pomembno izbrati ustrezne metrike za merjenje ravni storitev, kako zdaj veste, katere metrike so pomembne za storitev ali sistem?
Kaj skrbi vas in vaše uporabnike?
Ni vam treba uporabiti vsake metrike kot SLI, ki ji lahko sledite v sistemu za spremljanje; Razumevanje, kaj uporabniki želijo od sistema, vam bo pomagalo izbrati več meritev. Če izberete preveč indikatorjev, se težko osredotočite na pomembne indikatorje, medtem ko lahko z izbiro majhnega števila ostanejo veliki deli vašega sistema nenadzorovani. Običajno uporabljamo več ključnih indikatorjev za oceno in razumevanje zdravja sistema.
Storitve je na splošno mogoče razdeliti na več delov glede na SLI, ki so zanje pomembni:
- Prilagojeni sprednji sistemi, kot so iskalni vmesniki za storitev Shakespeare iz našega primera. Biti morajo na voljo, brez zakasnitev in imeti zadostno pasovno širino. V skladu s tem se lahko zastavijo vprašanja: ali lahko odgovorimo na zahtevo? Kako dolgo je trajal odgovor na zahtevo? Koliko zahtevkov je mogoče obdelati?
- Sistemi za shranjevanje. Cenijo nizko zakasnitev odziva, razpoložljivost in vzdržljivost. Sorodna vprašanja: Koliko časa traja branje ali pisanje podatkov? Ali lahko dostopamo do podatkov na zahtevo? Ali so podatki na voljo, ko jih potrebujemo? Glejte Poglavje 26 Integriteta podatkov: Kar berete, to pišete za podrobno razpravo o teh vprašanjih.
- Sistemi za velike količine podatkov, kot so cevovodi za obdelavo podatkov, se zanašajo na prepustnost in zakasnitev obdelave poizvedb. Povezana vprašanja: Koliko podatkov je obdelanih? Koliko časa traja, da podatki potujejo od prejema zahteve do izdaje odgovora? (Nekateri deli sistema imajo lahko tudi zamude v določenih fazah.)
Zbirka indikatorjev
Številni indikatorji ravni storitev se najbolj naravno zbirajo na strani strežnika z uporabo nadzornega sistema, kot je Borgmon (glejte spodaj). ) ali Prometheus, ali preprosto občasno analiziranje dnevnikov, pri čemer prepozna odgovore HTTP s statusom 500. Vendar bi morali biti nekateri sistemi opremljeni z zbiranjem meritev na strani odjemalca, saj lahko pomanjkanje spremljanja na strani odjemalca povzroči manjkajoče številne težave, ki vplivajo uporabnikov, vendar ne vplivajo na meritve na strani strežnika. Na primer, osredotočanje na zakasnitev odziva zaledja naše testne aplikacije za iskanje Shakespeare lahko povzroči zakasnitev na strani uporabnika zaradi težav z JavaScriptom: v tem primeru je boljša meritev merjenje, koliko časa potrebuje brskalnik, da obdela stran.
Združevanje
Zaradi preprostosti in enostavne uporabe pogosto združujemo neobdelane meritve. To je treba storiti previdno.
Nekatere meritve se zdijo preproste, na primer število zahtev na sekundo, vendar tudi ta navidezno enostavna meritev implicitno združuje podatke skozi čas. Ali je meritev prejeta posebej enkrat na sekundo ali je meritev povprečna glede na število zahtev na minuto? Slednja možnost lahko skrije veliko večje trenutno število zahtev, ki trajajo le nekaj sekund. Razmislite o sistemu, ki streže 200 zahtev na sekundo s sodimi številkami in 0 preostali čas. Konstanta v obliki povprečne vrednosti 100 zahtevkov na sekundo in dvakratna trenutna obremenitev nista ista stvar. Podobno se zdi povprečje zakasnitev poizvedb privlačno, vendar skriva pomembno podrobnost: možno je, da bo večina poizvedb hitrih, veliko pa bo poizvedb, ki bodo počasne.
Večino kazalnikov je bolje obravnavati kot distribucije kot povprečja. Na primer, za zakasnitev SLI bodo nekatere zahteve obdelane hitro, medtem ko bodo nekatere vedno trajale dlje, včasih veliko dlje. Preprosto povprečje lahko skrije te dolge zamude. Na sliki je prikazan primer: čeprav tipična zahteva traja približno 50 ms, da je vročena, je 5 % zahtev 20-krat počasnejših! Spremljanje in opozarjanje, ki temelji samo na povprečni zakasnitvi, ne kaže sprememb v vedenju čez dan, medtem ko so v resnici opazne spremembe v času obdelave nekaterih zahtev (najvišja vrstica).
50, 85, 95 in 99 percentilna sistemska zakasnitev. Os Y je v logaritemski obliki.
Uporaba percentilov za indikatorje vam omogoča, da vidite obliko porazdelitve in njene značilnosti: visoka raven percentila, kot je 99 ali 99,9, prikazuje najslabšo vrednost, medtem ko 50 percentil (znan tudi kot mediana) prikazuje najpogostejše stanje metrika. Večja kot je disperzija odzivnega časa, bolj dolgotrajne zahteve vplivajo na uporabniško izkušnjo. Učinek se poveča pri visoki obremenitvi in v prisotnosti čakalnih vrst. Raziskave uporabniške izkušnje so pokazale, da imajo ljudje na splošno raje počasnejši sistem z visoko varianco odzivnega časa, zato se nekatere ekipe SRE osredotočajo le na visoke percentile, na podlagi tega, da če je vedenje meritve pri 99,9 percentilu dobro, večina uporabnikov ne bo imela težav .
Opomba o statističnih napakah
Na splošno raje delamo s percentili kot s srednjo (aritmetično sredino) nabora vrednosti. To nam omogoča, da upoštevamo bolj razpršene vrednosti, ki imajo pogosto bistveno drugačne (in zanimivejše) značilnosti od povprečja. Zaradi umetne narave računalniških sistemov so vrednosti meritev pogosto popačene, na primer nobena zahteva ne more prejeti odgovora v manj kot 0 ms, časovna omejitev 1000 ms pa pomeni, da ne more biti uspešnih odgovorov z vrednostmi, višjimi kot časovna omejitev. Posledično ne moremo sprejeti, da sta lahko povprečje in mediana enaki ali blizu!
Brez predhodnega testiranja in razen če veljajo nekatere standardne predpostavke in približki, pazimo, da ne sklepamo, da so naši podatki normalno porazdeljeni. Če distribucija ni po pričakovanjih, postopek avtomatizacije, ki odpravi težavo (na primer, ko opazi odstopanja, znova zažene strežnik z visokimi zakasnitvami obdelave zahtev), to morda počne prepogosto ali premalo pogosto (oboje ni zelo dobro).
Standardizirajte kazalnike
Priporočamo standardizacijo splošnih značilnosti za SLI, da vam ne bo treba vsakič špekulirati o njih. Vsaka funkcija, ki ustreza standardnim vzorcem, je lahko izključena iz specifikacije posameznega SLI, na primer:
- Intervali združevanja: "v povprečju v 1 minuti"
- Območja združevanja: »Vsa opravila v gruči«
- Kako pogosto se izvajajo meritve: "Vsakih 10 sekund"
- Katere zahteve so vključene: "HTTP GET iz opravil spremljanja črne skrinjice"
- Kako se pridobijo podatki: "Zahvaljujoč našemu nadzoru, izmerjenemu na strežniku"
- Zakasnitev dostopa do podatkov: "Čas do zadnjega bajta"
Da prihranite trud, ustvarite niz predlog SLI za večkratno uporabo za vsako skupno metriko; prav tako vsem olajšajo razumevanje, kaj določen SLI pomeni.
Cilji v praksi
Začnite tako, da razmislite (ali ugotovite!), kaj zanima vaše uporabnike, ne pa o tem, kaj lahko merite. To, kar zanima vaše uporabnike, je pogosto težko ali nemogoče izmeriti, tako da se na koncu približate njihovim potrebam. Če pa samo začnete s tem, kar je enostavno izmeriti, boste na koncu dobili manj uporabne SLO. Posledično smo včasih ugotovili, da začetna opredelitev želenih ciljev in nato delo s specifičnimi kazalniki deluje bolje kot izbira kazalnikov in nato doseganje ciljev.
Določite cilje
Za največjo jasnost je treba opredeliti, kako se merijo SLO in pogoji, pod katerimi so veljavni. Na primer, lahko rečemo naslednje (druga vrstica je enaka prvi, vendar uporablja privzete nastavitve SLI):
- 99 % (v povprečju v 1 minuti) klicev Get RPC se bo končalo v manj kot 100 ms (merjeno na vseh zalednih strežnikih).
- 99 % klicev Get RPC bo končanih v manj kot 100 ms.
Če je oblika krivulj zmogljivosti pomembna, lahko določite več SLO:
- 90 % klicev Get RPC se zaključi v manj kot 1 ms.
- 99 % klicev Get RPC se zaključi v manj kot 10 ms.
- 99.9 % klicev Get RPC se zaključi v manj kot 100 ms.
Če vaši uporabniki ustvarjajo heterogene delovne obremenitve: množično obdelavo (za katero je pomembna prepustnost) in interaktivno obdelavo (za katero je pomembna zakasnitev), je morda smiselno določiti ločene cilje za vsak razred obremenitve:
- 95 % zahtev strank zahteva pretočnost. Nastavite število izvedenih klicev RPC <1 s.
- 99 % strank skrbi za zakasnitev. Nastavite število klicev RPC s prometom <1 KB in trajanjem <10 ms.
Nerealno in nezaželeno je vztrajati, da bodo SLO izpolnjeni 100 % časa: to lahko zmanjša hitrost uvajanja novih funkcionalnosti in uvajanja ter zahteva drage rešitve. Namesto tega je bolje dovoliti proračun za napake – odstotek dovoljenega izpada sistema – in spremljati to vrednost dnevno ali tedensko. Višje vodstvo bo morda želelo mesečne ali četrtletne ocene. (Proračun napake je preprosto SLO za primerjavo z drugim SLO.)
Odstotek kršitev SLO je mogoče primerjati s proračunom napak (glejte 3. poglavje in razdelek ), z vrednostjo razlike, ki se uporablja kot vhod v proces, ki se odloči, kdaj uvesti nove izdaje.
Izbira ciljnih vrednosti
Izbira načrtovalskih vrednosti (SLO) ni zgolj tehnična dejavnost zaradi proizvodnih in poslovnih interesov, ki se morajo odražati v izbranih SLI, SLO (in po možnosti SLA). Podobno bo morda treba izmenjati informacije v zvezi z vprašanji, povezanimi z osebjem, časom do trga, razpoložljivostjo opreme in financiranjem. SRE bi moral biti del tega pogovora in pomagati razumeti tveganja in izvedljivost različnih možnosti. Poiskali smo nekaj vprašanj, ki bi lahko pomagala zagotoviti bolj produktivno razpravo:
Ne izberite cilja na podlagi trenutne uspešnosti.
Medtem ko je razumevanje prednosti in omejitev sistema pomembno, vas prilagajanje meritev brez obrazložitve lahko prepreči pri vzdrževanju sistema: zahtevala bo junaška prizadevanja za doseganje ciljev, ki jih ni mogoče doseči brez znatnega preoblikovanja.
Naj bo preprosto
Zapleteni izračuni SLI lahko skrijejo spremembe v delovanju sistema in otežijo iskanje vzroka težave.
Izogibajte se absolutom
Medtem ko je skušnjava imeti sistem, ki lahko prenese neskončno naraščajočo obremenitev brez povečanja zakasnitve, je ta zahteva nerealna. Sistem, ki se približuje takšnim idealom, bo verjetno zahteval veliko časa za načrtovanje in izdelavo, drago bo za upravljanje in bo predober za pričakovanja uporabnikov, ki bi storili s čim manj.
Uporabite čim manj SLO
Izberite zadostno število SLO, da zagotovite dobro pokritost sistemskih atributov. Zaščitite SLO, ki jih izberete: če nikoli ne morete zmagati v sporu o prednostnih nalogah z navedbo določene SLO, verjetno ni vredno upoštevati tega SLO. Vendar pa niso vsi sistemski atributi primerni za SLO: težko je izračunati stopnjo navdušenja uporabnikov z uporabo SLO.
Ne lovi popolnosti
Sčasoma lahko definicije in cilje SLO vedno izboljšate, ko izveste več o obnašanju sistema pod obremenitvijo. Bolje je začeti z lebdečim ciljem, ki ga boste sčasoma izboljšali, kot izbrati prestrog cilj, ki ga je treba omiliti, ko ugotovite, da je nedosegljiv.
SLO so lahko in bi morali biti ključno gonilo pri določanju prednosti dela za SRE in razvijalce izdelkov, ker odražajo skrb za uporabnike. Dober SLO je koristno orodje za uveljavljanje za razvojno ekipo. Toda slabo zasnovana SLO lahko vodi v potratno delo, če se ekipa junaško trudi doseči preveč agresivno SLO, ali v slab izdelek, če je SLO prenizek. SLO je močan vzvod, uporabljajte ga pametno.
Nadzorujte svoje meritve
SLI in SLO sta ključna elementa za upravljanje sistemov:
- Spremljajte in merite sisteme SLI.
- Primerjajte SLI s SLO in se odločite, ali je potrebno ukrepanje.
- Če je potrebno ukrepanje, ugotovite, kaj se mora zgoditi, da dosežete cilj.
- Dokončajte to dejanje.
Na primer, če 2. korak pokaže, da se zahteva izteka in bo prekinilo SLO v nekaj urah, če ne storite ničesar, lahko 3. korak vključuje testiranje hipoteze, da so strežniki vezani na CPE in da bo dodajanje več strežnikov porazdelilo obremenitev. Brez SLO ne bi vedeli, ali (ali kdaj) ukrepati.
Nastavite SLO - potem bodo nastavljena pričakovanja uporabnikov
Objava SLO določa pričakovanja uporabnikov glede vedenja sistema. Uporabniki (in potencialni uporabniki) pogosto želijo vedeti, kaj lahko pričakujejo od storitve, da razumejo, ali je primerna za uporabo. Na primer, ljudje, ki želijo uporabljati spletno stran za skupno rabo fotografij, bi se morda želeli izogniti uporabi storitve, ki obljublja dolgoživost in nizke stroške v zameno za nekoliko nižjo razpoložljivost, čeprav bi bila ista storitev morda idealna za sistem za upravljanje arhivskih zapisov.
Če želite svojim uporabnikom postaviti realna pričakovanja, uporabite eno ali obe od naslednjih taktik:
- Ohranite mejo varnosti. Uporabite strožji notranji SLO od tistega, ki se oglašuje uporabnikom. To vam bo dalo priložnost, da se odzovete na težave, preden postanejo vidne navzven. Medpomnilnik SLO vam prav tako omogoča, da imate varnostno rezervo pri nameščanju izdaj, ki vplivajo na zmogljivost sistema, in zagotavlja, da je sistem enostavno vzdrževati, ne da bi morali uporabnike frustrirati z izpadi.
- Ne presezite pričakovanj uporabnikov. Uporabniki temeljijo na tem, kar ponujate, ne na tem, kar govorite. Če je dejanska zmogljivost vaše storitve veliko boljša od navedene SLO, se bodo uporabniki zanašali na trenutno zmogljivost. Prekomerni odvisnosti se lahko izognete tako, da namerno zaustavite sistem ali omejite delovanje pod majhnimi obremenitvami.
Razumevanje tega, kako dobro sistem izpolnjuje pričakovanja, pomaga pri odločitvi, ali vlagati v pospešitev sistema ter njegovo večjo dostopnost in odpornost. Druga možnost je, če storitev deluje predobro, nekaj časa zaposlenih nameniti drugim prednostnim nalogam, kot je odplačilo tehničnega dolga, dodajanje novih funkcij ali uvedba novih izdelkov.
Dogovori v praksi
Ustvarjanje SLA zahteva, da poslovne in pravne ekipe opredelijo posledice in kazni za njeno kršitev. Vloga SRE je, da jim pomaga razumeti verjetne izzive pri izpolnjevanju SLO, ki jih vsebuje SLA. Večina priporočil za ustvarjanje SLO velja tudi za SLA. Pametno je biti konzervativen pri tem, kar obljubljate uporabnikom, saj več kot imate, težje je spremeniti ali odstraniti pogodbe o ravni storitev, ki se zdijo nerazumne ali jih je težko izpolniti.
Hvala, ker ste prebrali prevod do konca. Naročite se na moj telegram kanal o spremljanju и .
Vir: www.habr.com