SRE (Site Reliability Engineering) er aðferð til að tryggja framboð á vefverkefnum. Það er talið ramma fyrir DevOps og talar um hvernig á að ná árangri í að beita DevOps starfsháttum. Þýðing í þessari grein bækur frá Google. Ég útbjó þessa þýðingu sjálfur og treysti á eigin reynslu til að skilja eftirlitsferla. Í símskeyti rásinni и Ég gaf líka út þýðingu á 6. kafla sömu bókar um þjónustustigsmarkmið.
Þýðing eftir kött. Njóttu þess að lesa!
Það er ómögulegt að stjórna þjónustu ef enginn skilningur er á því hvaða vísbendingar skipta í raun og veru máli og hvernig á að mæla og meta þá. Í þessu skyni skilgreinum við og veitum notendum okkar ákveðið þjónustustig, óháð því hvort þeir nota eitt af innri API okkar eða opinbera vöru.
Við notum innsæi okkar, reynslu og skilning á löngun notenda til að skilja þjónustustigsvísa (SLI), þjónustustigsmarkmið (SLOs) og þjónustustigssamninga (SLA). Þessar víddir lýsa helstu mæligildum sem við viljum fylgjast með og sem við munum bregðast við ef við getum ekki veitt væntanleg gæði þjónustunnar. Að lokum hjálpar það að velja réttu mælikvarðana að leiðbeina réttum aðgerðum ef eitthvað fer úrskeiðis og veitir SRE teyminu einnig traust á heilsu þjónustunnar.
Þessi kafli lýsir nálguninni sem við notum til að berjast gegn vandamálum við mælingalíkan, mælikvarðaval og mælikvarðagreiningu. Flestar skýringar verða án dæma, þannig að við notum Shakespeare þjónustuna sem lýst er í útfærsludæmi hennar (leit að verkum Shakespeares) til að útskýra aðalatriðin.
Hugtök þjónustustigs
Margir lesendur kannast líklega við hugtakið SLA, en hugtökin SLI og SLO eiga skilið vandlega skilgreiningu vegna þess að almennt er hugtakið SLA of mikið og hefur ýmsa merkingu eftir samhengi. Til glöggvunar viljum við aðgreina þessi gildi.
Vísar
SLI er þjónustustigsvísir - vandlega skilgreindur megindlegur mælikvarði á einn þátt þjónustustigsins sem veitt er.
Fyrir flestar þjónustur er lykillinn SLI talinn vera biðtími - hversu langan tíma það tekur að skila svari við beiðni. Aðrar algengar SLI eru meðal annars villuhlutfall, oft gefið upp sem brot af öllum beiðnum sem berast, og afköst kerfisins, venjulega mæld í beiðnum á sekúndu. Mælingar eru oft teknar saman: hráum gögnum er fyrst safnað og síðan umreiknað í breytingatíðni, meðaltal eða hundraðshluta.
Helst mælir SLI beint þjónustustigið sem vekur áhuga, en stundum er aðeins tengdur mælikvarði tiltækur fyrir mælingu vegna þess að upprunalega er erfitt að fá eða túlka. Til dæmis, biðtími viðskiptavinar er oft viðeigandi mælikvarði, en það eru tímar þar sem leynd er aðeins hægt að mæla á þjóninum.
Önnur tegund af SLI sem er mikilvæg fyrir SREs er framboð, eða sá hluti tíma sem hægt er að nota þjónustu. Oft skilgreint sem hlutfall árangursríkra beiðna, stundum kallað ávöxtun. (Líftími - líkurnar á því að gögnum verði varðveitt í langan tíma - er einnig mikilvægt fyrir gagnageymslukerfi.) Þótt 100% framboð sé ekki mögulegt er oft hægt að ná aðgengi nálægt 100%; framboðsgildi eru gefin upp sem fjöldi "níur" » prósentu af framboði. Til dæmis gæti 99% og 99,999% framboð verið merkt sem "2 níur" og "5 níur". Núverandi yfirlýst framboðsmarkmið Google Compute Engine er „þrjár og hálfar níur“ eða 99,95%.
Markmið
SLO er þjónustustigsmarkmið: markgildi eða gildissvið fyrir þjónustustig sem er mælt af SLI. Eðlilegt gildi fyrir SLO er „SLI ≤ Target“ eða „Lower Limit ≤ SLI ≤ Upper Limit“. Til dæmis gætum við ákveðið að við skilum Shakespeare leitarniðurstöðum „hratt“ með því að stilla SLO á meðaltals biðtíma leitarfyrirspurnar sem er minna en 100 millisekúndur.
Að velja rétta SLO er flókið ferli. Í fyrsta lagi geturðu ekki alltaf valið ákveðið gildi. Fyrir utanaðkomandi HTTP-beiðnir til þjónustu þinnar er mælikvarðinn Query Per Second (QPS) fyrst og fremst ákvörðuð af löngun notenda þinna til að heimsækja þjónustuna þína og þú getur ekki stillt SLO fyrir það.
Á hinn bóginn geturðu sagt að þú viljir að meðaltöf fyrir hverja beiðni sé innan við 100 millisekúndur. Að setja slíkt markmið gæti þvingað þig til að skrifa framendann þinn með lítilli leynd eða kaupa búnað sem veitir slíka leynd. (100 millisekúndur er augljóslega handahófskennd tala, en það er betra að hafa enn lægri leyndartölur. Það eru vísbendingar sem benda til þess að hraður hraði sé betri en hægur og að leynd í vinnslu notendabeiðna yfir ákveðnum gildum neyði fólk í raun til að halda sig í burtu frá þjónustu þinni.)
Aftur, þetta er óljósara en það kann að virðast við fyrstu sýn: þú ættir ekki að útiloka QPS algjörlega frá útreikningnum. Staðreyndin er sú að QPS og leynd eru mjög tengd hvort öðru: Hærri QPS leiðir oft til hærri töf og þjónustur verða yfirleitt fyrir mikilli lækkun á frammistöðu þegar þær ná ákveðnum álagsþröskuldi.
Að velja og gefa út SLO setur væntingar notenda um hvernig þjónustan mun virka. Þessi stefna getur dregið úr ástæðulausum kvörtunum á hendur eiganda þjónustunnar, svo sem hægum afköstum. Án skýrs SLO búa notendur oft til sínar eigin væntingar um æskilegan árangur, sem hefur kannski ekkert að gera með skoðanir fólks sem hannar og stjórnar þjónustunni. Þetta ástand getur leitt til uppblásnar væntinga til þjónustunnar, þegar notendur telja ranglega að þjónustan verði aðgengilegri en hún er í raun og veru, og valdið vantrausti þegar notendur telja að kerfið sé minna áreiðanlegt en það er í raun.
Samningar
Þjónustustigssamningur er skýr eða óbeinn samningur við notendur þína sem felur í sér afleiðingar þess að uppfylla (eða uppfylla ekki) SLOs sem þeir innihalda. Auðveldast er að greina afleiðingar þegar þær eru fjárhagslegar — afsláttur eða sekt — en þær geta verið aðrar. Auðveld leið til að tala um muninn á SLO og SLA er að spyrja „hvað gerist ef SLOs eru ekki uppfyllt? Ef það eru engar skýrar afleiðingar ertu næstum örugglega að horfa á SLO.
SRE tekur venjulega ekki þátt í að búa til SLA vegna þess að SLA eru nátengd viðskipta- og vöruákvörðunum. SRE tekur hins vegar þátt í að hjálpa til við að draga úr afleiðingum misheppnaðra SLOs. Þeir geta einnig hjálpað til við að ákvarða SLI: Augljóslega verður að vera hlutlæg leið til að mæla SLO í samningnum eða það verður ágreiningur.
Google leit er dæmi um mikilvæga þjónustu sem er ekki með opinbert SLA: við viljum að allir noti leit á eins skilvirkan hátt og mögulegt er, en við höfum ekki skrifað undir samning við heiminn. Hins vegar hefur það enn afleiðingar ef leit er ekki tiltæk - ótiltækileiki hefur í för með sér lækkun á orðspori okkar sem og minni auglýsingatekjur. Margar aðrar Google þjónustur, eins og Google for Work, hafa skýra þjónustusamninga við notendur. Óháð því hvort tiltekin þjónusta er með SLA, þá er mikilvægt að skilgreina SLI og SLO og nota þau til að stjórna þjónustunni.
Svo mikil kenning - nú til reynslu.
Vísar í reynd
Í ljósi þess að við höfum komist að þeirri niðurstöðu að það sé mikilvægt að velja viðeigandi mælikvarða til að mæla þjónustustig, hvernig veistu núna hvaða mælikvarðar skipta máli fyrir þjónustu eða kerfi?
Hvað er þér og notendum þínum sama um?
Þú þarft ekki að nota alla mælikvarða sem SLI sem þú getur fylgst með í eftirlitskerfi; Að skilja hvað notendur vilja fá úr kerfi mun hjálpa þér að velja nokkrar mælikvarðar. Að velja of marga vísbendingar gerir það erfitt að einbeita sér að mikilvægum vísbendingum, en að velja lítinn fjölda getur skilið eftir stóra bita af kerfinu þínu án eftirlits. Við notum venjulega nokkra lykilvísa til að meta og skilja heilsu kerfis.
Almennt er hægt að skipta þjónustu niður í nokkra hluta hvað varðar SLI sem skipta máli fyrir þá:
- Sérsniðin framendakerfi, eins og leitarviðmót fyrir Shakespeare þjónustuna frá okkar dæmi. Þeir verða að vera tiltækir, hafa engar tafir og hafa næga bandbreidd. Í samræmi við það er hægt að spyrja spurninga: getum við svarað beiðninni? Hvað tók langan tíma að svara beiðninni? Hversu margar beiðnir er hægt að vinna úr?
- Geymslukerfi. Þeir meta litla svörunartöf, framboð og endingu. Tengdar spurningar: Hversu langan tíma tekur það að lesa eða skrifa gögn? Getum við nálgast gögnin sé þess óskað? Eru gögnin tiltæk þegar við þurfum á þeim að halda? Sjá kafla 26 Heilindi gagna: Það sem þú lest er það sem þú skrifar fyrir ítarlega umfjöllun um þessi mál.
- Stór gagnakerfi eins og gagnavinnsluleiðslur treysta á afköst og biðtíma fyrirspurnavinnslu. Tengdar spurningar: Hversu mikið af gögnum er unnið? Hversu langan tíma tekur það fyrir gögn að ferðast frá því að beiðni berst þar til svar er gefið? (Sumir hlutar kerfisins geta einnig haft tafir á ákveðnum stigum.)
Safn vísbendinga
Mörgum þjónustustigsvísum er eðlilegast safnað á netþjónahlið með því að nota eftirlitskerfi eins og Borgmon (sjá hér að neðan). ) eða Prometheus, eða einfaldlega að greina annálana reglulega, auðkenna HTTP svör með stöðu 500. Hins vegar ættu sum kerfi að vera búin söfnun mæligilda viðskiptavinarhliðar, þar sem skortur á eftirliti viðskiptavinarhliðar getur leitt til þess að missa af fjölda vandamála sem hafa áhrif á notendur, en hafa ekki áhrif á mælikvarða á miðlarahlið. Til dæmis, að einblína á töf á bakendasvörun Shakespeare leitarprófunarforritsins okkar getur leitt til leynd á notendahliðinni vegna JavaScript vandamála: í þessu tilviki er það betri mælikvarði að mæla hversu langan tíma það tekur vafrann að vinna úr síðunni.
Söfnun
Til að einfalda og auðvelda notkun tökum við oft saman hráar mælingar. Þetta verður að fara varlega.
Sumar mælingar virðast einfaldar, eins og beiðnir á sekúndu, en jafnvel þessi að því er virðist einföld mæling safnar óbeint saman gögnum með tímanum. Er mælingin móttekin sérstaklega einu sinni á sekúndu eða er mælingin miðuð yfir fjölda beiðna á mínútu? Síðarnefndi valkosturinn getur falið miklu hærri samstundis fjölda beiðna sem endast í nokkrar sekúndur. Íhugaðu kerfi sem þjónar 200 beiðnum á sekúndu með sléttum tölum og 0 það sem eftir er. Fasti í formi meðalgildi upp á 100 beiðnir á sekúndu og tvöfalt tafarlaust álag er ekki það sama. Að sama skapi kann að vera að meðaltali biðtími fyrirspurna aðlaðandi, en það felur í sér mikilvæg smáatriði: það er mögulegt að flestar fyrirspurnir verði hraðar, en það verða margar fyrirspurnir sem eru hægar.
Flestir vísbendingar eru betur skoðaðar sem dreifingar frekar en meðaltal. Til dæmis, fyrir SLI leynd, verða sumar beiðnir unnar hratt, á meðan sumar munu alltaf taka lengri tíma, stundum mun lengri tíma. Einfalt meðaltal getur falið þessar miklu tafir. Myndin sýnir dæmi: þó dæmigerð beiðni taki um það bil 50 ms að þjóna, eru 5% beiðna 20 sinnum hægari! Vöktun og viðvörun sem byggist eingöngu á meðaltöfum sýnir ekki breytingar á hegðun yfir daginn, þegar í raun eru áberandi breytingar á afgreiðslutíma sumra beiðna (efsta línan).
50, 85, 95 og 99 hundraðshluta kerfisleynd. Y-ásinn er á lógaritmísku sniði.
Notkun hundraðshluta fyrir vísbendingar gerir þér kleift að sjá lögun dreifingarinnar og eiginleika hennar: hátt prósentustig, eins og 99 eða 99,9, sýnir versta gildið, en 50 hundraðshluti (einnig þekkt sem miðgildi) sýnir algengasta ástand mæligildið. Því meiri dreifing viðbragðstíma, því fleiri langvarandi beiðnir hafa áhrif á notendaupplifunina. Áhrifin aukast við mikið álag og í viðurvist biðraðir. Rannsóknir á notendaupplifun hafa sýnt að fólk kýs almennt hægara kerfi með miklu svörunartímafráviki, þannig að sum SRE teymi einbeita sér aðeins að háum prósentustigum, á þeim grundvelli að ef hegðun mælikvarða á 99,9 hundraðshlutanum er góð munu flestir notendur ekki upplifa vandamál .
Athugið um tölfræðilegar villur
Við kjósum almennt að vinna með hundraðshluti frekar en meðaltal (reiknings meðaltal) gildishóps. Þetta gerir okkur kleift að íhuga dreifðari gildi, sem hafa oft verulega aðra (og áhugaverðari) eiginleika en meðaltalið. Vegna gervi eðlis tölvukerfa eru mæligildi oft skekkt, til dæmis getur engin beiðni fengið svar á innan við 0 ms og 1000 ms tími þýðir að ekki er hægt að svara með hærri gildum en tímamörkin. Þar af leiðandi getum við ekki sætt okkur við að meðaltal og miðgildi geti verið það sama eða nálægt hvort öðru!
Án fyrri prófunar, og nema ákveðnar staðlaðar forsendur og nálganir standist, gætum við þess að álykta ekki að gögnin okkar séu eðlilega dreift. Ef dreifingin er ekki eins og búist var við, gæti sjálfvirkniferlið sem lagar vandamálið (til dæmis þegar það sér útúrsnúninga, það endurræsir netþjóninn með mikilli biðvinnslutöf) verið að gera það of oft eða ekki nógu oft (bæði eru það ekki mjög gott).
Staðlaðu vísbendingar
Við mælum með því að staðla almenna eiginleika SLI svo að þú þurfir ekki að spá í þá í hvert skipti. Allir eiginleikar sem uppfylla staðlað mynstur geta verið útilokaðir frá forskrift einstakra SLI, til dæmis:
- Söfnunarbil: „að meðaltali yfir 1 mínútu“
- Söfnunarsvæði: „Öll verkefni í klasanum“
- Hversu oft eru mælingar teknar: „Á 10 sekúndna fresti“
- Hvaða beiðnir eru innifalin: „HTTP GET frá eftirlitsstörfum með svörtum kassa“
- Hvernig gögnin eru fengin: „Þökk sé vöktun okkar sem er mæld á þjóninum“
- Gagnaaðgangstíðni: „Tími til síðasta bæti“
Til að spara fyrirhöfn skaltu búa til safn af endurnýtanlegum SLI sniðmátum fyrir hverja algenga mælikvarða; þeir gera það líka auðveldara fyrir alla að skilja hvað tiltekið SLI þýðir.
Markmið í reynd
Byrjaðu á því að hugsa um (eða finna út!) hvað notendum þínum þykir vænt um, ekki hvað þú getur mælt. Oft er erfitt eða ómögulegt að mæla hvað notendum þínum þykir vænt um, þannig að þú endar með því að komast nær þörfum þeirra. Hins vegar, ef þú byrjar bara á því sem auðvelt er að mæla, endarðu með minna gagnlegar SLOs. Fyrir vikið höfum við stundum komist að því að það að skilgreina æskileg markmið í upphafi og vinna síðan með ákveðna vísbendingar virkar betur en að velja vísbendingar og ná síðan markmiðunum.
Skilgreindu markmið þín
Til að fá hámarks skýrleika ætti að skilgreina hvernig SLOs eru mæld og við hvaða skilyrði þau gilda. Til dæmis gætum við sagt eftirfarandi (önnur línan er sú sama og sú fyrri, en notar SLI sjálfgefna stillingar):
- 99% (að meðaltali yfir 1 mínútu) af Get RPC símtölum mun ljúka á innan við 100 ms (mælt á öllum bakendaþjónum).
- 99% af fá RPC símtölum mun ljúka á innan við 100 ms.
Ef lögun frammistöðuferlanna er mikilvæg geturðu tilgreint mörg SLOs:
- 90% af Fá RPC símtöl sem lokið er á innan við 1 ms.
- 99% af Fá RPC símtöl sem lokið er á innan við 10 ms.
- 99.9% af Fá RPC símtöl sem lokið er á innan við 100 ms.
Ef notendur þínir búa til misleitt vinnuálag: magnvinnsla (sem afköst er mikilvæg fyrir) og gagnvirka vinnslu (sem leynd er mikilvæg fyrir), gæti verið þess virði að skilgreina aðskilin markmið fyrir hvern álagsflokk:
- 95% af beiðnum viðskiptavina þurfa afköst. Stilltu fjölda RPC símtala sem eru keyrð <1 s.
- 99% viðskiptavina er sama um leynd. Stilltu fjölda RPC símtala með umferð <1 KB og keyrandi <10 ms.
Það er óraunhæft og óæskilegt að krefjast þess að SLOs verði uppfyllt 100% af tímanum: þetta getur dregið úr hraða innleiðingar nýrrar virkni og dreifingar og krefst dýrra lausna. Þess í stað er betra að leyfa villukostnaðaráætlun - hlutfall leyfðar niðurtíma kerfis - og fylgjast með þessu gildi daglega eða vikulega. Yfirstjórn gæti viljað mánaðarlegt eða ársfjórðungslegt mat. (Villa fjárhagsáætlunin er einfaldlega SLO til samanburðar við annað SLO.)
Hlutfall SLO brota má bera saman við villufjárhagsáætlun (sjá kafla 3 og kafla ), með mismunagildinu sem notað er sem inntak í ferlið sem ákveður hvenær á að dreifa nýjum útgáfum.
Val á markgildum
Val á áætlunargildum (SLOs) er ekki eingöngu tæknileg starfsemi vegna vöru- og viðskiptahagsmuna sem verða að endurspeglast í völdum SLIs, SLOs (og hugsanlega SLAs). Sömuleiðis gæti þurft að skiptast á upplýsingum um málefni sem tengjast starfsmannahaldi, markaðstíma, framboði á búnaði og fjármögnun. SRE ætti að vera hluti af þessu samtali og hjálpa til við að skilja áhættu og hagkvæmni mismunandi valkosta. Við höfum komið með nokkrar spurningar sem gætu hjálpað til við að tryggja afkastameiri umræðu:
Ekki velja markmið byggt á núverandi frammistöðu.
Þó að það sé mikilvægt að skilja styrkleika og takmörk kerfis, getur aðlögun mæligilda án rökstuðnings hindrað þig í að viðhalda kerfinu: það mun krefjast hetjulegrar viðleitni til að ná markmiðum sem ekki er hægt að ná án verulegrar endurhönnunar.
Hafðu það einfalt
Flóknir SLI útreikningar geta falið breytingar á afköstum kerfisins og gert það erfiðara að finna orsök vandans.
Forðastu alger
Þó að það sé freistandi að hafa kerfi sem þolir endalaust vaxandi álag án þess að auka leynd, þá er þessi krafa óraunhæf. Kerfi sem nálgast slíkar hugsjónir mun líklega þurfa mikinn tíma til að hanna og smíða, verður dýrt í rekstri og mun vera of gott fyrir væntingar notenda sem myndu gera eitthvað minna.
Notaðu eins fá SLO og mögulegt er
Veldu nægjanlegan fjölda SLOs til að tryggja góða umfjöllun um kerfiseiginleika. Verndaðu SLO sem þú velur: Ef þú getur aldrei unnið rifrildi um forgangsröðun með því að tilgreina tiltekið SLO, er það líklega ekki þess virði að íhuga það SLO. Hins vegar eru ekki allir kerfiseiginleikar tiltækir fyrir SLOs: það er erfitt að reikna út hversu mikið notendaánægja er með því að nota SLOs.
Ekki elta fullkomnun
Þú getur alltaf betrumbætt skilgreiningar og markmið SLO með tímanum eftir því sem þú lærir meira um hegðun kerfisins undir álagi. Það er betra að byrja á fljótandi markmiði sem þú fínpússar með tímanum heldur en að velja of strangt markmið sem þarf að slaka á þegar þér finnst það óviðunandi.
SLOs geta og ættu að vera lykildrifkraftur í forgangsröðun vinnu fyrir SRE og vöruþróunaraðila vegna þess að þau endurspegla umhyggju fyrir notendum. Gott SLO er gagnlegt framfylgdartæki fyrir þróunarteymi. En illa hannað SLO getur leitt til sóunarlegrar vinnu ef teymið gerir hetjulega tilraun til að ná of árásargjarnri SLO, eða lélegri vöru ef SLO er of lágt. SLO er öflug lyftistöng, notaðu hana skynsamlega.
Stjórnaðu mælingum þínum
SLI og SLO eru lykilþættir sem notaðir eru til að stjórna kerfum:
- Fylgjast með og mæla SLI kerfi.
- Berðu SLI saman við SLO og ákveðið hvort aðgerða sé þörf.
- Ef aðgerða er þörf, reiknaðu út hvað þarf að gerast til að ná markmiðinu.
- Ljúktu við þessa aðgerð.
Til dæmis, ef skref 2 sýnir að beiðnin er að renna út og mun brjóta SLO eftir nokkrar klukkustundir ef ekkert er að gert, gæti skref 3 falið í sér að prófa þá tilgátu að þjónarnir séu CPU bundnir og að bæta við fleiri netþjónum mun dreifa álaginu. Án SLO myndirðu ekki vita hvort (eða hvenær) þú ættir að grípa til aðgerða.
Stilltu SLO - þá verða væntingar notenda stilltar
Að birta SLO setur væntingar notenda um hegðun kerfisins. Notendur (og hugsanlegir notendur) vilja oft vita hvers megi búast við af þjónustu til að skilja hvort hún henti til notkunar. Til dæmis gæti fólk sem vill nota vefsíðu til að deila myndum viljað forðast að nota þjónustu sem lofar langlífi og litlum tilkostnaði í skiptum fyrir aðeins minna framboð, jafnvel þó að sama þjónustan gæti verið tilvalin fyrir skjalastjórnunarkerfi.
Til að setja raunhæfar væntingar til notenda þinna skaltu nota eina eða báðar eftirfarandi aðferða:
- Haltu öryggismörkum. Notaðu strangara innra SLO en það sem er auglýst fyrir notendur. Þetta gefur þér tækifæri til að bregðast við vandamálum áður en þau verða sýnileg ytra. SLO biðminni gerir þér einnig kleift að hafa öryggisbil þegar þú setur upp útgáfur sem hafa áhrif á afköst kerfisins og tryggja að auðvelt sé að viðhalda kerfinu án þess að þurfa að trufla notendur með niður í miðbæ.
- Ekki fara fram úr væntingum notenda. Notendur eru byggðir á því sem þú býður, ekki því sem þú segir. Ef raunverulegur árangur þjónustunnar þinnar er mun betri en uppgefið SLO, munu notendur treysta á núverandi frammistöðu. Þú getur forðast of háð með því að slökkva viljandi á kerfinu eða takmarka afköst við létt álag.
Skilningur á því hversu vel kerfi uppfyllir væntingar hjálpar til við að ákveða hvort fjárfesta eigi í því að flýta fyrir kerfinu og gera það aðgengilegra og seigara. Að öðrum kosti, ef þjónusta gengur of vel, ætti að eyða einhverjum tíma starfsfólks í önnur forgangsverkefni, svo sem að greiða niður tæknilegar skuldir, bæta við nýjum eiginleikum eða kynna nýjar vörur.
Samningar í framkvæmd
Að búa til SLA krefst þess að viðskipta- og lögfræðiteymi skilgreini afleiðingar og viðurlög við því að brjóta það. Hlutverk SRE er að hjálpa þeim að skilja líklegar áskoranir við að mæta SLOs sem er að finna í SLA. Flestar ráðleggingar um að búa til SLO eiga einnig við um SLA. Það er skynsamlegt að vera íhaldssamur í því sem þú lofar notendum því því meira sem þú hefur, því erfiðara er að breyta eða fjarlægja SLA sem virðast óeðlileg eða erfitt að standa við.
Þakka þér fyrir að lesa þýðinguna til enda. Gerast áskrifandi að símskeyti rásinni minni um eftirlit и .
Heimild: www.habr.com