SRE (Uhandisi wa Kuegemea wa Tovuti) ni mbinu ya kufanya miradi ya wavuti kufikiwa. Inachukuliwa kuwa mfumo wa DevOps na inaelezea jinsi ya kufaulu katika utumiaji wa mazoea ya DevOps. Makala hii inatafsiri vitabu kutoka Google. Nilitayarisha tafsiri hii mwenyewe na kutegemea uzoefu wangu mwenyewe katika kuelewa michakato ya ufuatiliaji. Katika chaneli ya telegraph и Pia nilichapisha tafsiri ya Sura ya 6 ya kitabu hicho hicho kuhusu malengo ya kiwango cha huduma.
Tafsiri ya paka. Furahia kusoma!
Haiwezekani kusimamia huduma ikiwa hakuna uelewa wa viashiria muhimu na jinsi ya kuvipima na kuvitathmini. Ili kufikia hili, tunafafanua na kutoa kiwango fulani cha huduma kwa watumiaji wetu, bila kujali kama wanatumia mojawapo ya API zetu za ndani au bidhaa ya umma.
Tunatumia angaleo, uzoefu na uelewa wetu wa hamu ya watumiaji kuelewa Viashiria vya Kiwango cha Huduma (SLI), Malengo ya Kiwango cha Huduma (SLOs), na Makubaliano ya Kiwango cha Huduma (SLAs). Vipimo hivi vinaelezea vipimo vikuu ambavyo tunataka kufuatilia na ambavyo tutatenda ikiwa hatuwezi kutoa ubora unaotarajiwa wa huduma. Hatimaye, kuchagua vipimo vinavyofaa husaidia kuongoza hatua zinazofaa ikiwa kitu kitaenda vibaya, na pia huipa timu ya SRE imani katika afya ya huduma.
Sura hii inaelezea mbinu tunayotumia kupambana na matatizo ya uundaji wa metri, uteuzi wa metri na uchanganuzi wa metri. Ufafanuzi mwingi hautakuwa na mifano, kwa hivyo tutatumia huduma ya Shakespeare iliyoelezewa katika mfano wake wa utekelezaji (tafuta kazi za Shakespeare) ili kuelezea hoja kuu.
Istilahi ya kiwango cha huduma
Wasomaji wengi huenda wanafahamu dhana ya SLA, lakini istilahi SLI na SLO zinastahili ufafanuzi makini kwa sababu kwa ujumla neno SLA limejaa kupita kiasi na lina maana kadhaa kulingana na muktadha. Kwa uwazi, tunataka kutenganisha maadili haya.
Viashiria
SLI ni kiashirio cha kiwango cha huduma—kipimo kilichofafanuliwa kwa uangalifu cha kiasi cha kipengele kimoja cha kiwango cha huduma inayotolewa.
Kwa huduma nyingi, SLI muhimu inachukuliwa kuwa muda wa ombi - inachukua muda gani kurejesha jibu kwa ombi. SLI zingine za kawaida ni pamoja na kiwango cha makosa, ambacho mara nyingi huonyeshwa kama sehemu ya maombi yote yanayopokelewa, na matokeo ya mfumo, ambayo kawaida hupimwa kwa maombi kwa sekunde. Vipimo mara nyingi hujumlishwa: data ghafi hukusanywa kwanza na kisha kubadilishwa kuwa kiwango cha mabadiliko, wastani au asilimia.
Kwa hakika, SLI hupima moja kwa moja kiwango cha riba cha huduma, lakini wakati mwingine ni kipimo kinachohusiana pekee kinachopatikana kwa kipimo kwa sababu cha awali ni vigumu kupata au kufasiri. Kwa mfano, muda wa kusubiri wa mteja mara nyingi ni kipimo kinachofaa zaidi, lakini kuna nyakati ambapo muda wa kusubiri unaweza kupimwa kwenye seva pekee.
Aina nyingine ya SLI ambayo ni muhimu kwa SRE ni upatikanaji, au sehemu ya muda ambayo huduma inaweza kutumika. Mara nyingi hufafanuliwa kama kiwango cha maombi yaliyofaulu, wakati mwingine huitwa mavuno. (Muda wa maisha—uwezekano wa kwamba data itahifadhiwa kwa muda mrefu—pia ni muhimu kwa mifumo ya kuhifadhi data.) Ingawa upatikanaji wa 100% hauwezekani, upatikanaji wa karibu 100% mara nyingi unaweza kupatikana; thamani za upatikanaji zinaonyeshwa kama idadi ya "nines" » asilimia ya upatikanaji. Kwa mfano, upatikanaji wa 99% na 99,999% unaweza kuwekewa lebo ya "tisa 2" na "tisa 5". Lengo la sasa la upatikanaji wa Google Compute Engine ni "tisa tisa na nusu" au 99,95%.
Malengo ya
SLO ni lengo la kiwango cha huduma: thamani inayolengwa au anuwai ya thamani kwa kiwango cha huduma ambayo hupimwa na SLI. Thamani ya kawaida ya SLO ni "SLI ≤ Lengo" au "Kikomo cha Chini ≤ SLI ≤ Kikomo cha Juu". Kwa mfano, tunaweza kuamua kwamba tutarejesha matokeo ya utafutaji wa Shakespeare "haraka" kwa kuweka SLO hadi muda wa kusubiri wa hoja ya utafutaji wa chini ya milisekunde 100.
Kuchagua SLO sahihi ni mchakato mgumu. Kwanza, huwezi kuchagua thamani maalum kila wakati. Kwa maombi yanayoingia ya HTTP ya nje kwa huduma yako, kipimo cha Query Per Second (QPS) kimsingi huamuliwa na hamu ya watumiaji wako kutembelea huduma yako, na huwezi kuweka SLO kwa hilo.
Kwa upande mwingine, unaweza kusema kwamba unataka muda wa kusubiri wastani kwa kila ombi kuwa chini ya milisekunde 100. Kuweka lengo kama hilo kunaweza kukulazimisha kuandika sehemu ya mbele yako kwa muda wa chini au kununua vifaa vinavyotoa muda kama huo. (Milisekunde 100 bila shaka ni nambari ya kiholela, lakini ni bora kuwa na nambari za muda za chini zaidi. Kuna ushahidi wa kupendekeza kwamba kasi ya haraka ni bora kuliko ya polepole, na kwamba utulivu katika usindikaji maombi ya mtumiaji juu ya maadili fulani kwa kweli huwalazimisha watu kukaa mbali. kutoka kwa huduma yako.)
Tena, hii ni ngumu zaidi kuliko inavyoweza kuonekana mwanzoni: haupaswi kuwatenga kabisa QPS kutoka kwa hesabu. Ukweli ni kwamba QPS na latency zinahusiana sana: QPS ya juu mara nyingi husababisha latencies ya juu, na huduma kawaida hupata kupungua kwa kasi kwa utendaji wakati wanafikia kizingiti fulani cha mzigo.
Kuchagua na kuchapisha SLO huweka matarajio ya mtumiaji kuhusu jinsi huduma itafanya kazi. Mkakati huu unaweza kupunguza malalamiko yasiyo na msingi dhidi ya mmiliki wa huduma, kama vile utendakazi polepole. Bila SLO dhahiri, watumiaji mara nyingi huunda matarajio yao kuhusu utendakazi wanaotaka, ambayo inaweza kuwa haihusiani na maoni ya watu wanaounda na kusimamia huduma. Hali hii inaweza kusababisha matarajio ya kuongezeka kutoka kwa huduma, wakati watumiaji wanaamini kimakosa kuwa huduma itafikiwa zaidi kuliko ilivyo kweli, na kusababisha kutoaminiana wakati watumiaji wanaamini kuwa mfumo hautegemeki kuliko ulivyo.
Makubaliano
Makubaliano ya kiwango cha huduma ni mkataba wa wazi au usiofichika na watumiaji wako unaojumuisha matokeo ya kufikia (au kutotimiza) SLO zilizomo. Matokeo yanatambulika kwa urahisi zaidi yakiwa ya kifedha—punguzo au faini—lakini yanaweza kuchukua aina nyinginezo. Njia rahisi ya kuzungumzia tofauti kati ya SLO na SLA ni kuuliza "nini kitatokea ikiwa SLO hazitafikiwa?" Ikiwa hakuna matokeo ya wazi, karibu bila shaka unatazama SLO.
SRE kwa kawaida haishirikishwi katika kuunda SLA kwa sababu SLA zinafungamana kwa karibu na maamuzi ya biashara na bidhaa. SRE, hata hivyo, inahusika katika kusaidia kupunguza matokeo ya SLO zilizoshindwa. Wanaweza pia kusaidia kuamua SLI: Ni wazi, lazima kuwe na njia madhubuti ya kupima SLO katika makubaliano au kutakuwa na kutokubaliana.
Huduma ya Tafuta na Google ni mfano wa huduma muhimu ambayo haina SLA ya umma: tunataka kila mtu atumie Utafutaji kwa ufanisi iwezekanavyo, lakini hatujatia saini mkataba na ulimwengu. Hata hivyo, bado kuna madhara ikiwa utafutaji haupatikani - kutopatikana kunasababisha kushuka kwa sifa yetu na pia kupunguza mapato ya utangazaji. Huduma zingine nyingi za Google, kama vile Google for Work, zina makubaliano ya kiwango cha huduma na watumiaji. Bila kujali ikiwa huduma fulani ina SLA, ni muhimu kufafanua SLI na SLO na kuzitumia kusimamia huduma.
Nadharia nyingi - sasa kupata uzoefu.
Viashiria katika mazoezi
Kwa kuzingatia kwamba tumehitimisha kuwa ni muhimu kuchagua vipimo vinavyofaa ili kupima kiwango cha huduma, unajuaje sasa ni vipimo vipi muhimu kwa huduma au mfumo?
Je, wewe na watumiaji wako mnajali nini?
Huhitaji kutumia kila kipimo kama SLI unayoweza kufuatilia katika mfumo wa ufuatiliaji; Kuelewa ni nini watumiaji wanataka kutoka kwa mfumo kutakusaidia kuchagua vipimo kadhaa. Kuchagua viashiria vingi hufanya iwe vigumu kuzingatia viashiria muhimu, wakati kuchagua idadi ndogo inaweza kuacha vipande vikubwa vya mfumo wako bila tahadhari. Kwa kawaida sisi hutumia viashirio kadhaa muhimu kutathmini na kuelewa afya ya mfumo.
Huduma kwa ujumla zinaweza kugawanywa katika sehemu kadhaa kulingana na SLI ambazo ni muhimu kwao:
- Mifumo maalum ya mbele, kama vile violesura vya utafutaji vya huduma ya Shakespeare kutoka kwa mfano wetu. Ni lazima ziwepo, zisiwe na ucheleweshaji na ziwe na bandwidth ya kutosha. Ipasavyo, maswali yanaweza kuulizwa: tunaweza kujibu ombi? Ilichukua muda gani kujibu ombi hilo? Ni maombi mangapi yanaweza kushughulikiwa?
- Mifumo ya kuhifadhi. Wanathamini muda wa chini wa majibu, upatikanaji na uimara. Maswali yanayohusiana: Inachukua muda gani kusoma au kuandika data? Je, tunaweza kufikia data kwa ombi? Je, data inapatikana tunapoihitaji? Tazama Sura ya 26 Uadilifu wa Data: Ulichosoma Ndicho Unachoandika kwa mjadala wa kina wa masuala haya.
- Mifumo mikubwa ya data kama vile mabomba ya kuchakata data hutegemea upitishaji na ucheleweshaji wa usindikaji wa hoja. Maswali yanayohusiana: Ni data ngapi inachakatwa? Je, inachukua muda gani kwa data kusafiri kutoka kupokea ombi hadi kutoa jibu? (Baadhi ya sehemu za mfumo zinaweza pia kuwa na ucheleweshaji katika hatua fulani.)
Mkusanyiko wa viashiria
Viashiria vingi vya kiwango cha huduma hukusanywa kwa kawaida kwenye upande wa seva, kwa kutumia mfumo wa ufuatiliaji kama vile Borgmon (tazama hapa chini). ) au Prometheus, au kuchanganua kumbukumbu mara kwa mara, kubainisha majibu ya HTTP yenye hali ya 500. Hata hivyo, baadhi ya mifumo inapaswa kuwa na mkusanyiko wa vipimo vya upande wa mteja, kwa kuwa ukosefu wa ufuatiliaji wa upande wa mteja unaweza kusababisha kukosa idadi ya matatizo ambayo huathiri. watumiaji, lakini zisiathiri vipimo vya upande wa seva. Kwa mfano, kuangazia muda wa kusubiri wa majibu ya nyuma ya ombi letu la jaribio la utafutaji la Shakespeare kunaweza kusababisha kusubiri kwa upande wa mtumiaji kutokana na masuala ya JavaScript: katika hali hii, kupima muda unaochukua kivinjari kuchakata ukurasa ni kipimo bora.
Kujumlisha
Kwa urahisi na urahisi wa matumizi, mara nyingi tunajumlisha vipimo vibichi. Hii lazima ifanyike kwa uangalifu.
Baadhi ya vipimo vinaonekana kuwa rahisi, kama maombi kwa sekunde, lakini hata kipimo hiki cha moja kwa moja hujumlisha data kwa muda. Je, kipimo kinapokelewa mahususi mara moja kwa sekunde au kipimo kinakadiriwa juu ya idadi ya maombi kwa dakika? Chaguo la mwisho linaweza kuficha idadi ya juu zaidi ya maombi ambayo hudumu sekunde chache tu. Fikiria mfumo unaohudumia maombi 200 kwa sekunde yenye nambari sawa na 0 wakati wote. Mara kwa mara kwa namna ya thamani ya wastani ya maombi 100 kwa pili na mara mbili ya mzigo wa papo hapo sio kitu sawa. Vile vile, ucheleweshaji wa swala wa wastani unaweza kuonekana kuvutia, lakini huficha maelezo muhimu: inawezekana kwamba maswali mengi yatakuwa ya haraka, lakini kutakuwa na maswali mengi ambayo ni polepole.
Viashiria vingi hufikiriwa vyema kama usambazaji badala ya wastani. Kwa mfano, kwa muda wa kusubiri wa SLI, baadhi ya maombi yatashughulikiwa haraka, wakati baadhi yatachukua muda mrefu zaidi, wakati mwingine zaidi. Wastani rahisi unaweza kuficha ucheleweshaji huu mrefu. Takwimu inaonyesha mfano: ingawa ombi la kawaida huchukua takriban 50 ms kutumika, 5% ya maombi ni polepole mara 20! Ufuatiliaji na tahadhari kwa kuzingatia tu muda wa wastani wa kusubiri hauonyeshi mabadiliko ya tabia siku nzima, wakati kwa kweli kuna mabadiliko yanayoonekana katika muda wa usindikaji wa baadhi ya maombi (mstari wa juu kabisa).
Ucheleweshaji wa mfumo wa 50, 85, 95, na 99%. Mhimili wa Y uko katika umbizo la logarithmic.
Kutumia asilimia kwa viashiria hukuruhusu kuona umbo la usambazaji na sifa zake: kiwango cha juu cha asilimia, kama vile 99 au 99,9, kinaonyesha thamani mbaya zaidi, wakati asilimia 50 (pia inajulikana kama wastani) inaonyesha hali ya mara kwa mara ya kipimo. Kadiri mtawanyiko wa muda wa majibu unavyoongezeka, ndivyo maombi ya muda mrefu yanavyoathiri matumizi ya mtumiaji. Athari huimarishwa chini ya mzigo mkubwa na mbele ya foleni. Utafiti wa uzoefu wa mtumiaji umeonyesha kuwa kwa ujumla watu wanapendelea mfumo wa polepole na tofauti ya muda wa majibu, kwa hivyo baadhi ya timu za SRE huzingatia tu alama za juu za asilimia, kwa msingi kwamba ikiwa tabia ya kipimo katika asilimia 99,9 ni nzuri, watumiaji wengi hawatakumbana na matatizo. .
Kumbuka juu ya makosa ya takwimu
Kwa ujumla tunapendelea kufanya kazi na asilimia badala ya wastani (wastani wa hesabu) wa seti ya thamani. Hii inaturuhusu kuzingatia thamani zilizotawanywa zaidi, ambazo mara nyingi huwa na sifa tofauti (na zinazovutia zaidi) kuliko wastani. Kwa sababu ya hali ya bandia ya mifumo ya kompyuta, thamani za metri mara nyingi hupotoshwa, kiasi kwamba hakuna ombi linaloweza kupokea jibu chini ya 0 ms, na kuisha kwa 1000 ms inamaanisha kuwa hakuwezi kuwa na majibu yaliyofaulu yenye thamani kubwa kuliko. muda umeisha. Matokeo yake, hatuwezi kukubali kwamba maana na wastani inaweza kuwa sawa au karibu kwa kila mmoja!
Bila majaribio ya awali, na isipokuwa kama makadirio fulani ya kawaida na makadirio yatadhibitiwa, tuko makini tusihitimishe kuwa data yetu inasambazwa kwa kawaida. Ikiwa usambazaji sio kama inavyotarajiwa, mchakato wa otomatiki ambao hurekebisha shida (kwa mfano, inapoona wauzaji, huanzisha tena seva na ucheleweshaji wa usindikaji wa ombi la juu) inaweza kuwa inafanya mara nyingi sana au haitoshi mara nyingi (zote mbili hazifanyi kazi). vizuri sana).
Sawazisha viashiria
Tunapendekeza kusawazisha sifa za jumla za SLI ili usilazimike kubashiri kuzihusu kila wakati. Kipengele chochote kinachokidhi ruwaza za kawaida kinaweza kuondolewa kwenye vipimo vya SLI mahususi, kwa mfano:
- Vipindi vya kujumlisha: "wastani wa zaidi ya dakika 1"
- Maeneo ya kujumlisha: "Kazi zote kwenye nguzo"
- Ni mara ngapi vipimo vinachukuliwa: "Kila sekunde 10"
- Ni maombi gani yamewezeshwa: "HTTP GET kutoka kwa kazi za ufuatiliaji wa kisanduku cheusi"
- Jinsi data inavyopatikana: "Asante kwa ufuatiliaji wetu uliopimwa kwenye seva"
- Muda wa kufikia data: "Wakati wa mwisho"
Ili kuokoa juhudi, unda seti ya violezo vya SLI vinavyoweza kutumika tena kwa kila kipimo cha kawaida; pia hufanya iwe rahisi kwa kila mtu kuelewa maana ya SLI fulani.
Malengo katika mazoezi
Anza kwa kufikiria (au kujua!) watumiaji wako wanajali nini, sio kile unachoweza kupima. Mara nyingi kile ambacho watumiaji wako wanajali ni vigumu au haiwezekani kupima, kwa hivyo unaishia kukaribia mahitaji yao. Hata hivyo, ukianza tu na kile ambacho ni rahisi kupima, utapata SLO muhimu sana. Kutokana na hali hiyo, wakati mwingine tumegundua kuwa mwanzoni kubainisha malengo yanayotarajiwa na kisha kufanya kazi kwa kutumia viashirio mahususi hufanya kazi vizuri zaidi kuliko kuchagua viashiria na kisha kufikia malengo.
Bainisha malengo yako
Kwa uwazi zaidi, inapaswa kufafanuliwa jinsi SLOs hupimwa na masharti ambayo ni halali. Kwa mfano, tunaweza kusema yafuatayo (mstari wa pili ni sawa na wa kwanza, lakini hutumia chaguo-msingi za SLI):
- 99% (wastani wa zaidi ya dakika 1) ya Pata simu za RPC zitakamilika kwa chini ya 100ms (zinazopimwa kwenye seva zote za nyuma).
- 99% ya simu za Pata RPC zitakamilika kwa chini ya 100ms.
Ikiwa umbo la curve za utendakazi ni muhimu, unaweza kubainisha SLO nyingi:
- 90% ya Pata simu za RPC hukamilishwa kwa chini ya ms 1.
- 99% ya Pata simu za RPC hukamilishwa kwa chini ya ms 10.
- 99.9% ya Pata simu za RPC hukamilishwa kwa chini ya ms 100.
Iwapo watumiaji wako hutoa mizigo mingi ya kazi: usindikaji wa wingi (ambao upitishaji ni muhimu) na uchakataji mwingiliano (ambao ucheleweshaji ni muhimu), inaweza kufaa kufafanua malengo tofauti kwa kila darasa la mzigo:
- 95% ya maombi ya mteja yanahitaji upitishaji. Weka hesabu ya simu za RPC zinazotekelezwa <1 s.
- 99% ya wateja wanajali kuhusu muda wa kusubiri. Weka hesabu ya simu za RPC kwa trafiki <1 KB na kukimbia <10 ms.
Sio kweli na haifai kusisitiza kuwa SLOs zitatimizwa 100% ya wakati: hii inaweza kupunguza kasi ya kuanzisha utendakazi mpya na uwekaji, na kuhitaji suluhisho ghali. Badala yake, ni bora kuruhusu bajeti ya makosa - asilimia ya muda wa kupungua kwa mfumo unaoruhusiwa - na ufuatilie thamani hii kila siku au kila wiki. Wasimamizi wakuu wanaweza kutaka tathmini za kila mwezi au robo mwaka. (Bajeti ya makosa ni SLO kwa kulinganisha na SLO nyingine.)
Asilimia ya ukiukaji wa SLO inaweza kulinganishwa na bajeti ya makosa (angalia Sura ya 3 na sehemu ), na thamani ya tofauti inayotumika kama ingizo kwa mchakato unaoamua wakati wa kupeleka matoleo mapya.
Kuchagua maadili lengwa
Kuchagua thamani za kupanga (SLOs) si shughuli ya kiufundi pekee kwa sababu ya bidhaa na maslahi ya biashara ambayo ni lazima yaonekane katika SLI, SLO zilizochaguliwa (na ikiwezekana SLA). Vile vile, taarifa inaweza kuhitaji kubadilishana kuhusu masuala yanayohusiana na uajiri, muda wa soko, upatikanaji wa vifaa na ufadhili. SRE inapaswa kuwa sehemu ya mazungumzo haya na kusaidia kuelewa hatari na uwezekano wa chaguo tofauti. Tumekuja na maswali machache ambayo yanaweza kusaidia kuhakikisha majadiliano yenye tija zaidi:
Usichague lengo kulingana na utendaji wa sasa.
Ingawa kuelewa uwezo na mipaka ya mfumo ni muhimu, kurekebisha vipimo bila hoja kunaweza kukuzuia kudumisha mfumo: itahitaji juhudi za kishujaa ili kufikia malengo ambayo hayawezi kuafikiwa bila uundaji upya muhimu.
Weka rahisi
Mahesabu magumu ya SLI yanaweza kuficha mabadiliko katika utendaji wa mfumo na kufanya iwe vigumu kupata sababu ya tatizo.
Epuka kabisa
Ingawa inajaribu kuwa na mfumo ambao unaweza kushughulikia mzigo unaokua kwa muda usiojulikana bila kusubiri kuongezeka, hitaji hili haliwezekani. Mfumo unaoafiki maadili kama haya huenda ukahitaji muda mwingi wa kubuni na kujenga, utakuwa ghali kufanya kazi, na utakuwa mzuri sana kwa matarajio ya watumiaji ambao wangefanya na chochote kidogo.
Tumia SLO chache iwezekanavyo
Chagua idadi ya kutosha ya SLO ili kuhakikisha huduma nzuri ya sifa za mfumo. Linda SLO unazochagua: Ikiwa huwezi kamwe kushinda hoja kuhusu vipaumbele kwa kubainisha SLO mahususi, pengine haifai kuzingatia SLO hiyo. Hata hivyo, si sifa zote za mfumo zinazokubalika kwa SLO: ni vigumu kukokotoa kiwango cha furaha ya mtumiaji kwa kutumia SLO.
Usifuate ukamilifu
Unaweza kuboresha ufafanuzi na malengo ya SLO kwa wakati unapojifunza zaidi kuhusu tabia ya mfumo unapopakia. Ni bora kuanza na lengo linaloelea ambalo utaboresha baada ya muda kuliko kuchagua lengo kali sana ambalo lazima lilegezwe unapoona haliwezi kufikiwa.
SLO zinaweza na zinapaswa kuwa kichocheo kikuu katika kuweka kipaumbele kwa kazi kwa SRE na wasanidi wa bidhaa kwa sababu zinaonyesha wasiwasi kwa watumiaji. SLO nzuri ni zana muhimu ya utekelezaji kwa timu ya maendeleo. Lakini SLO iliyoundwa vibaya inaweza kusababisha kazi mbaya ikiwa timu itafanya juhudi za kishujaa kufikia SLO yenye fujo kupita kiasi, au bidhaa duni ikiwa SLO iko chini sana. SLO ni lever yenye nguvu, itumie kwa busara.
Dhibiti vipimo vyako
SLI na SLO ni vitu muhimu vinavyotumika kudhibiti mifumo:
- Kufuatilia na kupima mifumo ya SLI.
- Linganisha SLI na SLO na uamue ikiwa hatua inahitajika.
- Ikiwa hatua inahitajika, tambua nini kifanyike ili kufikia lengo.
- Kamilisha kitendo hiki.
Kwa mfano, ikiwa hatua ya 2 inaonyesha kuwa ombi limeisha muda na itavunja SLO baada ya saa chache ikiwa hakuna kitakachofanyika, hatua ya 3 inaweza kuhusisha kujaribu dhana kwamba seva zimefungwa na CPU na kuongeza seva zaidi kutasambaza mzigo . Bila SLO, hungejua kama (au lini) kuchukua hatua.
Weka SLO - kisha matarajio ya mtumiaji yatawekwa
Kuchapisha SLO huweka matarajio ya mtumiaji kwa tabia ya mfumo. Watumiaji (na watumiaji watarajiwa) mara nyingi wanataka kujua nini cha kutarajia kutoka kwa huduma ili kuelewa ikiwa inafaa kutumika. Kwa mfano, watu wanaotaka kutumia tovuti ya kushiriki picha wanaweza kutaka kuepuka kutumia huduma inayoahidi maisha marefu na gharama ya chini ili kubadilishana na upatikanaji kidogo, ingawa huduma hiyo hiyo inaweza kuwa bora kwa mfumo wa usimamizi wa kumbukumbu za kumbukumbu.
Ili kuweka matarajio ya kweli kwa watumiaji wako, tumia mbinu moja au zote mbili kati ya zifuatazo:
- Dumisha ukingo wa usalama. Tumia SLO kali ya ndani kuliko ile inayotangazwa kwa watumiaji. Hii itakupa fursa ya kujibu matatizo kabla ya kuonekana nje. Bafa ya SLO pia hukuruhusu kuwa na ukingo wa usalama unaposakinisha matoleo yanayoathiri utendakazi wa mfumo na kuhakikisha kuwa mfumo ni rahisi kutunza bila kuwakatisha tamaa watumiaji na muda wa kupungua.
- Usizidi matarajio ya mtumiaji. Watumiaji wanategemea kile unachotoa, sio kile unachosema. Ikiwa utendakazi halisi wa huduma yako ni bora zaidi kuliko SLO iliyotajwa, watumiaji watategemea utendakazi wa sasa. Unaweza kuepuka kutegemea zaidi kwa kuzima mfumo kwa makusudi au kupunguza utendaji chini ya mizigo ya mwanga.
Kuelewa jinsi mfumo unavyokidhi matarajio husaidia kuamua iwapo utawekeza katika kuharakisha mfumo na kuufanya ufikiwe zaidi na ustahimilivu. Vinginevyo, ikiwa huduma inafanya vizuri sana, muda fulani wa wafanyakazi unapaswa kutumiwa kwa vipaumbele vingine, kama vile kulipa deni la kiufundi, kuongeza vipengele vipya au kutambulisha bidhaa mpya.
Makubaliano katika mazoezi
Kuunda SLA kunahitaji timu za biashara na za kisheria kufafanua matokeo na adhabu kwa kukiuka. Jukumu la SRE ni kuwasaidia kuelewa changamoto zinazowezekana katika kufikia SLOs zilizomo katika SLA. Mapendekezo mengi ya kuunda SLO pia yanatumika kwa SLA. Ni jambo la busara kuwa mwangalifu katika kile unachowaahidi watumiaji kwa sababu kadri unavyozidi kuwa nazo, ndivyo inavyokuwa vigumu kubadilisha au kuondoa SLA ambazo zinaonekana kuwa zisizo na maana au vigumu kuzitimiza.
Asante kwa kusoma tafsiri hadi mwisho. Jiunge na chaneli yangu ya telegraph kuhusu ufuatiliaji и .
Chanzo: mapenzi.com