SRE (Site Reliability Engineering) web proiektuen erabilgarritasuna bermatzeko hurbilketa bat da. DevOps-en esparrutzat hartzen da eta DevOps praktikak aplikatzean arrakasta nola lortu buruz hitz egiten du. Itzulpena artikulu honetan liburuak Google-tik. Itzulpen hau neuk prestatu nuen eta jarraipen-prozesuak ulertzeko nire esperientzian oinarritu nintzen. Telegram kanalean ΠΈ Liburu bereko 6. kapituluaren itzulpena ere argitaratu nuen zerbitzu-mailaren helburuei buruz.
Katuaren itzulpena. Gozatu irakurtzen!
Ezinezkoa da zerbitzu bat kudeatzea adierazleek benetan zer axola duten eta nola neurtu eta ebaluatu behar diren ulertzen ez bada. Horretarako, gure erabiltzaileei zerbitzu-maila jakin bat definitu eta eskaintzen diegu, gure barneko APIetako bat edo produktu publiko bat erabiltzen duten kontuan hartu gabe.
Gure intuizioa, esperientzia eta erabiltzaileek Zerbitzu Mailaren Adierazleak (SLI), Zerbitzu Mailaren Helburuak (SLO) eta Zerbitzu Mailaren Akordioak (SLA) ulertzeko duten nahiaren ulermena erabiltzen dugu. Dimentsio hauek monitorizatu nahi ditugun neurgailu nagusiak eta zeintzuk erreakzionatuko ditugun deskribatzen dituzte esperotako zerbitzuaren kalitatea eman ezin badugu. Azken finean, neurketa egokiak aukeratzeak ekintza egokiak gidatzen laguntzen du zerbait gaizki gertatzen bada, eta, gainera, SRE taldeari konfiantza ematen dio zerbitzuaren osasunean.
Kapitulu honetan modelizazio metrikoaren, hautapen metrikoaren eta metrika-analisiaren arazoei aurre egiteko erabiltzen dugun ikuspegia deskribatzen da. Azalpen gehiena adibiderik gabea izango da, beraz, bere ezarpen adibidean (Shakespeareren lanak bilatu) deskribatutako Shakespeare zerbitzua erabiliko dugu puntu nagusiak ilustratzeko.
Zerbitzu-mailako terminologia
Irakurle askok ziurrenik SLA kontzeptua ezagutzen dute, baina SLI eta SLO terminoek definizio zehatza merezi dute, orokorrean SLA terminoa gainkargatuta dagoelako eta testuinguruaren arabera esanahi ugari dituelako. Argitasuna lortzeko, balio hauek bereizi nahi ditugu.
Adierazleak
SLI zerbitzu-mailaren adierazlea da, arretaz definitutako zerbitzu-mailaren alderdi baten neurketa kuantitatiboa.
Zerbitzu gehienetarako, SLI gakoa eskaeraren latentziatzat hartzen da - zenbat denbora behar duen eskaera bati erantzuna itzultzeko. Beste SLI arrunten artean, errore-tasa, askotan jasotako eskaera guztien zati gisa adierazten da, eta sistemaren errendimendua, normalean segundoko eskaeretan neurtuta. Neurketak batu egiten dira askotan: lehenik eta behin datu gordinak biltzen dira eta gero aldaketa-tasa, batez bestekoa edo pertzentil batean bihurtzen dira.
Egokiena, SLIk zerbitzu interesgarriaren maila zuzenean neurtzen du, baina batzuetan erlazionatutako metrika bat baino ez dago eskuragarri neurtzeko, jatorrizkoa lortzea edo interpretatzea zaila delako. Adibidez, bezeroaren latentzia sarritan metrika egokiagoa da, baina latentzia zerbitzarian soilik neur daitekeen une batzuetan.
SREentzat garrantzitsua den beste SLI mota bat erabilgarritasuna da, edo zerbitzu bat erabil daitekeen denbora tartea. Sarritan eskaera arrakastatsuen tasa gisa definitzen da, batzuetan etekina deitzen zaio. (Bizi-iraupena βdatuak denbora luzez gordetzeko probabilitateaβ datuak biltegiratzeko sistemetarako ere garrantzitsua da.) % 100eko erabilgarritasuna posible ez den arren, % 100etik gertu dagoen erabilgarritasuna lor daiteke askotan; erabilgarritasun-balioak honela adierazten dira. "bederatzi" kopurua Β» erabilgarritasunaren ehunekoa. Adibidez, %99 eta %99,999ko erabilgarritasuna "2 bederatzi" eta "5 bederatzi" gisa etiketatuta egon daitezke. Google Compute Engine-ren egungo erabilgarritasun-helburua "hiru bederatzi eta erdi" edo %99,95 da.
helburuak
SLO bat zerbitzu-mailaren helburua da: SLI-k neurtzen duen zerbitzu-maila baterako helburu-balioa edo balio-tartea. SLOren balio normal bat "SLI β€ Helburua" edo "Beheko muga β€ SLI β€ Goiko muga" da. Adibidez, Shakespeareren bilaketa-emaitzak "azkar" itzuliko ditugula erabaki genezake, SLO-a 100 milisegundo baino gutxiagoko batez besteko bilaketa-kontsulten latentzia ezarriz.
SLO egokia aukeratzea prozesu konplexua da. Lehenik eta behin, ezin duzu beti balio zehatz bat aukeratu. Zure zerbitzurako kanpoko sarrerako HTTP eskaerak egiteko, segundoko kontsulta (QPS) neurketa zure erabiltzaileek zure zerbitzua bisitatzeko nahiak zehazten du batez ere, eta ezin duzu horretarako SLOrik ezarri.
Bestalde, eskaera bakoitzaren batez besteko latentzia 100 milisegundotik beherakoa izatea nahi duzula esan dezakezu. Helburu hori ezartzeak zure frontend-a latentzia baxuarekin idaztera edo latentzia hori ematen duen ekipoa erostera behartuko zaitu. (100 milisegundo zenbaki arbitrarioa da, jakina, baina hobe da latentzia-zenbakiak are txikiagoak izatea. Ebidentzia dago abiadura azkarrak abiadura motelak baino hobeak direla iradokitzen duena, eta erabiltzaileen eskaerak balio batzuen gainetik prozesatzeko latentziak jendea kanpoan geratzera behartzen duela. zure zerbitzutik.)
Berriz ere, hau lehen begiratuan badirudi baino anbiguoagoa da: ez zenuke QPS guztiz baztertu behar kalkulutik. Kontua da QPS eta latentzia oso lotuta daudela elkarren artean: QPS handiagoak maiz latentzia handiagoak dakartza, eta zerbitzuek normalean errendimenduaren beherakada nabarmena izaten dute karga-atalase jakin batera iristen direnean.
SLO bat hautatu eta argitaratzeak erabiltzaileen itxaropenak ezartzen ditu zerbitzuak nola funtzionatuko duen. Estrategia honek zerbitzuaren jabearen aurkako oinarririk gabeko kexak murriztu ditzake, adibidez, errendimendu motela. SLO espliziturik gabe, erabiltzaileek maiz beren itxaropenak sortzen dituzte nahi den errendimenduari buruz, eta baliteke zerikusirik ez izatea zerbitzua diseinatzen eta kudeatzen duten pertsonen iritziekin. Egoera honek zerbitzuarekiko itxaropenak puztu egin ditzake, erabiltzaileek zerbitzua benetan dena baino eskuragarriagoa izango dela uste dutenean oker, eta mesfidantza sor dezake erabiltzaileek sistema benetan baino fidagarritasun txikiagoa dela uste dutenean.
Akordioak
Zerbitzu-maila-akordioa zure erabiltzaileekiko kontratu esplizitua edo inplizitua da, haiek dituzten SLOak betetzearen (edo ez betetzearen) ondorioak barne hartzen dituena. Ondorioak errazen antzematen dira ekonomikoak direnean βdeskontua edo isunaβ, baina beste forma batzuk har ditzakete. SLO eta SLAen arteko desberdintasunaz hitz egiteko modu erraz bat "zer gertatzen da SLOak betetzen ez badira?" Ondorio argirik ez badago, ia ziur SLO bati begira zaude.
SRE normalean ez da parte hartzen SLAak sortzen, SLAak negozio eta produktuen erabakiekin estu lotuta daudelako. SRE, ordea, huts egin duten SLOen ondorioak arintzen laguntzen du. SLI zehazten ere lagun dezakete: jakina, akordioan SLO neurtzeko modu objektibo bat egon behar da edo desadostasuna egongo da.
SLA publikorik ez duen zerbitzu garrantzitsu baten adibidea da Google Bilaketa: denek Bilaketa ahalik eta modu eraginkorrenean erabiltzea nahi dugu, baina ez dugu munduarekin kontraturik sinatu. Hala ere, oraindik ere ondorioak daude bilaketa erabilgarri ez badago - erabilgarritasunik ezak gure ospearen beherakada eragiten du, baita publizitate-sarrerak murriztu ere. Google-ren beste zerbitzu askok, Google for Work adibidez, zerbitzu-maila-akordio esplizituak dituzte erabiltzaileekin. Zerbitzu jakin batek SLA bat duen ala ez, garrantzitsua da SLI eta SLO definitzea eta horiek erabiltzea zerbitzua kudeatzeko.
Hainbeste teoria - orain esperimentatu.
Adierazleak praktikan
Zerbitzu-maila neurtzeko neurketa egokiak hautatzea garrantzitsua dela ondorioztatu dugula kontuan hartuta, nola dakizu gaur egun zer-nolako neurketa garrantzitsuak diren zerbitzu edo sistema baterako?
Zer axola zaizu zuk eta zure erabiltzaileei?
Ez duzu monitorizazio-sistema batean jarrai dezakezun SLI gisa erabili beharrik; Erabiltzaileek sistema batetik zer nahi duten ulertzeak hainbat neurketa hautatzen lagunduko dizu. Adierazle gehiegi aukeratzeak zaildu egiten du adierazle garrantzitsuetan zentratzea, eta kopuru txiki bat aukeratzeak zure sistemaren zati handiak arretarik gabe utzi ditzake. Normalean, hainbat funtsezko adierazle erabiltzen ditugu sistema baten osasuna ebaluatzeko eta ulertzeko.
Zerbitzuak, oro har, haientzat garrantzitsuak diren SLIri dagokionez hainbat zatitan bana daitezke:
- Frontend sistema pertsonalizatuak, adibidez, Shakespeare zerbitzuaren bilaketa-interfazeak gure adibidetik. Eskuragarri egon behar dute, ez dute atzerapenik izan eta banda zabalera nahikoa izan. Horren arabera, galderak egin daitezke: erantzun diezaiokegu eskaerari? Zenbat denbora behar izan da eskaerari erantzuteko? Zenbat eskaera prozesatu daitezke?
- Biltegiratze sistemak. Erantzunaren latentzia, erabilgarritasun eta iraunkortasun baxua baloratzen dute. Lotutako galderak: Zenbat denbora behar da datuak irakurtzeko edo idazteko? Datuak eskatuz gero sar gaitezke? Datuak behar ditugunean eskuragarri al daude? Ikus 26. kapitulua Datuen osotasuna: irakurtzen duzuna idazten duzuna da gai hauei buruzko eztabaida zehatza izateko.
- Datu handien sistemak, hala nola datuak prozesatzeko kanalizazioak, errendimenduan eta kontsultak prozesatzeko latentzian oinarritzen dira. Lotutako galderak: Zenbat datu prozesatzen dira? Zenbat denbora behar da datuek eskaera jasotzetik erantzuna ematera igarotzeko? (Sistemaren zati batzuek atzerapenak ere izan ditzakete fase batzuetan.)
Adierazleen bilketa
Zerbitzu-mailako adierazle asko zerbitzariaren aldean biltzen dira modu naturalean, Borgmon bezalako monitorizazio sistema bat erabiliz (ikus behean). ) edo Prometheus, edo, besterik gabe, erregistroak aldian-aldian aztertuz, HTTP erantzunak 500. egoerarekin identifikatuz. Hala ere, sistema batzuek bezeroaren alboko neurgailuen bilketaz hornitu beharko lukete, bezeroaren alboko monitorizazio faltak eragina duten hainbat arazo galtzea ekar baitezake. erabiltzaileek, baina ez dute zerbitzariaren inguruko metriketan eragiten. Adibidez, gure Shakespeare bilaketa-probaren aplikazioaren backend erantzunaren latentzian zentratuz gero, erabiltzailearen aldetik latentzia ekar dezake JavaScript arazoengatik: kasu honetan, arakatzaileak orria prozesatzeko zenbat denbora behar duen neurtzea metrika hobea da.
Agregazioa
Erraztasuna eta erabilera errazteko, sarritan neurketa gordinak biltzen ditugu. Hau kontu handiz egin behar da.
Zenbait neurketa sinpleak dirudite, segundoko eskaerak bezalakoak, baina itxuraz erraza den neurketa honek ere denboran zehar datuak biltzen ditu inplizituki. Neurketa segunduko behin jasotzen da ala neurketa minutuko eskaera kopuruaren arabera egiten da batez bestekoa? Azken aukera honek segundo gutxi irauten duen berehalako eskaera kopuru askoz handiagoa ezkutatu dezake. Demagun 200 eskaera segundoko zenbaki bikoitiekin eta gainerako denboran 0 balio duen sistema bat. Ez dira gauza bera 100 eskaera segundoko batez besteko balioaren formako konstante bat eta berehalako kargaren bikoitza. Era berean, kontsulten latentziaren batez bestekoa egitea erakargarria dirudi, baina xehetasun garrantzitsu bat ezkutatzen du: baliteke kontsulta gehienak azkarrak izatea, baina motelak diren kontsulta asko egongo dira.
Adierazle gehienak batez bestekoak baino banaketa gisa hobeto ikusten dira. Esate baterako, SLI latentziarako, eskaera batzuk azkar prozesatu egingo dira, eta beste batzuk beti denbora gehiago iraungo dute, batzuetan askoz ere gehiago. Batez besteko sinple batek atzerapen luze hauek ezkutatu ditzake. Irudiak adibide bat erakusten du: eskaera tipiko batek zerbitzatzeko 50 ms inguru behar dituen arren, eskaeren %5 20 aldiz motelagoa da! Batez besteko latentzian soilik oinarritutako monitorizazioak eta alertak ez du portaera-aldaketarik erakusten egunean zehar, izan ere, eskaera batzuen prozesatze-denboran (goiko lerroa) aldaketa nabariak daudenean.
50, 85, 95 eta 99 pertzentileko sistemaren latentzia. Y ardatza formatu logaritmikoan dago.
Adierazleetarako pertzentilak erabiltzeak banaketaren forma eta bere ezaugarriak ikusteko aukera ematen du: pertzentil-maila altu batek, 99 edo 99,9 adibidez, baliorik txarrena erakusten du, eta 50 pertzentileak (mediana bezala ere ezagutzen dena) erakusten du egoerarik maizena. metrikoa. Zenbat eta erantzun-denboraren sakabanaketa handiagoa izan, orduan eta luzeagoak diren eskaerak erabiltzailearen esperientzian eragina izango du. Efektua karga handian eta ilarak daudenean areagotzen da. Erabiltzaileen esperientzia ikerketek erakutsi dute jendeak, oro har, sistema motelagoa nahiago duela erantzun denboraren bariantza handikoa, eta, beraz, SRE talde batzuek pertzentilen puntuazio altuetan soilik jartzen dute arreta, 99,9 pertzentilean metrika baten portaera ona bada, erabiltzaile gehienek ez dutela arazorik izango oinarritzat hartuta. .
Errore estatistikoei buruzko oharra
Oro har, nahiago dugu pertzentilekin lan egitea balio multzo baten batez bestekoarekin (batezbesteko aritmetikoa) baino. Horri esker, sakabanatuta dauden balioak kontuan hartu ditzakegu, askotan batez bestekoak baino ezaugarri nabarmen desberdinak (eta interesgarriagoak) dituztenak. Informatika-sistemen izaera artifiziala dela eta, balio metrikoak sarritan okertu egiten dira, adibidez, eskaerak ezin du erantzunik jaso 0 ms baino gutxiagotan, eta 1000 ms-ko denbora-muga batek esan nahi du ezin dela erantzun arrakastatsurik egon balio handiagoekin. denbora-muga baino. Ondorioz, ezin dugu onartu batez bestekoa eta mediana berdinak edo elkarrengandik hurbilak izan daitezkeenik!
Aurretik probatu gabe, eta zenbait hipotesi eta hurbilketa estandar betetzen ez badira, kontuz ibiltzen gara gure datuak normalean banatuta daudela ondorioztatzeko. Banaketa espero bezalakoa ez bada, arazoa konpontzen duen automatizazio-prozesuak (adibidez, outlier-ak ikusten dituenean, zerbitzaria berrabiarazten du eskaerak prozesatzeko latentzia handiekin) sarriegi edo nahikoa ez (biak ez dira). oso ondo).
Adierazleak estandarizatu
SLIren ezaugarri orokorrak estandarizatzea gomendatzen dugu, aldi bakoitzean horiei buruz espekulatu beharrik izan ez dezazun. Eredu estandarrak betetzen dituen edozein ezaugarri SLI indibidual baten zehaztapenetik kanpo egon daiteke, adibidez:
- Agregazio-tarteak: "minutu 1 baino gehiagoko batez bestekoa"
- Agregazio eremuak: "Klusterreko zeregin guztiak"
- Neurketak zenbat aldiz egiten diren: "10 segundoro"
- Zer eskaera gaituta dago: "HTTP GET koadro beltzeko monitorizazio lanetatik"
- Datuak nola lortzen diren: "Esker zerbitzarian neurtutako gure jarraipenari"
- Datuetarako sarbidearen latentzia: "Azken bytearen denbora"
Ahaleginak aurrezteko, sortu SLI txantiloi berrerabilgarrien multzo bat ohiko metrika bakoitzerako; gainera, denek errazten dute SLI jakin batek zer esan nahi duen ulertzea.
Helburuak praktikan
Hasi pentsatzen (edo jakiten!) zure erabiltzaileei zer axola dien, ez zer neurtu dezakezun. Askotan zure erabiltzaileei axola zaiena zaila edo ezinezkoa da neurtzea, beraz, haien beharretara hurbiltzen zara. Hala ere, neurtzeko erraza denarekin hasten bazara, SLO ez hain erabilgarriak izango dituzu. Ondorioz, batzuetan aurkitu dugu hasieran nahi diren helburuak identifikatzeak eta gero adierazle zehatzekin lan egiteak adierazleak aukeratzea eta gero helburuak lortzea baino hobeto funtzionatzen duela.
Definitu zure helburuak
Argitasun handiena lortzeko, SLOak nola neurtzen diren eta zein baldintzatan balio duten zehaztu beharko litzateke. Adibidez, honako hau esan genezake (bigarren lerroa lehenengoaren berdina da, baina SLI lehenetsiak erabiltzen ditu):
- Get RPC deien % 99 (minutu 1 baino gehiagokoa batez beste) 100 ms baino gutxiagotan burutuko da (backend zerbitzari guztietan neurtuta).
- Get RPC deien % 99 100 ms baino gutxiagotan burutuko da.
Errendimendu-kurben forma garrantzitsua bada, hainbat SLO zehaztu ditzakezu:
- Lortu RPC deien % 90 ms 1 baino gutxiagoan burutu da.
- Lortu RPC deien % 99 ms 10 baino gutxiagoan burutu da.
- Lortu RPC deien % 99.9 ms 100 baino gutxiagoan burutu da.
Zure erabiltzaileek lan-karga heterogeneoak sortzen badituzte: masa prozesatzea (horretarako errendimendua garrantzitsua da) eta prozesamendu interaktiboa (horretarako latentzia garrantzitsua da), baliteke karga klase bakoitzerako helburu bereiziak zehaztea komenigarria izatea:
- Bezeroen eskaeren % 95ek abiadura eskatzen dute. Ezarri exekutatutako RPC deien kopurua <1 s.
- Bezeroen %99ri latentzia axola zaio. Ezarri trafikoa <1 KB eta <10 ms exekutatzen duten RPC deien kopurua.
Ez da errealista eta desiragarria SLOak denboraren % 100ean beteko direla azpimarratzea: horrek funtzionalitate eta hedapen berriak sartzeko erritmoa murriztu dezake eta irtenbide garestiak eska ditzake. Horren ordez, hobe da errore-aurrekontua onartzea -sistemaren geldialdi-denboraren ehunekoa- eta balio hori egunero edo astero kontrolatzea. Goi-zuzendaritzak hilero edo hiruhileko ebaluazioak nahi izan ditzake. (Errorearen aurrekontua SLO bat besterik ez da beste SLO batekin alderatzeko.)
SLO urraketen ehunekoa akatsen aurrekontuarekin aldera daiteke (ikus 3. kapitulua eta atala ), bertsio berriak noiz zabaldu erabakitzen duen prozesuan sarrera gisa erabiltzen den diferentzia-balioarekin.
Helburu-balioak hautatzea
Plangintza-balioak (SLO) hautatzea ez da jarduera tekniko hutsa, hautatutako SLIetan, SLOetan (eta agian SLAetan) islatu behar diren produktu eta negozio-interesengatik. Era berean, baliteke langileei, merkaturatzeko denborari, ekipamenduen erabilgarritasunari eta finantzaketari lotutako gaiei buruzko informazioa trukatu behar izatea. SRE elkarrizketa honen parte izan behar du eta aukera ezberdinen arriskuak eta bideragarritasuna ulertzen lagundu. Eztabaida emankorragoa bermatzen lagun dezaketen galdera batzuk egin ditugu:
Ez aukeratu helbururik uneko errendimenduan oinarrituta.
Sistema baten indarguneak eta mugak ulertzea garrantzitsua den arren, neurriak arrazoitu gabe egokitzeak sistema mantentzea eragotzi dezake: esfortzu heroikoak beharko dira birdiseinu garrantzitsurik gabe lortu ezin diren helburuak lortzeko.
Mantendu sinplea
SLI kalkulu konplexuek sistemaren errendimenduaren aldaketak ezkutatu ditzakete eta arazoaren kausa aurkitzea zailagoa izan daiteke.
Absolutuak saihestu
Latentzia handitu gabe etengabe hazten den karga kudeatu dezakeen sistema bat izatea tentagarria bada ere, baldintza hau ez da errealista. Horrelako idealetara hurbiltzen den sistema batek diseinatzeko eta eraikitzeko denbora asko beharko du ziurrenik, funtzionatzeko garestia izango da eta ezer gutxiagorekin egingo luketen erabiltzaileen itxaropenetarako ona izango da.
Erabili ahalik eta SLO gutxien
Hautatu SLO kopuru nahikoa sistemaren atributuen estaldura ona ziurtatzeko. Babestu aukeratzen dituzun SLOak: SLO zehatz bat zehaztuz ezin baduzu inoiz lehentasunei buruzko eztabaidarik irabazi, ziurrenik ez du merezi SLO hori kontuan hartzea. Hala ere, sistema-atributu guztiak ez dira SLOetarako egokiak: zaila da SLOak erabiliz erabiltzaileen gozamen-maila kalkulatzea.
Ez ezazu perfekzioa atzetik
SLOen definizioak eta helburuak denboran zehar hobetu ditzakezu beti kargapean sistemaren portaerari buruz gehiago ikasten duzun bitartean. Hobe da denborarekin finduko duzun helburu flotagarri batekin hastea helburu zorrotzegia hautatzea, lortu ezina ikusten duzunean lasaitu behar dena.
SLOak funtsezko eragileak izan daitezke eta izan behar dute SREen eta produktuen garatzaileen lana lehenesteko, erabiltzaileen kezka islatzen dutelako. SLO on bat garapen-talde baterako betearazteko tresna erabilgarria da. Baina gaizki diseinatutako SLO batek lan alferrik galtzea ekar dezake taldeak SLO oldarkorregia lortzeko ahalegin heroikoak egiten baditu, edo produktu eskasa SLO baxuegia bada. SLO palanka indartsua da, erabili zentzuz.
Kontrolatu zure neurriak
SLI eta SLO sistemak kudeatzeko erabiltzen diren funtsezko elementuak dira:
- SLI sistemak monitorizatzea eta neurtzea.
- Konparatu SLI eta SLOrekin eta erabaki ekintza behar den ala ez.
- Ekintza beharrezkoa bada, asmatu zer gertatu behar den helburua lortzeko.
- Osatu ekintza hau.
Adibidez, 2. urratsak eskaera denbora-muga egiten ari dela erakusten badu eta SLO-a hautsiko duela ordu gutxiren buruan ezer egiten ez bada, 3. urratsak zerbitzariak PUZarekin lotuta daudela dioen hipotesia probatu eta zerbitzari gehiago gehitzeak karga banatuko du . SLOrik gabe, ez zenuke jakingo (edo noiz) neurriak hartu behar dituzun.
Ezarri SLO - orduan erabiltzailearen itxaropenak ezarriko dira
SLO bat argitaratzeak sistemaren portaerari buruzko erabiltzaileen itxaropenak ezartzen ditu. Erabiltzaileek (eta erabiltzaile potentzialak) askotan jakin nahi dute zer espero duten zerbitzu batetik erabiltzeko egokia den ala ez ulertzeko. Adibidez, argazkiak partekatzeko webgune bat erabili nahi duten pertsonek iraupena eta kostu baxua agintzen duten zerbitzu bat erabiltzea saihestu nahi dute erabilgarritasun apur bat gutxiagoren truke, nahiz eta zerbitzu bera aproposa izan daitekeen artxibo-erregistroak kudeatzeko sistema baterako.
Erabiltzaileentzako itxaropen errealistak ezartzeko, erabili taktika hauetako bat edo bi:
- Mantendu segurtasun-marjina. Erabili erabiltzaileei iragartzen zaiena baino barne SLO zorrotzagoa. Honek arazoei erreakzionatzeko aukera emango dizu kanpotik ikusi baino lehen. SLO buffer-ak segurtasun-marjina bat izatea ahalbidetzen du sistemaren errendimenduan eragina duten bertsioak instalatzean eta sistema mantentzea erraza dela ziurtatzen du erabiltzaileak geldialdiarekin zapuztu beharrik gabe.
- Ez gainditu erabiltzaileen itxaropenak. Erabiltzaileak eskaintzen duzunean oinarritzen dira, ez zuk esaten duzunean. Zure zerbitzuaren benetako errendimendua adierazitako SLO baino askoz hobea bada, erabiltzaileak uneko errendimenduan fidatuko dira. Gehiegizko mendekotasuna saihestu dezakezu sistema nahita itzaliz edo karga arinetan errendimendua mugatuz.
Sistema batek itxaropenak zenbateraino betetzen dituen ulertzeak sistema bizkortzeko eta eskuragarriago eta erresistenteagoa izan dadin inbertitu erabakitzen du. Bestela, zerbitzu bat ondo funtzionatzen badu, langileen denbora pixka bat beste lehentasun batzuetara bideratu beharko litzateke, hala nola zor teknikoa ordaintzea, funtzio berriak gehitzea edo produktu berriak sartzea.
Hitzarmenak praktikan
SLA bat sortzeak negozio eta talde juridikoek haustearen ondorioak eta zigorrak definitzea eskatzen du. SREren eginkizuna SLAn jasotako SLOak betetzeko erronkak ulertzen laguntzea da. SLOak sortzeko gomendio gehienak SLAei ere aplikatzen zaizkie. Erabiltzaileei agintzen diezunean kontserbadorea izatea komeni da, zenbat eta gehiago izan, orduan eta zailagoa baita arrazoigabeak edo betetzeko zailak diruditen SLAk aldatzea edo kentzea.
Eskerrik asko itzulpena amaiera arte irakurtzeagatik. Harpidetu nire telegram kanalera monitorizazioari buruz ΠΈ .
Iturria: www.habr.com