SRE (Site Reliability Engineering) on ​​lähenemine veebiprojektide kättesaadavuse tagamiseks. Seda peetakse DevOpsi raamistikuks ja see räägib sellest, kuidas saavutada edu DevOpsi praktikate rakendamisel. Tõlge selles artiklis 4. peatükk Teenuse taseme eesmärgid raamatud Saidi töökindluse tehnika Google'ilt. Selle tõlke koostasin ise ja tuginesin oma kogemustele seireprotsesside mõistmisel. Telegrammi kanalis monitorim_it и viimane postitus Habré kohta Avaldasin ka sama raamatu 6. peatüki tõlke teenusetaseme eesmärkide kohta.

Kassi tõlge. Nautige lugemist!

Teenust on võimatu juhtida, kui puudub arusaam, millised näitajad tegelikult olulised ning kuidas neid mõõta ja hinnata. Sel eesmärgil määratleme ja pakume oma kasutajatele teatud teenusetaseme, olenemata sellest, kas nad kasutavad mõnda meie sisemist API-d või avalikku toodet.

Kasutame oma intuitsiooni, kogemusi ja arusaama kasutajate soovist mõista teenusetaseme indikaatoreid (SLI), teenusetaseme eesmärke (SLO) ja teenusetaseme lepinguid (SLA). Need dimensioonid kirjeldavad peamisi mõõdikuid, mida soovime jälgida ja millele me reageerime, kui ei suuda pakkuda oodatud teenuse kvaliteeti. Lõppkokkuvõttes aitab õigete mõõdikute valimine suunata õigeid toiminguid, kui midagi läheb valesti, ja annab ka SRE meeskonnale kindlustunde teenuse tervise suhtes.

Selles peatükis kirjeldatakse lähenemisviisi, mida me kasutame meetermõõdustiku modelleerimise, mõõdikute valiku ja mõõdikuanalüüsi probleemidega võitlemiseks. Suurem osa selgitustest on ilma näideteta, seega kasutame põhipunktide illustreerimiseks selle rakendusnäites kirjeldatud Shakespeare'i teenust (otsige Shakespeare'i teoseid).

Teenusetaseme terminoloogia

Paljud lugejad on SLA mõistega tõenäoliselt tuttavad, kuid mõisted SLI ja SLO väärivad hoolikat defineerimist, sest üldiselt on termin SLA ülekoormatud ja sellel on olenevalt kontekstist mitu tähendust. Selguse huvides tahame need väärtused eraldada.

näitajad

SLI on teenusetaseme indikaator – hoolikalt määratletud kvantitatiivne mõõdik osutatava teenuse taseme ühe aspekti kohta.

Enamiku teenuste puhul loetakse võtme SLI-ks päringu latentsust – kui kaua kulub päringule vastuse tagastamiseks. Teised levinud SLI-d hõlmavad veamäära, mida sageli väljendatakse murdosa kõigist saadud päringutest, ja süsteemi läbilaskevõimet, mida tavaliselt mõõdetakse päringutes sekundis. Mõõtmised on sageli koondatud: algandmed kogutakse esmalt ja seejärel teisendatakse muutuse määraks, keskmiseks või protsentiiliks.

Ideaalis mõõdab SLI otse huvipakkuvat teenusetaset, kuid mõnikord on mõõtmiseks saadaval ainult seotud mõõdik, kuna algset on raske hankida või tõlgendada. Näiteks kliendipoolne latentsusaeg on sageli sobivam mõõdik, kuid mõnikord saab latentsust mõõta ainult serveris.

Teine SRE-de jaoks oluline SLI tüüp on saadavus või ajavahemik, mille jooksul teenust saab kasutada. Sageli määratletakse edukate taotluste määrana, mida mõnikord nimetatakse ka tootluseks. (Eluiga – tõenäosus, et andmeid säilitatakse pikema aja jooksul – on samuti oluline andmesalvestussüsteemide puhul.) Kuigi 100% saadavus pole võimalik, on sageli saavutatav 100% lähedane saadavus; saadavuse väärtused on väljendatud järgmiselt. "üheksade" arv » saadavuse protsent. Näiteks võib 99% ja 99,999% saadavuse märgistada kui "2 üheksat" ja "5 üheksat". Google Compute Engine'i praegune teatatud saadavuseesmärk on "kolm ja pool üheksat" ehk 99,95%.

Eesmärgid

