SRE (Téknik Reliabilitas Situs) mangrupikeun pendekatan pikeun mastikeun kasadiaan proyék wéb. Éta dianggap kerangka pikeun DevOps sareng ngobrolkeun kumaha carana ngahontal kasuksésan dina nerapkeun prakték DevOps. Tarjamahan dina artikel ieu Bab 6 Ngawaskeun Sistem Distribusi buku Téknik Reliabilitas Loka ti Google. Kuring nyiapkeun tarjamahan ieu sorangan sareng ngandelkeun pangalaman kuring sorangan dina ngartos prosés ngawaskeun. Dina saluran telegram @monitorim_éta и blog on Medium Kuring ogé nyebarkeun tautan kana tarjamahan Bab 4 tina buku anu sami ngeunaan tujuan tingkat jasa.

Tarjamahan ku ucing. Senang maca!

Tim SRE Google gaduh prinsip dasar sareng prakték pangsaéna pikeun nyiptakeun sistem monitoring sareng béwara anu suksés. Bab ieu nyayogikeun pitunjuk ngeunaan masalah naon waé anu tiasa dipendakan ku pangunjung halaman wéb sareng cara ngabéréskeun masalah anu ngajantenkeun halaman wéb sesah ditampilkeun.

mere batesan

Henteu aya kosakata tunggal anu dianggo pikeun ngabahas topik anu aya hubunganana sareng monitoring. Malah dina Google, istilah di handap teu ilahar dipake, tapi urang bakal daptar interpretasi paling umum.

Ngawaskeun

Koléksi, pamrosésan, aggregation sareng tampilan data kuantitatif sacara real waktos ngeunaan sistem: jumlah pamundut sareng jinis pamundut, jumlah kasalahan sareng jinis kasalahan, waktos ngolah pamundut sareng waktos server.

Ngawaskeun kotak bodas

Ngawaskeun dumasar kana métrik anu ditampilkeun ku komponén sistem internal, kalebet log, métrik profil Mesin Virtual Java, atanapi métrik panangan HTTP anu ngahasilkeun statistik internal.

Ngawaskeun Hideung-kotak

Nguji paripolah aplikasi tina sudut pandang pangguna.

Dasbor

Antarbeungeut (biasana wéb) anu nyayogikeun tinjauan indikator kaséhatan konci jasa. Dashboard tiasa gaduh saringan, kamampuan pikeun milih indikator anu dipidangkeun, jsb. Antarmuka dirancang pikeun ngaidentipikasi indikator anu paling penting pikeun pangguna. Dasbor ogé tiasa nampilkeun inpormasi pikeun staf dukungan téknis: antrian pamundut, daptar kasalahan anu prioritas luhur, sareng insinyur anu ditugaskeun pikeun tanggung jawab anu tangtu.

Waspada (bewara)

Bewara anu dimaksudkeun pikeun ditampi ku hiji jalma ngalangkungan email atanapi cara anu sanés, anu tiasa dipicu ku kasalahan atanapi paningkatan dina antrian pamundut. Bewara digolongkeun kana: tikét, panggeuing email sareng pesen utusan instan.

Akar panyabab

A cacad software atawa kasalahan manusa nu, sakali dilereskeun, teu kudu lumangsung deui. Masalahna tiasa gaduh sababaraha panyabab utama: otomatisasi prosés anu teu cekap, cacad parangkat lunak, elaborasi anu teu cekap tina logika aplikasi. Masing-masing faktor ieu tiasa janten panyababna, sareng masing-masing kedah dileungitkeun.

Node sareng mesin (node ​​sareng mesin)

Istilah anu tiasa ditukeurkeun pikeun ngarujuk kana hiji conto aplikasi anu dijalankeun dina server fisik, mesin virtual, atanapi wadahna. Hiji mesin tiasa nyayogikeun sababaraha jasa. Jasa tiasa:

• disambungkeun ka silih: contona, server cache sarta web server;
• jasa anu teu aya hubunganana dina sapotong hardware: contona, gudang kode sareng wizard pikeun sistem konfigurasi, sapertos Bonéka atawa sirah.

Teken

Sagala parobahan dina konfigurasi software.

Naha perlu ngawaskeun?

Aya sababaraha alesan kunaon aplikasi kedah diawaskeun:

Analisis tren jangka panjang

Sabaraha ageung database sareng kumaha gancangna ngembang? Kumaha jumlah pamaké poéan robah?

Perbandingan kinerja

