Webinar nduweni audio sing ora apik, mula kita wis transkripsi.
Jenengku Medvedev Eduard. Dina iki aku bakal ngomong babagan apa SRE, carane SRE muncul, apa kritéria kerja kanggo insinyur SRE, sethithik babagan kritéria linuwih, sethithik babagan pemantauan. Kita bakal lumaku ing ndhuwur, amarga sampeyan ora bisa ngomong akeh ing jam, nanging aku bakal menehi bahan kanggo review tambahan, lan kita kabeh nunggu sampeyan ing . ing Moscow ing pungkasan Januari.
Pisanan, ayo ngomong babagan apa SRE - Rekayasa Reliabilitas Situs. Lan carane katon minangka posisi sing kapisah, minangka arah sing kapisah. Iku kabeh diwiwiti kanthi kasunyatan manawa ing bunderan pangembangan tradisional, Dev lan Ops minangka rong tim sing beda, biasane kanthi rong tujuan sing beda. Tujuane tim pangembang yaiku ngluncurake fitur-fitur anyar lan nyukupi kabutuhan bisnis. Tujuan saka tim Ops yaiku kanggo mesthekake yen kabeh bisa digunakake lan ora ana sing rusak. Temenan, tujuan kasebut langsung bertentangan: supaya kabeh bisa digunakake lan ora ana sing rusak, gulungake fitur-fitur anyar sabisa-bisa. Amarga iki, ana akeh konflik internal sing metodologi sing saiki diarani DevOps nyoba kanggo ngatasi.
Masalahe yaiku kita ora duwe definisi DevOps sing jelas lan implementasine DevOps sing jelas. Aku ngomong ing konferensi ing Yekaterinburg 2 taun kepungkur, lan nganti saiki bagean DevOps diwiwiti kanthi laporan "Apa DevOps". Ing 2017, Devops meh 10 taun, nanging kita isih mbantah apa iku. Lan iki minangka kahanan sing aneh banget sing Google nyoba ngatasi sawetara taun kepungkur.
Ing 2016, Google ngrilis buku sing diarani Site Reliability Engineering. Lan nyatane, kanthi buku iki gerakan SRE diwiwiti. SRE minangka implementasi spesifik paradigma DevOps ing perusahaan tartamtu. Insinyur SRE duwe komitmen kanggo mesthekake yen sistem bisa digunakake kanthi andal. Umume saka pangembang, kadhangkala saka pangurus kanthi latar mburi pangembangan sing kuwat. Lan padha nindakake apa administrator sistem digunakake kanggo nindakake, nanging latar mburi kuwat ing pembangunan lan kawruh saka sistem ing syarat-syarat kode ndadékaké kanggo kasunyatan sing wong-wong iki ora kepekso kanggo karya administratif tumindake, nanging kepekso kanggo automation.
Pranyata paradigma DevOps ing tim SRE ditindakake kanthi kasunyatan manawa ana insinyur SRE sing ngrampungake masalah struktural. Iki, sambungan sing padha antarane Dev lan Ops sing wis diomongake wong suwene 8 taun. Peran SRE padha karo arsitek amarga wong anyar ora dadi SRE. Wong ing wiwitan karire durung duwe pengalaman, ora duwe kawruh sing perlu. Amarga SRE mbutuhake kawruh banget subtle persis apa lan nalika persis bisa salah. Mulane, sawetara pengalaman dibutuhake ing kene, minangka aturan, ing njero perusahaan lan ing njaba.
Padha takon apa prabédan antarane SRE lan devops bakal diterangake. Dheweke wis mung diterangake. Kita bisa ngomong babagan panggonan SRE ing organisasi. Ora kaya pendekatan DevOps klasik iki, ing ngendi Ops isih dadi departemen sing kapisah, SRE minangka bagean saka tim pangembangan. Dheweke melu pangembangan produk. Malah ana pendekatan ing ngendi SRE minangka peran sing ditransfer saka siji pangembang menyang liyane. Dheweke melu review kode kanthi cara sing padha, contone, desainer UX, pangembang dhewe, kadhangkala manajer produk. SRE kerja ing tingkat sing padha. Kita kudu nyetujoni, kita kudu mriksa maneh, supaya saben panyebaran SRE bakal ujar: "Oke, penyebaran iki, produk iki ora bakal mengaruhi linuwih. Lan yen mengkono, banjur ing sawetara watesan ditrima. Kita uga bakal ngomong babagan iki.
Mulane, SRE duwe hak veto kanggo ngganti kode kasebut. Lan umume, iki uga nyebabake sawetara konflik cilik yen SRE dileksanakake kanthi ora bener. Ing buku sing padha babagan Rekayasa Reliabilitas Situs, akeh bagean, malah ora ana siji, nyritakake carane nyegah konflik kasebut.
Dheweke takon kepiye hubungane SRE karo keamanan informasi. SRE ora melu langsung ing keamanan informasi. Sejatine, ing perusahaan gedhe, iki ditindakake dening individu, penguji, analis. Nanging SRE uga sesambungan karo wong-wong mau ing pangertèn sing sawetara operasi, sawetara laku, sawetara deployments sing mengaruhi keamanan uga bisa mengaruhi kasedhiyan produk. Mulane, SRE sacara sakabehe duwe interaksi karo tim apa wae, kalebu tim keamanan, kalebu analis. Mulane, SRE utamane dibutuhake nalika nyoba ngetrapake DevOps, nanging ing wektu sing padha, beban pangembang dadi gedhe banget. Tegese, tim pangembang dhewe ora bisa ngatasi kasunyatan sing saiki uga kudu tanggung jawab kanggo Ops. Lan ana peran sing kapisah. Peran iki direncanakake ing anggaran. Kadhangkala peran iki dilebokake ing ukuran tim, wong sing kapisah katon, kadhangkala salah sijine pangembang dadi. Iki carane SRE pisanan katon ing tim.
Kompleksitas sistem sing kena pengaruh SRE, kerumitan sing mengaruhi linuwih operasi, perlu lan ora sengaja. Kompleksitas sing dibutuhake yaiku nalika kerumitan produk mundhak nganti kaya sing dibutuhake dening fitur produk anyar. Kompleksitas acak nalika kerumitan sistem mundhak, nanging fitur produk lan syarat bisnis ora langsung mengaruhi iki. Pranyata manawa pangembang nggawe kesalahan ing endi wae, utawa algoritma kasebut ora optimal, utawa sawetara kapentingan tambahan dienalake sing nambah kerumitan produk tanpa perlu khusus. A SRE apik kudu tansah Cut kahanan iki mati. Yaiku, komitmen apa wae, panyebaran apa wae, panjaluk tarik apa wae, sing angel tambah amarga tambahan acak, kudu diblokir.
Pitakonan kenapa ora mung nyewa insinyur, administrator sistem kanthi akeh kawruh ing tim. Pangembang ing peran insinyur, kita dikandhani, dudu solusi kepegawaian sing paling apik. Pangembang ing peran insinyur ora mesthi dadi solusi kepegawaian sing paling apik, nanging sing penting ing kene yaiku pangembang sing melu Ops duwe kepinginan kanggo otomatisasi, duwe kawruh lan katrampilan sing luwih sithik kanggo ngetrapake. otomatis iki. Lan patut, kita nyuda ora mung wektu kanggo sawetara operasi tartamtu, ora mung tumindake, nanging uga paramèter bisnis penting kayata MTTR (Tegese Wektu Kanggo Recovery, wektu Recovery). Mangkono, lan kita uga bakal ngomong babagan iki mengko, kita nyimpen dhuwit kanggo organisasi.
Saiki ayo ngomong babagan kritéria kanggo operasi SRE. Lan pisanan kabeh babagan linuwih. Ing perusahaan cilik, startup, asring kedadeyan yen wong nganggep yen layanan kasebut ditulis kanthi apik, yen produk kasebut ditulis kanthi apik lan bener, bakal bisa digunakake, ora bakal rusak. Sing, kita nulis kode apik, supaya ana apa-apa kanggo break. Kode banget prasaja, ana apa-apa kanggo break. Iki bab wong sing padha ngomong yen kita ora perlu tes, amarga, katon, iki telung cara VPI, kok break kene.
Iki kabeh salah, mesthi. Lan wong-wong iki kerep banget digigit dening kode kasebut ing laku, amarga iku rusak. Kadhangkala kedadeyan kanthi cara sing ora bisa ditebak. Kadang wong ngomong ora, iku ora bakal kelakon. Lan mengkono kabeh wektu. Cukup asring kedadeyan. Lan mulane ora ana sing ngupayakake kasedhiyan 100%, amarga kasedhiyan 100% ora tau kedadeyan. Iki minangka norma. Mulane, nalika kita ngomong babagan kasedhiyan layanan, kita mesthi ngomong babagan sangang. 2 sangang, 3 sangang, 4 sangang, 5 sangang. Yen kita nerjemahake iki menyang downtime, banjur, contone, 5 nines, banjur iki sethitik luwih saka 5 menit downtime saben taun, 2 nines iku 3,5 dina downtime.
Nanging ketok yen ing sawetara titik ana nyuda ing POI, bali ing investasi. Saka rong sangang dadi telung sangang tegese kurang downtime luwih saka 3 dina. Saka papat sangang nganti lima nyuda downtime kanthi 47 menit saben taun. Lan ternyata kanggo bisnis bisa uga ora kritis. Lan umume, keandalan sing dibutuhake dudu masalah teknis, sepisanan, masalah bisnis, yaiku masalah produk. Apa tingkat downtime ditrima kanggo pangguna prodhuk, apa padha nyana, pinten padha mbayar, contone, pinten dhuwit ilang, carane akeh dhuwit sistem ilang.
Pitakonan penting ing kene yaiku apa linuwih komponen sing isih ana. Amarga prabédan antarane 4 lan 5 sangang ora bakal katon ing smartphone karo 2 sangang linuwih. Kira-kira, yen ana sing rusak ing smartphone ing layanan sampeyan 10 kaping setahun, kemungkinan 8 kaping rusak ing sisih OS. Pangguna wis digunakake kanggo iki, lan ora bakal mbayar manungsa waé kanggo liyane wektu taun. Sampeyan perlu kanggo nggandhengake rega nambah linuwih lan nambah bathi.
Mung ing buku ing SRE ana conto sing apik kanggo nambah dadi 4 sangang saka 3 sangang. Pranyata mundhak kasedhiyan kurang saka 0,1%. Lan yen revenue saka layanan punika $1 yuta saben taun, banjur tambah ing revenue $900. Yen regane kurang saka $900 saben taun kanggo nambah keterjangkauan nganti sangang, kenaikan kasebut ndadekake pangertèn finansial. Yen regane luwih saka 900 dolar saben taun, ora ana gunane maneh, amarga paningkatan revenue mung ora ngimbangi biaya tenaga kerja, biaya sumber daya. Lan 3 sangang bakal cukup kanggo kita.
Iki mesthi minangka conto sing disederhanakake ing ngendi kabeh panjaluk padha. Lan pindhah saka 3 sangang nganti 4 sangang cukup gampang, nanging ing wektu sing padha, contone, saka 2 sangang dadi 3, iki wis dadi tabungan 9 ewu dolar, bisa nggawe pangertèn finansial. Alami, ing kasunyatan, kegagalan panyuwunan registrasi luwih elek tinimbang gagal nampilake kaca, panjaluk duwe bobot sing beda. Padha bisa duwe kritéria temen beda saka sudut pandang bisnis, nanging tho, minangka aturan, yen kita ora ngomong bab sawetara layanan tartamtu, iki kira-kira cukup dipercaya.
Kita nampa pitakonan apa SRE minangka salah sawijining koordinator nalika milih solusi arsitektur kanggo layanan kasebut. Upamane ing babagan integrasi menyang prasarana sing wis ana, supaya ora kelangan stabilitas. Ya, SRE, kanthi cara sing padha narik panjaluk, nindakake, rilis mengaruhi arsitektur, introduksi layanan anyar, layanan mikro, implementasine solusi anyar. Apa aku ngomong sadurunge pengalaman dibutuhake, kualifikasi dibutuhake. Nyatane, SRE minangka salah sawijining swara pamblokiran ing solusi arsitektur lan piranti lunak. Mulane, SRE minangka insinyur kudu, pisanan kabeh, ora mung ngerti, nanging uga ngerti carane sawetara pancasan tartamtu bakal mengaruhi linuwih, stabilitas, lan ngerti carane iki ana hubungane karo kabutuhan bisnis, lan saka sudut pandang apa iku bisa ditrima lan kang ora.
Mulane, saiki kita mung bisa ngomong babagan kritéria linuwih, sing ditetepake sacara tradisional ing SRE minangka SLA (Perjanjian Tingkat Layanan). Paling kamungkinan istilah akrab. SLI (Service Level Indicator). SLO (Service Level Objective). Persetujuan Tingkat Layanan bisa uga minangka istilah simbolis, utamane yen sampeyan wis kerja karo jaringan, karo panyedhiya, karo hosting. Iki minangka persetujuan umum sing nggambarake kinerja kabeh layanan sampeyan, paukuman, sawetara paukuman kanggo kesalahan, metrik, kritéria. Lan SLI minangka metrik kasedhiyan dhewe. Sing, apa SLI bisa: wektu nanggepi saka layanan, nomer kasalahan minangka persentasi. Bisa uga bandwidth yen ana sawetara jinis file hosting. Nalika nerangake algoritma pangenalan, indikator kasebut bisa, contone, malah bener jawaban. SLO (Service Level Objective) minangka kombinasi saka indikator SLI, nilai lan periode.
Ayo ngomong SLA bisa kaya iki. Layanan kasedhiya 99,95% wektu ing saindhenging taun. Utawa 99 tiket dhukungan kritis bakal ditutup sajrone 3 jam saben waktu. Utawa 85% pitakon bakal entuk tanggapan sajrone 1,5 detik saben wulan. Yaiku, mboko sithik kita ngerti manawa kesalahan lan kegagalan cukup normal. Iki minangka kahanan sing bisa ditampa, kita ngrancang, malah ngetung nganti sawetara. Tegese, SRE mbangun sistem sing bisa nggawe kesalahan, sing kudu nanggapi kanthi normal kanggo kesalahan, sing kudu digatekake. Lan sawayah-wayah, padha kudu nangani kasalahan supaya pangguna ora sok dong mirsani wong, utawa kabar, nanging ana sawetara jenis workaround, thanks kanggo kang kabeh ora bakal tiba mudhun.
Contone, yen sampeyan ngunggah video menyang YouTube, lan YouTube ora bisa langsung ngowahi, yen video gedhe banget, yen format ora optimal, banjur panjalukan ora bakal gagal kanthi wektu entek, YouTube ora bakal menehi kesalahan 502. , YouTube bakal ujar: "Kita wis nggawe kabeh, video sampeyan lagi diproses. Kira-kira 10 menit wis siyap." Iki minangka prinsip degradasi anggun, sing wis dikenal, contone, saka pangembangan ngarep, yen sampeyan wis nindakake iki.
Istilah sabanjure sing bakal kita ucapake, sing penting banget kanggo nggarap linuwih, kanthi kesalahan, kanthi pangarepan, yaiku MTBF lan MTTR. MTBF minangka wektu rata-rata antarane kegagalan. MTTR Tegese Wektu Kanggo Recovery, rata-rata wektu kanggo Recovery. Yaiku, sepira suwene wektu wiwit kesalahan ditemokake, wiwit kesalahan kasebut katon nganti layanan dibalekake kanthi normal. MTBF utamane ditindakake kanthi kualitas kode. Sing, kasunyatan sing SRE bisa ngomong "ora". Lan sampeyan butuh pangerten saka kabeh tim sing nalika SRE ngandika "ora", ngandika iku ora amarga iku mbebayani, ora amarga iku ala, nanging amarga digunakake everyone bakal nandhang sangsara.
Maneh, ana akeh artikel, akeh cara, akeh cara sanajan ing buku sing asring dakkandhakake, carane nggawe manawa pangembang liyane ora sengit marang SRE. MTTR, ing tangan liyane, babagan nggarap SLO (Tujuan Tingkat Layanan). Lan biasane otomatis. Amarga, contone, SLO kita wektu aktif 4 sangang saben waktu. Iki tegese ing 3 sasi kita bisa ngidini 13 menit downtime. Lan ternyata MTTR ora bisa luwih saka 13 menit. Yen kita nanggapi paling ora 13 downtime sajrone 1 menit, iki tegese kita wis kesel kabeh anggaran kanggo kuartal kasebut. Kita nglanggar SLO. 13 menit kanggo nanggepi lan ndandani kacilakan akeh kanggo mesin, nanging cendhak banget kanggo manungsa. Amarga nganti wong nampa tandha, nganti dheweke nanggapi, nganti dheweke ngerti kesalahane, iku wis sawetara menit. Nganti wong ngerti carane ndandani, apa sing kudu didandani, apa sing kudu ditindakake, banjur sawetara menit maneh. Lan nyatane, sanajan sampeyan mung kudu miwiti maneh server, ternyata, utawa ngunggahake simpul anyar, banjur MTTR kanthi manual wis kira-kira 7-8 menit. Nalika ngotomatisasi proses kasebut, MTTR asring tekan detik, kadhangkala milidetik. Google biasane ngomong babagan milidetik, nanging ing kasunyatan, mesthi, kabeh ora apik.
Saenipun, SRE kudu ngotomatisasi karyane meh rampung, amarga iki langsung mengaruhi MTTR, metrik, SLO kabeh layanan, lan, kanthi mangkono, keuntungan bisnis. Yen wektu ngluwihi, kita ditakoni yen SRE salah. Untunge, ora ana sing kudu disalahake. Lan iki minangka budaya sing kapisah sing disebut postmortem balmeless, sing ora bakal diomongake dina iki, nanging bakal dianalisis ing Slurm. Iki minangka topik sing menarik banget sing bisa diomongake akeh. Kira-kira, yen wektu sing diwenehake saben seprapat wis ngluwihi, mesthine kabeh wong sing disalahake, tegese nyalahake kabeh wong ora produktif, ayo wae, mbok menawa ora nyalahke sapa wae, nanging mbenerake kahanan lan nggarap apa sing ana. Ing pengalamanku, pendekatan iki rada asing kanggo umume tim, utamane ing Rusia, nanging bisa digunakake kanthi apik. Mulane, aku bakal menehi rekomendasi ing pungkasan artikel lan literatur sing bisa diwaca babagan topik iki. Utawa teka menyang Slurm SRE.
Ayo kula nerangake. Yen wektu SLO saben waktu ngluwihi, yen downtime ora 13 menit, nanging 15, sing bisa disalahake kanggo iki? Mesthi, SRE bisa uga disalahake, amarga dheweke kanthi jelas nggawe komitmen utawa penyebaran sing ala. Administrator pusat data bisa uga disalahake, amarga dheweke bisa nindakake sawetara pangopènan sing ora dijadwal. Yen administrator pusat data disalahake, mula wong saka Ops kudu disalahake, sing ora ngetung pangopènan nalika koordinasi SLO. Manajer, direktur teknis utawa wong sing mlebu kontrak pusat data lan ora nggatekake kasunyatan manawa SLA pusat data ora dirancang kanggo downtime sing dibutuhake kanggo nyalahke iki. Patut, kabeh sethitik dening sethitik ing kahanan iki kanggo nyalahke. Lan tegese ora ana gunane nyalahake sapa wae ing kahanan iki. Nanging mesthine kudu didandani. Mulane ana postmortems. Lan yen sampeyan maca, contone, GitHub postmortems, lan iki tansah menarik banget, crita cilik lan ora dikarepke ing saben kasus tartamtu, sampeyan bisa ngganti sing ora ana sing tau ngomong sing wong tartamtu iki kanggo nyalahke. Nyalahke tansah diselehake ing proses ora sampurna tartamtu.
Ayo pindhah menyang pitakonan sabanjure. Otomasi. Nalika aku ngomong babagan otomatisasi ing konteks liyane, aku kerep ngrujuk menyang tabel sing ngandhani suwene sampeyan bisa ngotomatisasi tugas tanpa njupuk wektu luwih akeh kanggo ngotomatisasi tinimbang sing bener disimpen. Ana snag. Sing nyekel yaiku nalika SRE ngotomatisasi tugas, ora mung ngirit wektu, nanging uga ngirit dhuwit, amarga otomatisasi langsung mengaruhi MTTR. Padha nyimpen, supaya bisa ngomong, semangat karyawan lan pangembang, sing uga minangka sumber daya sing ora ana. Padha nyuda rutinitas. Lan kabeh iki duweni efek positif ing karya lan, minangka asil, ing bisnis, sanajan misale jek sing otomatis ora nggawe pangertèn saka segi biaya wektu.
Ing kasunyatan, iku meh tansah duwe, lan ana sawetara banget kasus ngendi soko kudu ora otomatis ing peran SRE. Sabanjure kita bakal ngomong babagan apa sing diarani anggaran kesalahan, anggaran kanggo kesalahan. Ing kasunyatan, ternyata yen kabeh luwih apik kanggo sampeyan tinimbang SLO sing sampeyan aturake dhewe, iki uga ora apik banget. Iki rada ala, amarga SLO dianggo ora mung minangka ngisor, nanging uga minangka wates ndhuwur kira-kira. Nalika sampeyan nyetel dhewe SLO 99% kasedhiyan, lan nyatane sampeyan duwe 99,99%, pranyata sing duwe sawetara papan kanggo nyobi sing ora bakal cilaka bisnis ing kabeh, amarga sampeyan dhewe wis nemtokake iki kabeh bebarengan, lan sampeyan papan iki ora digunakake. Sampeyan duwe anggaran kanggo kesalahan, sing ing kasus sampeyan ora digunakake.
Apa kita nindakake karo. Kita nggunakake kanggo secara harfiah kabeh. Kanggo testing ing kahanan produksi, kanggo muter metu fitur anyar sing bisa mengaruhi kinerja, kanggo release, kanggo pangopènan, kanggo downtimes ngrancang. Aturan mbalikke uga ditrapake: yen anggaran wis kesel, kita ora bisa ngeculake apa-apa sing anyar, amarga yen ora, kita bakal ngluwihi SLO. Anggaran wis kesel, kita wis ngeculake apa wae yen mengaruhi kinerja, yaiku, yen iki dudu sawetara perbaikan sing langsung nambah SLO, mula kita bakal ngluwihi anggaran, lan iki kahanan sing ala. , perlu dianalisis, postmortem, lan bisa uga sawetara perbaikan proses.
Yaiku, yen layanan kasebut ora bisa digunakake kanthi apik, lan SLO dibuwang lan anggaran ora ditindakake kanggo eksperimen, ora kanggo sawetara rilis, nanging dhewe, banjur tinimbang sawetara perbaikan sing menarik, tinimbang fitur sing menarik. tinimbang rilis menarik. Tinimbang sembarang karya kreatif, sampeyan bakal kudu menehi hasil karo mbenakake bodho kanggo njaluk budget bali supaya, utawa nyunting SLO, lan iki uga proses sing ngirim ora kelakon asring.
Mulane, ternyata ing kahanan sing duwe anggaran luwih akeh kanggo kesalahan, kabeh wong kasengsem: loro SRE lan pangembang. Kanggo pangembang, anggaran gedhe kanggo kewan omo tegese sampeyan bisa ngatasi rilis, tes, eksperimen. Kanggo SRE, anggaran kanggo kesalahan lan ngetik anggaran kasebut tegese dheweke langsung nindakake tugas kanthi apik. Lan iki mengaruhi motivasi sawetara jinis karya bebarengan. Yen sampeyan ngrungokake SRE minangka pangembang, sampeyan bakal duwe luwih akeh ruang kanggo kerja sing apik lan luwih rutin.
Pranyata eksperimen ing produksi minangka bagean penting lan meh integral saka SRE ing tim gedhe. Lan biasane diarani chaos engineering, sing asale saka tim ing Netflix sing ngetokake sarana sing diarani Chaos Monkey.
Chaos Monkey nyambung menyang CI / pipo CD lan acak crash server ing produksi. Maneh, ing struktur SRE, kita ngomong bab kasunyatan sing server downed ora ala ing dhewe, wis samesthine. Lan yen ana ing anggaran, bisa ditampa lan ora ngrusak bisnis. Mesthine, Netflix nduweni server sing cukup keluwih, replikasi sing cukup, supaya kabeh iki bisa didandani, lan supaya pangguna kanthi sakabehe ora sok dong mirsani, lan luwih-luwih ora ana sing ninggalake server siji kanggo anggaran apa wae.
Netflix duwe kabeh utilitas kasebut kanggo sawetara wektu, salah sijine, Chaos Gorilla, mateni salah sawijining Zona Ketersediaan Amazon. Lan prekara kasebut mbantu mbukak, sepisanan, dependensi sing didhelikake, nalika ora jelas apa sing kena pengaruh, gumantung apa. Lan iki, yen sampeyan nggarap microservice, lan dokumentasi ora cukup sampurna, iki bisa uga menowo kanggo sampeyan. Lan maneh, iki mbantu akeh kanggo nyekel kesalahan ing kode sing sampeyan ora bisa nyekel ing pementasan, amarga pementasan apa wae ora persis simulasi sing tepat, amarga ukuran beban beda, pola beban beda, peralatan kasebut uga, paling kamungkinan, liyane. Beban puncak bisa uga ora dikarepke lan ora bisa ditebak. Lan tes kasebut, sing maneh ora ngluwihi anggaran, mbantu banget kanggo nangkep kesalahan ing infrastruktur sing ora bakal nangkep pementasan, tes otomatis, pipa CI / CD. Lan anggere iku kabeh klebu ing budget Panjenengan, iku ora Matter sing layanan mudhun ana, sanajan iku bakal katon banget medeni, server mudhun, apa ngimpi elek. Ora, sing normal, sing apik, sing mbantu nyekel kewan omo. Yen sampeyan duwe anggaran, sampeyan bisa nglampahi.
P: Sastra apa sing bisa dakkarepake? Dhaptar ing pungkasan. Ana akeh literatur, aku bakal menehi saran sawetara laporan. Kepiye cara kerjane, lan SRE bisa digunakake ing perusahaan tanpa produk piranti lunak dhewe utawa kanthi pangembangan minimal. Contone, ing perusahaan sing kegiatan utama dudu piranti lunak. Ing perusahaan, ing ngendi kegiatan utama dudu piranti lunak, SRE kerjane persis kaya ing papan liya, amarga ing perusahaan sampeyan uga kudu nggunakake, sanajan ora dikembangake, produk piranti lunak, sampeyan kudu nganyari nganyari, sampeyan kudu ngganti. infrastruktur, sampeyan kudu tuwuh, sampeyan kudu ukuran. Lan SRE mbantu ngenali lan prédhiksi masalah sing bisa ditindakake ing proses kasebut lan ngontrol sawise sawetara wutah diwiwiti lan kabutuhan bisnis diganti. Amarga pancen ora perlu melu pangembangan piranti lunak supaya duwe SRE yen sampeyan duwe paling sethithik sawetara server lan sampeyan bakal duwe paling sethithik wutah.
Semono uga kanggo proyek cilik, organisasi cilik, amarga perusahaan gedhe duwe anggaran lan ruang kanggo eksperimen. Nanging ing wektu sing padha, kabeh woh-wohan eksperimen iki bisa digunakake ing ngendi wae, yaiku, SRE, mesthi, muncul ing Google, ing Netflix, ing Dropbox. Nanging ing wektu sing padha, perusahaan cilik lan startup wis bisa maca materi sing dipadhetke, maca buku, nonton laporan. Padha wiwit krungu bab iku luwih kerep, padha katon ing conto tartamtu, Aku ora apa-apa, iku bisa tenan migunani, kita uga kudu iki, iku apik banget.
Yaiku, kabeh karya utama kanggo standarisasi proses kasebut wis rampung kanggo sampeyan. Sampeyan tetep kanggo nemtokake peran SRE khusus ing perusahaan sampeyan lan wiwiti ngetrapake kabeh praktik kasebut, sing, maneh, wis diterangake. Sing, saka prinsip migunani kanggo perusahaan cilik, iki tansah definisi SLA, SLI, SLO. Yen sampeyan ora melu software, iki bakal SLA internal lan SLO internal, budget internal kanggo kasalahan. Iki meh mesthi ndadékaké sawetara diskusi sing menarik ing tim lan ing bisnis, amarga bisa uga sampeyan nggunakake infrastruktur, ing sawetara organisasi pangolahan sing cocog, pipa sing cocog luwih akeh tinimbang sing dibutuhake. Lan 4 nine sing sampeyan duwe ing departemen IT, sampeyan ora butuh saiki. Nanging ing wektu sing padha, sampeyan bisa nglampahi wektu, nglampahi budget kanggo kesalahane ing mergo.
Mulane, ngawasi lan organisasi ngawasi migunani kanggo perusahaan saka ukuran apa wae. Lan umume, cara iki mikir, ngendi kesalahane soko ditrima, ngendi ana budget, ngendi ana Objectives, iku maneh migunani kanggo perusahaan saka sembarang ukuran, miwiti saka wiwitan kanggo 3 wong.
Sing terakhir saka nuansa teknis sing bakal dibahas yaiku ngawasi. Amarga yen kita ngomong bab SLA, SLI, SLO, kita ora bisa ngerti tanpa ngawasi apa kita pas menyang budget, apa kita tundhuk karo Objectives, lan carane pengaruhe SLA final. Aku wis ndeleng kaping pirang-pirang sing ngawasi kedadeyan kaya iki: ana sawetara nilai, umpamane, wektu panyuwunan menyang server, wektu rata-rata, utawa jumlah panjalukan menyang database. Dheweke duwe standar sing ditemtokake dening insinyur. Yen metrik nyimpang saka norma, banjur e-mail teka. Iki kabeh pancen ora ana gunane, minangka aturan, amarga ndadékaké tandha-tandha kaya ngono, akeh pesen saka pemantauan, nalika wong, sepisanan, kudu menehi interpretasi saben wektu, yaiku, nemtokake manawa nilai metrik kasebut. perlu kanggo sawetara tumindak. Lan kaping pindho, dheweke mung mandheg nggatekake kabeh tandha kasebut, nalika ora ana tumindak sing dibutuhake saka dheweke. Iki minangka aturan ngawasi sing apik lan aturan pisanan nalika SRE dileksanakake yaiku kabar mung kudu ditindakake nalika tumindak dibutuhake.
Ing kasus standar, ana 3 tingkat acara. Ana tandha, ana tiket, ana log. Tandha yaiku apa wae sing mbutuhake sampeyan langsung tumindak. Tegese, kabeh rusak, sampeyan kudu ndandani saiki. Tiket sing mbutuhake tumindak telat. Ya, sampeyan kudu nindakake apa wae, sampeyan kudu nindakake kanthi manual, otomatisasi gagal, nanging sampeyan ora kudu nindakake sawetara menit sabanjure. Log iku apa wae sing ora mbutuhake tumindak, lan umume, yen kabeh mlaku, ora ana sing bakal maca. Sampeyan mung kudu maca log nalika, ing retrospect, ternyata ana sing pecah kanggo sawetara wektu, kita ora ngerti bab iku. Utawa sampeyan kudu nindakake riset. Nanging umume, kabeh sing ora mbutuhake tumindak menyang log.
Minangka efek sisih kabeh iki, yen kita wis ditetepake acara apa mbutuhake tumindak lan uga diterangake apa tumindak iki, iki tegese tumindak bisa otomatis. Sing, apa mengkono. Kita lunga saka waspada. Ayo padha tumindak. Kita pindhah menyang gambaran saka tumindak iki. Banjur kita pindhah menyang otomatisasi. Yaiku, otomatisasi apa wae diwiwiti kanthi reaksi menyang acara.
Saka ngawasi, kita pindhah menyang istilah sing diarani Observability. Ana uga sawetara hype babagan tembung iki sajrone sawetara taun kepungkur. Lan sawetara wong ngerti apa tegese metu saka konteks. Nanging titik utama yaiku Observability minangka metrik kanggo transparansi sistem. Yen ana sing salah, sepira cepet sampeyan bisa nemtokake apa sing salah lan apa kahanan sistem kasebut ing wektu kasebut. Ing istilah kode: fungsi sing gagal, layanan sing gagal. Apa kahanan, contone, variabel internal, konfigurasi. Ing babagan infrastruktur, ing ngendi zona kasedhiyan ana kegagalan, lan yen sampeyan duwe Kubernetes sing diinstal, banjur ing pod endi kegagalan kasebut, apa kahanan pod kasebut. Lan miturut, Observability nduweni hubungan langsung karo MTTR. Sing luwih dhuwur Observability saka layanan, luwih gampang kanggo ngenali kesalahan, luwih gampang kanggo ndandani kesalahan, luwih gampang kanggo ngotomatisasi kesalahan, ing ngisor MTTR.
Ngalih menyang perusahaan cilik maneh, umum banget kanggo takon, sanajan saiki, kepiye cara ngatasi ukuran tim, lan manawa tim cilik kudu nyewa SRE sing kapisah. Wis ngomong bab iki sethitik sadurungé. Ing tahap wiwitan pangembangan wiwitan utawa, contone, tim, iki ora perlu, amarga SRE bisa dadi peran transisi. Lan iki bakal nyegerake tim sethithik, amarga paling ora ana macem-macem. Lan ditambahake bakal nyiapake wong kanggo kasunyatan manawa kanthi wutah, umume, tanggung jawab SRE bakal owah banget. Yen sampeyan nyewa wong, mesthi, dheweke duwe sawetara pangarepan. Lan pangarepan iki ora bakal owah saka wektu, nanging syarat bakal diganti banget. Mulane, carane nyewa SRE cukup angel ing tahap awal. Tuwuh dhewe luwih gampang. Nanging kudu dipikirake.
Siji-sijine pangecualian, mbok menawa, nalika ana syarat pertumbuhan sing ketat lan jelas. Yaiku, ing kasus wiwitan, iki bisa uga ana tekanan saka investor, sawetara ramalan kanggo tuwuh kaping pirang-pirang sekaligus. Banjur nyewa SRE pancen bener amarga bisa dibenerake. Kita duwe syarat kanggo wutah, kita butuh wong sing tanggung jawab kanggo kasunyatan manawa kanthi wutah kasebut ora ana sing bakal rusak.
Siji pitakonan maneh. Apa sing kudu ditindakake nalika kaping pirang-pirang pangembang ngethok fitur sing lulus tes, nanging ngrusak produksi, ngemot dhasar, ngilangi fitur liyane, proses apa sing kudu ditindakake. Patut, ing kasus iki, iku budget kanggo kasalahan sing ngenalaken. Lan sawetara layanan, sawetara fitur sing wis diuji ing produksi. Bisa dadi kenari, nalika mung sawetara pangguna, nanging wis ana ing produksi, fitur wis disebarake, nanging wis ngarep-arep yen ana sing rusak, umpamane, setengah persen kabeh pangguna, isih bakal ketemu budget kanggo kasalahan. Patut, ya, bakal ana kesalahan, kanggo sawetara pangguna kabeh bakal rusak, nanging kita wis ujar manawa iki normal.
Ana pitakonan babagan alat SRE. Yaiku, apa ana sing bakal digunakake SRE sing ora bakal digunakake dening wong liya. Nyatane, ana sawetara utilitas khusus, ana sawetara piranti lunak sing, contone, nyimulasi beban utawa melu tes kenari A / B. Nanging dhasar toolkit SRE yaiku sing wis digunakake para pangembang sampeyan. Amarga SRE sesambungan langsung karo tim pangembangan. Lan yen sampeyan duwe alat sing beda-beda, mula butuh wektu kanggo nyinkronake. Utamane yen SRE kerja ing tim gedhe, ing perusahaan gedhe sing bisa ana sawetara tim, standarisasi perusahaan sing bakal mbantu akeh ing kene, amarga yen 50 utilitas beda digunakake ing 50 tim, iki tegese SRE kudu ngerti. kabeh. Lan mesthi iki ora bakal kelakon. Lan kualitas karya, kualitas kontrol paling ora sawetara tim bakal suda sacara signifikan.
Webinar kita wis rampung. Aku bisa ngomong sawetara perkara dhasar. Mesthi, ora ana apa-apa babagan SRE sing bisa dicritakake lan dimangerteni sajrone jam. Nanging muga-muga aku bisa ngaturake cara mikir iki, minangka poin utama. Lan banjur bakal bisa, yen kasengsem, kanggo delve menyang topik, sinau ing dhewe, ndeleng carane lagi dipun ginakaken dening wong liya, ing perusahaan liyane. Lan miturut, ing awal Februari, teka menyang kita ing Slurm SRE.
Slurm SRE minangka kursus intensif telung dina sing bakal ngomong babagan apa sing saiki dakkandhakake, nanging kanthi luwih jero, kanthi kasus nyata, kanthi praktik, kabeh intensif ditujokake kanggo kerja praktis. Wong bakal dipérang dadi tim. Sampeyan kabeh bakal nggarap kasus nyata. Mulane, kita duwe instruktur Booking.com Ivan Kruglov lan Ben Tyler. Kita duwe Eugene Barabbas sing apik banget saka Google, saka San Francisco. Lan aku uga bakal ngandhani sampeyan. Dadi manawa kanggo ngunjungi kita.
Dadi, bibliografi. Ana referensi ing SRE. ing buku sing padha, utawa luwih ing 2 buku babagan SRE, sing ditulis dening Google. Siji liyane , ngendi syarat lan aplikasi sing rada luwih rinci. 3 sabanjure yaiku laporan babagan SRE ing macem-macem perusahaan. pisanan- , iki minangka intine saka Ben Trainer Google. Kapindho - . Katelu maneh . Laporan kaping papat saka , sing mung duwe 5 karyawan kunci SRE ing 190 negara. Apik banget kanggo ndeleng kabeh iki, amarga kaya DevOps tegese beda banget kanggo perusahaan sing beda-beda lan uga tim sing beda, SRE duwe tanggung jawab sing beda banget, sanajan ing perusahaan sing ukurane padha.
2 pranala liyane babagan prinsip chaos engineering: , . Lan ing pungkasan ana 3 dhaptar saka seri Awesome Lists babagan , babagan lan babagan . Dhaptar ing SRE iku luar biasa ageng, iku ora perlu kanggo mbukak liwat kabeh, ana bab 200 artikel. Aku banget nyaranake artikel saka ing kana babagan perencanaan kapasitas lan babagan postmortem tanpa cacad.
Artikel sing nyenengake:
Matur nuwun kanggo ngrungokake aku kabeh wektu iki. Mugi sampeyan wis sinau soko. Muga-muga sampeyan duwe materi sing cukup kanggo sinau luwih akeh. Lan ketemu sampeyan. Muga-muga ing Februari.
Webinar iki dianakake dening Eduard Medvedev.
PS: kanggo sing seneng maca, Eduard menehi dhaptar referensi. Sing seneng mangertos ing laku olèh .
Source: www.habr.com