SLO on teenusetaseme eesmärk: teenusetaseme sihtväärtus või väärtuste vahemik, mida SLI mõõdab. SLO normaalväärtus on “SLI ≤ sihtmärk” või “Alumine piir ≤ SLI ≤ ülemine piir”. Näiteks võime otsustada, et tagastame Shakespeare'i otsingutulemused kiiresti, määrates SLO-ks keskmiseks otsingupäringu latentsusajaks alla 100 millisekundi.

Õige SLO valimine on keeruline protsess. Esiteks ei saa te alati valida konkreetset väärtust. Teie teenusesse sissetulevate väliste HTTP-päringute puhul määrab päringu sekundis (QPS) mõõdiku peamiselt teie kasutajate soov teie teenust külastada ja te ei saa selle jaoks SLO-d määrata.

Teisest küljest võite öelda, et soovite, et iga päringu keskmine latentsusaeg oleks alla 100 millisekundi. Sellise eesmärgi seadmine võib sundida teid kirjutama oma kasutajaliidese madala latentsusajaga või ostma seadmeid, mis sellist latentsust pakuvad. (100 millisekundit on ilmselgelt suvaline arv, kuid parem on veelgi väiksemad latentsusarvud. On tõendeid, mis viitavad sellele, et kiired kiirused on paremad kui aeglased ja et teatud väärtustest suurem latentsus kasutajate päringute töötlemisel sunnib inimesi tegelikult eemale hoidma teie teenusest.)

See on jällegi mitmetähenduslikum, kui esmapilgul võib tunduda: te ei tohiks QPS-i arvutusest täielikult välja jätta. Fakt on see, et QPS ja latentsus on üksteisega tugevalt seotud: kõrgem QPS viib sageli kõrgema latentsusaega ja teenuste jõudlus väheneb tavaliselt järsult, kui nad jõuavad teatud koormusläveni.

SLO valimine ja avaldamine seab kasutaja ootused teenuse toimimise suhtes. See strateegia võib vähendada alusetuid kaebusi teenuse omaniku vastu, näiteks aeglast jõudlust. Ilma selgesõnalise SLOta loovad kasutajad sageli oma ootused soovitud jõudluse kohta, millel ei pruugi olla midagi pistmist teenust kavandavate ja haldavate inimeste arvamustega. Selline olukord võib tekitada teenuselt ülespuhutud ootusi, kui kasutajad usuvad ekslikult, et teenus on kättesaadavam kui see tegelikult on, ning tekitada umbusaldust, kui kasutajad usuvad, et süsteem on vähem töökindel kui see tegelikult on.

Kokkulepped

Teenusetaseme leping on otsene või kaudne leping teie kasutajatega, mis hõlmab selles sisalduvate SLO-de täitmise (või mittetäitmise) tagajärgi. Tagajärjed on kõige kergemini äratuntavad, kui need on rahalised – allahindlus või trahv –, kuid need võivad esineda ka muul kujul. Lihtne viis SLO-de ja SLA-de erinevusest rääkida on küsida: "Mis juhtub, kui SLO-d ei ole täidetud?" Kui selgeid tagajärgi pole, vaatate peaaegu kindlasti SLO-d.

SRE ei ole tavaliselt SLA-de loomisega seotud, kuna SLA-d on tihedalt seotud äri- ja tooteotsustega. SRE on aga seotud ebaõnnestunud SLO-de tagajärgede leevendamisega. Need võivad aidata ka SLI-d määrata: Ilmselgelt peab lepingus olema objektiivne viis SLO mõõtmiseks, vastasel juhul tekib lahkarvamus.

Google'i otsing on näide olulisest teenusest, millel pole avalikku teeninduslepingut: me tahame, et kõik kasutaksid otsingut võimalikult tõhusalt, kuid me pole sõlminud maailmaga lepingut. Otsingu puudumisel on siiski tagajärjed – kättesaamatus toob kaasa meie maine languse ja reklaamitulu vähenemise. Paljudel teistel Google'i teenustel, nagu Google for Work, on kasutajatega selgesõnalised teenusetaseme lepingud. Olenemata sellest, kas konkreetsel teenusel on SLA, on oluline määratleda SLI ja SLO ning kasutada neid teenuse haldamiseks.

Nii palju teooriat – nüüd kogeda.

Näitajad praktikas

Arvestades, et oleme jõudnud järeldusele, et teenusetaseme mõõtmiseks on oluline valida sobivad mõõdikud, kuidas te nüüd teate, millised mõõdikud on teenuse või süsteemi jaoks olulised?

