SRE (Site Reliability Engineering) estas aliro por fari retprojektojn alireblaj. Ĝi estas konsiderata kadro por DevOps kaj rakontas kiel sukcesi en la apliko de DevOps-praktikoj. Ĉi tiu artikolo tradukiĝas libroj de Guglo. Mi mem preparis ĉi tiun tradukon kaj fidis je mia propra sperto pri komprenado de kontrolaj procezoj. En la telegrama kanalo и Mi ankaŭ publikigis tradukon de Ĉapitro 6 de la sama libro pri servonivelaj celoj.
Traduko de kato. Ĝuu legadon!
Estas neeble administri servon se mankas kompreno pri kio indikiloj fakte gravas kaj kiel mezuri kaj taksi ilin. Tiucele ni difinas kaj provizas certan servon al niaj uzantoj, sendepende de ĉu ili uzas unu el niaj internaj API-oj aŭ publikan produkton.
Ni uzas nian intuicion, sperton kaj komprenon pri la deziro de uzantoj kompreni Servonivelajn Indikilojn (SLI), Servonivelajn Celojn (SLO) kaj Servonivelajn Interkonsentojn (SLA). Ĉi tiuj dimensioj priskribas la ĉefajn metrikojn, kiujn ni volas kontroli kaj al kiuj ni reagos se ni ne povas provizi la atendatan kvaliton de servo. Finfine, elekti la ĝustajn metrikojn helpas gvidi la ĝustajn agojn se io misfunkcias, kaj ankaŭ donas al la SRE-teamo fidon pri la sano de la servo.
Ĉi tiu ĉapitro priskribas la aliron, kiun ni uzas por kontraŭbatali la problemojn de metrika modeligado, metrika elekto kaj metrika analizo. Plejparto de la klarigo estos sen ekzemploj, do ni uzos la Ŝekspir-servon priskribitan en ĝia efektiviga ekzemplo (serĉo de la verkoj de Ŝekspiro) por ilustri la ĉefajn punktojn.
Servonivela terminologio
Multaj legantoj verŝajne konas la koncepton de SLA, sed la esprimoj SLI kaj SLO meritas zorgan difinon ĉar ĝenerale la esprimo SLA estas troŝarĝita kaj havas kelkajn signifojn depende de la kunteksto. Por klareco, ni volas apartigi ĉi tiujn valorojn.
Indikiloj
La SLI estas servnivela indikilo - singarde difinita kvanta mezuro de unu aspekto de la nivelo de servo provizita.
Por plej multaj servoj, la ŝlosila SLI estas konsiderata kiel peta latenco - kiom da tempo necesas por resendi respondon al peto. Aliaj oftaj SLIoj inkludas erarprocenton, ofte esprimitan kiel frakcio de ĉiuj petoj ricevitaj, kaj sistemtrairo, kutime mezurita en petoj je sekundo. Mezuradoj ofte estas agregitaj: krudaj datenoj unue estas kolektitaj kaj poste konvertitaj en ŝanĝorapidecon, meznombran aŭ percentilon.
Ideale, SLI rekte mezuras la servnivelon de intereso, sed foje nur rilata metriko estas havebla por mezurado ĉar la originalo malfacilas akiri aŭ interpreti. Ekzemple, latencia kliento ofte estas pli taŭga metriko, sed estas tempoj kiam la latenco nur povas esti mezurita sur la servilo.
Alia speco de SLI, kiu estas grava al SREoj, estas havebleco, aŭ la tempodaŭro dum kiu servo povas esti uzata. Ofte difinita kiel la indico de sukcesaj petoj, foje nomita rendimento. (Vivdaŭro—la verŝajneco ke datumoj estos konservitaj por plilongigita tempodaŭro—ankaŭ gravas por datumstokaj sistemoj.) Kvankam 100% havebleco ne estas ebla, havebleco proksime al 100% estas ofte atingebla; haveblecaj valoroj estas esprimitaj kiel la nombro de "naŭ" » procento de havebleco. Ekzemple, 99% kaj 99,999% havebleco povus esti etikeditaj kiel "2 naŭoj" kaj "5 naŭoj". La nuna deklarita havebleccelo de Google Compute Engine estas "tri kaj duono naŭ" aŭ 99,95%.
Objektivoj
SLO estas servnivela celo: celvaloro aŭ gamo de valoroj por serva nivelo, kiu estas mezurita de la SLI. Normala valoro por SLO estas "SLI ≤ Celo" aŭ "Malsupra Limo ≤ SLI ≤ Supra Limo". Ekzemple, ni eble decidos, ke ni resendos Ŝekspirrezultajn serĉrezultojn "rapide" agordante la SLO al averaĝa serĉa latenteco de malpli ol 100 milisekundoj.
Elekti la ĝustan SLO estas kompleksa procezo. Unue, vi ne ĉiam povas elekti specifan valoron. Por eksteraj envenantaj HTTP-petoj al via servo, la metriko de Demando por Sekundo (QPS) estas ĉefe determinita de la deziro de viaj uzantoj viziti vian servon, kaj vi ne povas agordi SLO por tio.
Aliflanke, vi povas diri, ke vi volas, ke la averaĝa latenco por ĉiu peto estu malpli ol 100 milisekundoj. Fiksi tian celon povas devigi vin skribi vian fasadon kun malalta latenco aŭ aĉeti ekipaĵon kiu provizas tian latencia. (100 milisekundoj estas evidente arbitra nombro, sed estas pli bone havi eĉ pli malaltajn latentecajn nombrojn. Estas evidenteco sugestas, ke rapidaj rapidoj estas pli bonaj ol malrapidaj rapidoj, kaj ke latenco en prilaborado de uzantpetoj super certaj valoroj efektive devigas homojn resti for. de via servo.)
Denove, ĉi tio estas pli ambigua ol ĝi povus ŝajni unuavide: vi ne devus tute ekskludi QPS de la kalkulo. La fakto estas, ke QPS kaj latencia estas forte rilataj unu al la alia: pli alta QPS ofte kondukas al pli altaj latentecoj, kaj servoj kutime spertas akran malkreskon en rendimento kiam ili atingas certan ŝarĝsojlon.
Elekti kaj publikigi SLO fiksas uzantajn atendojn pri kiel funkcios la servo. Ĉi tiu strategio povas redukti senbazajn plendojn kontraŭ la servoposedanto, kiel malrapida agado. Sen eksplicita SLO, uzantoj ofte kreas siajn proprajn atendojn pri dezirata agado, kiu eble havas nenion komunan kun la opinioj de la homoj dezajnantaj kaj administrante la servon. Ĉi tiu situacio povas konduki al ŝveligitaj atendoj de la servo, kiam uzantoj erare kredas ke la servo estos pli alirebla ol ĝi fakte estas, kaj kaŭzi malfidon kiam uzantoj kredas ke la sistemo estas malpli fidinda ol ĝi fakte estas.
Interkonsentoj
Interkonsento pri serva nivelo estas eksplicita aŭ implica kontrakto kun viaj uzantoj, kiu inkluzivas la sekvojn de renkonti (aŭ ne renkonti) la SLO-ojn kiujn ili enhavas. Konsekvencoj estas plej facile rekonitaj kiam ili estas financaj - rabato aŭ monpuno - sed ili povas preni aliajn formojn. Facila maniero paroli pri la diferenco inter SLO-oj kaj SLA-oj estas demandi "kio okazas se la SLO-oj ne estas plenumitaj?" Se ne estas klaraj sekvoj, vi preskaŭ certe rigardas SLO.
La SRE kutime ne estas implikita en kreado de SLAoj ĉar SLAoj estas proksime ligitaj al komercaj kaj produktaj decidoj. La SRE, aliflanke, estas engaĝita en helpado mildigi la sekvojn de malsukcesaj SLOoj. Ili ankaŭ povas helpi determini la SLI: Evidente, devas ekzisti objektiva maniero mezuri la SLO en la interkonsento aŭ estos malkonsento.
Google Search estas ekzemplo de grava servo, kiu ne havas publikan SLA: ni volas, ke ĉiuj uzu Serĉon kiel eble plej efike, sed ni ne subskribis kontrakton kun la mondo. Tamen, ankoraŭ ekzistas sekvoj se serĉo ne disponeblas - nedisponebleco rezultigas falon de nia reputacio kaj ankaŭ reduktitan reklaman enspezon. Multaj aliaj Google-servoj, kiel ekzemple Google for Work, havas eksplicitajn servnivelajn interkonsentojn kun uzantoj. Sendepende de ĉu aparta servo havas SLA, estas grave difini la SLI kaj SLO kaj uzi ilin por administri la servon.
Tiom da teorio - nun sperti.
Indikiloj en la praktiko
Konsiderante ke ni konkludis, ke estas grave elekti taŭgajn metrikojn por mezuri servonivelon, kiel vi nun scias, kiuj metrikoj gravas por servo aŭ sistemo?
Pri kio vi kaj viaj uzantoj zorgas?
Vi ne bezonas uzi ĉiun metrikon kiel SLI, kiun vi povas spuri en monitora sistemo; Kompreni kion uzantoj volas de sistemo helpos vin elekti plurajn metrikojn. Elekti tro multajn indikilojn malfaciligas koncentriĝi pri gravaj indikiloj, dum elekti malgrandan nombron povas lasi grandajn partojn de via sistemo neatendita. Ni kutime uzas plurajn ŝlosilajn indikilojn por taksi kaj kompreni la sanon de sistemo.
Servoj ĝenerale povas esti dividitaj en plurajn partojn laŭ SLI, kiuj rilatas al ili:
- Propraj antaŭfinaj sistemoj, kiel la serĉinterfacoj por la Ŝekspir-servo el nia ekzemplo. Ili devas esti disponeblaj, ne havi prokrastojn kaj havi sufiĉan larĝan bandon. Sekve oni povas fari demandojn: ĉu ni povas respondi al la peto? Kiom da tempo daŭris por respondi al la peto? Kiom da petoj povas esti procesitaj?
- Stoksistemoj. Ili taksas malaltan respondan latentecon, haveblecon kaj fortikecon. Rilataj demandoj: Kiom da tempo necesas por legi aŭ skribi datumojn? Ĉu ni povas aliri la datumojn laŭpeto? Ĉu la datumoj haveblas kiam ni bezonas ĝin? Vidu Ĉapitro 26 Datuma Integreco: Kion Vi Legas Estas Kion Vi Skribas por detala diskuto pri ĉi tiuj aferoj.
- Grandaj datumsistemoj kiel ekzemple datumtraktadduktoj dependas de trafluo kaj demanda prilaborado latenteco. Rilataj demandoj: Kiom da datumoj estas prilaboritaj? Kiom da tempo necesas por ke datumoj veturas de ricevado de peto ĝis emisio de respondo? (Kelkaj partoj de la sistemo ankaŭ povas havi prokrastojn en certaj stadioj.)
Kolekto de indikiloj
Multaj servnivelaj indikiloj estas plej nature kolektitaj ĉe la servilflanko, uzante monitoran sistemon kiel Borgmon (vidu malsupre). ) aŭ Prometheus, aŭ simple periode analizante la protokolojn, identigante HTTP-respondojn kun statuso 500. Tamen, iuj sistemoj devus esti ekipitaj per klient-flanka metrikkolekto, ĉar la manko de klient-flanka monitorado povas konduki al maltrafi kelkajn problemojn kiuj influas. uzantoj, sed ne influas servilflankajn metrikojn. Ekzemple, koncentriĝi pri la backend responda latenteco de nia Ŝekspir-serĉa testo-aplikaĵo povas rezultigi latentecon ĉe la uzanto-flanko pro JavaScript-problemoj: en ĉi tiu kazo, mezuri kiom da tempo necesas la retumilo por prilabori la paĝon estas pli bona metriko.
Agregado
Por simpleco kaj facileco de uzo, ni ofte kunigas krudajn mezurojn. Ĉi tio devas esti farita zorge.
Iuj metrikoj ŝajnas simplaj, kiel petoj je sekundo, sed eĉ ĉi tiu ŝajne simpla mezurado implicite agregas datumojn laŭlonge de la tempo. Ĉu la mezurado ricevas specife unufoje je sekundo aŭ ĉu la mezurado estas averaĝata laŭ la nombro da petoj je minuto? Ĉi-lasta opcio povas kaŝi multe pli altan tujan nombron da petoj, kiuj daŭras nur kelkajn sekundojn. Konsideru sistemon, kiu servas 200 petojn je sekundo kun paraj nombroj kaj 0 la reston de la tempo. Konstanto en la formo de averaĝa valoro de 100 petoj je sekundo kaj dufoje la tuja ŝarĝo ne estas la sama afero. Simile, averaĝi demandajn latentecojn povas ŝajni alloga, sed ĝi kaŝas gravan detalon: eblas, ke la plej multaj demandoj estos rapidaj, sed estos multaj demandoj, kiuj estas malrapidaj.
Plej multaj indikiloj estas pli bone rigardataj kiel distribuoj prefere ol mezumoj. Ekzemple, por SLI-latenteco, iuj petoj estos procesitaj rapide, dum iuj ĉiam daŭros pli longe, foje multe pli longe. Simpla mezumo povas kaŝi ĉi tiujn longajn malfruojn. La figuro montras ekzemplon: kvankam tipa peto bezonas proksimume 50 ms por servi, 5% de petoj estas 20 fojojn pli malrapidaj! Monitorado kaj atentigo bazita nur sur averaĝa latencia ne montras ŝanĝojn en konduto dum la tuta tago, kiam fakte estas rimarkindaj ŝanĝoj en la prilaborado de iuj petoj (plej supra linio).
50, 85, 95, kaj 99 percentila sistemo latenteco. La Y-akso estas en logaritma formato.
Uzado de percentiloj por indikiloj permesas vidi la formon de la distribuo kaj ĝiaj karakterizaĵoj: alta percentila nivelo, kiel ekzemple 99 aŭ 99,9, montras la plej malbonan valoron, dum la 50 percentilo (ankaŭ konata kiel la mediano) montras la plej oftan staton de la metriko. Ju pli granda la responda tempodisvastigo, des pli longdaŭraj petoj influas la uzantan sperton. La efiko estas plifortigita sub alta ŝarĝo kaj en ĉeesto de vostoj. Esplorado de uzanto-sperto montris, ke homoj ĝenerale preferas pli malrapidan sistemon kun alta responda tempovarianco, do iuj SRE-teamoj fokusiĝas nur al altaj procentaj poentaroj, surbaze, ke se la konduto de metriko ĉe la 99,9 percentilo estas bona, la plej multaj uzantoj ne spertos problemojn. .
Noto pri statistikaj eraroj
Ni ĝenerale preferas labori kun procentoj prefere ol la meznombro (aritmetika meznombro) de aro de valoroj. Ĉi tio permesas al ni konsideri pli disajn valorojn, kiuj ofte havas signife malsamajn (kaj pli interesajn) trajtojn ol la mezumo. Pro la artefarita naturo de komputikaj sistemoj, metrikaj valoroj ofte estas distorditaj, ekzemple neniu peto povas ricevi respondon en malpli ol 0 ms, kaj tempodaŭro de 1000 ms signifas, ke ne povas esti sukcesaj respondoj kun valoroj pli grandaj. ol la paŭzo. Kiel rezulto, ni ne povas akcepti, ke la meznombro kaj mediano povas esti la sama aŭ proksima unu al la alia!
Sen antaŭa testado, kaj krom se certaj normaj supozoj kaj proksimumoj validas, ni zorgas ne konkludi, ke niaj datumoj estas normale distribuitaj. Se la distribuo ne estas tia, la aŭtomatigprocezo, kiu riparas la problemon (ekzemple, kiam ĝi vidas eksteraĵojn, ĝi rekomencas la servilon kun altaj petaj prilaboraj latentecoj) povas fari ĝin tro ofte aŭ ne sufiĉe ofte (kiuj ambaŭ ne estas. tre bona).
Normigi indikilojn
Ni rekomendas normigi la ĝeneralajn karakterizaĵojn por SLI por ke vi ne devu spekuli pri ili ĉiufoje. Ĉiu trajto kiu kontentigas normajn padronojn povas esti ekskludita de la specifo de individua SLI, ekzemple:
- Agregaj intervaloj: "averaĝe pli ol 1 minuto"
- Agregaj areoj: "Ĉiuj taskoj en la areto"
- Kiom ofte oni faras mezurojn: "Ĉiuj 10 sekundoj"
- Kiaj petoj estas inkluzivitaj: "HTTP GET de laborpostenoj pri monitorado de nigra skatolo"
- Kiel la datumoj estas akiritaj: "Dankon al nia monitorado mezurita sur la servilo"
- Latenteco de aliro al datumoj: "Tempo por lasta bajto"
Por ŝpari penon, kreu aron da reuzeblaj SLI-ŝablonoj por ĉiu komuna metriko; ili ankaŭ faciligas al ĉiuj kompreni kion signifas certa SLI.
Celoj en praktiko
Komencu pensi (aŭ ekscii!) pri kio zorgas viaj uzantoj, ne pri tio, kion vi povas mezuri. Ofte tio, pri kio viaj uzantoj zorgas, estas malfacile aŭ neeble mezurebla, do vi finas proksimiĝi al iliaj bezonoj. Tamen, se vi nur komencas per kio estas facile mezurebla, vi finos kun malpli utilaj SLOoj. Kiel rezulto, ni foje trovis, ke komence identigi deziratajn celojn kaj poste labori kun specifaj indikiloj funkcias pli bone ol elekti indikilojn kaj poste atingi la celojn.
Difinu viajn celojn
Por maksimuma klareco, ĝi devus esti difinita kiel SLOoj estas mezuritaj kaj la kondiĉoj sub kiuj ili validas. Ekzemple, ni povus diri la jenon (la dua linio estas la sama kiel la unua, sed uzas la defaŭltajn SLI):
- 99% (averaĝe pli ol 1 minuto) de Get RPC-vokoj finiĝos en malpli ol 100ms (mezuritaj tra ĉiuj backend-serviloj).
- 99% de Get RPC-vokoj finiĝos en malpli ol 100ms.
Se la formo de la rendimentokurboj estas grava, vi povas specifi plurajn SLOojn:
- 90% de Get RPC-vokoj finiĝis en malpli ol 1 ms.
- 99% de Get RPC-vokoj finiĝis en malpli ol 10 ms.
- 99.9% de Get RPC-vokoj finiĝis en malpli ol 100 ms.
Se viaj uzantoj generas heterogenajn laborŝarĝojn: pogranda prilaborado (por kiu trairo estas grava) kaj interaga prilaborado (por kiu latencia estas grava), eble indas difini apartajn celojn por ĉiu ŝarĝklaso:
- 95% de klientpetoj postulas trairon. Agordu la nombron de RPC-vokoj efektivigitaj <1 s.
- 99% de klientoj zorgas pri la latenco. Agordu la nombron de RPC-vokoj kun trafiko <1 KB kaj kuranta <10 ms.
Estas nereale kaj nedezirinda insisti, ke SLO-oj estos plenumitaj 100% de la tempo: ĉi tio povas redukti la ritmon de enkonduko de novaj funkcioj kaj deplojo, kaj postuli multekostajn solvojn. Anstataŭe, estas pli bone permesi erarbuĝeton - la procenton de sistemo malfunkcio permesita - kaj kontroli ĉi tiun valoron ĉiutage aŭ semajne. Altranga administrado eble volas monatajn aŭ trimonatajn taksojn. (La erara buĝeto estas simple SLO por komparo kun alia SLO.)
La procento de SLO-malobservoj povas esti komparita kun la erara buĝeto (vidu Ĉapitro 3 kaj sekcion ), kun la diferencvaloro utiligita kiel enigaĵo al la procezo kiu decidas kiam deploji novajn eldonojn.
Elektante celvalorojn
Elekti planajn valorojn (SLO) ne estas pure teknika agado pro la produktaj kaj komercaj interesoj, kiuj devas esti reflektitaj en la elektitaj SLIoj, SLOoj (kaj eble SLAoj). Same, eble necesas interŝanĝi informojn pri aferoj rilataj al dungitaro, tempo al merkato, ekipaĵhavebleco kaj financado. SRE devus esti parto de ĉi tiu konversacio kaj helpi kompreni la riskojn kaj daŭrigeblecon de malsamaj elektoj. Ni elpensis kelkajn demandojn, kiuj povus helpi certigi pli produktivan diskuton:
Ne elektu celon bazitan sur nuna agado.
Dum kompreni la fortojn kaj limojn de sistemo gravas, adapti metrikojn sen rezonado povas malhelpi vin konservi la sistemon: ĝi postulos heroajn klopodojn atingi celojn, kiuj ne povas esti atingitaj sen grava restrukturado.
Konservu ĝin simpla
Kompleksaj SLI-kalkuloj povas kaŝi ŝanĝojn en sistema rendimento kaj malfaciligi trovi la kaŭzon de la problemo.
Evitu absolutajn
Kvankam estas tenta havi sistemon, kiu povas trakti senfine kreskantan ŝarĝon sen pliigi latentecon, ĉi tiu postulo estas nerealisma. Sistemo kiu alproksimiĝas al tiaj idealoj verŝajne postulos multan tempon por desegni kaj konstrui, estos multekosta funkcii kaj estos tro bona por la atendoj de uzantoj, kiuj farus ion malpli.
Uzu kiel eble plej malmultajn SLO-ojn
Elektu sufiĉan nombron da SLO-oj por certigi bonan priraportadon de sistemaj atributoj. Protektu la SLO-ojn, kiujn vi elektas: Se vi neniam povas gajni argumenton pri prioritatoj specifante specifan SLO, verŝajne ne indas konsideri tiun SLO. Tamen, ne ĉiuj sistematributoj estas alireblaj al SLOoj: estas malfacile kalkuli la nivelon de uzantĝojo uzante SLOojn.
Ne persekutu perfektecon
Vi ĉiam povas rafini la difinojn kaj celojn de SLO-oj laŭlonge de la tempo dum vi lernas pli pri la konduto de la sistemo sub ŝarĝo. Estas pli bone komenci per flosanta celo, kiun vi rafinos kun la tempo, ol elekti tro striktan celon, kiu devas esti malstreĉita kiam vi trovas, ke ĝi estas neatingebla.
SLOoj povas kaj devas esti ŝlosila ŝoforo en prioritatado de laboro por SREoj kaj produktoprogramistoj ĉar ili reflektas zorgon por uzantoj. Bona SLO estas utila plenuma ilo por evolua teamo. Sed malbone dizajnita SLO povas konduki al malŝparema laboro se la teamo faras heroajn klopodojn atingi tro agreseman SLO, aŭ malbonan produkton se la SLO estas tro malalta. SLO estas potenca levilo, uzu ĝin saĝe.
Kontrolu viajn mezuradojn
SLI kaj SLO estas ŝlosilaj elementoj uzataj por administri sistemojn:
- Monitoru kaj mezuru SLI-sistemojn.
- Komparu SLI al SLO kaj decidu ĉu ago estas necesa.
- Se ago estas postulata, eltrovu, kio devas okazi por atingi la celon.
- Plenumu ĉi tiun agon.
Ekzemple, se paŝo 2 montras ke la peto finiĝas kaj rompos la SLO en kelkaj horoj se nenio estas farita, paŝo 3 eble implikos testi la hipotezon ke la serviloj estas CPU ligitaj kaj aldoni pli da serviloj distribuos la ŝarĝon. Sen SLO, vi ne scius ĉu (aŭ kiam) agi.
Agordu SLO - tiam uzantaj atendoj estos fiksitaj
Eldoni SLO fiksas uzantajn atendojn por sistema konduto. Uzantoj (kaj eblaj uzantoj) ofte volas scii kion atendi de servo por kompreni ĉu ĝi taŭgas por uzo. Ekzemple, homoj dezirantaj uzi foto-kunhavan retejon eble volas eviti uzi servon kiu promesas longvivecon kaj malaltan koston kontraŭ iomete malpli havebleco, kvankam la sama servo povus esti ideala por arĥiva rekorda administradsistemo.
Por agordi realismajn atendojn por viaj uzantoj, uzu unu aŭ ambaŭ el la sekvaj taktikoj:
- Konservu marĝenon de sekureco. Uzu pli striktan internan SLO ol kio estas reklamita al uzantoj. Ĉi tio donos al vi la ŝancon reagi al problemoj antaŭ ol ili fariĝos ekstere videblaj. La SLO-bufro ankaŭ ebligas al vi havi sekurecan marĝenon kiam vi instalas eldonojn, kiuj influas sisteman rendimenton kaj certigas, ke la sistemo estas facile konservebla sen devi frustri uzantojn kun malfunkcio.
- Ne superu la atendojn de uzantoj. Uzantoj baziĝas sur tio, kion vi proponas, ne sur tio, kion vi diras. Se la reala agado de via servo estas multe pli bona ol la deklarita SLO, uzantoj fidos je la nuna agado. Vi povas eviti troan dependecon intence fermante la sistemon aŭ limigante rendimenton sub malpezaj ŝarĝoj.
Kompreni kiom bone sistemo renkontas atendojn helpas decidi ĉu investi en akceli la sistemon kaj igi ĝin pli alirebla kaj rezistema. Alternative, se servo funkcias tro bone, iom da dungita tempo devus esti elspezita por aliaj prioritatoj, kiel pagi teknikan ŝuldon, aldoni novajn funkciojn aŭ enkonduki novajn produktojn.
Interkonsentoj en la praktiko
Krei SLA postulas komercajn kaj jurajn teamojn difini la sekvojn kaj punojn por malobservo de ĝi. La rolo de la SRE estas helpi ilin kompreni la verŝajnajn defiojn en renkontado de la SLOoj enhavitaj en la SLA. La plej multaj el la rekomendoj por krei SLO-ojn ankaŭ validas por SLA-oj. Estas saĝe esti konservativa pri tio, kion vi promesas al uzantoj, ĉar ju pli vi havas, des pli malfacilas ŝanĝi aŭ forigi SLA-ojn, kiuj ŝajnas neraciaj aŭ malfacile plenumeblaj.
Dankon pro legi la tradukon ĝis la fino. Abonu mian telegraman kanalon pri monitorado и .
fonto: www.habr.com