Naha pamundut langkung gancang dina Acme Bucket of Bytes 2.72 dibandingkeun sareng AJAX DB 3.14? Sabaraha langkung saé panyumputan sindangan saatos munculna titik tambahan? Naha situs ngajalankeun langkung laun dibandingkeun minggu kamari?

Waspada (bewara)

Aya anu rusak sareng aya anu kedah ngalereskeunana. Atawa hiji hal bakal megatkeun geura-giru sarta batur kudu pariksa deui geura-giru.

Nyieun dasbor

Dashboards kedah ngajawab patarosan dasar tur ngawengku hal ti "4 sinyal emas" - telat (latency), lalu lintas (lalulintas), kasalahan (kasalahan) sareng ukuran beban (saturasi).

Ngalaksanakeun analisis retrospektif (debugging)

Tunda pamrosésan pamundut parantos ningkat, tapi naon deui anu kajantenan dina waktos anu sami?
Sistem pangimeutan mangpaat salaku sumber data pikeun sistem intelijen bisnis sareng pikeun ngagampangkeun analisa insiden kaamanan. Kusabab buku ieu museurkeun kana daérah rékayasa dimana SRE gaduh kaahlian, kami moal ngabahas téknik ngawaskeun di dieu.

Pangimeutan sareng panggeuing ngamungkinkeun sistem pikeun ngawartosan anjeun nalika parantos ngarecah atanapi badé ngarecah. Lamun sistem teu bisa otomatis ngalereskeun sorangan, urang hayang hiji manusa analisa ngageter, nangtukeun lamun masalahna masih aktip, ngabéréskeun eta, sarta nangtukeun cukang lantaranana. Upami anjeun henteu nga-audit komponén sistem, anjeun moal pernah nampi waspada ngan saukur kusabab "aya anu rada anéh."

Ngabeungbeuratan jalma ku béwara mangrupikeun panggunaan waktos karyawan anu lumayan mahal. Upami karyawan damel, waspada ngaganggu prosés padamelan. Upami para karyawan aya di bumi, waspada ngaganggu waktos pribadi sareng kamungkinan bobo. Nalika panggeuing sering kajantenan, para karyawan ngiringan aranjeunna, pareum, atanapi teu malire panggeuing anu asup. Ti jaman ka jaman aranjeunna malire waspada nyata, nu masked ku acara noise. Gangguan jasa tiasa tahan kanggo waktos anu lami sabab acara bising nyegah masalahna gancang didiagnosis sareng dilereskeun. Sistem peringatan anu épéktip ngagaduhan rasio sinyal-to-noise anu saé.

Netepkeun ekspektasi lumrah pikeun sistem monitoring

Nyetél ngawaskeun pikeun aplikasi anu kompleks mangrupikeun tugas rékayasa anu rumit. Sanaos ku infrastruktur anu penting pikeun ngumpulkeun, tampilan, sareng alat ngageter, tim Google SRE tina 10-12 anggota biasana kalebet hiji atanapi dua jalma anu tujuan utami nyaéta ngawangun sareng ngajaga sistem ngawaskeun. Jumlah ieu parantos turun dina waktosna nalika urang ngahijikeun sareng sentralisasi infrastruktur ngawaskeun, tapi unggal tim SRE biasana ngagaduhan sahenteuna hiji jalma khusus pikeun ngawaskeun. Urang kudu nyebutkeun yén bari ngawaskeun sistem dashboards rada metot katingal pa, tim SRE taliti nyingkahan kaayaan anu merlukeun batur katingal dina layar pikeun monitor masalah.

Gemblengna, Google parantos ngalih ka sistem ngawaskeun anu sederhana sareng gancang kalayan alat analisis saatos-kanyataan anu optimal. Urang nyingkahan sistem "sihir" anu nyobian ngaduga ambang atanapi otomatis ngadeteksi akar sababna. Sénsor anu ngadeteksi eusi anu teu dihaja dina pamundut pangguna akhir mangrupikeun hiji-hijina conto kontra; Salami sensor ieu tetep saderhana, aranjeunna tiasa gancang ngadeteksi anu nyababkeun anomali serius. Format séjén pikeun ngagunakeun data ngawaskeun, sapertos perencanaan kapasitas atanapi ramalan lalu lintas, langkung kompleks. Observasi dina periode waktu anu pohara lila (bulan atawa taun) dina laju sampling low (jam atawa poé) bakal nembongkeun trend jangka panjang.