Mis teile ja teie kasutajatele korda läheb?

Te ei pea kasutama kõiki mõõdikuid SLI-na, mida saate jälgida seiresüsteemis; Mõistmine, mida kasutajad süsteemilt soovivad, aitab teil valida mitu mõõdikut. Kui valite liiga palju indikaatoreid, on raske olulistele näitajatele keskenduda, samas kui väikese arvu valimine võib jätta teie süsteemi suured osad järelevalveta. Tavaliselt kasutame süsteemi tervise hindamiseks ja mõistmiseks mitut põhinäitajat.

Teenused võib üldiselt jagada mitmeks osaks, mis on nende jaoks asjakohased:

• Kohandatud esiotsasüsteemid, näiteks Shakespeare'i teenuse otsinguliidesed meie näites. Need peavad olema kättesaadavad, neil ei tohi olla viivitusi ja neil peab olema piisav ribalaius. Sellest lähtuvalt võib esitada küsimusi: kas saame päringule vastata? Kui kaua kulus taotlusele vastamiseks? Kui palju taotlusi saab töödelda?
• Säilitussüsteemid. Nad hindavad madalat reageerimise latentsust, kättesaadavust ja vastupidavust. Seotud küsimused: kui kaua kulub andmete lugemiseks või kirjutamiseks? Kas soovi korral saame andmetele juurde pääseda? Kas andmed on saadaval siis, kui neid vajame? Nende probleemide üksikasjalikuks aruteluks vaadake 26. peatükki Andmete terviklikkus: see, mida loete, on see, mida kirjutate.
• Suured andmesüsteemid, nagu andmetöötluskonveierid, sõltuvad läbilaskevõimest ja päringu töötlemise latentsusest. Seotud küsimused: kui palju andmeid töödeldakse? Kui kaua kulub andmete liikumiseks päringu saamisest vastuse andmiseni? (Mõnel süsteemi osal võib teatud etappidel esineda viivitusi.)

Näitajate kogumine

Paljud teenusetaseme näitajad kogutakse kõige loomulikumalt serveri poolel, kasutades jälgimissüsteemi nagu Borgmon (vt allpool). 10. peatükk Ajaridade andmetel põhinevad hoiatused) või Prometheus või lihtsalt logide perioodiline analüüsimine, HTTP-vastuste tuvastamine olekuga 500. Mõned süsteemid peaksid siiski olema varustatud kliendipoolsete mõõdikute kogumisega, kuna kliendipoolse jälgimise puudumine võib kaasa tuua mitmete probleemide puudumise. kasutajaid, kuid see ei mõjuta serveripoolseid mõõdikuid. Näiteks meie Shakespeare'i otsingu testrakenduse taustavastuse latentsusele keskendumine võib JavaScripti probleemide tõttu põhjustada kasutaja poolel latentsusaega: sel juhul on parem mõõdik, kui mõõta, kui kaua brauseril lehe töötlemiseks kulub.

Liitmine

Lihtsuse ja kasutusmugavuse huvides koondame sageli töötlemata mõõtmised. Seda tuleb teha hoolikalt.

Mõned mõõdikud tunduvad lihtsad, näiteks päringud sekundis, kuid isegi see näiliselt lihtne mõõtmine koondab kaudselt andmeid aja jooksul. Kas mõõtmistulemus võetakse vastu konkreetselt üks kord sekundis või keskmistatakse taotluste arv minutis? Viimane valik võib varjata palju suurema hetkepäringute arvu, mis kestavad vaid mõne sekundi. Mõelge süsteemile, mis teenindab 200 taotlust sekundis paarisarvudega ja 0 ülejäänud aja. Konstant keskmise väärtusena 100 päringut sekundis ja kaks korda suurem hetkekoormus ei ole sama asi. Samamoodi võib päringu latentsusaegade keskmistamine tunduda atraktiivne, kuid see peidab endas olulist detaili: on võimalik, et enamik päringuid on kiired, kuid palju on aeglaseid päringuid.

Enamikku näitajaid on parem vaadelda pigem jaotuste kui keskmistena. Näiteks SLI latentsusaja puhul töödeldakse mõnda taotlust kiiresti, samas kui mõnel kulub alati kauem aega, mõnikord palju kauem. Lihtne keskmine võib neid pikki viivitusi varjata. Joonisel on näide: kuigi tüüpilise päringu teenindamiseks kulub umbes 50 ms, on 5% päringutest 20 korda aeglasemad! Ainult keskmisel latentsusajal põhinev jälgimine ja hoiatamine ei näita muutusi käitumises päeva jooksul, kuigi tegelikult on märgatavaid muutusi mõne päringu töötlemise ajas (ülemine rida).

