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 link sa pagsasalin ng Kabanata 4 ng parehong aklat tungkol sa mga layunin sa antas ng serbisyo.
Pagsasalin ng pusa. Enjoy reading!
Ang mga SRE team ng Google ay may mga pangunahing prinsipyo at pinakamahuhusay na kagawian para sa paglikha ng matagumpay na monitoring at notification system. Ang kabanatang ito ay nagbibigay ng gabay sa kung anong mga problema ang maaaring makaharap ng isang bisita sa web page at kung paano lutasin ang mga problema na nagpapahirap sa mga web page na ipakita.
Mga kahulugan
Walang iisang bokabularyo ang ginagamit upang talakayin ang mga paksang may kaugnayan sa pagsubaybay. Kahit sa Google, ang mga termino sa ibaba ay hindi karaniwang ginagamit, ngunit ililista namin ang mga pinakakaraniwang interpretasyon.
Pagsubaybay
Pagkolekta, pagproseso, pagsasama-sama at pagpapakita ng dami ng data sa real time tungkol sa system: bilang ng mga kahilingan at uri ng mga kahilingan, bilang ng mga error at uri ng mga error, oras ng pagproseso ng kahilingan at uptime ng server.
Pagsubaybay sa puting kahon
Pagsubaybay batay sa mga sukatan na ipinapakita ng mga internal na bahagi ng system, kabilang ang mga log, Java Virtual Machine profiling metrics, o HTTP handler metrics na bumubuo ng mga internal na istatistika.
Pagsubaybay sa black-box
Pagsubok sa gawi ng application mula sa pananaw ng user.
Dashboard
Isang interface (karaniwang web) na nagbibigay ng pangkalahatang-ideya ng mga pangunahing tagapagpahiwatig ng kalusugan ng mga serbisyo. Ang dashboard ay maaaring may mga filter, ang kakayahang piliin ang mga indicator na ipinapakita, atbp. Ang interface ay idinisenyo upang matukoy ang mga indicator na pinakamahalaga sa mga user. Ang dashboard ay maaari ding magpakita ng impormasyon para sa mga kawani ng teknikal na suporta: isang pila ng mga kahilingan, isang listahan ng mga error na may mataas na priyoridad, at isang nakatalagang engineer para sa isang partikular na lugar ng responsibilidad.
Alerto (notification)
Mga notification na nilalayong matanggap ng isang tao sa pamamagitan ng email o iba pang paraan, na maaaring ma-trigger ng mga error o pagtaas sa queue ng kahilingan. Ang mga abiso ay inuri bilang: mga tiket, mga alerto sa email at mga mensahe ng instant messenger.
Ang ugat na dahilan
Isang depekto sa software o pagkakamali ng tao na, kapag naitama, ay hindi na dapat mangyari muli. Ang problema ay maaaring magkaroon ng ilang pangunahing dahilan: hindi sapat na proseso ng automation, software na depekto, hindi sapat na elaborasyon ng application logic. Ang bawat isa sa mga salik na ito ay maaaring ang ugat na sanhi, at ang bawat isa sa kanila ay dapat alisin.
Node at machine (node ββat machine)
Mapapalitang termino para tumukoy sa iisang instance ng tumatakbong application sa isang pisikal na server, virtual machine, o container. Ang isang makina ay maaaring mag-host ng ilang mga serbisyo. Ang mga serbisyo ay maaaring:
- konektado sa isa't isa: halimbawa, isang caching server at isang web server;
- hindi nauugnay na mga serbisyo sa isang piraso ng hardware: halimbawa, isang code repository at isang wizard para sa isang configuration system, tulad ng o .
Itulak
Anumang pagbabago sa configuration ng software.
Bakit kailangan ang pagsubaybay?
Mayroong ilang mga dahilan kung bakit kailangang subaybayan ang mga application:
Pagsusuri ng mga pangmatagalang uso
Gaano kalaki ang database at gaano ito kabilis lumalaki? Paano nagbabago ang pang-araw-araw na bilang ng mga gumagamit?
Paghahambing ng pagganap
Mas mabilis ba ang mga kahilingan sa Acme Bucket of Bytes 2.72 kumpara sa Ajax DB 3.14? Gaano kahusay ang pag-cache ng mga kahilingan pagkatapos lumitaw ang isang karagdagang node? Mas mabagal ba ang pagtakbo ng site kumpara noong nakaraang linggo?
Pag-aalerto (mga abiso)
May nasira at may kailangang ayusin. O may masisira sa lalong madaling panahon at kailangan ng isang tao na suriin ito sa lalong madaling panahon.
Paglikha ng mga dashboard
Dapat sagutin ng mga dashboard ang mga pangunahing tanong at may kasamang mula sa β mga pagkaantala (latency), trapiko (trapiko), mga error (error) at laki ng load (saturation).
Pagsasagawa ng retrospective analysis (debug)
Tumaas ang pagkaantala sa pagproseso ng kahilingan, ngunit ano pa ang nangyari sa parehong oras?
Kapaki-pakinabang ang mga monitoring system bilang pinagmumulan ng data para sa mga business intelligence system at para mapadali ang pagsusuri ng mga insidente sa seguridad. Dahil ang aklat na ito ay nakatuon sa mga larangan ng engineering kung saan ang mga SRE ay may kadalubhasaan, hindi namin tatalakayin ang mga diskarte sa pagsubaybay dito.
Ang pagsubaybay at mga alerto ay nagbibigay-daan sa system na sabihin sa iyo kapag ito ay nasira o malapit nang masira. Kapag ang isang system ay hindi maaaring awtomatikong ayusin ang sarili nito, gusto namin ng isang tao na suriin ang alerto, alamin kung ang problema ay aktibo pa rin, lutasin ito, at tukuyin ang ugat na sanhi. Kung hindi ka mag-audit ng mga bahagi ng system, hindi ka makakatanggap ng alerto dahil lang sa "may tila kakaiba."
Ang pagpapabigat sa isang tao ng mga abiso ay isang medyo mahal na paggamit ng oras ng isang empleyado. Kung ang empleyado ay nagtatrabaho, ang alerto ay nakakaabala sa proseso ng trabaho. Kung ang empleyado ay nasa bahay, ang alerto ay nakakaabala sa personal na oras at posibleng matulog. Kapag masyadong madalas mangyari ang mga alerto, binabalak ng mga empleyado ang mga ito, ipagpaliban ang mga ito, o binabalewala ang mga papasok na alerto. Paminsan-minsan ay binabalewala nila ang tunay na alerto, na natatakpan ng mga kaganapang ingay. Maaaring tumagal ng mahabang panahon ang mga pagkaantala ng serbisyo dahil pinipigilan ng mga kaganapang ingay ang problema na mabilis na masuri at maitama. Ang mga epektibong sistema ng babala ay may magandang ratio ng signal-to-noise.
Pagtatakda ng mga makatwirang inaasahan para sa sistema ng pagsubaybay
Ang pag-set up ng pagsubaybay para sa isang kumplikadong aplikasyon ay isang kumplikadong gawain sa engineering mismo. Kahit na may malaking imprastraktura ng mga tool sa pagkolekta, pagpapakita, at pag-alerto, ang isang pangkat ng Google SRE na may 10β12 miyembro ay karaniwang kinabibilangan ng isa o dalawang tao na ang pangunahing layunin ay bumuo at magpanatili ng mga sistema ng pagsubaybay. Bumaba ang bilang na ito sa paglipas ng panahon habang pinagsasama-sama at isinasaulo natin ang imprastraktura ng pagsubaybay, ngunit ang bawat pangkat ng SRE ay karaniwang mayroong kahit isang tao na nakatuon lamang sa pagsubaybay. Dapat nating sabihin na habang ang mga dashboard ng system sa pagsubaybay ay medyo kawili-wiling tingnan, maingat na iniiwasan ng mga SRE team ang mga sitwasyon na nangangailangan ng isang tao na tumingin sa isang screen upang subaybayan ang mga problema.
Sa pangkalahatan, lumipat ang Google sa simple at mabilis na monitoring system na may pinakamainam na after-the-fact analysis tool. Iniiwasan namin ang mga "magic" na sistema na sumusubok na hulaan ang mga limitasyon o awtomatikong makita ang ugat na sanhi. Ang mga sensor na nakakakita ng hindi sinasadyang nilalaman sa mga kahilingan ng end-user ay ang tanging counterexample; Hangga't nananatiling simple ang mga sensor na ito, mabilis nilang matutukoy ang mga sanhi ng malubhang anomalya. Ang iba pang mga format para sa paggamit ng data ng pagsubaybay, tulad ng pagpaplano ng kapasidad o pagtataya ng trapiko, ay mas kumplikado. Ang pagmamasid sa napakahabang yugto ng panahon (mga buwan o taon) sa mababang sampling rate (mga oras o araw) ay magpapakita ng pangmatagalang trend.
Ang koponan ng Google SRE ay nagkaroon ng magkakahalong tagumpay sa mga kumplikadong hierarchy ng dependency. Bihira kaming gumamit ng mga panuntunan tulad ng "kung nalaman kong mabagal ang database, nakakatanggap ako ng alerto na mabagal ang database, kung hindi, nakakakuha ako ng alerto na mabagal ang site." Ang mga panuntunang nakabatay sa dependency ay karaniwang tumutukoy sa mga hindi nababagong bahagi ng aming system, gaya ng system para sa pag-filter ng trapiko ng user sa data center. Halimbawa, "kung ang pag-filter ng trapiko sa data center ay na-configure, huwag mo akong alertuhan tungkol sa mga pagkaantala sa pagproseso ng mga kahilingan ng user" ay isang pangkalahatang tuntunin para sa mga alerto mula sa data center. Ilang koponan sa Google ang sumusuporta sa mga kumplikadong hierarchy ng dependency dahil ang aming imprastraktura ay may pare-parehong rate ng patuloy na refactoring.
Ang ilan sa mga ideyang inilarawan sa kabanatang ito ay may kaugnayan pa rin: palaging may pagkakataon na lumipat nang mas mabilis mula sa sintomas hanggang sa ugat, lalo na sa patuloy na pagbabago ng mga sistema. Samakatuwid, habang binabalangkas ng kabanatang ito ang ilang layunin para sa mga sistema ng pagsubaybay at kung paano makamit ang mga layuning iyon, mahalaga na ang mga sistema ng pagsubaybay ay simple at naiintindihan ng lahat sa pangkat.
Gayundin, upang mapanatiling mababa ang antas ng ingay at mataas ang antas ng signal, ang mga diskarte sa pagsubaybay sa mga inalertong asset ay dapat na napakasimple at maaasahan. Ang mga panuntunan na bumubuo ng mga babala para sa mga tao ay dapat na madaling maunawaan at nagpapakita ng isang malinaw na problema.
Sintomas laban sa mga sanhi
Dapat sagutin ng iyong monitoring system ang dalawang tanong: "ano ang nasira" at "bakit ito nasira."
Ang "Ano ang nasira" ay nagsasalita tungkol sa sintomas, at ang "bakit ito nasira" ay nagsasalita tungkol sa sanhi. Ang talahanayan sa ibaba ay nagpapakita ng mga halimbawa ng gayong mga koneksyon.
Isang sintomas
Maging sanhi
Pagkuha ng HTTP Error 500 o 404
Tinatanggihan ng mga server ng database ang mga koneksyon
Mabagal na tugon ng server
Mataas na paggamit ng CPU o sirang Ethernet cable
Ang mga user sa Antarctica ay hindi nakakatanggap ng mga GIF ng pusa
Kinamumuhian ng iyong CDN ang mga siyentipiko at pusa, kaya na-blacklist ang ilang IP address
Ang pribadong nilalaman ay naging available mula sa lahat ng dako
Dahil sa paglulunsad ng bagong software release, nakalimutan ng firewall ang lahat ng ACL at pinapasok ang lahat
Ang "Ano" at "bakit" ay ilan sa mga pinakamahalagang bloke ng gusali para sa paglikha ng isang mahusay na sistema ng pagsubaybay na may pinakamataas na signal at pinakamababang ingay.
Black-box vs White-box
Pinagsasama namin ang malawak na pagsubaybay sa White-box na may katamtamang pagsubaybay sa Black-box para sa mga kritikal na sukatan. Ang pinakamadaling paraan upang ihambing ang Black-box sa White-box ay ang Black-box ay nakatuon sa sintomas at reaktibo sa halip na proactive na pagsubaybay: "ang system ay hindi gumagana nang tama sa ngayon." Nakadepende ang white-box sa mga internal na kakayahan sa pag-verify ng mga system: mga log ng kaganapan o mga web server. Kaya, pinapayagan ka ng White-box na makita ang mga paparating na problema, mga pagkakamali na tila isang muling pagpapadala ng isang kahilingan, atbp.
Tandaan na sa isang multi-layer system, ang isang sintomas sa lugar ng responsibilidad ng isang engineer ay isang sintomas sa lugar ng responsibilidad ng isa pang engineer. Halimbawa, ang pagganap ng database ay nabawasan. Ang mabagal na pagbabasa ng database ay isang sintomas ng database na SRE na nakakakita sa kanila. Gayunpaman, para sa isang front-end na SRE na nagmamasid sa isang mabagal na website, ang sanhi ng parehong mabagal na pagbasa ng database ay isang mabagal na database. Samakatuwid, ang pagsubaybay sa white-box ay minsan nakatuon sa sintomas at kung minsan ay nakatuon sa sanhi, depende sa kung gaano ito kalawak.
Kapag nangongolekta ng telemetry para sa pag-debug, kinakailangan ang pagsubaybay sa White-box. Kung ang mga web server ay mabagal na tumugon sa mga query sa database, kailangan mong malaman kung gaano kabilis ang pakikipag-ugnayan ng web server sa database at kung gaano ito kabilis tumugon. Kung hindi, hindi ka makakapag-iba sa pagitan ng isang mabagal na database server at isang problema sa network sa pagitan ng web server at ng database.
Ang pagsubaybay sa black-box ay may pangunahing bentahe kapag nagpapadala ng mga alerto: pinalitaw mo ang abiso sa tatanggap kapag ang problema ay nagresulta na sa mga tunay na sintomas. Sa kabilang banda, ang pagsubaybay ay walang silbi para sa isang Black-box na problema na hindi pa lumitaw ngunit nalalapit na.
Apat na gintong senyales
Ang apat na gintong signal sa pagsubaybay ay latency, trapiko, mga error, at saturation. Kung apat na sukatan ng system ng user lang ang masusukat mo, tumuon sa apat na iyon.
Pag-antala
Ang oras na kinakailangan upang iproseso ang kahilingan. Mahalagang makilala ang pagitan ng latency ng matagumpay at hindi matagumpay na mga kahilingan. Halimbawa, ang isang HTTP 500 na error na sanhi ng pagkawala ng koneksyon sa isang database o iba pang backend ay maaaring ma-diagnose nang napakabilis, gayunpaman, ang isang HTTP 500 na error ay maaaring magpahiwatig ng isang nabigong kahilingan. Ang pagtukoy sa epekto ng isang 500 na error sa pangkalahatang latency ay maaaring humantong sa mga maling konklusyon. Sa kabilang banda, ang isang mabagal na error ay isang mabilis na error! Samakatuwid, mahalagang subaybayan ang latency ng error sa halip na i-filter lang ang mga error.
trapiko
Ang bilang ng mga kahilingan sa iyong system ay sinusukat sa mataas na antas ng mga sukatan ng system. Para sa isang serbisyo sa web, karaniwang kinakatawan ng pagsukat na ito ang bilang ng mga kahilingan sa HTTP bawat segundo, na hinati sa katangian ng mga kahilingan (halimbawa, static o dynamic na nilalaman). Para sa isang audio streaming system, maaaring tumuon ang pagsukat na ito sa bilis ng I/O ng network o sa bilang ng mga sabay-sabay na session. Para sa isang key-value storage system, ang pagsukat na ito ay maaaring mga transaksyon o mga resulta ng paghahanap sa bawat segundo.
Mga error
Ito ang rate ng mga nabigong kahilingan na tahasan (hal. HTTP 500), implicit (hal. HTTP 200 ngunit sinamahan ng di-wastong nilalaman) o patakaran (hal. "Kung nakakuha ka ng tugon sa isang segundo, anumang isang segundo ay isang error"). Kung hindi sapat ang mga HTTP response code para ipahayag ang lahat ng kundisyon ng pagkabigo, maaaring kailanganin ang mga pangalawang (internal) na protocol upang matukoy ang bahagyang pagkabigo. Ang pagsubaybay sa lahat ng naturang nabigong kahilingan ay maaaring hindi nagbibigay-kaalaman, habang ang end-to-end na mga pagsubok sa system ay makakatulong na matukoy na nagpoproseso ka ng maling nilalaman.
Saturation
Ipinapakita ng sukatan kung gaano kalakas ang paggamit ng iyong serbisyo. Ito ay isang panukala sa pagsubaybay ng system na tumutukoy sa mga mapagkukunan na pinaka-nalilimitahan (halimbawa, sa isang memory-constrained system, nagpapakita ng memorya, sa isang I/O-constrained system, ay nagpapakita ng bilang ng mga I/Os). Tandaan na maraming system ang nagpapababa sa performance bago nila maabot ang 100% na paggamit, kaya mahalaga ang pagkakaroon ng layunin sa paggamit.
Sa mga kumplikadong system, ang saturation ay maaaring dagdagan ng mas mataas na antas ng mga pagsukat ng pag-load: maaari bang maayos na mahawakan ng iyong serbisyo ang dobleng trapiko, mahawakan lamang ang 10% mas maraming trapiko, o mapangasiwaan ang mas kaunting trapiko kaysa sa kasalukuyan? Para sa mga simpleng serbisyo na walang mga parameter na nagbabago sa pagiging kumplikado ng kahilingan (halimbawa, "Bigyan mo ako ng wala" o "Kailangan ko ng isang natatanging solong monotonic integer"), na bihirang magbago ng configuration, maaaring sapat ang isang static na halaga ng pagsubok sa pagkarga. Gayunpaman, tulad ng tinalakay sa nakaraang talata, karamihan sa mga serbisyo ay dapat gumamit ng mga hindi direktang signal tulad ng paggamit ng CPU o bandwidth ng network, na may kilalang upper bound. Ang pagtaas ng latency ay madalas na isang nangungunang tagapagpahiwatig ng saturation. Ang pagsukat sa 99th percentile na oras ng pagtugon sa isang maliit na window (hal., isang minuto) ay maaaring magbigay ng napakaaga na signal ng saturation.
Sa wakas, ang saturation ay nauugnay din sa mga hula tungkol sa nalalapit na saturation, halimbawa: "Mukhang pupunuin ng iyong database ang iyong hard drive sa loob ng 4 na oras."
Kung susukatin mo ang lahat ng apat na ginintuang signal at kapag may problema sa isa sa mga sukatan (o, sa kaso ng saturation, isang malapit na problema), inaalertuhan mo ang isang tao, ang iyong serbisyo ay higit pa o hindi gaanong saklaw ng pagsubaybay.
Mga alalahanin tungkol sa "buntot" (o instrumentasyon at pagganap)
Kapag lumilikha ng isang sistema ng pagsubaybay mula sa simula, mayroong isang tukso na bumuo ng isang sistema batay sa mga average na halaga: average na latency, average na paggamit ng CPU ng mga node, o average na kapunuan ng database. Ang panganib ng huling dalawang halimbawa ay halata: ang mga processor at database ay itinatapon sa isang napaka-unpredictable na paraan. Ang parehong naaangkop sa pagkaantala. Kung nagpapatakbo ka ng serbisyo sa web na may average na latency na 100ms na may 1000 kahilingan sa bawat segundo, maaaring tumagal ng 1 segundo ang 5% ng mga kahilingan. Kung umaasa ang mga user sa maraming naturang serbisyo sa web, ang 99th percentile ng isang backend ay madaling maging median response time ng frontend.
Ang pinakasimpleng paraan upang matukoy ang pagkakaiba sa pagitan ng mabagal na average at ang napakabagal na buntot ng mga kahilingan ay upang mangolekta ng mga sukat ng mga kahilingan na ipinahayag sa mga istatistika (isang mahusay na tool upang ipakita ay histograms) kaysa sa aktwal na mga latency: kung gaano karaming mga kahilingan ang inihatid ng serbisyo na tumagal sa pagitan ng 0 ms at 10 ms, sa pagitan ng 10 ms at 30 ms, sa pagitan ng 30 ms at 100 ms, sa pagitan ng 100 ms at 300 ms, atbp. Ang pagpapalawak ng mga hangganan ng histogram nang humigit-kumulang exponentially (sa pamamagitan ng tinatayang salik na 3) ay kadalasang isang simpleng paraan upang mailarawan ang pamamahagi ng mga kahilingan.
Pagpili ng naaangkop na antas ng detalye para sa mga sukat
Ang iba't ibang elemento ng system ay dapat masukat sa iba't ibang antas ng detalye. Halimbawa:
- Ang pagsubaybay sa paggamit ng CPU sa loob ng isang yugto ng panahon ay hindi magpapakita ng mga pangmatagalang spike na humahantong sa mataas na latency.
- Sa kabilang banda, para sa isang web service na nagta-target ng hindi hihigit sa 9 na oras ng downtime bawat taon (99,9% taunang uptime), ang pagsuri para sa isang HTTP 200 na tugon nang higit sa isang beses o dalawang beses sa isang minuto ay malamang na hindi kinakailangang madalas.
- Gayundin, ang pagsuri sa espasyo ng hard drive para sa 99,9% na kakayahang magamit nang higit sa isang beses bawat 1-2 minuto ay malamang na hindi kinakailangan.
Mag-ingat sa kung paano mo binubuo ang granularity ng iyong mga sukat. Ang pagkolekta ng CPU load isang beses bawat segundo ay maaaring magbigay ng kawili-wiling data, ngunit ang mga madalas na pagsukat ay maaaring maging napakamahal upang mangolekta, mag-imbak, at magsuri. Kung ang iyong layunin sa pagsubaybay ay nangangailangan ng mataas na granularity at hindi nangangailangan ng mataas na pagtugon, maaari mong bawasan ang mga gastos na ito sa pamamagitan ng pag-set up ng pagkolekta ng mga sukatan sa server at pagkatapos ay pag-set up ng external na system para kolektahin at pagsama-samahin ang mga sukatang iyon. maaari mo bang:
- Sukatin ang pag-load ng CPU bawat segundo.
- Bawasan ang detalye sa 5%.
- Pinagsama-samang sukatan bawat minuto.
Ang diskarteng ito ay magbibigay-daan sa iyong mangolekta ng data sa isang mataas na granularity nang hindi nagkakaroon ng mataas na pagsusuri at overhead ng storage.
Bilang simple hangga't maaari, ngunit hindi mas simple
Ang overlay ng iba't ibang mga kinakailangan sa ibabaw ng bawat isa ay maaaring magresulta sa isang napakakomplikadong sistema ng pagsubaybay. Halimbawa, ang iyong system ay maaaring may mga sumusunod na kumplikadong elemento:
- Mga alerto ayon sa iba't ibang threshold para sa latency ng pagproseso ng kahilingan, sa iba't ibang percentile, para sa lahat ng uri ng iba't ibang indicator.
- Pagsusulat ng karagdagang code upang matukoy at matukoy ang mga posibleng dahilan.
- Lumikha ng mga kaugnay na dashboard para sa bawat posibleng dahilan ng mga problema.
Ang mga mapagkukunan ng potensyal na komplikasyon ay hindi nagtatapos. Tulad ng lahat ng software system, ang pagsubaybay ay maaaring maging napakakumplikado na ito ay nagiging marupok at mahirap baguhin at mapanatili.
Samakatuwid, idisenyo ang iyong monitoring system upang gawing simple ito hangga't maaari. Kapag pumipili kung ano ang susubaybayan, tandaan ang sumusunod:
- Ang mga patakaran na kadalasang nakakakuha ng mga totoong insidente ay dapat na kasing simple, mahuhulaan at maaasahan hangga't maaari.
- Dapat alisin ang configuration para sa pangongolekta, pagsasama-sama, at pag-aalerto ng data na madalang na ginagawa (halimbawa, mas mababa sa quarterly para sa ilang SRE team).
- Ang mga sukatan na nakolekta ngunit hindi ipinapakita sa anumang preview dashboard o ginagamit ng anumang alerto ay mga kandidato para sa pagtanggal.
Sa Google, ang pagkolekta at pagsasama-sama ng mga pangunahing sukatan, na sinamahan ng mga alerto at dashboard, ay gumagana nang maayos bilang isang medyo stand-alone na system (ang sistema ng pagsubaybay ng Google ay aktwal na hinati-hati sa ilang mga subsystem, ngunit karaniwang alam ng mga tao ang lahat ng aspeto ng mga subsystem na ito). Maaaring nakakaakit na pagsamahin ang pagsubaybay sa iba pang mga diskarte para sa pagsusuri ng mga kumplikadong system: detalyadong pag-profile ng system, pag-debug ng proseso, mga detalye ng pagsubaybay tungkol sa mga pagbubukod o pagkabigo, pagsubok sa pag-load, pagkolekta at pagsusuri ng log, o inspeksyon ng trapiko. Bagama't karamihan sa mga bagay na ito ay may mga pagkakatulad sa pangunahing pagsubaybay, ang paghahalo sa mga ito ay magreresulta sa napakaraming resulta at lilikha ng isang kumplikado at marupok na sistema. Tulad ng maraming iba pang aspeto ng software development, ang pagsuporta sa iba't ibang mga system na may malinaw, simple, maluwag na pinagsamang mga punto ng pagsasama ay ang pinakamahusay na diskarte (halimbawa, paggamit ng web API upang makuha ang pinagsama-samang data sa isang format na maaaring manatiling pare-pareho sa mahabang panahon. ).
Pinagsasama-sama ang mga Prinsipyo
Ang mga prinsipyong tinalakay sa kabanatang ito ay maaaring pagsamahin sa isang pilosopiyang pagsubaybay at pag-aalerto na ineendorso at sinusundan ng mga koponan ng Google SRE. Ang pagsunod sa pilosopiyang ito sa pagsubaybay ay kanais-nais, ay isang magandang panimulang punto para sa paglikha o pagbabago ng iyong pamamaraan sa pag-aalerto, at makakatulong sa iyong magtanong ng mga tamang tanong sa iyong pagpapaandar, anuman ang laki ng iyong organisasyon o ang pagiging kumplikado ng serbisyo o system.
Kapag gumagawa ng mga panuntunan sa pagsubaybay at pag-aalerto, ang pagtatanong ng mga sumusunod na tanong ay makakatulong sa iyong maiwasan ang mga maling positibo at hindi kinakailangang alerto:
- Nakikita ba ng panuntunang ito ang isang hindi matukoy na estado ng system na apurahan, tumatawag sa pagkilos, at hindi maiiwasang makakaapekto sa user?
- Maaari ko bang balewalain ang babalang ito dahil alam kong ito ay benign? Kailan at bakit ko maaaring balewalain ang babalang ito at paano ko maiiwasan ang sitwasyong ito?
- Nangangahulugan ba ang alertong ito na ang mga user ay negatibong naaapektuhan? Mayroon bang mga sitwasyon kung saan hindi negatibong naaapektuhan ang mga user, gaya ng sa pamamagitan ng pag-filter ng trapiko o kapag gumagamit ng mga pagsubok na system kung saan dapat i-filter ang mga alerto?
- Maaari ba akong kumilos bilang tugon sa alertong ito? Apurahan ba ang mga hakbang na ito o maaari ba silang maghintay hanggang umaga? Maaari bang ligtas na i-automate ang isang aksyon? Ang aksyon ba na ito ay isang pangmatagalang solusyon o isang panandaliang solusyon?
- Ang ilang mga tao ay nakakakuha ng maramihang mga alerto para sa isyung ito, kaya mayroon bang paraan upang bawasan ang bilang ng mga alerto?
Ang mga tanong na ito ay sumasalamin sa pangunahing pilosopiya sa mga alerto at mga sistema ng babala:
- Sa tuwing may papasok na alerto, kailangan kong mag-react kaagad. Maaari akong mag-react nang madalian ng ilang beses sa isang araw bago ako mapagod.
- Ang bawat alerto ay dapat na may kaugnayan.
- Ang bawat tugon sa isang alerto ay nangangailangan ng interbensyon ng tao. Kung awtomatikong maproseso ang notification, hindi ito dapat dumating.
- Ang mga alerto ay dapat tungkol sa isang bagong problema o kaganapan na hindi pa umiiral noon.
Ang diskarteng ito ay nagpapalabo ng ilang partikular na pagkakaiba: kung ang alerto ay nakakatugon sa nakaraang apat na kundisyon, hindi mahalaga kung ang alerto ay ipinadala mula sa isang White-box o Black-Box na monitoring system. Ang pamamaraang ito ay nagpapatibay din ng ilang mga pagkakaiba: mas mahusay na gumastos ng higit na pagsisikap sa pagtukoy ng mga sintomas kaysa sa mga sanhi; pagdating sa mga sanhi, kailangan mo lamang mag-alala tungkol sa mga hindi maiiwasang dahilan.
Pangmatagalang pagsubaybay
Sa mga kapaligiran sa pagiging produktibo ngayon, sinusubaybayan ng mga monitoring system ang isang patuloy na umuunlad na sistema ng produksyon na may nagbabagong arkitektura ng software, mga katangian ng workload, at mga target sa pagganap. Ang mga alerto na kasalukuyang mahirap i-automate ay maaaring maging karaniwan, marahil ay nagkakahalaga pa ng pagtugon. Sa puntong ito, dapat mahanap at alisin ng isang tao ang mga ugat ng problema; kung ang naturang resolusyon ay hindi posible, ang pagtugon sa alerto ay nangangailangan ng ganap na automation.
Mahalaga na ang mga desisyon sa pagsubaybay ay ginawa nang nasa isip ang mga pangmatagalang layunin. Ang bawat alerto na tumatakbo ngayon ay nakakaabala sa isang tao mula sa pagpapabuti ng system bukas, kaya madalas na may pagbawas sa kakayahang magamit o pagganap ng isang produktibong sistema para sa oras na kinakailangan upang mapabuti ang sistema ng pagsubaybay sa mahabang panahon. Tingnan natin ang dalawang halimbawa upang ilarawan ang hindi pangkaraniwang bagay na ito.
Bigtable SRE: A Tale of Over-Alert
Ang panloob na imprastraktura ng Google ay karaniwang ibinibigay at sinusukat laban sa isang antas ng serbisyo (service level (SLO). Maraming taon na ang nakalipas, ang serbisyo ng Bigtable na SLO ay batay sa average na pagganap ng isang synthetic na transaksyon na ginagaya ang isang live na kliyente. Dahil sa mga isyu sa Bigtable at mas mababang antas ng storage stack, ang average na performance ay hinimok ng isang "malaking" buntot: ang pinakamasamang 5% ng mga query ay kadalasang mas mabagal kaysa sa iba.
Ipinadala ang mga abiso sa email habang nalalapit na ang limitasyon ng SLO, at ipinadala ang mga alerto sa messenger kapag nalampasan ang SLO. Ang parehong mga uri ng mga alerto ay madalas na ipinadala, na kumukuha ng hindi katanggap-tanggap na oras ng engineering: ang koponan ay gumugol ng isang malaking tagal ng oras sa pag-aayos sa mga alerto upang mahanap ang iilan na aktwal na nauugnay. Madalas naming napalampas ang isang isyu na aktwal na nakaapekto sa mga user dahil ilan lang sa mga alerto ang para sa partikular na isyu na iyon. Marami sa mga alerto ay hindi apurahan dahil sa naiintindihan na mga problema sa imprastraktura at naproseso sa karaniwang paraan, o hindi naproseso.
Upang malutas ang sitwasyon, gumawa ang team ng tatlong-pronged na diskarte: Habang nagsusumikap na pahusayin ang performance ng Bigtable, pansamantala naming itinakda ang aming layunin sa SLO na maging ika-75 percentile para sa latency ng pagtugon sa query. In-off din namin ang mga alerto sa email dahil napakarami sa kanila kaya imposibleng gumugol ng oras sa pag-diagnose ng mga ito.
Ang diskarteng ito ay nagbigay-daan sa amin sa paghinga para simulan ang pag-aayos ng mga pangmatagalang isyu sa Bigtable at ang mas mababang mga layer ng storage stack, sa halip na patuloy na ayusin ang mga taktikal na isyu. Magagawa ng mga inhinyero ang trabaho nang hindi binobomba ng mga alerto sa lahat ng oras. Sa huli, ang pansamantalang pagpapaliban sa pagproseso ng alerto ay nagbigay-daan sa amin na mapabuti ang kalidad ng aming serbisyo.
Gmail: Mahuhulaan, Algorithmic na Mga Tugon ng Tao
Sa simula nito, binuo ang Gmail sa isang binagong sistema ng pamamahala ng proseso ng Workqueue na idinisenyo upang i-batch ang mga bahagi ng proseso ng isang index ng paghahanap. Ang workqueue ay inangkop sa mga prosesong matagal nang nabubuhay at pagkatapos ay inilapat sa Gmail, ngunit ang ilang mga bug sa opaque na scheduler code ay napatunayang napakahirap ayusin.
Noong panahong iyon, nakaayos ang pagsubaybay sa Gmail upang ma-trigger ang mga alerto kapag nakansela ang mga indibidwal na gawain gamit ang Workqueue. Ang diskarte na ito ay hindi perpekto, dahil kahit na sa oras na iyon, ang Gmail ay nagsagawa ng maraming libu-libong mga gawain, bawat isa ay ibinigay sa isang bahagi ng isang porsyento ng aming mga gumagamit. Labis kaming nag-aalala tungkol sa pagbibigay sa mga user ng Gmail ng magandang karanasan ng user, ngunit hindi maabot ang paghawak ng napakaraming alerto.
Upang matugunan ang isyung ito, gumawa ang Gmail SRE ng tool upang makatulong sa pag-debug ng scheduler sa pinakamainam na paraan upang mabawasan ang epekto sa mga user. Ang koponan ay nagkaroon ng ilang mga talakayan tungkol sa kung isa-automate na lang ang buong cycle mula sa pagtuklas ng problema sa pamamagitan ng remediation hanggang sa matagpuan ang isang pangmatagalang solusyon, ngunit ang ilan ay nag-aalala na ang naturang solusyon ay maantala ang aktwal na pag-aayos ng problema.
Ang pag-igting na ito ay karaniwan sa koponan at madalas na nagpapakita ng kawalan ng tiwala sa disiplina sa sarili: habang ang ilang miyembro ng koponan ay gustong magbigay ng oras para sa tamang pag-aayos, ang iba ay nag-aalala na ang panghuling pag-aayos ay malilimutan at ang pansamantalang pag-aayos ay magtatagal magpakailanman. Ang isyung ito ay nararapat pansinin dahil napakadaling pansamantalang ayusin ang mga problema sa halip na gawing permanente ang sitwasyon. Ang mga tagapamahala at teknikal na kawani ay gumaganap ng isang mahalagang papel sa pagpapatupad ng mga pangmatagalang pag-aayos, pagsuporta at pagbibigay-priyoridad sa mga potensyal na pangmatagalang pag-aayos kahit na matapos ang unang "sakit" ay humupa.
Ang mga regular, paulit-ulit na alerto at algorithmic na tugon ay dapat na isang pulang bandila. Ang pag-aatubili ng iyong koponan na i-automate ang mga alertong ito ay nangangahulugan na ang koponan ay walang kumpiyansa na mapagkakatiwalaan nila ang mga algorithm. Ito ay isang seryosong problema na kailangang matugunan.
Pangmatagalan
Ang isang karaniwang tema ay nagli-link sa mga halimbawa ng Bigtable at Gmail: ang kumpetisyon sa pagitan ng panandalian at pangmatagalang availability. Kadalasan, ang isang malakas na pagsisikap ay makakatulong sa isang marupok na sistema na makamit ang mataas na kakayahang magamit, ngunit ang landas na ito ay karaniwang panandalian, puno ng pagkapagod ng koponan at pag-asa sa isang maliit na bilang ng mga miyembro ng parehong heroic na koponan.
Ang kinokontrol, panandaliang pagbawas sa availability ay kadalasang masakit, ngunit madiskarteng mahalaga para sa pangmatagalang katatagan ng system. Mahalagang huwag tingnan ang bawat alerto nang hiwalay, ngunit isaalang-alang kung ang kabuuang antas ng dami ng alerto ay humahantong sa isang malusog, maayos na naa-access na sistema na may mabubuhay na koponan at isang paborableng pagbabala. Sinusuri namin ang mga istatistika ng dalas ng alerto (karaniwang ipinapahayag bilang mga insidente sa bawat shift, kung saan ang isang insidente ay maaaring binubuo ng maraming nauugnay na insidente) sa mga quarterly na ulat sa pamamahala, na nagbibigay-daan sa mga gumagawa ng desisyon na magkaroon ng patuloy na pagtingin sa pag-load ng alert system at pangkalahatang kalusugan ng team.
Konklusyon
Ang landas sa malusog na pagsubaybay at pag-alerto ay simple at malinaw. Nakatuon ito sa mga sintomas ng problema na nagpapalitaw ng mga alerto, at ang pagsubaybay sa sanhi ay nagsisilbing tulong sa mga problema sa pag-debug. Mas madali ang pagsubaybay sa mga sintomas kapag mas mataas ka sa stack na kinokontrol mo, kahit na ang pagsubaybay sa pagkarga at pagganap ng database ay dapat gawin nang direkta sa database mismo. Ang mga abiso sa email ay may napakalimitadong pakinabang at malamang na madaling maging ingay; sa halip, dapat kang gumamit ng dashboard na sumusubaybay sa lahat ng kasalukuyang isyu na nagpapalitaw ng mga alerto sa email. Ang dashboard ay maaari ding ipares sa isang log ng kaganapan upang suriin ang mga makasaysayang ugnayan.
Sa mahabang panahon, kinakailangan upang makamit ang matagumpay na pag-ikot ng mga alerto tungkol sa mga sintomas at napipintong tunay na mga problema, pag-angkop ng mga layunin upang matiyak na sinusuportahan ng pagsubaybay ang mabilis na pagsusuri.
Salamat sa pagbabasa ng pagsasalin hanggang sa dulo. Mag-subscribe sa aking telegram channel tungkol sa pagsubaybay ΠΈ .
Pinagmulan: www.habr.com