Tim Google SRE parantos suksés dicampur sareng hierarki kagumantungan anu kompleks. Urang jarang make aturan kawas "lamun kuring manggihan yén database téh slow, abdi meunang ngageter yén database téh slow, disebutkeun kuring meunang ngageter yén situs téh slow". Aturan dumasar-dependensi biasana ngarujuk kana bagian anu teu tiasa dirobih tina sistem kami, sapertos sistem pikeun nyaring lalu lintas pangguna ka pusat data. Salaku conto, "upami nyaring lalu lintas ka pusat data dikonpigurasi, ulah waspada kuring ngeunaan telat dina ngolah pamundut pangguna" mangrupikeun aturan umum pikeun panggeuing ti pusat data. Sababaraha tim di Google ngadukung hierarki kagumantungan anu kompleks sabab infrastruktur urang gaduh laju refactoring kontinyu.

Sababaraha ideu anu dijelaskeun dina bab ieu masih relevan: sok aya kasempetan pikeun mindahkeun langkung gancang tina gejala ka akar sabab, khususna dina sistem anu terus-terusan robih. Ku alatan éta, bari bab ieu outlines sababaraha tujuan pikeun sistem monitoring sarta kumaha carana ngahontal éta tujuan, hal anu penting yén sistem monitoring basajan tur kaharti ku dulur di tim.

Kitu ogé, pikeun ngajaga tingkat bising lemah sareng tingkat sinyal anu luhur, pendekatan pikeun ngawaskeun aset anu diwaspadakeun kedah saderhana sareng dipercaya. Aturan anu ngahasilkeun peringatan pikeun jalma kedah gampang kahartos sareng nampilkeun masalah anu jelas.

Gejala versus sabab

Sistem ngawaskeun anjeun kedah ngajawab dua patarosan: "naon peupeus" sareng "naha éta pegat."
"Naon peupeus" ceramah ngeunaan gejala, sarta "naha eta peupeus" ceramah ngeunaan cukang lantaranana. tabél di handap nembongkeun conto sambungan misalna.

Gejala
alesan

Kéngingkeun Kasalahan HTTP 500 atanapi 404
Pangladén databés nampik sambungan

réspon server slow
utilization CPU tinggi atawa kabel Ethernet ruksak

Pamaké di Antartika henteu nampi GIF ucing
CDN Anjeun hates élmuwan jeung ucing, jadi sababaraha alamat IP réngsé nepi keur blacklisted

Eusi pribadi parantos sayogi ti mana waé
Ngaluncurkeun sékrési parangkat lunak énggal ngajantenkeun firewall hilap sadayana ACL sareng ngantepkeun sadayana

"Naon" jeung "naha" sababaraha blok wangunan pangpentingna pikeun nyieun sistem ngawaskeun alus kalawan sinyal maksimum sarta noise minimum.

Hideung-kotak vs Bodas-kotak

Urang ngagabungkeun ngawas Bodas-kotak éksténsif jeung modest ngawaskeun Hideung-kotak pikeun metrics kritis. Cara panggampangna pikeun ngabandingkeun Black-box ka White-box nyaéta Black-box museurkeun kana gejala sareng réaktif tinimbang ngawaskeun proaktif: "sistem éta henteu jalan leres ayeuna." Kotak bodas gumantung kana kamampuan verifikasi internal tina sistem: log acara atanapi server wéb. Ku kituna, White-box ngidinan Anjeun pikeun ngadeteksi masalah impending, faults nu sigana retransmission tina pamundut a, jsb.

Catet yén dina sistem multi-lapisan, gejala di daérah tanggung jawab hiji insinyur mangrupikeun gejala di daérah tanggung jawab insinyur sanés. Contona, kinerja database geus turun. Bacaan database anu lambat mangrupikeun gejala tina database SRE anu ngadeteksi aranjeunna. Sanajan kitu, pikeun SRE hareup-tungtung niténan ramatloka slow, ngabalukarkeun sarua slow database maca database slow. Ku alatan éta, ngawaskeun bodas-kotak kadang gejala-fokus sarta kadangkala ngabalukarkeun-fokus, gumantung kana kumaha éksténsif éta.

Nalika ngumpulkeun telemétri pikeun debugging, monitor White-box diperyogikeun. Upami pangladén wéb lambat ngaréspon kana pamundut pangkalan data, anjeun kedah terang kumaha gancangna pangladén wéb komunikasi sareng pangkalan data sareng kumaha gancangna ngaréspon. Upami teu kitu, anjeun moal tiasa ngabédakeun antara pangladén pangkalan data anu lambat sareng masalah jaringan antara pangladén wéb sareng pangkalan data.