50, 85, 95 ja 99 protsentiili süsteemi latentsusaeg. Y-telg on logaritmilises vormingus.

Indikaatorite protsentiilide kasutamine võimaldab näha jaotuse kuju ja selle omadusi: kõrge protsentiili tase, näiteks 99 või 99,9, näitab halvimat väärtust, samas kui 50 protsentiil (tuntud ka kui mediaan) näitab kõige sagedasemat jaotuse olekut. mõõdik. Mida suurem on reageerimisaja hajumine, seda rohkem mõjutavad pikaajalised päringud kasutajakogemust. Efekt tugevneb suure koormuse korral ja järjekordade korral. Kasutajakogemuse uuringud on näidanud, et inimesed eelistavad üldiselt aeglasemat ja suure reageerimisaja dispersiooniga süsteemi, mistõttu mõned SRE meeskonnad keskenduvad ainult kõrgetele protsentiiliskooridele, lähtudes sellest, et kui mõõdiku käitumine 99,9 protsentiili juures on hea, ei teki enamikul kasutajatel probleeme. .

Märkus statistiliste vigade kohta

Üldiselt eelistame töötada protsentiilidega, mitte väärtuste komplekti keskmise (aritmeetilise keskmise) abil. See võimaldab arvestada hajutatumaid väärtusi, millel on sageli keskmisest oluliselt erinevad (ja huvitavamad) omadused. Arvutussüsteemide kunstliku olemuse tõttu on meetrilised väärtused sageli moonutatud, näiteks ükski päring ei saa vastust vähem kui 0 ms jooksul ja 1000 ms ajalõpp tähendab, et suuremate väärtustega ei saa olla edukaid vastuseid kui ajalõpp. Selle tulemusena ei saa me nõustuda sellega, et keskmine ja mediaan võivad olla samad või üksteisele lähedased!

Ilma eelneva testimiseta ja kui teatud standardsed eeldused ja ligikaudsed hinnangud ei kehti, oleme ettevaatlikud, et mitte järeldada, et meie andmed on tavapäraselt jaotunud. Kui levitamine ei vasta ootustele, võib probleemi lahendav automatiseerimisprotsess (näiteks kui see näeb kõrvalekaldeid, taaskäivitab serveri suure päringu töötlemise latentsusajaga) seda teha liiga sageli või mitte piisavalt sageli (mõlemad ei ole väga hea).

Indikaatorite standardimine

Soovitame SLI üldomadused standardida, et te ei peaks nende üle iga kord spekuleerima. Üksiku SLI spetsifikatsioonist võib välja jätta kõik funktsioonid, mis vastavad standardmustritele, näiteks:

• Koondamisintervallid: "keskmiselt üle 1 minuti"
• Koondamisalad: „Kõik ülesanded klastris”
• Mõõtmiste sagedus: "Iga 10 sekundi järel"
• Mis päringud on kaasatud: "HTTP GET from black box monitooring jobs"
• Kuidas andmeid saadakse: "Tänu meie serveris mõõdetud monitooringule"
• Andmejuurdepääsu latentsusaeg: "Aeg viimase baidini"

Jõupingutuste säästmiseks looge iga ühise mõõdiku jaoks korduvkasutatavate SLI mallide komplekt; need aitavad ka kõigil paremini mõista, mida teatud SLI tähendab.

Eesmärgid praktikas

Alustuseks mõelge (või uurige välja!), mis teie kasutajatele korda läheb, mitte sellele, mida saate mõõta. Sageli on seda, millest teie kasutajad hoolivad, raske või võimatu mõõta, nii et jõuate nende vajadustele lähemale. Kui aga alustate lihtsalt sellest, mida on lihtne mõõta, saate lõpuks vähem kasulikke SLO-sid. Seetõttu oleme mõnikord avastanud, et algselt soovitud eesmärkide väljaselgitamine ja seejärel konkreetsete näitajatega töötamine toimib paremini kui indikaatorite valimine ja seejärel eesmärkide saavutamine.

Määratlege oma eesmärgid

