SRE (Site Reliability Engineering) yra būdas padaryti žiniatinklio projektus prieinamus. Tai laikoma „DevOps“ sistema ir nurodo, kaip sėkmingai taikyti „DevOps“ praktiką. Šis straipsnis verčiamas knygos iš Google. Šį vertimą rengiau pati ir, suprasdama stebėjimo procesus, rėmiausi savo patirtimi. Telegramos kanale и Taip pat išleidau tos pačios knygos 6 skyriaus apie paslaugų lygio tikslus vertimą.
Katės vertimas. Mėgaukitės skaitymu!
Neįmanoma valdyti paslaugos, jei nėra supratimo, kokie rodikliai iš tikrųjų yra svarbūs ir kaip juos išmatuoti bei įvertinti. Šiuo tikslu apibrėžiame ir teikiame tam tikrą paslaugų lygį savo vartotojams, neatsižvelgiant į tai, ar jie naudoja vieną iš mūsų vidinių API, ar viešąjį produktą.
Mes naudojame savo intuiciją, patirtį ir supratimą apie vartotojų norą suprasti paslaugų lygio rodiklius (SLI), paslaugų lygio tikslus (SLO) ir paslaugų lygio sutartis (SLA). Šie matmenys apibūdina pagrindines metrikas, kurias norime stebėti ir į kurias reaguosime, jei negalėsime suteikti laukiamos paslaugos kokybės. Galiausiai, tinkamos metrikos parinkimas padeda nukreipti teisingus veiksmus, jei kas nors nepavyksta, ir suteikia SRE komandai pasitikėjimo paslaugos būkle.
Šiame skyriuje aprašomas metodas, kurį naudojame kovojant su metrinio modeliavimo, metrinės atrankos ir metrinės analizės problemomis. Didžioji dalis paaiškinimų bus be pavyzdžių, todėl pagrindiniams dalykams iliustruoti naudosime jos įgyvendinimo pavyzdyje aprašytą Šekspyro paslaugą (Šekspyro kūrinių paieška).
Paslaugų lygio terminija
Daugelis skaitytojų tikriausiai yra susipažinę su SLA sąvoka, tačiau terminai SLI ir SLO nusipelno kruopštaus apibrėžimo, nes paprastai SLA terminas yra perkrautas ir turi daug reikšmių, priklausomai nuo konteksto. Aiškumo dėlei norime šias vertybes atskirti.
Rodikliai
SLI yra paslaugų lygio rodiklis – kruopščiai apibrėžtas kiekybinis vieno teikiamos paslaugos lygio aspekto matas.
Daugumos paslaugų raktas SLI laikomas užklausos delsa – kiek laiko užtrunka atsakymo į užklausą grąžinimas. Kiti įprasti SLI apima klaidų lygį, dažnai išreiškiamą visų gautų užklausų dalimi, ir sistemos pralaidumą, paprastai matuojamą užklausomis per sekundę. Matavimai dažnai yra apibendrinami: iš pradžių renkami neapdoroti duomenys, o paskui konvertuojami į kitimo greitį, vidurkį arba procentilį.
Idealiu atveju SLI tiesiogiai matuoja dominančios paslaugos lygį, tačiau kartais galima išmatuoti tik susijusią metriką, nes originalią sunku gauti ar interpretuoti. Pavyzdžiui, kliento delsa dažnai yra tinkamesnė metrika, tačiau kartais delsą galima išmatuoti tik serveryje.
Kitas SLI tipas, svarbus SRE, yra pasiekiamumas arba laiko dalis, per kurią galima naudotis paslauga. Dažnai apibrėžiamas kaip sėkmingų užklausų rodiklis, kartais vadinamas pajamingumu. (Visą laiką – tikimybė, kad duomenys bus saugomi ilgą laiką – taip pat svarbu duomenų saugojimo sistemoms.) Nors 100 % pasiekiamumas neįmanomas, dažnai pasiekiamas beveik 100 %; pasiekiamumo reikšmės išreiškiamos kaip „devynių“ » prieinamumo procentas. Pavyzdžiui, 99 % ir 99,999 % pasiekiamumas gali būti pažymėtas kaip "2 devynios" ir "5 devynios". Dabartinis „Google Compute Engine“ pasiekiamumo tikslas yra „trys su puse devynerių“ arba 99,95%.
Tikslai
SLO yra paslaugos lygio tikslas: paslaugų lygio tikslinė vertė arba verčių diapazonas, kurį matuoja SLI. Įprasta SLO reikšmė yra „SLI ≤ Target“ arba „ Lower Limit ≤ SLI ≤ Upper Limit“. Pavyzdžiui, galime nuspręsti, kad Shakespeare paieškos rezultatus pateiksime „greitai“, nustatydami SLO į vidutinę paieškos užklausos delsą, mažesnę nei 100 milisekundžių.
Tinkamo SLO pasirinkimas yra sudėtingas procesas. Pirma, ne visada galite pasirinkti konkrečią vertę. Išorinių gaunamų HTTP užklausų į jūsų paslaugą atveju užklausos per sekundę (QPS) metriką pirmiausia lemia jūsų vartotojų noras apsilankyti jūsų paslaugoje, todėl negalite tam nustatyti SLO.
Kita vertus, galite pasakyti, kad norite, kad vidutinė kiekvienos užklausos delsa būtų mažesnė nei 100 milisekundžių. Nustačius tokį tikslą, gali būti, kad turėsite parašyti savo sąsają su mažu delsos laiku arba įsigyti įrangą, kuri užtikrina tokį delsą. (100 milisekundžių akivaizdžiai yra savavališkas skaičius, bet geriau turėti dar mažesnius delsos skaičius. Yra įrodymų, kad greitas greitis yra geresnis už lėtą greitį ir kad delsa apdorojant vartotojų užklausas, viršijančias tam tikras vertes, iš tikrųjų verčia žmones nesitraukti iš jūsų tarnybos.)
Vėlgi, tai labiau dviprasmiška, nei gali pasirodyti iš pirmo žvilgsnio: neturėtumėte visiškai neįtraukti QPS į skaičiavimą. Faktas yra tai, kad QPS ir delsa yra glaudžiai susiję vienas su kitu: didesnis QPS dažnai lemia didesnį delsą, o paslaugų našumas paprastai smarkiai sumažėja, kai pasiekia tam tikrą apkrovos slenkstį.
SLO pasirinkimas ir paskelbimas nustato vartotojo lūkesčius, kaip paslauga veiks. Ši strategija gali sumažinti nepagrįstų skundų prieš paslaugos savininką, pvz., lėto veikimo, skaičių. Neturėdami aiškaus SLO, vartotojai dažnai sukuria savo lūkesčius dėl pageidaujamo našumo, o tai gali turėti nieko bendro su paslaugą kuriančių ir valdančių žmonių nuomone. Tokia situacija gali sukelti išpūstus lūkesčius iš paslaugos, kai vartotojai klaidingai mano, kad paslauga bus prieinamesnė, nei yra iš tikrųjų, ir sukelti nepasitikėjimą, kai vartotojai mano, kad sistema yra mažiau patikima, nei yra iš tikrųjų.
Susitarimai
Paslaugos lygio sutartis yra aiški arba numanoma sutartis su naudotojais, apimanti jose pateiktų SLO įvykdymo (arba nevykdymo) pasekmes. Pasekmes lengviausia atpažinti, kai jos yra finansinės – nuolaida ar bauda – tačiau jos gali būti ir kitokios formos. Paprastas būdas kalbėti apie skirtumą tarp SLO ir SLA yra paklausti „kas atsitiks, jei SLO nesilaikoma? Jei nėra aiškių pasekmių, beveik neabejotinai žiūrite į SLO.
SRE paprastai nedalyvauja kuriant SLA, nes SLA yra glaudžiai susiję su verslo ir produktų sprendimais. Tačiau SRE dalyvauja padedant sušvelninti nesėkmingų SLO pasekmes. Jie taip pat gali padėti nustatyti SLI: Akivaizdu, kad susitarime turi būti objektyvus būdas išmatuoti SLO, kitaip kils nesutarimų.
„Google“ paieška yra svarbios paslaugos, kuri neturi viešo SLA, pavyzdys: norime, kad visi naudotųsi Paieška kuo efektyviau, tačiau nesame pasirašę sutarties su pasauliu. Tačiau vis tiek yra pasekmių, jei paieška nepasiekiama – nepasiekiamumas sumažina mūsų reputaciją ir pajamas iš reklamos. Daugelis kitų „Google“ paslaugų, pvz., „Google for Work“, turi aiškias paslaugų lygio sutartis su naudotojais. Nepriklausomai nuo to, ar tam tikra paslauga turi SLA, svarbu apibrėžti SLI ir SLO ir naudoti juos paslaugai valdyti.
Tiek teorijos – dabar patirti.
Rodikliai praktikoje
Atsižvelgdami į tai, kad padarėme išvadą, kad paslaugų lygiui matuoti svarbu pasirinkti tinkamus rodiklius, kaip dabar žinoti, kurie rodikliai yra svarbūs paslaugai ar sistemai?
Kas jums ir jūsų vartotojams rūpi?
Nereikia naudoti kiekvienos metrikos kaip SLI, kurią galite stebėti stebėjimo sistemoje; Suprasdami, ko vartotojai nori iš sistemos, galėsite pasirinkti keletą metrikų. Pasirinkus per daug indikatorių sunku sutelkti dėmesį į svarbius rodiklius, o pasirinkus nedidelį skaičių gali likti be priežiūros didelės sistemos dalys. Paprastai mes naudojame kelis pagrindinius rodiklius, kad įvertintume ir suprastume sistemos būklę.
Paprastai paslaugas galima suskirstyti į kelias dalis, susijusias su joms aktualiomis SLI:
- Tinkintos priekinės sistemos, pvz., Šekspyro paslaugos paieškos sąsajos pagal mūsų pavyzdį. Jie turi būti prieinami, nedelsti ir turėti pakankamai pralaidumo. Atitinkamai galima užduoti klausimus: ar galime atsakyti į užklausą? Kiek laiko užtruko atsakyti į prašymą? Kiek užklausų galima apdoroti?
- Sandėliavimo sistemos. Jie vertina mažą atsako delsą, prieinamumą ir ilgaamžiškumą. Susiję klausimai: kiek laiko užtrunka nuskaityti arba įrašyti duomenis? Ar galime prieiti prie duomenų pateikę prašymą? Ar duomenys prieinami, kai mums jų reikia? Norėdami išsamiai aptarti šias problemas, žr. 26 skyrių Duomenų vientisumas: ką skaitote, tą ir rašote.
- Didelės duomenų sistemos, tokios kaip duomenų apdorojimo vamzdynai, priklauso nuo pralaidumo ir užklausų apdorojimo delsos. Susiję klausimai: kiek duomenų apdorojama? Kiek laiko užtrunka, kol duomenys keliauja nuo užklausos gavimo iki atsakymo? (Kai kurios sistemos dalys tam tikrais etapais taip pat gali vėluoti.)
Rodiklių rinkimas
Daugelis paslaugų lygio rodiklių natūraliai renkami serverio pusėje, naudojant stebėjimo sistemą, tokią kaip Borgmon (žr. toliau). ) arba Prometheus, arba tiesiog periodiškai analizuoti žurnalus, identifikuoti HTTP atsakymus, kurių būsena yra 500. Tačiau kai kuriose sistemose turėtų būti įrengtas kliento pusės metrikų rinkimas, nes dėl kliento pusės stebėjimo trūkumo gali trūkti problemų, kurios turi įtakos vartotojų, tačiau tai neturi įtakos serverio metrikai. Pavyzdžiui, sutelkus dėmesį į mūsų Šekspyro paieškos bandomosios programos užpakalinio atsako delsą, naudotojo pusėje gali atsirasti delsos dėl „JavaScript“ problemų: šiuo atveju geresnė metrika yra įvertinti, kiek laiko naršyklė apdoroja puslapį.
Agregacija
Siekdami paprastumo ir naudojimo patogumo, dažnai apibendriname neapdorotus matavimus. Tai turi būti padaryta atsargiai.
Kai kurios metrikos atrodo paprastos, pavyzdžiui, užklausos per sekundę, tačiau net ir šis akivaizdžiai paprastas matavimas netiesiogiai apibendrina duomenis laikui bėgant. Ar matavimas gaunamas konkrečiai kartą per sekundę, ar matavimo vidurkis pagal užklausų skaičių per minutę? Pastaroji parinktis gali paslėpti daug didesnį momentinį užklausų skaičių, kuris trunka tik kelias sekundes. Apsvarstykite sistemą, kuri aptarnauja 200 užklausų per sekundę su lyginiais skaičiais ir 0 likusį laiką. Konstanta, kuri yra vidutinė 100 užklausų per sekundę vertė ir dvigubai didesnė momentinė apkrova, nėra tas pats. Panašiai ir užklausų delsos vidurkio nustatymas gali atrodyti patraukliai, tačiau slepia svarbią detalę: gali būti, kad dauguma užklausų bus greitos, tačiau bus daug užklausų, kurios bus lėtos.
Daugumą rodiklių geriau laikyti pasiskirstymu, o ne vidurkiais. Pavyzdžiui, dėl SLI delsos kai kurios užklausos bus apdorojamos greitai, o kai kurios visada užtruks ilgiau, kartais daug ilgiau. Paprastas vidurkis gali paslėpti šiuos ilgus vėlavimus. Paveikslėlyje parodytas pavyzdys: nors įprastai užklausai pateikti reikia maždaug 50 ms, 5 % užklausų yra 20 kartų lėtesnės! Stebėjimas ir įspėjimai, pagrįsti tik vidutine delsa, nerodo elgesio pokyčių per dieną, nors iš tikrųjų pastebimi kai kurių užklausų apdorojimo laiko pasikeitimai (viršutinė eilutė).
50, 85, 95 ir 99 procentilių sistemos delsa. Y ašis yra logaritminio formato.
Rodiklių procentilių naudojimas leidžia matyti pasiskirstymo formą ir jo charakteristikas: aukštas procentilio lygis, pvz., 99 arba 99,9, rodo blogiausią reikšmę, o 50 procentilių (taip pat žinomas kaip mediana) – dažniausiai pasitaikanti būsena. metriką. Kuo didesnė atsako laiko sklaida, tuo daugiau ilgalaikių užklausų paveiks vartotojo patirtį. Efektas sustiprėja esant didelei apkrovai ir esant eilėms. Naudotojų patirties tyrimai parodė, kad žmonės dažniausiai renkasi lėtesnę sistemą su dideliu atsako laiko dispersija, todėl kai kurios SRE komandos sutelkia dėmesį tik į aukštus procentilių balus, remdamosi tuo, kad jei 99,9 procentilio metrikos elgsena yra gera, dauguma vartotojų nepatirs problemų. .
Pastaba apie statistines klaidas
Mes paprastai norime dirbti su procentiliais, o ne su reikšmių rinkinio vidurkiu (aritmetiniu vidurkiu). Tai leidžia atsižvelgti į labiau išsklaidytas reikšmes, kurios dažnai turi žymiai kitokias (ir įdomesnes) charakteristikas nei vidutinės. Dėl dirbtinio skaičiavimo sistemų pobūdžio metrinės reikšmės dažnai yra iškreiptos, todėl jokia užklausa negali gauti atsakymo greičiau nei per 0 ms, o 1000 ms skirtasis laikas reiškia, kad negali būti sėkmingų atsakymų, kurių reikšmės yra didesnės nei skirtasis laikas. Dėl to negalime sutikti, kad vidurkis ir mediana gali būti vienodi arba artimi vienas kitam!
Neatlikę išankstinių bandymų ir nebent tam tikros standartinės prielaidos ir aproksimacijos pasitvirtintų, stengiamės nepadaryti išvados, kad mūsų duomenys yra įprastai paskirstyti. Jei paskirstymas nėra toks, kokio tikėtasi, automatizavimo procesas, kuris išsprendžia problemą (pavyzdžiui, kai mato nukrypimus, jis iš naujo paleidžia serverį su dideliu užklausų apdorojimo delsimu), gali tai daryti per dažnai arba nepakankamai dažnai (abu nėra labai gerai).
Standartizuoti rodiklius
Rekomenduojame standartizuoti bendras SLI charakteristikas, kad jums nereikėtų kiekvieną kartą apie jas spėlioti. Bet kuri standartinius modelius atitinkanti funkcija gali būti neįtraukta į atskiro SLI specifikaciją, pavyzdžiui:
- Sumavimo intervalai: „vidutiniškai daugiau nei 1 minutę“
- Agregavimo sritys: „Visos klasteryje esančios užduotys“
- Kaip dažnai atliekami matavimai: „Kas 10 sekundžių“
- Kokios užklausos įtrauktos: „HTTP GET iš juodosios dėžės stebėjimo darbų“
- Kaip gaunami duomenys: "Dėka mūsų stebėjimo, išmatuoto serveryje"
- Prieigos prie duomenų delsa: „Laikas iki paskutinio baito“
Norėdami sutaupyti pastangų, kiekvienai bendrai metrikai sukurkite daugkartinio naudojimo SLI šablonų rinkinį; jie taip pat padeda kiekvienam lengviau suprasti, ką reiškia tam tikras SLI.
Tikslai praktikoje
Pradėkite galvodami (arba išsiaiškindami!), kas rūpi jūsų naudotojams, o ne tai, ką galite įvertinti. Dažnai sunku arba neįmanoma įvertinti tai, kas rūpi jūsų naudotojams, todėl jūs priartėsite prie jų poreikių. Tačiau jei tik pradėsite nuo to, ką lengva išmatuoti, gausite mažiau naudingų SLO. Todėl kartais pastebėjome, kad iš pradžių nustatyti norimus tikslus, o vėliau dirbti su konkrečiais rodikliais veikia geriau, nei pasirinkti rodiklius ir tada pasiekti tikslus.
Apibrėžkite tikslus
Siekiant kuo didesnio aiškumo, reikėtų apibrėžti, kaip SLO matuojami ir kokiomis sąlygomis jie galioja. Pavyzdžiui, galime pasakyti taip (antroji eilutė yra tokia pati kaip pirmoji, bet naudoja SLI numatytuosius nustatymus):
- 99 % (vidutiniškai daugiau nei 1 minutę) gautų RPC skambučių bus užbaigti per mažiau nei 100 ms (matuojant visuose vidiniuose serveriuose).
- 99 % Gauti RPC skambučių bus užbaigti greičiau nei per 100 ms.
Jei našumo kreivių forma yra svarbi, galite nurodyti kelis SLO:
- 90 % gauti RPC skambučių užbaigiami greičiau nei per 1 ms.
- 99 % gauti RPC skambučių užbaigiami greičiau nei per 10 ms.
- 99.9 % gauti RPC skambučių užbaigiami greičiau nei per 100 ms.
Jei jūsų vartotojai generuoja nevienalyčius darbo krūvius: masinį apdorojimą (kuriam svarbus pralaidumas) ir interaktyvų apdorojimą (kuriam svarbi delsa), gali būti naudinga apibrėžti atskirus kiekvienos apkrovos klasės tikslus:
- 95% klientų užklausų reikalauja pralaidumo. Nustatykite įvykdytų RPC skambučių skaičių <1 s.
- 99% klientų rūpi delsa. Nustatykite RPC skambučių, kurių srautas mažesnis nei 1 KB ir veikia <10 ms, skaičių.
Nerealu ir nepageidautina reikalauti, kad SLO būtų įvykdyti 100 % laiko: tai gali sumažinti naujų funkcijų diegimo ir diegimo tempą ir reikalauti brangių sprendimų. Vietoj to geriau leisti klaidų biudžetą – leidžiamą sistemos prastovų procentą – ir stebėti šią vertę kasdien arba kas savaitę. Vyresnioji vadovybė gali norėti kas mėnesį arba kas ketvirtį atlikti vertinimus. (Klaidos biudžetas yra tiesiog SLO, palyginti su kitu SLO.)
SLO pažeidimų procentą galima palyginti su klaidų biudžetu (žr. 3 skyrių ir skyrių ), skirtumo reikšmė naudojama kaip įvestis procesui, kuris nusprendžia, kada įdiegti naujus leidimus.
Tikslinių verčių pasirinkimas
Planavimo verčių (SLO) parinkimas nėra vien techninė veikla dėl produkto ir verslo interesų, kurie turi atsispindėti pasirinktuose SLI, SLO (ir galbūt SLA). Taip pat gali tekti keistis informacija apie klausimus, susijusius su personalu, laiku iki rinkos, įrangos prieinamumu ir finansavimu. SRE turėtų būti šio pokalbio dalis ir padėti suprasti įvairių variantų riziką ir perspektyvumą. Pateikėme keletą klausimų, kurie gali padėti užtikrinti produktyvesnę diskusiją:
Nesirinkite tikslo pagal dabartinį našumą.
Nors svarbu suprasti sistemos stipriąsias ir ribas, metrikų pritaikymas be samprotavimų gali trukdyti išlaikyti sistemą: reikės didvyriškų pastangų, kad būtų pasiekti tikslai, kurių neįmanoma pasiekti be reikšmingo pertvarkymo.
Daryk paprastai
Sudėtingi SLI skaičiavimai gali paslėpti sistemos veikimo pokyčius ir apsunkinti problemos priežasties paiešką.
Venkite absoliučių
Nors ir kyla pagunda turėti sistemą, kuri galėtų atlaikyti neribotą laiką augančią apkrovą nepadidindama delsos, šis reikalavimas yra nerealus. Sistemai, kuri artėja prie tokių idealų, greičiausiai prireiks daug laiko suprojektuoti ir sukurti, ji bus brangi eksploatuoti ir bus per gera, kad atitiktų vartotojų, kurie norėtų padaryti ką nors mažiau, lūkesčius.
Naudokite kuo mažiau SLO
Pasirinkite pakankamą SLO skaičių, kad užtikrintumėte gerą sistemos atributų aprėptį. Apsaugokite pasirinktus SLO: jei niekada negalite laimėti ginčo dėl prioritetų nurodydami konkretų SLO, tikriausiai neverta svarstyti to SLO. Tačiau ne visi sistemos atributai yra pritaikyti SLO: naudojant SLO sunku apskaičiuoti vartotojo malonumo lygį.
Nesivaikykite tobulumo
Visada galite patikslinti SLO apibrėžimus ir tikslus laikui bėgant, kai sužinosite daugiau apie sistemos elgseną apkrovos metu. Geriau pradėti nuo slankiojo tikslo, kurį laikui bėgant patobulinsite, nei pasirinkti pernelyg griežtą tikslą, kurį reikia atsipalaiduoti, kai manote, kad jis nepasiekiamas.
SLO gali ir turėtų būti pagrindinis veiksnys nustatant SRE ir produktų kūrėjų darbo prioritetus, nes jie rodo vartotojų rūpestį. Geras SLO yra naudingas vykdymo įrankis kūrimo komandai. Tačiau prastai suprojektuotas SLO gali sukelti švaistomą darbą, jei komanda deda didvyriškas pastangas pasiekti pernelyg agresyvų SLO arba prastas produktas, jei SLO yra per mažas. SLO yra galingas svirtis, naudokite jį protingai.
Kontroliuokite savo matavimus
SLI ir SLO yra pagrindiniai sistemos valdymo elementai:
- Stebėti ir matuoti SLI sistemas.
- Palyginkite SLI su SLO ir nuspręskite, ar reikia imtis veiksmų.
- Jei reikia imtis veiksmų, išsiaiškinkite, kas turi atsitikti, kad pasiektumėte tikslą.
- Užbaikite šį veiksmą.
Pavyzdžiui, jei 2 veiksmas rodo, kad baigiasi užklausos skirtasis laikas ir, jei nieko nebus daroma, po kelių valandų sugadins SLO, 3 veiksmas gali apimti hipotezės, kad serveriai yra prijungti prie procesoriaus, patikrinimą ir pridėjus daugiau serverių bus paskirstyta apkrova . Be SLO nežinotumėte, ar (ar kada) imtis veiksmų.
Nustatyti SLO – tada bus nustatyti vartotojo lūkesčiai
SLO paskelbimas nustato vartotojo lūkesčius dėl sistemos elgesio. Vartotojai (ir potencialūs vartotojai) dažnai nori žinoti, ko tikėtis iš paslaugos, kad suprastų, ar ji tinkama naudoti. Pavyzdžiui, žmonės, norintys naudotis bendrinimo nuotraukomis svetaine, gali norėti nesinaudoti paslauga, kuri žada ilgaamžiškumą ir mažą kainą mainais į šiek tiek mažesnį pasiekiamumą, nors ta pati paslauga gali būti ideali archyvo įrašų valdymo sistemai.
Norėdami nustatyti realius naudotojų lūkesčius, naudokite vieną arba abi toliau nurodytas taktikas:
- Išlaikykite saugos ribą. Naudokite griežtesnį vidinį SLO, nei reklamuojama vartotojams. Tai suteiks jums galimybę reaguoti į problemas, kol jos dar netaps matomos iš išorės. SLO buferis taip pat leidžia turėti saugos ribą diegiant leidimus, turinčius įtakos sistemos veikimui, ir užtikrinti, kad sistemą būtų lengva prižiūrėti, nereikėtų varginti vartotojų prastovomis.
- Neviršykite vartotojo lūkesčių. Vartotojai remiasi tuo, ką jūs siūlote, o ne tuo, ką sakote. Jei faktinis jūsų paslaugos našumas yra daug geresnis nei nurodytas SLO, vartotojai pasikliaus esamu našumu. Galite išvengti pernelyg didelės priklausomybės tyčia išjungdami sistemą arba apribodami našumą esant nedidelėms apkrovoms.
Supratimas, kaip sistema atitinka lūkesčius, padeda apsispręsti, ar investuoti į sistemos spartinimą ir jos padarymą prieinamesne bei atsparesne. Arba, jei paslauga veikia per gerai, dalį personalo laiko reikėtų skirti kitiems prioritetams, pvz., techninių skolų apmokėjimui, naujų funkcijų pridėjimui ar naujų produktų pristatymui.
Susitarimai praktikoje
Norint sukurti SLA, verslo ir teisininkų komandos turi apibrėžti pasekmes ir nuobaudas už jo pažeidimą. SRE vaidmuo yra padėti jiems suprasti galimus iššūkius, kylančius įgyvendinant SLA nustatytus SLO. Dauguma SLO kūrimo rekomendacijų galioja ir SLA. Išmintinga būti konservatyviems, ką žadate vartotojams, nes kuo daugiau jų turite, tuo sunkiau pakeisti ar pašalinti PLS, kurios atrodo nepagrįstos arba sunkiai įgyvendinamos.
Ačiū, kad perskaitėte vertimą iki galo. Prenumeruokite mano telegramos kanalą apie stebėjimą и .
Šaltinis: www.habr.com