Ngawaskeun kotak hideung ngagaduhan kaunggulan konci nalika ngirim panggeuing: anjeun micu bewara ka panampi nalika masalahna parantos nyababkeun gejala nyata. Di sisi anu sanésna, ngawaskeun henteu aya gunana pikeun masalah Black-box anu henteu acan timbul tapi caket.

Opat sinyal emas

Opat sinyal ngawaskeun emas nyaéta latency, lalu lintas, kasalahan, sareng jenuh. Upami anjeun ngan ukur tiasa ngukur opat métrik sistem pangguna, pokus kana opat éta.

Reureuh

Waktos anu diperyogikeun pikeun ngolah pamundut. Kadé ngabedakeun antara latency requests suksés jeung gagal. Contona, kasalahan HTTP 500 disababkeun ku leungitna sambungan kana database atawa backend séjén bisa didiagnosis pisan gancang, kumaha oge, kasalahan HTTP 500 bisa nunjukkeun hiji pamundut gagal. Nangtukeun dampak kasalahan 500 dina latency sakabéh bisa ngakibatkeun conclusions erroneous. Di sisi séjén, kasalahan slow malah kasalahan gancang! Ku alatan éta, hal anu penting pikeun ngawas latency kasalahan tinimbang saukur nyaring kaluar kasalahan.

lalar liwat

Jumlah pamundut ka sistem anjeun diukur dina métrik sistem tingkat luhur. Pikeun layanan wéb, pangukuran ieu biasana ngagambarkeun jumlah pamundut HTTP per detik, dibagi ku sifat pamundut (contona, eusi statik atanapi dinamis). Pikeun sistem streaming audio, pangukuran ieu tiasa difokuskeun kana laju I/O jaringan atanapi jumlah sesi sakaligus. Pikeun sistem panyimpen nilai konci, pangukuran ieu tiasa janten transaksi atanapi hasil pamilarian per detik.

kasalahan

Ieu laju requests gagal anu eksplisit (misalna HTTP 500), implisit (misalna HTTP 200 tapi digabungkeun jeung eusi teu valid) atawa kawijakan (misalna "Lamun direbut respon dina hiji detik, salah sahiji detik mangrupa kasalahan"). Upami kodeu réspon HTTP henteu cekap pikeun ngémutan sadaya kaayaan gagal, protokol sekundér (internal) tiasa diperyogikeun pikeun ngadeteksi kagagalan parsial. Ngawaskeun sadaya pamundut anu salah sapertos kitu tiasa henteu informatif, sedengkeun tés sistem tungtung-ka-tungtung bakal ngabantosan ngadeteksi yén anjeun ngolah eusi anu salah.

jenuh

Métrik nunjukkeun kumaha intensif jasa anjeun dianggo. Ieu ukuran ngawaskeun sistem nu nangtukeun sumberdaya nu paling konstrain (Contona, dina sistem memori-konstrain, nembongkeun memori, dina hiji I / Sistim O-konstrain, nembongkeun jumlah I / os). Catet yén seueur sistem ngaréduksi kinerja sateuacan aranjeunna ngahontal 100% pamakean, janten gaduh tujuan pamanfaatan penting.

Dina sistem kompléks, jenuh bisa complemented ku pangukuran beban tingkat luhur: tiasa jasa anjeun leres nanganan lalulintas ganda, nanganan ngan 10% leuwih lalulintas, atawa nanganan malah kirang lalulintas ti ayeuna? Pikeun layanan basajan nu teu boga parameter nu ngarobah pajeulitna pamundut teh (Contona, "Pasihan abdi nanaon" atawa "Kuring perlu integer monotonik tunggal unik"), nu jarang ngarobah konfigurasi, a nilai test beban statik bisa jadi nyukupan. Sanajan kitu, sakumaha dibahas dina paragraf saméméhna, paling jasa kudu ngagunakeun sinyal teu langsung, kayaning utilization CPU atawa rubakpita jaringan, nu boga wates luhur dipikawanoh. Ngaronjatkeun latency sering mangrupikeun indikator jenuh. Ngukur waktos réspon persentil ka-99 dina jandela leutik (contona, hiji menit) tiasa masihan sinyal jenuh pisan.

Tungtungna, jenuh ogé pakait sareng prediksi ngeunaan jenuh anu bakal datang, contona: "Sigana database anjeun bakal ngeusian hard drive anjeun dina 4 jam."