Maksimaalse selguse huvides tuleks määratleda, kuidas SLO-sid mõõdetakse ja millistel tingimustel need kehtivad. Näiteks võime öelda järgmist (teine ​​rida on sama, mis esimene, kuid kasutab SLI vaikeseadeid):

• 99% (keskmiselt üle 1 minuti) Hangi RPC kõnedest sooritatakse vähem kui 100 ms jooksul (mõõdetuna kõigis taustaserverites).
• 99% Get RPC kõnedest lõpetatakse vähem kui 100 ms jooksul.

Kui jõudluskõverate kuju on oluline, saate määrata mitu SLO-d.

• 90% Get RPC kõnedest lõpetati vähem kui 1 ms jooksul.
• 99% Get RPC kõnedest lõpetati vähem kui 10 ms jooksul.
• 99.9% RPC-kõned viiakse lõpule vähem kui 100 ms-ga.

Kui teie kasutajad loovad heterogeenseid töökoormusi: hulgitöötlus (mille puhul on oluline läbilaskevõime) ja interaktiivne töötlemine (mille puhul on oluline latentsusaeg), võib olla kasulik määratleda iga koormusklassi jaoks eraldi eesmärgid:

• 95% klientide soovidest nõuavad läbilaskevõimet. Määrake teostatud RPC-kõnede arv <1 s.
• 99% klientidest hoolib latentsusest. Määrake RPC-kõnede arv liiklusega <1 KB ja kestusega <10 ms.

On ebareaalne ja ebasoovitav nõuda, et SLO-d täidetaks 100% ajast: see võib vähendada uute funktsioonide juurutamise ja juurutamise tempot ning nõuda kalleid lahendusi. Selle asemel on parem lubada veaeelarve – süsteemi seisaku protsent – ​​ja jälgida seda väärtust iga päev või kord nädalas. Kõrgem juhtkond võib soovida igakuist või kvartaalset hindamist. (Veaeelarve on lihtsalt SLO võrdluseks teise SLO-ga.)

SLO rikkumiste protsenti saab võrrelda veaeelarvega (vt peatükki 3 ja jaotist "Motivatsioon vigade eelarvete jaoks"), kusjuures erinevuse väärtust kasutatakse sisendina protsessis, mis otsustab, millal uusi versioone juurutada.

Sihtväärtuste valimine

Planeerimisväärtuste (SLO) valimine ei ole puhtalt tehniline tegevus, kuna need tooted ja ärihuvid peavad kajastuma valitud SLI-des, SLO-des (ja võib-olla ka SLA-des). Samuti võib osutuda vajalikuks teabe vahetamine personali, turule jõudmise aja, seadmete kättesaadavuse ja rahastamisega seotud küsimuste kohta. SRE peaks olema selle vestluse osa ja aitama mõista erinevate võimaluste riske ja elujõulisust. Oleme esitanud mõned küsimused, mis võivad aidata tagada produktiivsema arutelu:

Ärge valige eesmärki praeguse soorituse põhjal.
Kuigi süsteemi tugevuste ja piiride mõistmine on oluline, võib mõõdikute kohandamine ilma arutluseta takistada süsteemi ülalpidamist: see nõuab kangelaslikke jõupingutusi eesmärkide saavutamiseks, mida pole võimalik saavutada ilma olulise ümberkujundamiseta.

Hoidke see lihtne
Komplekssed SLI-arvutused võivad varjata muutusi süsteemi jõudluses ja raskendada probleemi põhjuse leidmist.

Vältige absoluutsusi
Kuigi on ahvatlev omada süsteemi, mis suudab toime tulla lõputult kasvava koormusega ilma latentsust suurendamata, on see nõue ebareaalne. Sellistele ideaalidele lähenev süsteem nõuab tõenäoliselt palju aega projekteerimiseks ja ehitamiseks, on kulukas kasutada ja on liiga hea nende kasutajate ootuste jaoks, kes teeksid midagi vähemat.

Kasutage võimalikult vähe SLO-sid
Valige piisav arv SLO-sid, et tagada süsteemiatribuutide hea katvus. Kaitske valitud SLO-sid: kui te ei saa kunagi võita prioriteetide üle vaidlemist konkreetse SLO määramisega, ei tasu tõenäoliselt seda SLO-d arvesse võtta. Kuid mitte kõik süsteemiatribuudid ei ole SLO-de jaoks kohaldatavad: kasutaja rõõmu taset on SLO-de abil keeruline arvutada.

