Ang SRE (Site Reliability Engineering) ay isang diskarte sa pagtiyak ng pagkakaroon ng mga proyekto sa web. Ito ay itinuturing na isang balangkas para sa DevOps at pinag-uusapan kung paano makamit ang tagumpay sa paglalapat ng mga kasanayan sa DevOps. Pagsasalin sa artikulong ito книги mula sa Google. Ako mismo ang naghanda ng pagsasaling ito at umasa sa sarili kong karanasan sa pag-unawa sa mga proseso ng pagsubaybay. Sa telegrama channel и Nag-publish din ako ng pagsasalin ng Kabanata 6 ng parehong aklat tungkol sa mga layunin sa antas ng serbisyo.
Pagsasalin ng pusa. Enjoy reading!
Imposibleng pamahalaan ang isang serbisyo kung walang pag-unawa sa kung ano talaga ang mga tagapagpahiwatig at kung paano sukatin at suriin ang mga ito. Sa layuning ito, tinutukoy at nagbibigay kami ng isang tiyak na antas ng serbisyo sa aming mga user, hindi alintana kung gumagamit sila ng isa sa aming mga panloob na API o isang pampublikong produkto.
Ginagamit namin ang aming intuwisyon, karanasan, at pag-unawa sa pagnanais ng mga user na maunawaan ang mga Service Level Indicators (SLI), Service Level Objectives (SLO), at Service Level Agreement (SLA). Inilalarawan ng mga dimensyong ito ang mga pangunahing sukatan na gusto naming subaybayan at kung saan kami magre-react kung hindi namin maibigay ang inaasahang kalidad ng serbisyo. Sa huli, ang pagpili ng mga tamang sukatan ay nakakatulong sa paggabay sa mga tamang aksyon kung may mali, at nagbibigay din ng kumpiyansa sa SRE team sa kalusugan ng serbisyo.
Inilalarawan ng kabanatang ito ang diskarte na ginagamit namin upang labanan ang mga problema ng pagmomodelo ng sukatan, pagpili ng sukatan, at pagsusuri ng sukatan. Karamihan sa mga paliwanag ay walang mga halimbawa, kaya gagamitin namin ang serbisyo ng Shakespeare na inilarawan sa halimbawa ng pagpapatupad nito (hanapin ang mga gawa ni Shakespeare) upang ilarawan ang mga pangunahing punto.
Terminolohiya sa antas ng serbisyo
Maraming mga mambabasa ang malamang na pamilyar sa konsepto ng SLA, ngunit ang mga terminong SLI at SLO ay nararapat na maingat na kahulugan dahil sa pangkalahatan ang terminong SLA ay overloaded at may ilang mga kahulugan depende sa konteksto. Para sa kalinawan, gusto naming paghiwalayin ang mga halagang ito.
Na tagapagsaad
Ang SLI ay isang tagapagpahiwatig ng antas ng serbisyo—isang maingat na tinukoy na sukat ng dami ng isang aspeto ng antas ng serbisyong ibinigay.
Para sa karamihan ng mga serbisyo, ang pangunahing SLI ay itinuturing na latency ng kahilingan - kung gaano katagal bago magbalik ng tugon sa isang kahilingan. Kasama sa iba pang mga karaniwang SLI ang rate ng error, na kadalasang ipinapahayag bilang bahagi ng lahat ng natanggap na kahilingan, at throughput ng system, kadalasang sinusukat sa mga kahilingan sa bawat segundo. Ang mga sukat ay madalas na pinagsama-sama: ang raw data ay unang kinokolekta at pagkatapos ay na-convert sa isang rate ng pagbabago, mean, o percentile.
Sa isip, direktang sinusukat ng SLI ang antas ng serbisyo ng interes, ngunit kung minsan ay isang kaugnay na sukatan lamang ang magagamit para sa pagsukat dahil ang orihinal ay mahirap makuha o bigyang-kahulugan. Halimbawa, ang latency sa panig ng kliyente ay kadalasang mas naaangkop na sukatan, ngunit may mga pagkakataong sa server lang masusukat ang latency.
Ang isa pang uri ng SLI na mahalaga sa mga SRE ay ang pagkakaroon, o ang bahagi ng oras kung kailan magagamit ang isang serbisyo. Kadalasang tinutukoy bilang ang rate ng matagumpay na mga kahilingan, kung minsan ay tinatawag na yield. (Ang habambuhay—ang posibilidad na mapanatili ang data sa loob ng mahabang panahon—ay mahalaga din para sa mga system ng pag-iimbak ng data.) Bagama't hindi posible ang 100% availability, ang availability na malapit sa 100% ay kadalasang makakamit; ang mga halaga ng availability ay ipinahayag bilang ang bilang ng "siyam" » porsyento ng kakayahang magamit. Halimbawa, ang 99% at 99,999% availability ay maaaring ma-label bilang "2 nines" at "5 nines". Ang kasalukuyang nakasaad na layunin ng pagiging available ng Google Compute Engine ay "tatlo at kalahating siyam" o 99,95%.
Mga Layunin
Ang SLO ay isang layunin sa antas ng serbisyo: isang target na halaga o hanay ng mga halaga para sa isang antas ng serbisyo na sinusukat ng SLI. Ang isang normal na halaga para sa SLO ay “SLI ≤ Target” o “Lower Limit ≤ SLI ≤ Upper Limit”. Halimbawa, maaari kaming magpasya na ibabalik namin nang "mabilis" ang mga resulta ng paghahanap sa Shakespeare sa pamamagitan ng pagtatakda ng SLO sa isang average na latency ng query sa paghahanap na mas mababa sa 100 millisecond.
Ang pagpili ng tamang SLO ay isang kumplikadong proseso. Una, hindi ka palaging makakapili ng isang partikular na halaga. Para sa mga panlabas na papasok na HTTP na kahilingan sa iyong serbisyo, ang sukatan ng Query Per Second (QPS) ay pangunahing tinutukoy ng pagnanais ng iyong mga user na bisitahin ang iyong serbisyo, at hindi ka makakapagtakda ng SLO para doon.
Sa kabilang banda, maaari mong sabihin na gusto mong ang average na latency para sa bawat kahilingan ay mas mababa sa 100 millisecond. Ang pagtatakda ng ganoong layunin ay maaaring pilitin kang isulat ang iyong frontend nang may mababang latency o bumili ng kagamitan na nagbibigay ng ganoong latency. (Malinaw na ang 100 millisecond ay isang di-makatwirang numero, ngunit mas mainam na magkaroon ng mas mababang latency na mga numero. May katibayan na nagmumungkahi na ang mabilis na bilis ay mas mahusay kaysa sa mabagal na bilis, at ang latency sa pagproseso ng mga kahilingan ng user na higit sa ilang partikular na halaga ay talagang pinipilit ang mga tao na lumayo mula sa iyong serbisyo.)
Muli, ito ay mas malabo kaysa sa maaaring mukhang sa unang tingin: hindi mo dapat ganap na ibukod ang QPS mula sa pagkalkula. Ang katotohanan ay ang QPS at latency ay mahigpit na nauugnay sa isa't isa: ang mas mataas na QPS ay kadalasang humahantong sa mas mataas na mga latency, at ang mga serbisyo ay kadalasang nakakaranas ng matinding pagbaba sa pagganap kapag naabot nila ang isang partikular na limitasyon ng pagkarga.
Ang pagpili at pag-publish ng SLO ay nagtatakda ng mga inaasahan ng user tungkol sa kung paano gagana ang serbisyo. Maaaring mabawasan ng diskarteng ito ang mga walang basehang reklamo laban sa may-ari ng serbisyo, gaya ng mabagal na performance. Kung walang tahasang SLO, kadalasang gumagawa ang mga user ng sarili nilang mga inaasahan tungkol sa ninanais na pagganap, na maaaring walang kinalaman sa mga opinyon ng mga taong nagdidisenyo at namamahala sa serbisyo. Ang sitwasyong ito ay maaaring humantong sa labis na mga inaasahan mula sa serbisyo, kapag ang mga gumagamit ay nagkakamali na naniniwala na ang serbisyo ay magiging mas madaling ma-access kaysa sa aktwal na ito, at magdulot ng kawalan ng tiwala kapag ang mga gumagamit ay naniniwala na ang system ay hindi gaanong maaasahan kaysa sa aktwal na ito.
Mga Kasunduan
Ang isang kasunduan sa antas ng serbisyo ay isang tahasan o implicit na kontrata sa iyong mga user na kinabibilangan ng mga kahihinatnan ng pagtugon (o hindi pagtugon) sa mga SLO na nilalaman ng mga ito. Ang mga kahihinatnan ay pinakamadaling makilala kapag ang mga ito ay pinansiyal—isang diskwento o multa—ngunit maaari silang kumuha ng iba pang mga anyo. Ang isang madaling paraan upang pag-usapan ang pagkakaiba sa pagitan ng mga SLO at SLA ay ang magtanong "ano ang mangyayari kung ang mga SLO ay hindi natutugunan?" Kung walang malinaw na kahihinatnan, halos tiyak na tumitingin ka sa isang SLO.
Ang SRE ay karaniwang hindi kasama sa paglikha ng mga SLA dahil ang mga SLA ay malapit na nauugnay sa mga desisyon sa negosyo at produkto. Ang SRE, gayunpaman, ay kasangkot sa pagtulong na pagaanin ang mga kahihinatnan ng mga nabigong SLO. Makakatulong din sila sa pagtukoy ng SLI: Malinaw, dapat mayroong layunin na paraan upang sukatin ang SLO sa kasunduan o magkakaroon ng hindi pagkakasundo.
Ang Google Search ay isang halimbawa ng mahalagang serbisyo na walang pampublikong SLA: gusto naming gamitin ng lahat ang Paghahanap nang mahusay hangga't maaari, ngunit hindi pa kami pumirma ng kontrata sa mundo. Gayunpaman, may mga kahihinatnan pa rin kung hindi available ang paghahanap - ang hindi available ay nagreresulta sa pagbaba sa aming reputasyon pati na rin ang pagbawas ng kita sa advertising. Maraming iba pang serbisyo ng Google, gaya ng Google for Work, ang may tahasang mga kasunduan sa antas ng serbisyo sa mga user. Hindi alintana kung ang isang partikular na serbisyo ay may SLA, mahalagang tukuyin ang SLI at SLO at gamitin ang mga ito upang pamahalaan ang serbisyo.
Napakaraming teorya - ngayon upang maranasan.
Mga tagapagpahiwatig sa pagsasanay
Dahil napagpasyahan namin na mahalagang pumili ng mga naaangkop na sukatan upang sukatin ang antas ng serbisyo, paano mo nalaman ngayon kung aling mga sukatan ang mahalaga para sa isang serbisyo o sistema?
Ano ang pinapahalagahan mo at ng iyong mga user?
Hindi mo kailangang gamitin ang bawat sukatan bilang isang SLI na masusubaybayan mo sa isang sistema ng pagsubaybay; Ang pag-unawa sa gusto ng mga user mula sa isang system ay makakatulong sa iyong pumili ng ilang sukatan. Ang pagpili ng masyadong maraming indicator ay nagpapahirap na tumuon sa mahahalagang indicator, habang ang pagpili ng isang maliit na numero ay maaaring mag-iwan ng malalaking bahagi ng iyong system na walang nag-aalaga. Karaniwan kaming gumagamit ng ilang pangunahing tagapagpahiwatig upang suriin at maunawaan ang kalusugan ng isang system.
Ang mga serbisyo ay karaniwang maaaring hatiin sa ilang bahagi ayon sa SLI na may kaugnayan sa kanila:
- Mga custom na front-end system, gaya ng mga interface ng paghahanap para sa serbisyo ng Shakespeare mula sa aming halimbawa. Dapat na available ang mga ito, walang mga pagkaantala at may sapat na bandwidth. Alinsunod dito, maaaring magtanong: maaari ba kaming tumugon sa kahilingan? Gaano katagal bago tumugon sa kahilingan? Ilang kahilingan ang maaaring iproseso?
- Mga sistema ng imbakan. Pinahahalagahan nila ang mababang latency ng tugon, kakayahang magamit, at tibay. Mga kaugnay na tanong: Gaano katagal bago magbasa o magsulat ng data? Maaari ba naming i-access ang data kapag hiniling? Available ba ang data kapag kailangan natin ito? Tingnan ang Kabanata 26 Integridad ng Data: Ang Iyong Binasa ay Iyong Isinulat para sa isang detalyadong pagtalakay sa mga isyung ito.
- Ang malalaking sistema ng data tulad ng mga pipeline sa pagpoproseso ng data ay umaasa sa throughput at latency sa pagproseso ng query. Mga kaugnay na tanong: Gaano karaming data ang naproseso? Gaano katagal bago maglakbay ang data mula sa pagtanggap ng kahilingan hanggang sa pagbibigay ng tugon? (Ang ilang bahagi ng system ay maaari ding magkaroon ng mga pagkaantala sa ilang mga yugto.)
Koleksyon ng mga tagapagpahiwatig
Maraming mga tagapagpahiwatig ng antas ng serbisyo ang pinaka natural na kinokolekta sa gilid ng server, gamit ang isang sistema ng pagsubaybay gaya ng Borgmon (tingnan sa ibaba). ) o Prometheus, o pana-panahong sinusuri ang mga log, na tinutukoy ang mga tugon sa HTTP na may status 500. Gayunpaman, ang ilang mga system ay dapat na nilagyan ng koleksyon ng mga sukatan sa panig ng kliyente, dahil ang kakulangan ng pagsubaybay sa panig ng kliyente ay maaaring humantong sa pagkawala ng ilang mga problema na nakakaapekto mga user, ngunit hindi nakakaapekto sa mga sukatan sa panig ng server. Halimbawa, ang pagtutuon sa latency ng pagtugon sa backend ng aming application sa pagsubok sa paghahanap sa Shakespeare ay maaaring magresulta sa latency sa panig ng user dahil sa mga isyu sa JavaScript: sa kasong ito, ang pagsukat kung gaano katagal ang browser upang maproseso ang pahina ay isang mas mahusay na sukatan.
Pagsasama-sama
Para sa pagiging simple at kadalian ng paggamit, madalas naming pinagsama-sama ang mga hilaw na sukat. Dapat itong gawin nang maingat.
Ang ilang sukatan ay mukhang simple, tulad ng mga kahilingan sa bawat segundo, ngunit kahit na ang tila tuwirang pagsukat na ito ay tuwirang pinagsasama-sama ang data sa paglipas ng panahon. Ang pagsukat ba ay partikular na natatanggap isang beses bawat segundo o ang pagsukat ba ay naa-average sa bilang ng mga kahilingan kada minuto? Ang huling opsyon ay maaaring magtago ng mas mataas na agarang bilang ng mga kahilingan na tumatagal lamang ng ilang segundo. Isaalang-alang ang isang system na naghahatid ng 200 kahilingan bawat segundo na may mga numerong pantay at 0 sa natitirang oras. Ang isang pare-pareho sa anyo ng isang average na halaga ng 100 mga kahilingan sa bawat segundo at dalawang beses ang agarang pag-load ay hindi pareho. Katulad nito, ang pag-average ng mga latency ng query ay maaaring mukhang kaakit-akit, ngunit nagtatago ito ng isang mahalagang detalye: posible na ang karamihan sa mga query ay magiging mabilis, ngunit magkakaroon ng maraming mga query na mabagal.
Karamihan sa mga tagapagpahiwatig ay mas mahusay na tinitingnan bilang mga pamamahagi sa halip na mga average. Halimbawa, para sa SLI latency, ang ilang mga kahilingan ay mabilis na mapoproseso, habang ang ilan ay palaging magtatagal, kung minsan ay mas matagal. Maaaring itago ng isang simpleng average ang mahabang pagkaantala na ito. Ang figure ay nagpapakita ng isang halimbawa: kahit na ang isang karaniwang kahilingan ay tumatagal ng humigit-kumulang 50 ms upang maihatid, 5% ng mga kahilingan ay 20 beses na mas mabagal! Ang pagsubaybay at pag-alerto batay lamang sa average na latency ay hindi nagpapakita ng mga pagbabago sa pag-uugali sa buong araw, kung sa katunayan ay may mga kapansin-pansing pagbabago sa oras ng pagproseso ng ilang kahilingan (pinakamataas na linya).
50, 85, 95, at 99 percentile system latency. Ang Y axis ay nasa logarithmic na format.
Ang paggamit ng mga percentile para sa mga indicator ay nagbibigay-daan sa iyong makita ang hugis ng distribusyon at ang mga katangian nito: ang mataas na antas ng percentile, gaya ng 99 o 99,9, ay nagpapakita ng pinakamasamang halaga, habang ang 50 percentile (kilala rin bilang median) ay nagpapakita ng pinakamadalas na estado ng ang panukat. Kung mas malaki ang pagpapakalat ng oras ng pagtugon, mas maraming matagal na kahilingan ang makakaapekto sa karanasan ng user. Ang epekto ay pinahusay sa ilalim ng mataas na pagkarga at sa pagkakaroon ng mga pila. Ipinakita ng pananaliksik sa karanasan ng user na sa pangkalahatan ay mas gusto ng mga tao ang isang mas mabagal na system na may mataas na pagkakaiba-iba ng oras ng pagtugon, kaya ang ilang mga SRE team ay tumutuon lamang sa mataas na mga marka ng porsyento, sa batayan na kung ang pag-uugali ng isang sukatan sa 99,9 na porsyento ay mabuti, karamihan sa mga gumagamit ay hindi makakaranas ng mga problema .
Tandaan sa mga error sa istatistika
Sa pangkalahatan, mas gusto naming gumamit ng mga percentile kaysa sa average (aritmetika mean) ng isang hanay ng mga halaga. Nagbibigay-daan ito sa amin na isaalang-alang ang higit pang mga dispersed na halaga, na kadalasang may makabuluhang pagkakaiba (at mas kawili-wili) na mga katangian kaysa sa karaniwan. Dahil sa artipisyal na katangian ng mga sistema ng pag-compute, ang mga halaga ng sukatan ay madalas na nabaluktot, halimbawa, walang kahilingan ang makakatanggap ng tugon nang mas mababa sa 0 ms, at ang isang timeout na 1000 ms ay nangangahulugan na hindi maaaring magkaroon ng matagumpay na mga tugon na may mga halaga na mas malaki. kaysa sa timeout. Bilang resulta, hindi natin matanggap na ang mean at median ay maaaring magkapareho o malapit sa isa't isa!
Nang walang paunang pagsubok, at maliban kung may ilang karaniwang pagpapalagay at pagtatantya, nag-iingat kami na huwag ipagpalagay na ang aming data ay karaniwang ipinamamahagi. Kung ang pamamahagi ay hindi tulad ng inaasahan, ang proseso ng automation na nag-aayos ng problema (halimbawa, kapag nakakita ito ng mga outlier, ini-restart nito ang server na may mataas na mga latency sa pagpoproseso ng kahilingan) ay maaaring ginagawa ito nang masyadong madalas o hindi sapat na madalas (na parehong hindi napakahusay).
I-standardize ang mga indicator
Inirerekomenda namin ang pag-standardize ng mga pangkalahatang katangian para sa SLI upang hindi mo na kailangang mag-isip-isip tungkol sa mga ito sa bawat oras. Ang anumang tampok na nakakatugon sa mga karaniwang pattern ay maaaring hindi kasama sa detalye ng isang indibidwal na SLI, halimbawa:
- Mga agwat ng pagsasama-sama: "na-average sa loob ng 1 minuto"
- Mga lugar ng pagsasama-sama: "Lahat ng gawain sa cluster"
- Gaano kadalas kinukuha ang mga pagsukat: "Bawat 10 segundo"
- Anong mga kahilingan ang kasama: "HTTP GET mula sa black box monitoring jobs"
- Paano nakuha ang data: "Salamat sa aming pagsubaybay na sinusukat sa server"
- Latency ng pag-access ng data: "Oras para huling byte"
Upang makatipid ng pagsisikap, lumikha ng isang set ng magagamit muli na mga template ng SLI para sa bawat karaniwang sukatan; ginagawa din nilang mas madali para sa lahat na maunawaan kung ano ang ibig sabihin ng isang partikular na SLI.
Mga layunin sa pagsasanay
Magsimula sa pamamagitan ng pag-iisip tungkol sa (o pag-alam!) kung ano ang mahalaga sa iyong mga user, hindi kung ano ang maaari mong sukatin. Kadalasan kung ano ang pinapahalagahan ng iyong mga user ay mahirap o imposibleng sukatin, kaya mas malapit ka sa kanilang mga pangangailangan. Gayunpaman, kung magsisimula ka lang sa kung ano ang madaling sukatin, mapupunta ka sa mga hindi gaanong kapaki-pakinabang na SLO. Bilang resulta, minsan nalaman namin na ang pagtukoy sa mga nais na layunin sa simula at pagkatapos ay ang pagtatrabaho sa mga partikular na tagapagpahiwatig ay mas gumagana kaysa sa pagpili ng mga tagapagpahiwatig at pagkatapos ay pagkamit ng mga layunin.
Tukuyin ang mga layunin
Para sa maximum na kalinawan, dapat itong tukuyin kung paano sinusukat ang mga SLO at ang mga kondisyon kung saan wasto ang mga ito. Halimbawa, maaari naming sabihin ang sumusunod (ang pangalawang linya ay kapareho ng una, ngunit ginagamit ang mga default ng SLI):
- Ang 99% (na-average na higit sa 1 minuto) ng Kumuha ng RPC na mga tawag ay makukumpleto sa mas mababa sa 100ms (sinusukat sa lahat ng backend server).
- 99% ng Get RPC na mga tawag ay makukumpleto nang wala pang 100ms.
Kung ang hugis ng mga curve ng pagganap ay mahalaga, maaari mong tukuyin ang maraming SLO:
- 90% ng Kumuha ng mga tawag sa RPC na nakumpleto nang wala pang 1 ms.
- 99% ng Kumuha ng mga tawag sa RPC na nakumpleto nang wala pang 10 ms.
- 99.9% ng Kumuha ng mga tawag sa RPC na nakumpleto nang wala pang 100 ms.
Kung ang iyong mga user ay bumubuo ng magkakaibang mga workload: maramihang pagpoproseso (kung saan mahalaga ang throughput) at interactive na pagproseso (kung saan mahalaga ang latency), maaaring sulit na tumukoy ng magkakahiwalay na layunin para sa bawat klase ng pag-load:
- 95% ng mga kahilingan ng customer ay nangangailangan ng throughput. Itakda ang bilang ng mga RPC na tawag na naisagawa <1 s.
- 99% ng mga kliyente ang nagmamalasakit sa latency. Itakda ang bilang ng mga RPC na tawag na may trapiko <1 KB at tumatakbo <10 ms.
Ito ay hindi makatotohanan at hindi kanais-nais na igiit na ang mga SLO ay matutugunan ng 100% ng oras: maaari nitong bawasan ang bilis ng pagpapakilala ng bagong paggana at pag-deploy, at nangangailangan ng mga mamahaling solusyon. Sa halip, mas mabuting payagan ang isang error na badyet - ang porsyento ng pinapayagang downtime ng system - at subaybayan ang halagang ito araw-araw o lingguhan. Maaaring gusto ng senior management ng buwanan o quarterly na pagsusuri. (Ang badyet ng error ay isang SLO lamang para sa paghahambing sa isa pang SLO.)
Ang porsyento ng mga paglabag sa SLO ay maihahambing sa badyet ng error (tingnan ang Kabanata 3 at seksyon ), gamit ang halaga ng pagkakaiba na ginamit bilang input sa prosesong nagpapasya kung kailan magde-deploy ng mga bagong release.
Pagpili ng mga target na halaga
Ang pagpili sa mga halaga ng pagpaplano (SLO) ay hindi isang purong teknikal na aktibidad dahil sa mga interes ng produkto at negosyo na dapat ipakita sa mga napiling SLI, SLO (at posibleng mga SLA). Gayundin, maaaring kailanganin ang palitan ng impormasyon tungkol sa mga isyu na may kaugnayan sa staffing, oras sa merkado, pagkakaroon ng kagamitan, at pagpopondo. Ang SRE ay dapat maging bahagi ng pag-uusap na ito at tumulong na maunawaan ang mga panganib at posibilidad na mabuhay ng iba't ibang mga opsyon. Nakagawa kami ng ilang tanong na maaaring makatulong na matiyak ang isang mas produktibong talakayan:
Huwag pumili ng layunin batay sa kasalukuyang pagganap.
Bagama't mahalaga ang pag-unawa sa mga lakas at limitasyon ng isang system, ang pag-aangkop sa mga sukatan nang walang pangangatwiran ay maaaring humadlang sa iyo sa pagpapanatili ng system: mangangailangan ito ng mga magiting na pagsisikap upang makamit ang mga layunin na hindi makakamit nang walang makabuluhang muling pagdidisenyo.
Panatilihin itong simple
Maaaring itago ng mga kumplikadong kalkulasyon ng SLI ang mga pagbabago sa pagganap ng system at gawing mas mahirap hanapin ang sanhi ng problema.
Iwasan ang mga ganap
Bagama't nakatutukso na magkaroon ng isang sistema na kayang humawak ng walang katapusang paglaki ng load nang hindi tumataas ang latency, hindi makatotohanan ang pangangailangang ito. Ang isang sistema na lumalapit sa mga ganitong ideya ay malamang na mangangailangan ng maraming oras sa pagdidisenyo at pagbuo, magiging magastos upang patakbuhin, at magiging napakahusay para sa mga inaasahan ng mga user na gagawa sa anumang bagay na mas mababa.
Gumamit ng kaunting SLO hangga't maaari
Pumili ng sapat na bilang ng mga SLO upang matiyak ang mahusay na saklaw ng mga katangian ng system. Protektahan ang mga SLO na pipiliin mo: Kung hindi ka kailanman mananalo ng argumento tungkol sa mga priyoridad sa pamamagitan ng pagtukoy ng isang partikular na SLO, malamang na hindi ito nagkakahalaga ng pagsasaalang-alang sa SLO na iyon. Gayunpaman, hindi lahat ng mga katangian ng system ay pumapayag sa mga SLO: mahirap kalkulahin ang antas ng kasiyahan ng gumagamit gamit ang mga SLO.
Huwag mong habulin ang pagiging perpekto
Maaari mong laging pinuhin ang mga kahulugan at layunin ng mga SLO sa paglipas ng panahon habang natututo ka pa tungkol sa gawi ng system sa ilalim ng pagkarga. Mas mainam na magsimula sa isang lumulutang na layunin na dadalhin mo sa paglipas ng panahon kaysa pumili ng isang labis na mahigpit na layunin na kailangang i-relax kapag nalaman mong hindi ito makakamit.
Ang mga SLO ay maaari at dapat na maging pangunahing driver sa pagbibigay-priyoridad sa trabaho para sa mga SRE at mga developer ng produkto dahil ang mga ito ay nagpapakita ng pag-aalala para sa mga user. Ang isang mahusay na SLO ay isang kapaki-pakinabang na tool sa pagpapatupad para sa isang development team. Ngunit ang isang hindi magandang disenyong SLO ay maaaring humantong sa maaksayang trabaho kung ang koponan ay gumagawa ng kabayanihan na pagsisikap na makamit ang isang labis na agresibong SLO, o isang hindi magandang produkto kung ang SLO ay masyadong mababa. Ang SLO ay isang malakas na pingga, gamitin ito nang matalino.
Kontrolin ang iyong mga sukat
Ang SLI at SLO ay mga pangunahing elemento na ginagamit upang pamahalaan ang mga system:
- Subaybayan at sukatin ang mga SLI system.
- Ihambing ang SLI sa SLO at magpasya kung kailangan ng aksyon.
- Kung kinakailangan ang aksyon, alamin kung ano ang kailangang mangyari upang makamit ang layunin.
- Kumpletuhin ang pagkilos na ito.
Halimbawa, kung ang hakbang 2 ay nagpapakita na ang kahilingan ay nagti-time out at masisira ang SLO sa loob ng ilang oras kung walang gagawin, ang hakbang 3 ay maaaring may kasamang pagsubok sa hypothesis na ang mga server ay nakatali sa CPU at ang pagdaragdag ng higit pang mga server ay mamamahagi ng load . Kung walang SLO, hindi mo malalaman kung (o kailan) kikilos.
Itakda ang SLO - pagkatapos ay itatakda ang mga inaasahan ng user
Ang pag-publish ng SLO ay nagtatakda ng mga inaasahan ng user para sa gawi ng system. Madalas na gustong malaman ng mga user (at potensyal na user) kung ano ang aasahan mula sa isang serbisyo upang maunawaan kung ito ay angkop para sa paggamit. Halimbawa, ang mga taong gustong gumamit ng website ng pagbabahagi ng larawan ay maaaring gustong iwasan ang paggamit ng isang serbisyong nangangako ng mahabang buhay at mababang gastos kapalit ng bahagyang mas kaunting kakayahang magamit, kahit na ang parehong serbisyo ay maaaring mainam para sa isang sistema ng pamamahala ng mga talaan ng archive.
Upang magtakda ng mga makatotohanang inaasahan para sa iyong mga user, gamitin ang isa o pareho sa mga sumusunod na taktika:
- Panatilihin ang margin ng kaligtasan. Gumamit ng mas mahigpit na panloob na SLO kaysa sa ina-advertise sa mga user. Bibigyan ka nito ng pagkakataong tumugon sa mga problema bago sila makita sa labas. Ang SLO buffer ay nagbibigay-daan din sa iyo na magkaroon ng safety margin kapag nag-i-install ng mga release na makakaapekto sa performance ng system at matiyak na ang system ay madaling mapanatili nang hindi kinakailangang biguin ang mga user sa downtime.
- Huwag lumampas sa inaasahan ng user. Ang mga user ay nakabatay sa kung ano ang iyong inaalok, hindi kung ano ang iyong sinasabi. Kung ang aktwal na pagganap ng iyong serbisyo ay mas mahusay kaysa sa nakasaad na SLO, ang mga user ay aasa sa kasalukuyang pagganap. Maiiwasan mo ang labis na pag-asa sa pamamagitan ng sadyang pag-shut down sa system o paglilimita sa pagganap sa ilalim ng magaan na pagkarga.
Ang pag-unawa sa kung gaano kahusay na natutugunan ng isang system ang mga inaasahan ay nakakatulong na magpasya kung mamumuhunan sa pagpapabilis ng system at gawin itong mas naa-access at nababanat. Bilang kahalili, kung ang isang serbisyo ay masyadong mahusay na gumaganap, ang ilang oras ng kawani ay dapat na ginugol sa iba pang mga priyoridad, tulad ng pagbabayad ng teknikal na utang, pagdaragdag ng mga bagong tampok, o pagpapakilala ng mga bagong produkto.
Mga kasunduan sa pagsasanay
Ang paggawa ng SLA ay nangangailangan ng mga negosyo at legal na koponan na tukuyin ang mga kahihinatnan at mga parusa para sa paglabag dito. Ang tungkulin ng SRE ay tulungan silang maunawaan ang mga malamang na hamon sa pagtugon sa mga SLO na nakapaloob sa SLA. Karamihan sa mga rekomendasyon para sa paglikha ng mga SLO ay nalalapat din sa mga SLA. Marunong na maging konserbatibo sa ipinangako mo sa mga user dahil kung mas marami ka, mas mahirap baguhin o alisin ang mga SLA na tila hindi makatwiran o mahirap matugunan.
Salamat sa pagbabasa ng pagsasalin hanggang sa dulo. Mag-subscribe sa aking telegram channel tungkol sa pagsubaybay и .
Pinagmulan: www.habr.com