Upami anjeun ngukur sadayana opat sinyal emas sareng nalika aya masalah sareng salah sahiji métrik (atanapi, dina kasus jenuh, masalah anu caket), anjeun ngingetkeun hiji jalma, jasa anjeun bakal katutupan ku ngawaskeun.

Kahariwang ngeunaan "buntut" (atanapi instrumentasi sareng pagelaran)

Nalika nyiptakeun sistem ngawaskeun ti mimiti, aya godaan pikeun ngembangkeun sistem dumasar kana nilai rata-rata: latency rata-rata, pamakean CPU rata-rata titik, atanapi kapenuhan database rata-rata. Bahaya tina dua conto anu terakhir écés: prosesor sareng pangkalan data dibuang ku cara anu teu kaduga. Sami manglaku ka reureuh. Upami anjeun ngajalankeun ladenan wéb kalayan latén rata-rata 100ms sareng 1000 pamundut per detik, 1% tina pamundut tiasa nyandak 5 detik. Upami pangguna gumantung kana sababaraha jasa wéb sapertos kitu, persentil ka-99 tina hiji backend tiasa gampang janten waktos réspon median tina frontend.

Cara pangbasajanna pikeun ngabédakeun antara rata-rata anu laun sareng buntut anu lambat pisan nyaéta pikeun ngumpulkeun pangukuran paménta anu dinyatakeun dina statistik (alat anu hadé pikeun ditampilkeun nyaéta histogram) tinimbang latency anu saleresna: sabaraha pamundut anu dilayanan ku jasa anu nyandak antara 0 mdet. jeung 10 ms, antara 10 ms jeung 30 ms, antara 30 ms jeung 100 ms, antara 100 ms jeung 300 ms, jsb. Ngalegaan wates histogram kira éksponénsial (ku faktor perkiraan 3) mindeng cara basajan pikeun visualize distribusi tina requests.

Milih tingkat detil anu pas pikeun pangukuran

Unsur-unsur sistem anu béda-béda kedah diukur dina tingkat detil anu béda. Salaku conto:

• Ngawaskeun panggunaan CPU dina sababaraha waktos moal nunjukkeun paku jangka panjang anu nyababkeun latensi tinggi.
• Di sisi anu sanés, pikeun jasa wéb anu nargétkeun henteu langkung ti 9 jam downtime per taun (99,9% uptime taunan), mariksa réspon HTTP 200 langkung ti sakali atanapi dua kali menit sigana teu perlu sering.
• Kitu ogé, mariksa rohangan hard drive pikeun 99,9% kasadiaan leuwih ti sakali unggal 1-2 menit meureun teu perlu.

Jaga kumaha anjeun nyusun granularity ukuran anjeun. Ngumpulkeun beban CPU sakali per detik bisa nyadiakeun data metot, tapi pangukuran sering misalna tiasa pisan mahal pikeun ngumpulkeun, nyimpen, jeung nganalisis. Lamun tujuan ngawaskeun Anjeun merlukeun granularity tinggi na teu merlukeun responsiveness tinggi, Anjeun bisa ngurangan waragad ieu ku cara nyetel ngumpulkeun metrics dina server lajeng nyetel hiji sistem éksternal pikeun ngumpulkeun sarta agrégat metrics maranéhanana. Tiasa henteu anjeun:

1. Ukur beban CPU unggal detik.
2. Ngurangan detil kana 5%.
3. Métrik agrégat unggal menit.

Strategi ieu bakal ngidinan Anjeun pikeun ngumpulkeun data dina granularity tinggi tanpa incurring tinggi analisis jeung neundeun overhead.

Salaku basajan sabisa, tapi teu basajan

The overlay tina syarat béda dina luhureun unggal lianna bisa ngahasilkeun sistem monitoring pisan kompléks. Salaku conto, sistem anjeun tiasa gaduh elemen rumit ieu:

• Panggeuing dumasar kana ambang anu béda pikeun ngolah paménta latency, dina persentil anu béda, pikeun sagala jinis indikator anu béda.
• Nulis kode tambahan pikeun ngadeteksi jeung ngaidentipikasi mungkin sabab.
• Damel dasbor anu aya hubunganana pikeun unggal panyabab masalah.

Sumber komplikasi poténsial henteu aya tungtungna. Sapertos sadaya sistem parangkat lunak, ngawaskeun tiasa janten kompleks anu janten rapuh sareng sesah dirobih sareng dijaga.