Ärge püüdke täiuslikkust taga
Saate SLO-de määratlusi ja eesmärke aja jooksul alati täpsustada, kui saate lisateavet süsteemi käitumise kohta koormuse all. Parem on alustada ujuvast eesmärgist, mida aja jooksul täpsustate, kui valida liiga range eesmärk, mida tuleb leevendada, kui leiate, et see on saavutamatu.

SLO-d võivad ja peaksid olema SRE-de ja tootearendajate töö prioriteedi määramisel võtmeteguriks, kuna need peegeldavad kasutajate muret. Hea SLO on arendusmeeskonna jaoks kasulik jõustamistööriist. Kuid halvasti kavandatud SLO võib põhjustada raiskavat tööd, kui meeskond teeb kangelaslikke jõupingutusi liiga agressiivse SLO saavutamiseks või kehva toote, kui SLO on liiga madal. SLO on võimas hoob, kasuta seda targalt.

Kontrollige oma mõõtmisi

SLI ja SLO on süsteemide haldamiseks kasutatavad põhielemendid:

• SLI-süsteemide jälgimine ja mõõtmine.
• Võrrelge SLI-d SLO-ga ja otsustage, kas on vaja midagi ette võtta.
• Kui on vaja tegutseda, mõelge välja, mis eesmärgi saavutamiseks peaks juhtuma.
• Viige see toiming lõpule.

Näiteks kui samm 2 näitab, et päring on aegumas ja katkestab SLO mõne tunni pärast, kui midagi ei tehta, võib 3. samm hõlmata hüpoteesi testimist, et serverid on CPU-ga seotud ja rohkemate serverite lisamine jaotab koormuse. Ilma SLO-ta ei teaks, kas (või millal) midagi ette võtta.

Määra SLO – siis määratakse kasutaja ootused
SLO avaldamine seab kasutaja ootused süsteemi käitumisele. Kasutajad (ja potentsiaalsed kasutajad) tahavad sageli teada, mida teenuselt oodata, et mõista, kas see sobib kasutamiseks. Näiteks võivad inimesed, kes soovivad kasutada fotode jagamise veebisaiti, soovida vältida teenuse kasutamist, mis lubab pikaealisust ja madalat hinda, vastutasuks veidi väiksema saadavuse eest, kuigi sama teenus võib olla ideaalne arhiividokumentide haldussüsteemi jaoks.

Kasutajatele realistlike ootuste seadmiseks kasutage ühte või mõlemat järgmistest taktikatest.

• Säilitage ohutusvaru. Kasutage kasutajatele reklaamitavast rangemat sisemist SLO-d. See annab sulle võimaluse reageerida probleemidele enne, kui need väljastpoolt nähtavaks muutuvad. SLO puhver võimaldab teil ka süsteemi jõudlust mõjutavate väljaannete installimisel kasutada ohutusvaru ja tagada, et süsteemi on lihtne hooldada, ilma et peaksite kasutajaid seisakutega häirima.
• Ärge ületage kasutaja ootusi. Kasutajad põhinevad teie pakutaval, mitte teie ütlemisel. Kui teie teenuse tegelik jõudlus on palju parem kui märgitud SLO, loodavad kasutajad praegusele jõudlusele. Saate vältida liigset sõltuvust, lülitades süsteemi tahtlikult välja või piirates jõudlust väikese koormuse korral.

Süsteemi ootustele vastamise mõistmine aitab otsustada, kas investeerida süsteemi kiirendamisse ning selle kättesaadavamaks ja vastupidavamaks muutmisse. Teise võimalusena, kui teenus toimib liiga hästi, tuleks osa töötajatest kulutada muudele prioriteetidele, näiteks tehniliste võlgade tasumisele, uute funktsioonide lisamisele või uute toodete tutvustamisele.

Kokkulepped praktikas

SLA loomine nõuab, et äri- ja juriidilised meeskonnad määratleksid selle rikkumise tagajärjed ja karistused. SRE roll on aidata neil mõista SLA-s sisalduvate SLO-de täitmise tõenäolisi väljakutseid. Enamik SLO-de loomise soovitusi kehtivad ka SLA-de kohta. Kasutajatele lubatavates asjades on mõistlik olla konservatiivne, sest mida rohkem teil on, seda raskem on muuta või eemaldada SLA-sid, mis tunduvad ebamõistlikud või raskesti täidetavad.

Täname, et lugesite tõlke lõpuni. Tellige minu telegrammi kanal jälgimise kohta monitorim_it и ajaveebi meedias.

Allikas: www.habr.com