SRE (Site Reliability Engineering) është një qasje për të siguruar disponueshmërinë e projekteve në internet. Konsiderohet si një kornizë për DevOps dhe flet se si të arrihet sukses në aplikimin e praktikave të DevOps. Përkthimi në këtë artikull libra nga Google. Unë e përgatita vetë këtë përkthim dhe u mbështeta në përvojën time për të kuptuar proceset e monitorimit. Në kanalin e telegramit и Unë botova gjithashtu një përkthim të Kapitullit 6 të të njëjtit libër për qëllimet e nivelit të shërbimit.
Përkthim nga cat. Kënaquni duke lexuar!
Është e pamundur të menaxhosh një shërbim nëse nuk ka të kuptuar se cilët tregues kanë në të vërtetë rëndësi dhe si të maten dhe vlerësohen ata. Për këtë qëllim, ne përcaktojmë dhe ofrojmë një nivel të caktuar shërbimi për përdoruesit tanë, pavarësisht nëse ata përdorin një nga API-të tona të brendshme ose një produkt publik.
Ne përdorim intuitën, përvojën dhe kuptimin tonë të dëshirës së përdoruesve për të kuptuar Treguesit e Nivelit të Shërbimit (SLI), Objektivat e Nivelit të Shërbimit (SLO) dhe Marrëveshjet e Nivelit të Shërbimit (SLA). Këto dimensione përshkruajnë matjet kryesore që duam të monitorojmë dhe ndaj të cilave do të reagojmë nëse nuk mund të ofrojmë cilësinë e pritur të shërbimit. Në fund të fundit, zgjedhja e metrikës së duhur ndihmon në drejtimin e veprimeve të duhura nëse diçka shkon keq, dhe gjithashtu i jep ekipit SRE besim në shëndetin e shërbimit.
Ky kapitull përshkruan qasjen që përdorim për të luftuar problemet e modelimit metrikë, përzgjedhjes metrike dhe analizës metrike. Shumica e shpjegimit do të jetë pa shembuj, kështu që ne do të përdorim shërbimin e Shekspirit të përshkruar në shembullin e zbatimit të tij (kërkimi për veprat e Shekspirit) për të ilustruar pikat kryesore.
Terminologjia e nivelit të shërbimit
Shumë lexues janë të njohur me konceptin e SLA, por termat SLI dhe SLO meritojnë përkufizim të kujdesshëm sepse në përgjithësi termi SLA është i mbingarkuar dhe ka një sërë kuptimesh në varësi të kontekstit. Për qartësi, ne duam t'i ndajmë këto vlera.
Treguesit
SLI është një tregues i nivelit të shërbimit - një masë sasiore e përcaktuar me kujdes e një aspekti të nivelit të shërbimit të ofruar.
Për shumicën e shërbimeve, SLI kyç konsiderohet të jetë vonesa e kërkesës - sa kohë duhet për të kthyer një përgjigje ndaj një kërkese. SLI-të e tjera të zakonshme përfshijnë shkallën e gabimit, shpesh e shprehur si një pjesë e të gjitha kërkesave të marra, dhe xhiron e sistemit, zakonisht i matur në kërkesa për sekondë. Matjet shpesh grumbullohen: të dhënat e papërpunuara fillimisht mblidhen dhe më pas konvertohen në një normë ndryshimi, mesatare ose përqindje.
Idealisht, SLI mat drejtpërdrejt nivelin e interesit të shërbimit, por ndonjëherë vetëm një metrikë e lidhur është e disponueshme për matje, sepse ajo origjinale është e vështirë për t'u marrë ose interpretuar. Për shembull, vonesa nga ana e klientit është shpesh një metrikë më e përshtatshme, por ka raste kur vonesa mund të matet vetëm në server.
Një lloj tjetër SLI që është i rëndësishëm për SRE-të është disponueshmëria, ose pjesa e kohës gjatë së cilës mund të përdoret një shërbim. Shpesh përkufizohet si norma e kërkesave të suksesshme, e quajtur ndonjëherë rendiment. (Gjatë jetëgjatësisë - gjasat që të dhënat do të mbahen për një periudhë të gjatë kohore - është gjithashtu e rëndësishme për sistemet e ruajtjes së të dhënave.) Megjithëse disponueshmëria 100% nuk është e mundur, disponueshmëria afër 100% shpesh është e arritshme; vlerat e disponueshmërisë shprehen si numri i "nëntëve" » përqindja e disponueshmërisë. Për shembull, disponueshmëria 99% dhe 99,999% mund të etiketohen si "2 nëntë" dhe "5 nëntë". Objektivi aktual i deklaruar i disponueshmërisë i Google Compute Engine është "tre nëntë e gjysmë" ose 99,95%.
qëllimet
Një SLO është një objektiv i nivelit të shërbimit: një vlerë e synuar ose një gamë vlerash për një nivel shërbimi që matet nga SLI. Një vlerë normale për SLO është "SLI ≤ Target" ose "Limit Lower ≤ SLI ≤ Upper Limit". Për shembull, ne mund të vendosim që do t'i kthejmë rezultatet e kërkimit të Shekspirit "shpejt" duke vendosur SLO në një vonesë mesatare të pyetjes së kërkimit prej më pak se 100 milisekonda.
Zgjedhja e SLO-së së duhur është një proces kompleks. Së pari, nuk mund të zgjidhni gjithmonë një vlerë specifike. Për kërkesat e jashtme hyrëse HTTP në shërbimin tuaj, metrika Query Per Second (QPS) përcaktohet kryesisht nga dëshira e përdoruesve tuaj për të vizituar shërbimin tuaj dhe ju nuk mund të vendosni një SLO për këtë.
Nga ana tjetër, mund të thoni se dëshironi që vonesa mesatare për secilën kërkesë të jetë më pak se 100 milisekonda. Vendosja e një qëllimi të tillë mund t'ju detyrojë të shkruani frontin tuaj me vonesë të ulët ose të blini pajisje që ofrojnë një vonesë të tillë. (100 milisekonda është padyshim një numër arbitrar, por është më mirë të kemi numra edhe më të ulët të vonesës. Ka prova që sugjerojnë se shpejtësitë e shpejta janë më të mira se shpejtësitë e ngadalta, dhe se vonesa në përpunimin e kërkesave të përdoruesve mbi vlera të caktuara në fakt i detyron njerëzit të qëndrojnë larg nga shërbimi juaj.)
Përsëri, kjo është më e paqartë sesa mund të duket në shikim të parë: nuk duhet të përjashtoni plotësisht QPS nga llogaritja. Fakti është se QPS dhe vonesa janë të lidhura fort me njëra-tjetrën: QPS më e lartë shpesh çon në vonesa më të larta dhe shërbimet zakonisht pësojnë një rënie të mprehtë të performancës kur arrijnë një prag të caktuar ngarkese.
Përzgjedhja dhe publikimi i një SLO vendos pritshmëritë e përdoruesve për mënyrën se si do të funksionojë shërbimi. Kjo strategji mund të zvogëlojë ankesat e pabaza kundër pronarit të shërbimit, të tilla si performanca e ngadaltë. Pa një SLO të qartë, përdoruesit shpesh krijojnë pritshmëritë e tyre për performancën e dëshiruar, të cilat mund të mos kenë të bëjnë fare me opinionet e njerëzve që projektojnë dhe menaxhojnë shërbimin. Kjo situatë mund të çojë në pritje të fryra nga shërbimi, kur përdoruesit gabimisht besojnë se shërbimi do të jetë më i aksesueshëm se sa është në të vërtetë dhe të shkaktojë mosbesim kur përdoruesit besojnë se sistemi është më pak i besueshëm se sa është në të vërtetë.
Marrëveshjet
Një marrëveshje e nivelit të shërbimit është një kontratë e qartë ose e nënkuptuar me përdoruesit tuaj që përfshin pasojat e përmbushjes (ose mos përmbushjes) të SLO-ve që ato përmbajnë. Pasojat njihen më lehtë kur ato janë financiare - zbritje ose gjobë - por ato mund të marrin forma të tjera. Një mënyrë e thjeshtë për të folur për ndryshimin midis SLO-ve dhe SLA-ve është të pyesni "çfarë ndodh nëse SLO-të nuk përmbushen?" Nëse nuk ka pasoja të qarta, pothuajse me siguri po shikoni një SLO.
SRE zakonisht nuk përfshihet në krijimin e SLA-ve sepse SLA-të janë të lidhura ngushtë me vendimet e biznesit dhe produktit. SRE, megjithatë, është i përfshirë në ndihmën për të zbutur pasojat e SLO-ve të dështuara. Ato gjithashtu mund të ndihmojnë në përcaktimin e SLI: Natyrisht, duhet të ketë një mënyrë objektive për të matur SLO në marrëveshje ose do të ketë mosmarrëveshje.
Kërkimi i Google është një shembull i një shërbimi të rëndësishëm që nuk ka një SLA publike: ne duam që të gjithë të përdorin "Kërkimin" në mënyrë sa më efikase të jetë e mundur, por ne nuk kemi nënshkruar një kontratë me botën. Megjithatë, ka ende pasoja nëse kërkimi është i padisponueshëm - padisponueshmëria rezulton në rënie të reputacionit tonë si dhe reduktim të të ardhurave nga reklamat. Shumë shërbime të tjera të Google, si Google for Work, kanë marrëveshje eksplicite të nivelit të shërbimit me përdoruesit. Pavarësisht nëse një shërbim i caktuar ka një SLA, është e rëndësishme të përkufizoni SLI dhe SLO dhe t'i përdorni ato për të menaxhuar shërbimin.
Kaq shumë teori - tani për të përjetuar.
Treguesit në praktikë
Duke qenë se kemi arritur në përfundimin se është e rëndësishme të zgjidhen metrikat e duhura për të matur nivelin e shërbimit, si e dini tani se cilat metrika kanë rëndësi për një shërbim apo sistem?
Për çfarë kujdeseni ju dhe përdoruesit tuaj?
Ju nuk keni nevojë të përdorni çdo metrikë si një SLI që mund të gjurmoni në një sistem monitorimi; Të kuptuarit se çfarë duan përdoruesit nga një sistem do t'ju ndihmojë të zgjidhni disa metrika. Zgjedhja e shumë treguesve e bën të vështirë përqendrimin në tregues të rëndësishëm, ndërsa zgjedhja e një numri të vogël mund të lërë pjesë të mëdha të sistemit tuaj të pambikëqyrur. Zakonisht përdorim disa tregues kyç për të vlerësuar dhe kuptuar shëndetin e një sistemi.
Shërbimet në përgjithësi mund të ndahen në disa pjesë për sa i përket SLI që janë të rëndësishme për to:
- Sistemet e përparme të personalizuara, të tilla si ndërfaqet e kërkimit për shërbimin Shakespeare nga shembulli ynë. Ato duhet të jenë të disponueshme, të mos kenë vonesa dhe të kenë gjerësi bande të mjaftueshme. Prandaj, mund të bëhen pyetje: a mund t'i përgjigjemi kërkesës? Sa kohë u desh për t'iu përgjigjur kërkesës? Sa kërkesa mund të përpunohen?
- Sistemet e ruajtjes. Ata vlerësojnë vonesën e ulët të përgjigjes, disponueshmërinë dhe qëndrueshmërinë. Pyetje të ngjashme: Sa kohë duhet për të lexuar ose shkruar të dhëna? A mund t'i qasemi të dhënave sipas kërkesës? A janë të disponueshme të dhënat kur na duhen? Shih kapitullin 26 Integriteti i të dhënave: Ajo që lexoni është ajo që shkruani për një diskutim të hollësishëm të këtyre çështjeve.
- Sistemet e të dhënave të mëdha, siç janë tubacionet e përpunimit të të dhënave, mbështeten në vonesën e xhiros dhe të përpunimit të pyetjeve. Pyetje të ngjashme: Sa të dhëna përpunohen? Sa kohë duhet që të dhënat të kalojnë nga marrja e një kërkese deri në lëshimin e një përgjigje? (Disa pjesë të sistemit mund të kenë gjithashtu vonesa në faza të caktuara.)
Mbledhja e treguesve
Shumë tregues të nivelit të shërbimit mblidhen më natyrshëm në anën e serverit, duke përdorur një sistem monitorimi si Borgmon (shih më poshtë). ) ose Prometheus, ose thjesht duke analizuar periodikisht regjistrat, duke identifikuar përgjigjet HTTP me statusin 500. Megjithatë, disa sisteme duhet të pajisen me mbledhjen e matjeve nga ana e klientit, pasi mungesa e monitorimit nga ana e klientit mund të çojë në mungesën e një numri problemesh që ndikojnë përdoruesit, por nuk ndikojnë në matjet nga ana e serverit. Për shembull, fokusimi në vonesën e përgjigjes së fundit të aplikacionit tonë të testit të kërkimit të Shekspirit mund të rezultojë në vonesë nga ana e përdoruesit për shkak të problemeve me JavaScript: në këtë rast, matja e kohës që i duhet shfletuesit për të përpunuar faqen është një metrikë më e mirë.
Agregimi
Për thjeshtësi dhe lehtësi përdorimi, ne shpesh grumbullojmë matje të papërpunuara. Kjo duhet të bëhet me kujdes.
Disa metrika duken të thjeshta, si kërkesat për sekondë, por edhe kjo matje në dukje e drejtpërdrejtë në mënyrë implicite grumbullon të dhënat me kalimin e kohës. A merret matja në mënyrë specifike një herë në sekondë apo matja është mesatarisht mbi numrin e kërkesave në minutë? Opsioni i fundit mund të fshehë një numër shumë më të lartë të menjëhershëm kërkesash që zgjasin vetëm disa sekonda. Konsideroni një sistem që shërben 200 kërkesa në sekondë me numra çift dhe 0 pjesën tjetër të kohës. Një konstante në formën e një vlere mesatare prej 100 kërkesash në sekondë dhe dyfishi i ngarkesës së menjëhershme nuk janë e njëjta gjë. Në mënyrë të ngjashme, mesatarja e vonesave të pyetjeve mund të duket tërheqëse, por fsheh një detaj të rëndësishëm: është e mundur që shumica e pyetjeve të jenë të shpejta, por do të ketë shumë pyetje që janë të ngadalta.
Shumica e treguesve shihen më mirë si shpërndarje dhe jo si mesatare. Për shembull, për vonesën SLI, disa kërkesa do të përpunohen shpejt, ndërsa disa do të zgjasin gjithmonë më shumë, ndonjëherë shumë më shumë. Një mesatare e thjeshtë mund të fshehë këto vonesa të gjata. Figura tregon një shembull: megjithëse një kërkesë tipike kërkon afërsisht 50 ms për t'u shërbyer, 5% e kërkesave janë 20 herë më të ngadalta! Monitorimi dhe sinjalizimi i bazuar vetëm në vonesën mesatare nuk tregon ndryshime në sjellje gjatë ditës, kur në fakt ka ndryshime të dukshme në kohën e përpunimit të disa kërkesave (linja e sipërme).
Vonesa e sistemit 50, 85, 95 dhe 99 përqindësh. Boshti Y është në format logaritmik.
Përdorimi i përqindjeve për tregues ju lejon të shihni formën e shpërndarjes dhe karakteristikat e saj: një nivel i lartë përqindje, si 99 ose 99,9, tregon vlerën më të keqe, ndërsa përqindja 50 (e njohur edhe si mesatare) tregon gjendjen më të shpeshtë të metrikën. Sa më i madh të jetë shpërndarja e kohës së përgjigjes, aq më shumë kërkesat afatgjata ndikojnë në përvojën e përdoruesit. Efekti përmirësohet nën ngarkesë të lartë dhe në prani të radhëve. Hulumtimi i përvojës së përdoruesit ka treguar se njerëzit në përgjithësi preferojnë një sistem më të ngadaltë me variancë të lartë të kohës së përgjigjes, kështu që disa ekipe SRE fokusohen vetëm në rezultatet e përqindjes së lartë, mbi bazën se nëse sjellja e një metrike në përqindjen 99,9 është e mirë, shumica e përdoruesve nuk do të kenë probleme .
Shënim për gabimet statistikore
Ne përgjithësisht preferojmë të punojmë me përqindje në vend të mesatares (mesatarja aritmetike) e një grupi vlerash. Kjo na lejon të marrim parasysh vlera më të shpërndara, të cilat shpesh kanë karakteristika dukshëm të ndryshme (dhe më interesante) sesa mesatarja. Për shkak të natyrës artificiale të sistemeve kompjuterike, vlerat metrike shpesh anojnë, për shembull, asnjë kërkesë nuk mund të marrë një përgjigje në më pak se 0 ms, dhe një afat kohor prej 1000 ms do të thotë që nuk mund të ketë përgjigje të suksesshme me vlera më të mëdha. se koha e ndërprerjes. Si rezultat, ne nuk mund të pranojmë që mesatarja dhe mesatarja mund të jenë të njëjta ose afër njëra-tjetrës!
Pa testime paraprake dhe nëse nuk ekzistojnë disa supozime standarde dhe përafrime, ne jemi të kujdesshëm që të mos arrijmë në përfundimin se të dhënat tona shpërndahen normalisht. Nëse shpërndarja nuk është siç pritej, procesi i automatizimit që rregullon problemin (për shembull, kur sheh të dhëna të jashtme, rinis serverin me vonesa të larta të përpunimit të kërkesave) mund ta bëjë atë shumë shpesh ose jo mjaftueshëm (të dyja nuk janë shume mire).
Standardizimi i treguesve
Ne rekomandojmë standardizimin e karakteristikave të përgjithshme për SLI në mënyrë që të mos keni nevojë të spekuloni rreth tyre çdo herë. Çdo veçori që plotëson modelet standarde mund të përjashtohet nga specifikimi i një SLI individuale, për shembull:
- Intervalet e grumbullimit: "mesatarisht mbi 1 minutë"
- Fushat e grumbullimit: "Të gjitha detyrat në grup"
- Sa shpesh bëhen matjet: "Çdo 10 sekonda"
- Cilat kërkesa përfshihen: "HTTP GET nga punët e monitorimit të kutisë së zezë"
- Si merren të dhënat: "Falë monitorimit tonë të matur në server"
- Vonesa e aksesit të të dhënave: "Koha për bajtin e fundit"
Për të kursyer përpjekje, krijoni një grup modelesh SLI të ripërdorshme për çdo metrikë të zakonshme; ato gjithashtu e bëjnë më të lehtë për të gjithë të kuptojnë se çfarë do të thotë një SLI e caktuar.
Qëllimet në praktikë
Filloni duke menduar (ose duke zbuluar!) për atë që u intereson përdoruesve tuaj, jo për atë që mund të matni. Shpesh ajo që interesojnë përdoruesit tuaj është e vështirë ose e pamundur të matet, kështu që ju përfundoni duke u afruar më shumë me nevojat e tyre. Megjithatë, nëse thjesht filloni me atë që është e lehtë për t'u matur, do të përfundoni me SLO më pak të dobishme. Si rezultat, ndonjëherë kemi gjetur se fillimisht identifikimi i qëllimeve të dëshiruara dhe më pas puna me tregues të veçantë funksionon më mirë sesa zgjedhja e treguesve dhe më pas arritja e qëllimeve.
Përcaktoni qëllimet tuaja
Për qartësi maksimale, duhet të përcaktohet se si maten SLO dhe kushtet në të cilat ato janë të vlefshme. Për shembull, mund të themi si vijon (rreshti i dytë është i njëjtë me i pari, por përdor standardet SLI):
- 99% (mesatarisht mbi 1 minutë) e thirrjeve Get RPC do të përfundojnë në më pak se 100 ms (të matura në të gjithë serverët mbështetës).
- 99% e telefonatave Get RPC do të përfundojnë në më pak se 100 ms.
Nëse forma e kurbave të performancës është e rëndësishme, mund të specifikoni SLO të shumta:
- 90% e telefonatave Get RPC përfundojnë në më pak se 1 ms.
- 99% e telefonatave Get RPC përfundojnë në më pak se 10 ms.
- 99.9% e telefonatave Get RPC përfundojnë në më pak se 100 ms.
Nëse përdoruesit tuaj gjenerojnë ngarkesa heterogjene të punës: përpunimi me shumicë (për të cilin xhiroja është e rëndësishme) dhe përpunimi ndërveprues (për të cilin vonesa është e rëndësishme), mund të jetë e vlefshme të përcaktohen qëllime të veçanta për secilën klasë të ngarkesës:
- 95% e kërkesave të klientëve kërkojnë xhiro. Cakto numrin e thirrjeve RPC të ekzekutuara <1 s.
- 99% e klientëve kujdesen për vonesën. Cakto numrin e thirrjeve RPC me trafik <1 KB dhe ekzekutim <10 ms.
Është joreale dhe e padëshirueshme të këmbëngulësh që SLO-të të përmbushen 100% të kohës: kjo mund të zvogëlojë ritmin e prezantimit të funksionalitetit dhe vendosjes së re dhe të kërkojë zgjidhje të shtrenjta. Në vend të kësaj, është më mirë të lejohet një buxhet gabimi - përqindja e kohës së lejuar të ndërprerjes së sistemit - dhe të monitorohet kjo vlerë çdo ditë ose javore. Menaxhmenti i lartë mund të dëshirojë vlerësime mujore ose tremujore. (Buxheti i gabimit është thjesht një SLO për krahasim me një SLO tjetër.)
Përqindja e shkeljeve të SLO mund të krahasohet me buxhetin e gabimeve (shih Kapitullin 3 dhe seksionin ), me vlerën e diferencës që përdoret si hyrje në procesin që vendos se kur të vendosen lëshimet e reja.
Zgjedhja e vlerave të synuara
Përzgjedhja e vlerave të planifikimit (SLO) nuk është një aktivitet thjesht teknik për shkak të produktit dhe interesave të biznesit që duhet të pasqyrohen në SLI-të e zgjedhura, SLO-të (dhe ndoshta SLA-të). Në mënyrë të ngjashme, informacioni mund të ketë nevojë të shkëmbehet në lidhje me çështjet që lidhen me personelin, kohën në treg, disponueshmërinë e pajisjeve dhe financimin. SRE duhet të jetë pjesë e kësaj bisede dhe të ndihmojë në kuptimin e rreziqeve dhe qëndrueshmërisë së opsioneve të ndryshme. Ne kemi dalë me disa pyetje që mund të ndihmojnë në sigurimin e një diskutimi më produktiv:
Mos zgjidhni një objektiv bazuar në performancën aktuale.
Ndërsa të kuptuarit e pikave të forta dhe kufijve të një sistemi është i rëndësishëm, përshtatja e metrikës pa arsyetim mund t'ju bllokojë nga mbajtja e sistemit: do të kërkojë përpjekje heroike për të arritur qëllime që nuk mund të arrihen pa ridizajnim domethënës.
Merre me buzeqeshje
Llogaritjet komplekse të SLI mund të fshehin ndryshimet në performancën e sistemit dhe ta bëjnë më të vështirë gjetjen e shkakut të problemit.
Shmangni absolutet
Ndërsa është joshëse të kesh një sistem që mund të përballojë një ngarkesë në rritje të pacaktuar pa rritur vonesën, kjo kërkesë është joreale. Një sistem që i afrohet idealeve të tilla ka të ngjarë të kërkojë shumë kohë për t'u projektuar dhe ndërtuar, do të jetë i shtrenjtë për t'u përdorur dhe do të jetë shumë i mirë për pritshmëritë e përdoruesve që do të bënin me asgjë më pak.
Përdorni sa më pak SLO të jetë e mundur
Zgjidhni një numër të mjaftueshëm SLO për të siguruar mbulim të mirë të atributeve të sistemit. Mbroni SLO-të që zgjidhni: Nëse nuk mund të fitoni kurrë një argument për prioritetet duke specifikuar një SLO specifike, ndoshta nuk ia vlen ta konsideroni atë SLO. Megjithatë, jo të gjitha atributet e sistemit janë të përshtatshme për SLO: është e vështirë të llogaritet niveli i kënaqësisë së përdoruesit duke përdorur SLO.
Mos e ndiqni përsosmërinë
Gjithmonë mund t'i përmirësoni përkufizimet dhe qëllimet e SLO-ve me kalimin e kohës ndërsa mësoni më shumë rreth sjelljes së sistemit nën ngarkesë. Është më mirë të filloni me një qëllim lundrues që do ta përpunoni me kalimin e kohës sesa të zgjidhni një objektiv tepër të rreptë që duhet të relaksoheni kur e shihni se është i paarritshëm.
SLO-të mund dhe duhet të jenë një shtytës kryesor në prioritizimin e punës për SRE-të dhe zhvilluesit e produkteve, sepse ato pasqyrojnë një shqetësim për përdoruesit. Një SLO e mirë është një mjet i dobishëm zbatimi për një ekip zhvillimi. Por një SLO e projektuar keq mund të çojë në punë të kota nëse ekipi bën përpjekje heroike për të arritur një SLO tepër agresive, ose një produkt të dobët nëse SLO është shumë i ulët. SLO është një levë e fuqishme, përdorni atë me mençuri.
Kontrolloni matjet tuaja
SLI dhe SLO janë elementë kyç që përdoren për të menaxhuar sistemet:
- Monitoroni dhe matni sistemet SLI.
- Krahasoni SLI me SLO dhe vendosni nëse nevojitet veprim.
- Nëse kërkohet veprim, kuptoni se çfarë duhet të ndodhë për të arritur qëllimin.
- Plotësoni këtë veprim.
Për shembull, nëse hapi 2 tregon se kërkesa po përfundon dhe do të prishë SLO në disa orë nëse nuk bëhet asgjë, hapi 3 mund të përfshijë testimin e hipotezës se serverët janë të lidhur me CPU dhe shtimi i më shumë serverëve do të shpërndajë ngarkesën. Pa një SLO, nuk do të dinit nëse (ose kur) të ndërmerrni veprime.
Set SLO - atëherë do të vendosen pritjet e përdoruesit
Publikimi i një SLO vendos pritshmëritë e përdoruesve për sjelljen e sistemit. Përdoruesit (dhe përdoruesit e mundshëm) shpesh duan të dinë se çfarë të presin nga një shërbim për të kuptuar nëse ai është i përshtatshëm për përdorim. Për shembull, njerëzit që dëshirojnë të përdorin një faqe interneti për ndarjen e fotografive mund të dëshirojnë të shmangin përdorimin e një shërbimi që premton jetëgjatësi dhe kosto të ulët në këmbim të disponueshmërisë pak më pak, edhe pse i njëjti shërbim mund të jetë ideal për një sistem të menaxhimit të të dhënave të arkivave.
Për të vendosur pritshmëri realiste për përdoruesit tuaj, përdorni një ose të dyja taktikat e mëposhtme:
- Mbani një kufi sigurie. Përdorni një SLO të brendshme më të rreptë sesa ajo që u reklamohet përdoruesve. Kjo do t'ju japë mundësinë për të reaguar ndaj problemeve përpara se ato të bëhen të dukshme nga jashtë. Buferi SLO ju lejon gjithashtu të keni një diferencë sigurie kur instaloni versione që ndikojnë në performancën e sistemit dhe sigurojnë që sistemi të jetë i lehtë për t'u mirëmbajtur pa pasur nevojë të irritoni përdoruesit me kohën e ndërprerjes.
- Mos i tejkaloni pritjet e përdoruesve. Përdoruesit bazohen në atë që ofroni, jo në atë që thoni. Nëse performanca aktuale e shërbimit tuaj është shumë më e mirë se SLO e deklaruar, përdoruesit do të mbështeten në performancën aktuale. Mund të shmangni varësinë e tepërt duke mbyllur qëllimisht sistemin ose duke kufizuar performancën nën ngarkesa të lehta.
Të kuptuarit se sa mirë një sistem i përmbush pritshmëritë ndihmon në vendosjen nëse duhet investuar në përshpejtimin e sistemit dhe për ta bërë atë më të aksesueshëm dhe elastik. Përndryshe, nëse një shërbim po funksionon shumë mirë, një pjesë e kohës së stafit duhet të shpenzohet për prioritete të tjera, të tilla si shlyerja e borxhit teknik, shtimi i veçorive të reja ose prezantimi i produkteve të reja.
Marrëveshjet në praktikë
Krijimi i një SLA kërkon që ekipet e biznesit dhe ligjore të përcaktojnë pasojat dhe gjobat për shkeljen e tij. Roli i SRE-së është t'i ndihmojë ata të kuptojnë sfidat e mundshme në përmbushjen e SLO-ve të përfshira në SLA. Shumica e rekomandimeve për krijimin e SLO-ve vlejnë edhe për SLA-të. Është e mençur të jesh konservator në atë që u premton përdoruesve, sepse sa më shumë të kesh, aq më e vështirë është të ndryshosh ose heqësh SLA-të që duken të paarsyeshme ose të vështira për t'u përmbushur.
Faleminderit që lexuat përkthimin deri në fund. Regjistrohu në kanalin tim të telegramit për monitorimin и .
Burimi: www.habr.com