Ku alatan éta, rarancang sistem ngawaskeun anjeun pikeun nyederhanakeun sabisa-bisa. Nalika milih naon anu kedah dilacak, perhatikeun ieu:

• Aturan anu paling sering nangkep kajadian nyata kedah saderhana, tiasa diprediksi sareng tiasa dipercaya.
• Konfigurasi pikeun ngumpulkeun data, aggregation, sarta alerting nu dipigawé jarang (contona, kirang ti quarterly pikeun sababaraha tim SRE) kudu dihapus.
• Métrik anu dikumpulkeun tapi henteu ditingalikeun dina dasbor pratinjau atanapi dianggo ku béwara naon waé anu bakal dipupus.

Di Google, koléksi métrik dasar sareng agrégasi, digabungkeun sareng panggeuing sareng dasbor, tiasa dianggo salaku sistem anu kawilang mandiri (sistem ngawaskeun Google saleresna dirobih janten sababaraha subsistem, tapi umumna jalma sadar kana sagala aspek subsistem ieu). Bisa jadi pikabitaeun pikeun ngagabungkeun monitoring jeung téhnik séjén pikeun examining sistem kompléks: profil sistem lengkep, prosés debugging, tracking rinci ngeunaan iwal atawa gagal, nguji beban, ngumpulkeun log jeung analisis, atawa inspeksi lalulintas. Sanaos kalolobaan hal ieu gaduh persamaan sareng ngawaskeun dasar, nyampur aranjeunna bakal ngahasilkeun seueur teuing hasil sareng nyiptakeun sistem anu rumit sareng rapuh. Sapertos seueur aspék pamekaran parangkat lunak, ngadukung sistem anu béda-béda kalayan titik integrasi anu jelas, saderhana, gandeng sacara bébas nyaéta strategi anu pangsaéna (contona, ngagunakeun API wéb pikeun nyandak data agrégat dina format anu tiasa tetep konsisten dina waktos anu lami. ).

Ngahijikeun Prinsip Babarengan

Prinsip-prinsip anu dibahas dina bab ieu tiasa digabungkeun kana filosofi ngawaskeun sareng waspada anu disayogikeun sareng dituturkeun ku tim Google SRE. Adhering kana filosofi monitoring ieu desirable, mangrupakeun titik awal alus pikeun nyieun atawa ngarévisi metodologi alerting Anjeun, tur bisa mantuan Anjeun nanya patarosan katuhu fungsi operasi Anjeun, paduli ukuran organisasi Anjeun atawa pajeulitna jasa atawa sistem.

Nalika nyieun aturan ngawaskeun sareng ngageter, naroskeun patarosan ieu tiasa ngabantosan anjeun ngahindarkeun positip palsu sareng panggeuing anu teu perlu:

• Naha aturan ieu ngadeteksi kaayaan sistem anu teu tiasa dideteksi anu urgent, nyauran tindakan, sareng pasti mangaruhan pangguna?
• Dupi abdi tiasa malire warning ieu nyaho éta benign? Iraha sareng kunaon kuring tiasa malire peringatan ieu sareng kumaha kuring tiasa nyingkahan skenario ieu?
• Naha waspada ieu hartosna yén pangguna dipangaruhan négatip? Naha aya kaayaan dimana pangguna henteu dipangaruhan négatif, sapertos ngalangkungan panyaring lalu lintas atanapi nalika nganggo sistem tés anu kedah disaring béwara?
• Naha kuring tiasa nyandak tindakan pikeun ngaréspon kana peringatan ieu? Naha langkah-langkah ieu penting atanapi tiasa ngantosan dugi ka énjing? Naha tindakan tiasa otomatis otomatis? Naha tindakan ieu bakal janten solusi jangka panjang atanapi solusi jangka pondok?
• Sababaraha urang nampi sababaraha panggeuing pikeun masalah ieu, janten aya cara pikeun ngirangan jumlah panggeuing?

Patarosan ieu ngagambarkeun filosofi dasar ngeunaan peringatan sareng sistem peringatan:

• Unggal ngageter asup, kuring kudu langsung ngaréaksikeun. Abdi tiasa ngaréspon gancang sababaraha kali sadinten sateuacan kuring capé.
• Unggal ngageter kedah relevan.
• Unggal réspon kana waspada kedah ngabutuhkeun campur tangan manusa. Upami béwara tiasa diolah sacara otomatis, éta henteu kedah sumping.
• Panggeuing kedah ngeunaan masalah atanapi kajadian anyar anu teu aya sateuacanna.

Pendekatan ieu ngaburkeun bédana anu tangtu: upami ngageter nyugemakeun opat kaayaan sateuacana, henteu masalah naha ngageter dikirim tina sistem ngawaskeun White-box atanapi Black-Box. pendekatan ieu ogé reinforces béda nu tangtu: eta leuwih hade méakkeun leuwih usaha dina identifying gejala ti on sabab; lamun datang ka sabab, Anjeun ngan perlu salempang ngeunaan sabab dilawan.

Ngawaskeun jangka panjang

Dina lingkungan produktivitas ayeuna, sistem ngawaskeun ngawas sistem produksi anu terus-terusan ngembang kalayan arsitéktur software anu robih, karakteristik beban kerja, sareng target kinerja. Panggeuing anu ayeuna hese diotomatiskeun tiasa janten hal anu lumrah, bahkan panginten kedah dijawab. Dina titik ieu, batur kudu manggihan tur ngaleungitkeun akar ngabalukarkeun masalah; lamun resolusi misalna teu mungkin, respon kana ngageter merlukeun automation pinuh.

Kadé kaputusan ngawaskeun dijieun kalawan tujuan jangka panjang dina pikiran. Unggal ngageter anu ngajalankeun dinten ieu ngaganggu jalma pikeun ningkatkeun sistem énjing, janten sering aya pangurangan dina kasadiaan atanapi kinerja sistem produktif pikeun waktos anu diperyogikeun pikeun ningkatkeun sistem ngawaskeun dina jangka panjang. Hayu urang tingali dua conto pikeun ngagambarkeun fenomena ieu.

Bigtable SRE: Dongeng Leuwih-Siaga

Infrastruktur internal Google biasana disayogikeun sareng diukur ngalawan tingkat layanan (SLO). Sababaraha taun ka pengker, SLO layanan Bigtable dumasar kana kinerja rata-rata transaksi sintétik simulating klien hirup. Alatan masalah dina Bigtable jeung tingkat handap tumpukan gudang, kinerja rata-rata didorong ku buntut "badag": awon 5% tina queries mindeng nyata laun ti sésana.

Bewara email dikirim nalika ambang SLO dideukeutan, sareng panggeuing utusan dikirim nalika SLO ngaleuwihan. Kadua jinis panggeuing sering dikirimkeun, nyéépkeun sajumlah waktos rékayasa anu teu katampi: tim nyéépkeun waktos anu penting pikeun nyortir béwara pikeun milarian sababaraha anu leres-leres relevan. Kami sering kantun masalah anu leres-leres mangaruhan pangguna sabab ngan ukur sababaraha panggeuing pikeun masalah khusus éta. Seueur panggeuing henteu urgent kusabab masalah anu kaharti dina infrastruktur sareng diolah ku cara standar, atanapi henteu diolah pisan.

Pikeun ngalereskeun kaayaan, tim nyandak pendekatan tilu-cabang: Bari digawé teuas pikeun ngaronjatkeun kinerja Bigtable urang, urang samentara nangtukeun tujuan SLO urang jadi persentil 75th pikeun latency respon query. Kami ogé mareuman panggeuing email sabab seueur pisan anu teu mungkin pikeun nyéépkeun waktos pikeun ngadiagnosa aranjeunna.

Strategi ieu ngamungkinkeun urang kamar engapan pikeun ngamimitian ngalereskeun masalah jangka panjang dina Bigtable sareng tingkat handap tumpukan gudang, tinimbang ngalereskeun masalah taktis terus-terusan. Insinyur tiasa leres-leres damel padamelan tanpa dibombardir ku peringatan sepanjang waktos. Pamustunganana, samentawis nunda pamrosésan waspada ngamungkinkeun urang ningkatkeun kualitas palayanan urang.

Gmail: Bisa Diprediksi, Tanggapan Manusa Algoritmik

Dina awalna, Gmail diwangun dina sistem manajemen prosés Workqueue anu dirobih anu dirarancang pikeun ngumpulkeun sakumpulan prosés tina indéks pilarian. Workqueue diadaptasi kana prosés anu hirup panjang teras diterapkeun kana Gmail, tapi sababaraha bug dina kode panjadwal opaque kabuktian hésé pisan dibenerkeun.

Dina waktos éta, pangimeutan Gmail disusun supados panggeuing bakal dipicu nalika tugas individu dibatalkeun nganggo Workqueue. Pendekatan ieu henteu idéal, sabab sanajan dina waktos éta, Gmail ngalaksanakeun rébuan tugas, anu masing-masing disayogikeun ka fraksi persén pangguna urang. Kami prihatin pisan pikeun masihan pangguna Gmail pangalaman pangguna anu saé, tapi nanganan seueur panggeuing henteu tiasa dicapai.

Pikeun ngabéréskeun masalah ieu, Gmail SRE nyiptakeun alat pikeun ngabantosan debug panjadwal sabisa-gancang pikeun ngaleutikan dampak ka pangguna. Tim éta ngagaduhan sababaraha diskusi ngeunaan naha ngan ukur ngajadikeun otomatis sadayana siklus tina panéangan masalah ngaliwatan remediasi dugi ka solusi jangka panjang kapanggih, tapi aya anu prihatin yén solusi sapertos kitu bakal ngalambatkeun leres-leres ngalereskeun masalah.

Tegangan ieu umum dina tim sareng sering nunjukkeun kurangna kapercayaan kana disiplin diri: sedengkeun sababaraha anggota tim hoyong masihan waktos pikeun ngalereskeun anu leres, anu sanésna hariwang yén perbaikan ahir bakal dipopohokeun sareng perbaikan samentawis bakal salamina. Masalah ieu pantes diperhatoskeun sabab gampang teuing pikeun ngalereskeun masalah samentawis tibatan ngajantenkeun kaayaan permanén. Gerentes sareng staf téknis maénkeun peran konci dina ngalaksanakeun perbaikan jangka panjang, ngadukung sareng prioritas perbaikan anu berpotensi jangka panjang sanaos saatos "nyeri" mimiti turun.

Biasa, panggeuing repetitive sareng réspon algoritma kedah janten bandéra beureum. Horéam tim anjeun pikeun ngajadikeun otomatis panggeuing ieu hartosna tim henteu yakin yén aranjeunna tiasa percanten kana algoritma. Ieu masalah serius anu kudu direngsekeun.

Jangka panjang

Téma umum ngahubungkeun conto Bigtable sareng Gmail: kompetisi antara kasadiaan jangka pondok sareng jangka panjang. Mindeng, usaha kuat bisa mantuan sistem rapuh ngahontal kasadiaan tinggi, tapi jalur ieu biasana pondok-cicing, fraught kalawan burnout tim sarta gumantungna kana sajumlah leutik anggota tim heroik sarua.

Dikadalikeun, réduksi jangka pondok dina kasadiaan mindeng nyeri, tapi strategis penting pikeun stabilitas jangka panjang sistem. Kadé ulah kasampak di unggal ngageter di isolasi, tapi mertimbangkeun naha tingkat sakabéh volume ngageter ngarah kana cageur, Sistim diaksés leres kalayan tim giat sarta ramalan nguntungkeun. Urang nganalisis statistik frékuénsi waspada (biasana dinyatakeun salaku insiden per shift, dimana hiji kajadian bisa diwangun ku sababaraha insiden patali) dina laporan quarterly ka manajemén, sahingga makers kaputusan boga tempoan lumangsung beban sistem waspada jeung kaséhatan tim sakabéh.

kacindekan

Jalur pikeun ngawaskeun sareng ngawaskeun séhat saderhana sareng jelas. Éta museurkeun kana gejala masalah anu memicu panggeuing, sareng ngawaskeun sababna janten bantosan pikeun masalah debugging. Ngawaskeun gejala langkung gampang nalika anjeun langkung luhur dina tumpukan anu anjeun kendalikeun, sanaos ngawaskeun beban sareng kinerja pangkalan data kedah dilakukeun langsung dina pangkalan data éta sorangan. Bewara email gaduh kagunaan anu kawates pisan sareng gampang janten bising; tibatan, anjeun kedah nganggo dasbor anu ngawaskeun sadaya masalah ayeuna anu memicu panggeuing email. Dashboard ogé tiasa dipasangkeun sareng log acara pikeun nganalisis korelasi sajarah.

Dina jangka panjang, perlu pikeun ngahontal rotasi suksés ngabejaan ngeunaan gejala jeung masalah nyata caket, adapting tujuan pikeun mastikeun yén monitoring ngarojong diagnosis gancang.

Hatur nuhun pikeun maca tarjamahan nepi ka ahir. Ngalanggan saluran telegram kuring ngeunaan monitoring @monitorim_éta и blog on Medium.

sumber: www.habr.com