Transkripsi webinar "SRE - gembar-gembur atau masa depan?"

Webinar mempunyai audio yang lemah, jadi kami telah menyalinnya.

Nama saya Medvedev Eduard. Hari ini saya akan bercakap tentang apa itu SRE, bagaimana SRE muncul, apakah kriteria kerja untuk jurutera SRE, sedikit tentang kriteria kebolehpercayaan, sedikit tentang pemantauannya. Kami akan berjalan di puncak, kerana anda tidak boleh memberitahu banyak dalam satu jam, tetapi saya akan memberikan bahan untuk semakan tambahan, dan kami semua menunggu untuk anda di Slurme SRE. di Moscow pada akhir Januari.

Mula-mula, mari kita bercakap tentang apa itu SRE - Kejuruteraan Kebolehpercayaan Tapak. Dan bagaimana ia muncul sebagai kedudukan yang berasingan, sebagai arah yang berasingan. Semuanya bermula dengan fakta bahawa dalam kalangan pembangunan tradisional, Dev dan Ops adalah dua pasukan yang sama sekali berbeza, biasanya dengan dua matlamat yang sama sekali berbeza. Matlamat pasukan pembangunan adalah untuk melancarkan ciri baharu dan memenuhi keperluan perniagaan. Matlamat pasukan Ops adalah untuk memastikan semuanya berfungsi dan tiada yang rosak. Jelas sekali, matlamat ini secara langsung bercanggah antara satu sama lain: agar segala-galanya berfungsi dan tiada apa-apa untuk dipecahkan, lancarkan ciri baharu sesedikit mungkin. Oleh sebab itu, terdapat banyak konflik dalaman yang cuba diselesaikan oleh metodologi yang kini dipanggil DevOps.

Masalahnya ialah kami tidak mempunyai definisi DevOps yang jelas dan pelaksanaan DevOps yang jelas. Saya bercakap pada persidangan di Yekaterinburg 2 tahun lalu, dan sehingga kini bahagian DevOps bermula dengan laporan "Apa itu DevOps". Pada tahun 2017, Devops berusia hampir 10 tahun, tetapi kami masih mempertikaikan apa itu. Dan ini adalah situasi yang sangat pelik yang cuba diselesaikan oleh Google beberapa tahun lalu.

Pada tahun 2016, Google mengeluarkan buku yang dipanggil Kejuruteraan Kebolehpercayaan Tapak. Dan sebenarnya, dengan buku inilah gerakan SRE bermula. SRE ialah pelaksanaan khusus paradigma DevOps dalam syarikat tertentu. Jurutera SRE komited untuk memastikan sistem beroperasi dengan pasti. Mereka kebanyakannya datang daripada pembangun, kadangkala daripada pentadbir dengan latar belakang pembangunan yang kukuh. Dan mereka melakukan apa yang biasa dilakukan oleh pentadbir sistem, tetapi latar belakang yang kukuh dalam pembangunan dan pengetahuan sistem dari segi kod membawa kepada fakta bahawa mereka ini tidak cenderung kepada kerja pentadbiran rutin, tetapi cenderung kepada automasi.

Ternyata paradigma DevOps dalam pasukan SRE dilaksanakan oleh fakta bahawa terdapat jurutera SRE yang menyelesaikan masalah struktur. Ini dia, hubungan yang sama antara Dev dan Ops yang telah diperkatakan oleh orang ramai selama 8 tahun. Peranan SRE adalah serupa dengan arkitek kerana pendatang baru tidak menjadi SRE. Orang pada permulaan kerjaya mereka belum mempunyai apa-apa pengalaman, tidak mempunyai keluasan pengetahuan yang diperlukan. Kerana SRE memerlukan pengetahuan yang sangat halus tentang apa dan bila sebenarnya boleh menjadi salah. Oleh itu, beberapa pengalaman diperlukan di sini, sebagai peraturan, di dalam syarikat dan di luar.

Mereka bertanya sama ada perbezaan antara SRE dan devops akan diterangkan. Dia baru sahaja diterangkan. Kita boleh bercakap tentang tempat SRE dalam organisasi. Tidak seperti pendekatan DevOps klasik ini, di mana Ops masih merupakan jabatan yang berasingan, SRE adalah sebahagian daripada pasukan pembangunan. Mereka terlibat dalam pembangunan produk. Malah terdapat pendekatan di mana SRE adalah peranan yang berpindah dari satu pembangun kepada pemaju yang lain. Mereka mengambil bahagian dalam ulasan kod dengan cara yang sama seperti, sebagai contoh, pereka UX, pembangun sendiri, kadangkala pengurus produk. SRE berfungsi pada tahap yang sama. Kami perlu meluluskannya, kami perlu menyemaknya, supaya bagi setiap penggunaan SRE berkata: “Baiklah, penggunaan ini, produk ini tidak akan menjejaskan kebolehpercayaan secara negatif. Dan jika ia berlaku, maka dalam beberapa had yang boleh diterima. Kami juga akan bercakap tentang ini.

Sehubungan itu, SRE mempunyai hak veto untuk menukar kod tersebut. Dan secara umum, ini juga membawa kepada beberapa jenis konflik kecil jika SRE dilaksanakan secara tidak betul. Dalam buku yang sama tentang Kejuruteraan Kebolehpercayaan Tapak, banyak bahagian, bukan satu pun, memberitahu cara untuk mengelakkan konflik ini.

Mereka bertanya bagaimana SRE berkaitan dengan keselamatan maklumat. SRE tidak terlibat secara langsung dalam keselamatan maklumat. Pada asasnya, dalam syarikat besar, ini dilakukan oleh individu, penguji, penganalisis. Tetapi SRE juga berinteraksi dengan mereka dalam erti kata bahawa beberapa operasi, beberapa komit, beberapa penempatan yang menjejaskan keselamatan juga boleh menjejaskan ketersediaan produk. Oleh itu, SRE secara keseluruhannya mempunyai interaksi dengan mana-mana pasukan, termasuk pasukan keselamatan, termasuk penganalisis. Oleh itu, SRE amat diperlukan apabila mereka cuba melaksanakan DevOps, tetapi pada masa yang sama, beban pembangun menjadi terlalu besar. Maksudnya, pasukan pembangunan itu sendiri tidak lagi dapat menampung hakikat bahawa kini mereka juga perlu bertanggungjawab terhadap Ops. Dan ada peranan yang berasingan. Peranan ini dirancang dalam belanjawan. Kadang-kadang peranan ini ditetapkan dalam saiz pasukan, orang yang berasingan muncul, kadang-kadang salah seorang pembangun menjadinya. Ini adalah bagaimana SRE pertama muncul dalam pasukan.

Kerumitan sistem yang dipengaruhi oleh SRE, kerumitan yang menjejaskan kebolehpercayaan operasi, adalah perlu dan tidak sengaja. Kerumitan yang diperlukan ialah apabila kerumitan produk meningkat sehingga tahap yang diperlukan oleh ciri produk baharu. Kerumitan rawak ialah apabila kerumitan sistem meningkat, tetapi ciri produk dan keperluan perniagaan tidak menjejaskan perkara ini secara langsung. Ternyata sama ada pembangun membuat kesilapan di suatu tempat, atau algoritma tidak optimum, atau beberapa minat tambahan diperkenalkan yang meningkatkan kerumitan produk tanpa keperluan khas. SRE yang baik harus sentiasa memotong keadaan ini. Iaitu, sebarang komitmen, apa-apa kerahan, sebarang permintaan tarik, di mana kesukaran meningkat disebabkan penambahan rawak, harus disekat.

Persoalannya kenapa tidak ambil jurutera sahaja, pentadbir sistem yang mempunyai banyak pengetahuan dalam pasukan. Seorang pemaju yang berperanan sebagai jurutera, kami diberitahu, bukanlah penyelesaian kakitangan terbaik. Pembangun yang berperanan sebagai jurutera bukanlah selalunya penyelesaian perjawatan terbaik, tetapi maksudnya di sini ialah pembangun yang terlibat dalam Ops mempunyai lebih sedikit keinginan untuk automasi, mempunyai lebih sedikit pengetahuan dan set kemahiran untuk melaksanakan automasi ini. Dan dengan itu, kami mengurangkan bukan sahaja masa untuk beberapa operasi tertentu, bukan sahaja rutin, tetapi juga parameter perniagaan yang penting seperti MTTR (Mean Time To Recovery, masa pemulihan). Oleh itu, dan kami juga akan bercakap tentang perkara ini sedikit kemudian, kami menjimatkan wang untuk organisasi.

Sekarang mari kita bercakap tentang kriteria untuk operasi SRE. Dan pertama sekali mengenai kebolehpercayaan. Dalam syarikat kecil, permulaan, ia sering berlaku bahawa orang menganggap bahawa jika perkhidmatan itu ditulis dengan baik, jika produk itu ditulis dengan baik dan betul, ia akan berfungsi, ia tidak akan pecah. Itu sahaja, kami menulis kod yang baik, jadi tiada apa yang perlu dipecahkan. Kodnya sangat mudah, tiada apa yang perlu dipecahkan. Ini adalah kira-kira orang yang sama yang mengatakan bahawa kita tidak memerlukan ujian, kerana, lihat, ini adalah tiga kaedah VPI, mengapa putus di sini.

Ini semua salah, sudah tentu. Dan orang-orang ini sangat kerap digigit oleh kod sedemikian dalam amalan, kerana perkara-perkara pecah. Perkara pecah kadang-kadang dengan cara yang paling tidak dapat diramalkan. Kadang-kadang orang berkata tidak, ia tidak akan berlaku. Dan ia berlaku sepanjang masa. Ia berlaku cukup kerap. Dan itulah sebabnya tiada siapa yang pernah berusaha untuk ketersediaan 100%, kerana ketersediaan 100% tidak pernah berlaku. Ini adalah norma. Oleh itu, apabila kita bercakap tentang ketersediaan perkhidmatan, kita sentiasa bercakap tentang sembilan. 2 sembilan, 3 sembilan, 4 sembilan, 5 sembilan. Jika kita menterjemah ini ke dalam masa henti, maka, sebagai contoh, 5 sembilan, maka ini adalah lebih sedikit daripada 5 minit masa henti setahun, 2 sembilan adalah 3,5 hari masa henti.

Tetapi jelas bahawa pada satu ketika terdapat penurunan dalam POI, pulangan pelaburan. Berubah daripada dua sembilan kepada tiga sembilan bermakna kurang masa henti selama lebih daripada 3 hari. Berubah daripada empat sembilan kepada lima mengurangkan masa berhenti sebanyak 47 minit setahun. Dan ternyata untuk perniagaan ia mungkin tidak kritikal. Dan secara umum, kebolehpercayaan yang diperlukan bukanlah isu teknikal, pertama sekali, ia adalah isu perniagaan, ia adalah isu produk. Apakah tahap masa henti yang boleh diterima untuk pengguna produk, apa yang mereka jangkakan, berapa banyak yang mereka bayar, contohnya, berapa banyak wang yang mereka hilang, berapa banyak wang yang hilang oleh sistem.

Soalan penting di sini ialah apakah kebolehpercayaan komponen yang tinggal. Kerana perbezaan antara 4 dan 5 sembilan tidak akan kelihatan pada telefon pintar dengan 2 sembilan kebolehpercayaan. Secara kasarnya, jika sesuatu rosak pada telefon pintar dalam perkhidmatan anda 10 kali setahun, kemungkinan besar 8 kali kerosakan berlaku pada bahagian OS. Pengguna sudah biasa dengan ini, dan tidak akan memberi perhatian sekali lagi dalam setahun. Ia adalah perlu untuk mengaitkan harga peningkatan kebolehpercayaan dan peningkatan keuntungan.
Hanya dalam buku mengenai SRE terdapat contoh yang baik untuk meningkatkan kepada 4 sembilan daripada 3 sembilan. Ternyata peningkatan ketersediaan adalah kurang sedikit daripada 0,1%. Dan jika hasil perkhidmatan itu ialah $1 juta setahun, maka peningkatan hasil ialah $900. Jika kos kami kurang daripada $900 setahun untuk meningkatkan kemampuan sebanyak sembilan, kenaikan itu masuk akal dari segi kewangan. Jika kosnya lebih daripada 900 dolar setahun, ia tidak lagi masuk akal, kerana peningkatan hasil semata-mata tidak mengimbangi kos buruh, kos sumber. Dan 3 sembilan akan cukup untuk kami.

Ini sudah tentu contoh yang dipermudahkan di mana semua permintaan adalah sama. Dan pergi dari 3 sembilan kepada 4 sembilan adalah cukup mudah, tetapi pada masa yang sama, sebagai contoh, pergi dari 2 sembilan kepada 3, ini sudah menjadi penjimatan sebanyak 9 ribu dolar, ia boleh masuk akal kewangan. Sememangnya, pada hakikatnya, kegagalan permintaan pendaftaran adalah lebih teruk daripada kegagalan untuk memaparkan halaman, permintaan mempunyai berat yang berbeza. Mereka mungkin mempunyai kriteria yang sama sekali berbeza dari sudut pandangan perniagaan, tetapi bagaimanapun, sebagai peraturan, jika kita tidak bercakap tentang beberapa perkhidmatan tertentu, ini adalah anggaran yang boleh dipercayai.
Kami menerima soalan sama ada SRE adalah salah satu penyelaras semasa memilih penyelesaian seni bina untuk perkhidmatan tersebut. Katakan dari segi integrasi ke dalam infrastruktur sedia ada, supaya tidak ada kerugian dalam kestabilannya. Ya, SRE, dengan cara yang sama menarik permintaan, komit, keluaran mempengaruhi seni bina, pengenalan perkhidmatan baharu, perkhidmatan mikro, pelaksanaan penyelesaian baharu. Kenapa saya kata sebelum ini pengalaman diperlukan, kelayakan diperlukan. Malah, SRE adalah salah satu suara penyekat dalam mana-mana penyelesaian seni bina dan perisian. Sehubungan itu, SRE sebagai jurutera mesti, pertama sekali, bukan sahaja memahami, tetapi juga memahami bagaimana beberapa keputusan tertentu akan mempengaruhi kebolehpercayaan, kestabilan, dan memahami bagaimana ini berkaitan dengan keperluan perniagaan, dan dari sudut pandangan apakah ia boleh diterima dan yang tidak.

Oleh itu, kini kita boleh bercakap tentang kriteria kebolehpercayaan, yang secara tradisinya ditakrifkan dalam SRE sebagai SLA (Perjanjian Tahap Perkhidmatan). Kemungkinan besar istilah yang biasa. SLI (Penunjuk Tahap Perkhidmatan). SLO (Objektif Tahap Perkhidmatan). Perjanjian Tahap Perkhidmatan mungkin merupakan istilah simbolik, terutamanya jika anda telah bekerja dengan rangkaian, dengan pembekal, dengan pengehosan. Ini ialah perjanjian umum yang menerangkan prestasi keseluruhan perkhidmatan anda, penalti, beberapa penalti untuk kesilapan, metrik, kriteria. Dan SLI ialah metrik ketersediaan itu sendiri. Iaitu, apa yang boleh SLI: masa tindak balas daripada perkhidmatan, bilangan ralat sebagai peratusan. Ia boleh menjadi lebar jalur jika ia adalah sejenis pengehosan fail. Apabila ia datang kepada algoritma pengecaman, penunjuk boleh, sebagai contoh, walaupun ketepatan jawapan. SLO (Objektif Tahap Perkhidmatan) adalah, masing-masing, gabungan penunjuk SLI, nilai dan tempohnya.

Katakan SLA boleh jadi seperti ini. Perkhidmatan ini tersedia 99,95% sepanjang tahun. Atau 99 tiket sokongan kritikal akan ditutup dalam masa 3 jam setiap suku tahun. Atau 85% permintaan akan dijawab dalam masa 1,5 saat setiap bulan. Iaitu, kita secara beransur-ansur memahami bahawa kesilapan dan kegagalan adalah perkara biasa. Ini adalah keadaan yang boleh diterima, kami sedang merancangnya, malah kami juga mengharapkannya sedikit sebanyak. Iaitu, SRE membina sistem yang boleh membuat kesilapan, yang mesti bertindak balas secara normal kepada ralat, yang mesti mengambil kiranya. Dan apabila boleh, mereka harus mengendalikan ralat sedemikian rupa sehingga pengguna sama ada tidak menyedarinya, atau menyedarinya, tetapi terdapat beberapa jenis penyelesaian, yang mana semuanya tidak akan jatuh sepenuhnya.

Sebagai contoh, jika anda memuat naik video ke YouTube, dan YouTube tidak boleh menukarnya dengan serta-merta, jika video terlalu besar, jika format tidak optimum, maka permintaan secara semula jadi tidak akan gagal dengan tamat masa, YouTube tidak akan memberikan ralat 502 , YouTube akan berkata: “Kami telah mencipta segala-galanya, video anda sedang diproses. Ia akan siap dalam masa kira-kira 10 minit." Ini adalah prinsip kemerosotan anggun, yang biasa, contohnya, dari pembangunan bahagian hadapan, jika anda pernah melakukan ini.

Istilah seterusnya yang akan kita bincangkan, yang sangat penting untuk bekerja dengan kebolehpercayaan, dengan ralat, dengan jangkaan, adalah MTBF dan MTTR. MTBF ialah masa purata antara kegagalan. MTTR Mean Time To Recovery, purata masa untuk pemulihan. Iaitu, berapa lama masa telah berlalu dari saat ralat ditemui, dari saat ralat muncul hingga saat perkhidmatan dipulihkan kepada operasi normal penuh. MTBF terutamanya ditetapkan oleh kerja pada kualiti kod. Iaitu, hakikat bahawa SRE boleh berkata "tidak". Dan anda memerlukan pemahaman seluruh pasukan bahawa apabila SRE berkata "tidak", dia mengatakannya bukan kerana dia berbahaya, bukan kerana dia jahat, tetapi kerana jika tidak semua orang akan menderita.

Sekali lagi, terdapat banyak artikel, banyak kaedah, banyak cara walaupun dalam buku yang sering saya rujuk, bagaimana untuk memastikan bahawa pembangun lain tidak mula membenci SRE. MTTR, sebaliknya, adalah tentang mengusahakan SLO anda (Objektif Tahap Perkhidmatan). Dan ia kebanyakannya automasi. Kerana, sebagai contoh, SLO kami adalah masa operasi 4 sembilan setiap suku tahun. Ini bermakna dalam 3 bulan kita boleh membenarkan 13 minit masa berhenti. Dan ternyata MTTR tidak boleh melebihi 13 minit. Jika kami membalas sekurang-kurangnya 13 masa henti dalam 1 minit, ini bermakna kami telah menghabiskan keseluruhan belanjawan untuk suku tersebut. Kami melanggar SLO. 13 minit untuk bertindak balas dan membetulkan ranap adalah banyak untuk mesin, tetapi sangat singkat untuk manusia. Kerana sehingga seseorang menerima amaran, sehingga dia bertindak balas, sehingga dia memahami kesilapan itu, sudah beberapa minit. Sehingga seseorang memahami bagaimana untuk memperbaikinya, apa sebenarnya yang perlu diperbaiki, apa yang perlu dilakukan, maka ini adalah beberapa minit lagi. Dan sebenarnya, walaupun anda hanya perlu memulakan semula pelayan, ternyata, atau menaikkan nod baru, maka secara manual MTTR sudah kira-kira 7-8 minit. Apabila mengautomasikan proses, MTTR selalunya mencapai satu saat, kadangkala milisaat. Google biasanya bercakap tentang milisaat, tetapi pada hakikatnya, sudah tentu, semuanya tidak begitu baik.

Sebaik-baiknya, SRE harus mengautomasikan kerjanya hampir sepenuhnya, kerana ini secara langsung memberi kesan kepada MTTR, metriknya, SLO keseluruhan perkhidmatan dan, oleh itu, keuntungan perniagaan. Jika melebihi masa, kami ditanya sama ada SRE bersalah. Nasib baik, tiada siapa yang perlu dipersalahkan. Dan ini adalah budaya berasingan yang dipanggil postmortem balmeless, yang kita tidak akan bercakap tentang hari ini, tetapi kita akan menganalisisnya di Slurm. Ini adalah topik yang sangat menarik yang boleh dibincangkan banyak. Secara kasarnya, jika melebihi masa yang diperuntukkan bagi setiap suku tahun, maka sedikit sebanyak semua orang dipersalahkan, bermakna menyalahkan semua orang tidak produktif, biarlah, mungkin tidak menyalahkan sesiapa, tetapi betulkan keadaan dan bekerja dengan apa yang kita ada. Mengikut pengalaman saya, pendekatan ini agak asing bagi kebanyakan pasukan, terutamanya di Rusia, tetapi ia masuk akal dan berfungsi dengan baik. Oleh itu, saya akan mengesyorkan pada akhir artikel dan kesusasteraan yang boleh anda baca mengenai topik ini. Atau datang ke Slurm SRE.

Biar saya jelaskan. Jika masa SLO setiap suku tahun melebihi, jika masa rehat bukan 13 minit, tetapi 15, siapa yang boleh dipersalahkan untuk ini? Sudah tentu, SRE mungkin dipersalahkan, kerana dia jelas membuat beberapa jenis komitmen atau penempatan yang tidak baik. Pentadbir pusat data mungkin dipersalahkan untuk ini, kerana dia mungkin telah menjalankan beberapa jenis penyelenggaraan tidak berjadual. Jika pentadbir pusat data dipersalahkan untuk ini, maka orang dari Ops harus dipersalahkan untuk ini, yang tidak mengira penyelenggaraan apabila dia menyelaraskan SLO. Pengurus, pengarah teknikal atau seseorang yang menandatangani kontrak pusat data dan tidak memberi perhatian kepada fakta bahawa SLA pusat data tidak direka untuk masa henti yang diperlukan adalah untuk dipersalahkan untuk ini. Sehubungan itu, semua sedikit demi sedikit dalam situasi ini harus dipersalahkan. Dan ini bermakna bahawa tidak ada gunanya meletakkan kesalahan kepada sesiapa dalam situasi ini. Tetapi sudah tentu ia perlu diperbetulkan. Sebab tu ada postmortem. Dan jika anda membaca, sebagai contoh, postmortem GitHub, dan ini sentiasa cerita yang sangat menarik, kecil dan tidak dijangka dalam setiap kes tertentu, anda boleh menggantikannya bahawa tiada siapa yang pernah mengatakan bahawa orang tertentu ini dipersalahkan. Persalahan sentiasa diletakkan pada proses tertentu yang tidak sempurna.

Mari kita beralih kepada soalan seterusnya. Automasi. Apabila saya bercakap tentang automasi dalam konteks lain, saya sering merujuk kepada jadual yang memberitahu anda berapa lama anda boleh bekerja untuk mengautomasikan tugasan tanpa mengambil lebih banyak masa untuk mengautomasikannya daripada yang anda simpan sebenarnya. Ada sangkut. Tangkapannya ialah apabila SRE mengautomasikan tugas, mereka bukan sahaja menjimatkan masa, mereka menjimatkan wang, kerana automasi secara langsung mempengaruhi MTTR. Mereka menjimatkan, boleh dikatakan, semangat pekerja dan pemaju, yang juga merupakan sumber yang habis. Mereka mengurangkan rutin. Dan semua ini mempunyai kesan positif terhadap kerja dan, sebagai hasilnya, pada perniagaan, walaupun nampaknya automasi tidak masuk akal dari segi kos masa.

Malah, hampir selalu ada, dan terdapat sangat sedikit kes di mana sesuatu tidak seharusnya diautomasikan dalam peranan SRE. Seterusnya kita akan bercakap tentang apa yang dipanggil belanjawan ralat, belanjawan untuk ralat. Malah, ternyata jika semuanya jauh lebih baik untuk anda daripada SLO yang anda tetapkan untuk diri sendiri, ini juga tidak begitu baik. Ini agak buruk, kerana SLO berfungsi bukan sahaja sebagai batas bawah, tetapi juga sebagai batas atas anggaran. Apabila anda menetapkan sendiri SLO sebanyak 99% ketersediaan, dan sebenarnya anda mempunyai 99,99%, ternyata anda mempunyai sedikit ruang untuk percubaan yang tidak akan membahayakan perniagaan sama sekali, kerana anda sendiri telah menentukan semuanya bersama-sama, dan anda ruang ini tidak digunakan. Anda mempunyai anggaran untuk kesilapan, yang dalam kes anda tidak digunakan.

Apa yang kita lakukan dengannya. Kami menggunakannya untuk segala-galanya. Untuk ujian dalam keadaan pengeluaran, untuk melancarkan ciri baharu yang mungkin menjejaskan prestasi, untuk keluaran, untuk penyelenggaraan, untuk masa henti yang dirancang. Peraturan terbalik juga terpakai: jika belanjawan habis, kami tidak boleh mengeluarkan apa-apa yang baru, kerana jika tidak, kami akan melebihi SLO. Belanjawan telah habis, kami telah mengeluarkan sesuatu jika ia menjejaskan prestasi secara negatif, iaitu, jika ini bukan sejenis pembaikan yang dengan sendirinya secara langsung meningkatkan SLO, maka kami melampaui belanjawan, dan ini adalah keadaan yang buruk , ia perlu dianalisis, bedah siasat, dan mungkin beberapa pembetulan proses.

Iaitu, ternyata jika perkhidmatan itu sendiri tidak berfungsi dengan baik, dan SLO dibelanjakan dan anggaran dibelanjakan bukan untuk eksperimen, bukan pada beberapa keluaran, tetapi dengan sendirinya, maka bukannya beberapa pembaikan yang menarik, bukannya ciri yang menarik, bukannya keluaran yang menarik. Daripada sebarang kerja kreatif, anda perlu berurusan dengan pembetulan bodoh untuk mendapatkan semula belanjawan, atau mengedit SLO, dan ini juga merupakan proses yang tidak sepatutnya berlaku terlalu kerap.

Oleh itu, ternyata dalam situasi di mana kami mempunyai lebih banyak belanjawan untuk ralat, semua orang berminat: kedua-dua SRE dan pembangun. Untuk pembangun, belanjawan yang besar untuk pepijat bermakna anda boleh menangani keluaran, ujian, percubaan. Bagi SRE, belanjawan untuk kesilapan dan memasukkan belanjawan itu bermakna mereka secara langsung menjalankan tugas mereka dengan baik. Dan ini menjejaskan motivasi beberapa jenis kerja bersama. Jika anda mendengar SRE anda sebagai pembangun, anda akan mempunyai lebih banyak ruang untuk kerja yang baik dan lebih kurang rutin.

Ternyata eksperimen dalam pengeluaran adalah bahagian yang penting dan hampir penting dalam SRE dalam pasukan besar. Dan ia biasanya dipanggil kejuruteraan huru-hara, yang datang daripada pasukan di Netflix yang mengeluarkan utiliti yang dipanggil Chaos Monkey.
Chaos Monkey menyambung ke saluran paip CI/CD dan ranap pelayan dalam pengeluaran. Sekali lagi, dalam struktur SRE, kita bercakap tentang hakikat bahawa pelayan yang jatuh tidak buruk dengan sendirinya, ia dijangka. Dan jika ia dalam bajet, ia boleh diterima dan tidak memudaratkan perniagaan. Sudah tentu, Netflix mempunyai pelayan berlebihan yang mencukupi, replikasi yang mencukupi, supaya semua ini boleh diperbaiki, dan supaya pengguna secara keseluruhan tidak menyedarinya, dan lebih-lebih lagi tiada siapa yang meninggalkan satu pelayan untuk sebarang belanjawan.

Netflix mempunyai rangkaian lengkap utiliti sedemikian untuk seketika, salah satunya, Chaos Gorilla, menutup sepenuhnya salah satu Zon Ketersediaan Amazon. Dan perkara sedemikian membantu untuk mendedahkan, pertama, kebergantungan tersembunyi, apabila tidak sepenuhnya jelas apa yang mempengaruhi apa, apa yang bergantung pada apa. Dan ini, jika anda bekerja dengan perkhidmatan mikro, dan dokumentasinya tidak begitu sempurna, ini mungkin biasa kepada anda. Dan sekali lagi, ini banyak membantu untuk menangkap ralat dalam kod yang anda tidak dapat menangkap pada pementasan, kerana mana-mana pementasan bukanlah simulasi yang tepat, disebabkan oleh fakta bahawa skala beban berbeza, corak beban berbeza, peralatan adalah juga, kemungkinan besar, lain-lain. Beban puncak juga boleh menjadi tidak dijangka dan tidak dapat diramalkan. Dan ujian sedemikian, yang sekali lagi tidak melangkaui belanjawan, sangat membantu untuk menangkap ralat dalam infrastruktur yang pementasan, autoujian, saluran paip CI / CD tidak akan dapat ditangkap. Dan selagi itu semua termasuk dalam bajet anda, tidak mengapa perkhidmatan anda turun ke sana, walaupun nampaknya sangat menakutkan, pelayan turun, sungguh mimpi ngeri. Tidak, itu perkara biasa, itu bagus, yang membantu menangkap pepijat. Jika anda mempunyai bajet, maka anda boleh membelanjakannya.

S: Apakah literatur yang boleh saya cadangkan? Senaraikan di hujung. Terdapat banyak literatur, saya akan menasihati beberapa laporan. Bagaimanakah ia berfungsi, dan adakah SRE berfungsi dalam syarikat tanpa produk perisian mereka sendiri atau dengan pembangunan yang minimum. Contohnya, dalam perusahaan yang aktiviti utamanya bukan perisian. Dalam perusahaan, di mana aktiviti utamanya bukan perisian, SRE berfungsi sama seperti di tempat lain, kerana dalam perusahaan anda juga perlu menggunakan, walaupun tidak dibangunkan, produk perisian, anda perlu melancarkan kemas kini, anda perlu menukar infrastruktur, anda perlu berkembang, anda perlu skala. Dan SRE membantu mengenal pasti dan meramalkan kemungkinan masalah dalam proses ini dan mengawalnya selepas beberapa pertumbuhan bermula dan keperluan perniagaan berubah. Kerana sama sekali tidak perlu terlibat dalam pembangunan perisian untuk memiliki SRE jika anda mempunyai sekurang-kurangnya beberapa pelayan dan anda dijangka mempunyai sekurang-kurangnya pertumbuhan.

Begitu juga dengan projek kecil, organisasi kecil, kerana syarikat besar mempunyai bajet dan ruang untuk mencuba. Tetapi pada masa yang sama, semua buah eksperimen ini boleh digunakan di mana-mana sahaja, iaitu, SRE, sudah tentu, muncul di Google, di Netflix, di Dropbox. Tetapi pada masa yang sama, syarikat kecil dan pemula sudah boleh membaca bahan pekat, membaca buku, menonton laporan. Mereka mula mendengar tentangnya dengan lebih kerap, mereka melihat contoh khusus, saya rasa tidak mengapa, ia benar-benar boleh berguna, kita juga memerlukan ini, ia bagus.

Iaitu, semua kerja utama untuk menyeragamkan proses ini telah dilakukan untuk anda. Anda tinggal menentukan peranan SRE secara khusus dalam syarikat anda dan mula melaksanakan semua amalan ini, yang, sekali lagi, telah diterangkan. Iaitu, dari prinsip berguna untuk syarikat kecil, ini selalu menjadi definisi SLA, SLI, SLO. Jika anda tidak terlibat dalam perisian, maka ini ialah SLA dalaman dan SLO dalaman, belanjawan dalaman untuk ralat. Ini hampir selalu membawa kepada beberapa perbincangan menarik dalam pasukan dan dalam perniagaan, kerana mungkin ternyata anda membelanjakan untuk infrastruktur, pada beberapa jenis organisasi proses yang ideal, saluran paip yang ideal adalah lebih daripada yang diperlukan. Dan 4 nine yang anda ada di bahagian IT, anda tidak memerlukannya sekarang. Tetapi pada masa yang sama, anda boleh menghabiskan masa, menghabiskan belanjawan untuk kesilapan pada sesuatu yang lain.

Sehubungan itu, pemantauan dan organisasi pemantauan berguna untuk syarikat dalam apa jua saiz. Dan secara umum, cara berfikir ini, di mana kesilapan adalah sesuatu yang boleh diterima, di mana ada belanjawan, di mana terdapat Objektif, ia sekali lagi berguna untuk syarikat dari mana-mana saiz, bermula dari permulaan untuk 3 orang.

Yang terakhir nuansa teknikal untuk dibincangkan ialah pemantauan. Kerana jika kita bercakap tentang SLA, SLI, SLO, kita tidak boleh memahami tanpa memantau sama ada kita sesuai dengan bajet, sama ada kita mematuhi Objektif kita, dan bagaimana kita mempengaruhi SLA akhir. Saya telah melihat banyak kali bahawa pemantauan berlaku seperti ini: terdapat beberapa nilai, contohnya, masa permintaan kepada pelayan, masa purata, atau bilangan permintaan kepada pangkalan data. Dia mempunyai standard yang ditentukan oleh seorang jurutera. Jika metrik menyimpang daripada norma, maka e-mel tiba. Ini semua sama sekali tidak berguna, sebagai peraturan, kerana ia membawa kepada lebihan makluman, lebihan mesej daripada pemantauan, apabila seseorang, pertama sekali, mesti mentafsirkannya setiap kali, iaitu, menentukan sama ada nilai metrik bermakna keperluan untuk beberapa tindakan. Dan kedua, dia hanya berhenti memerhatikan semua makluman ini, apabila pada dasarnya tiada tindakan diperlukan daripadanya. Itu adalah peraturan pemantauan yang baik dan peraturan pertama apabila SRE dilaksanakan ialah pemberitahuan hanya perlu datang apabila tindakan diperlukan.

Dalam kes standard, terdapat 3 peringkat acara. Ada makluman, ada tiket, ada log. Makluman ialah apa-apa sahaja yang memerlukan anda mengambil tindakan segera. Iaitu, semuanya rosak, anda perlu memperbaikinya sekarang. Tiket adalah perkara yang memerlukan tindakan tertunda. Ya, anda perlu melakukan sesuatu, anda perlu melakukan sesuatu secara manual, automasi gagal, tetapi anda tidak perlu melakukannya untuk beberapa minit seterusnya. Log ialah apa-apa sahaja yang tidak memerlukan tindakan, dan secara amnya, jika keadaan berjalan lancar, tiada sesiapa pun akan membacanya. Anda hanya perlu membaca log apabila, apabila dilihat semula, ternyata ada sesuatu yang pecah untuk beberapa waktu, kami tidak tahu mengenainya. Atau adakah anda perlu membuat kajian. Tetapi secara umum, semua yang tidak memerlukan sebarang tindakan pergi ke log.

Sebagai kesan sampingan daripada semua ini, jika kami telah menentukan peristiwa yang memerlukan tindakan dan telah menerangkan dengan baik tindakan ini sepatutnya, ini bermakna tindakan itu boleh diautomasikan. Iaitu, apa yang berlaku. Kami pergi dari berjaga-jaga. Jom beraksi. Kami pergi ke huraian tindakan ini. Dan kemudian kita beralih ke automasi. Iaitu, sebarang automasi bermula dengan reaksi terhadap sesuatu peristiwa.

Daripada pemantauan, kita beralih kepada istilah yang dipanggil Kebolehmerhatian. Terdapat juga sedikit gembar-gembur mengenai perkataan ini sejak beberapa tahun yang lalu. Dan beberapa orang memahami maksudnya di luar konteks. Tetapi perkara utama ialah Kebolehmerhatian ialah metrik untuk ketelusan sistem. Jika berlaku kesilapan, berapa cepat anda boleh menentukan apa yang sebenarnya berlaku dan keadaan sistem pada masa itu. Dari segi kod: fungsi mana yang gagal, perkhidmatan mana yang gagal. Apakah keadaan, sebagai contoh, pembolehubah dalaman, konfigurasi. Dari segi infrastruktur, ini adalah di zon ketersediaan kegagalan berlaku, dan jika anda mempunyai sebarang Kubernetes dipasang, maka di pod mana kegagalan berlaku, apakah keadaan pod itu. Dan oleh itu, Kebolehperhatian mempunyai hubungan langsung dengan MTTR. Semakin tinggi Kebolehmerhatian perkhidmatan, lebih mudah untuk mengenal pasti ralat, lebih mudah untuk membetulkan ralat, lebih mudah untuk mengautomasikan ralat, lebih rendah MTTR.

Beralih kepada syarikat kecil sekali lagi, adalah perkara biasa untuk bertanya, walaupun sekarang, cara menangani saiz pasukan, dan sama ada pasukan kecil perlu mengupah SRE yang berasingan. Sudah bercakap tentang ini sedikit lebih awal. Pada peringkat pertama pembangunan permulaan atau, sebagai contoh, pasukan, ini sama sekali tidak perlu, kerana SRE boleh dijadikan peranan peralihan. Dan ini akan menghidupkan semula pasukan itu sedikit, kerana terdapat sekurang-kurangnya beberapa kepelbagaian. Selain itu, ia akan menyediakan orang ramai untuk fakta bahawa dengan pertumbuhan, secara amnya, tanggungjawab SRE akan berubah dengan ketara. Jika anda mengupah seseorang, maka, sudah tentu, dia mempunyai beberapa jangkaan. Dan jangkaan ini tidak akan berubah dari semasa ke semasa, tetapi keperluan akan berubah sangat banyak. Oleh itu, cara mengupah SRE agak sukar pada peringkat awal. Menanam sendiri lebih mudah. Tetapi ia patut difikirkan.

Satu-satunya pengecualian, mungkin, adalah apabila terdapat keperluan pertumbuhan yang sangat ketat dan jelas. Iaitu, dalam kes permulaan, ini mungkin sejenis tekanan daripada pelabur, sejenis ramalan untuk pertumbuhan beberapa kali sekaligus. Kemudian mengupah SRE pada asasnya wajar kerana ia boleh dibenarkan. Kami mempunyai keperluan untuk pertumbuhan, kami memerlukan seseorang yang akan bertanggungjawab untuk fakta bahawa dengan pertumbuhan sedemikian tiada apa yang akan pecah.

Satu soalan lagi. Apa yang perlu dilakukan apabila beberapa kali pembangun memotong ciri yang lulus ujian, tetapi memecahkan pengeluaran, memuatkan pangkalan, memecahkan ciri lain, proses apa yang perlu dilaksanakan. Sehubungan itu, dalam kes ini, belanjawan untuk kesilapan yang diperkenalkan. Dan beberapa perkhidmatan, beberapa ciri sudah diuji dalam pengeluaran. Ia boleh menjadi kenari, apabila hanya sebilangan kecil pengguna, tetapi sudah dalam pengeluaran, ciri digunakan, tetapi sudah dengan jangkaan bahawa jika sesuatu rosak, contohnya, untuk setengah peratus daripada semua pengguna, ia masih akan memenuhi belanjawan untuk kesilapan. Oleh itu, ya, akan ada ralat, untuk sesetengah pengguna semuanya akan pecah, tetapi kami telah mengatakan bahawa ini adalah perkara biasa.

Terdapat soalan tentang alat SRE. Iaitu, adakah sesuatu yang khusus akan digunakan oleh SRE yang tidak akan digunakan oleh orang lain. Malah, terdapat beberapa utiliti yang sangat khusus, terdapat beberapa jenis perisian yang, sebagai contoh, mensimulasikan beban atau terlibat dalam ujian kanari A / B. Tetapi pada asasnya kit alat SRE ialah apa yang telah digunakan oleh pembangun anda. Kerana SRE berinteraksi secara langsung dengan pasukan pembangunan. Dan jika anda mempunyai alat yang berbeza, ternyata ia memerlukan masa untuk disegerakkan. Terutama jika SRE bekerja dalam pasukan yang besar, dalam syarikat besar di mana terdapat beberapa pasukan, standardisasi seluruh syarikat yang akan banyak membantu di sini, kerana jika 50 utiliti berbeza digunakan dalam 50 pasukan, ini bermakna SRE mesti mengenali mereka semua. Dan sudah tentu ini tidak akan berlaku. Dan kualiti kerja, kualiti kawalan sekurang-kurangnya beberapa pasukan akan menurun dengan ketara.

Webinar kami akan berakhir. Saya berjaya memberitahu beberapa perkara asas. Sudah tentu, tiada apa tentang SRE boleh diberitahu dan difahami dalam masa sejam. Tetapi saya harap saya berjaya menyampaikan cara berfikir ini, perkara utama utama. Dan kemudian mungkin, jika berminat, untuk menyelidiki topik itu, belajar sendiri, melihat bagaimana ia dilaksanakan oleh orang lain, di syarikat lain. Dan sewajarnya, pada awal Februari, datang kepada kami di Slurm SRE.

Slurm SRE ialah kursus intensif tiga hari yang akan membincangkan perkara yang saya perkatakan sekarang, tetapi dengan lebih mendalam, dengan kes sebenar, dengan latihan, keseluruhan intensif ditujukan kepada kerja praktikal. Orang akan dibahagikan kepada pasukan. Anda semua akan bekerja pada kes sebenar. Sehubungan itu, kami mempunyai tenaga pengajar Booking.com Ivan Kruglov dan Ben Tyler. Kami mempunyai Eugene Barabbas yang hebat dari Google, dari San Francisco. Dan saya akan memberitahu anda sesuatu juga. Jadi pastikan anda melawat kami.
Jadi, bibliografi. Terdapat rujukan mengenai SRE. Pertama pada buku yang sama, atau lebih tepat pada 2 buku tentang SRE, yang ditulis oleh Google. Yang lagi satu artikel kecil tentang SLA, SLI, SLO, di mana syarat dan penggunaannya lebih terperinci sedikit. 3 seterusnya ialah laporan mengenai SRE dalam syarikat yang berbeza. pertama - Kunci kepada SRE, ini adalah ucaptama daripada Ben Trainer Google. Kedua - SRE dalam Dropbox. Yang ketiga lagi SRE kepada Google. Laporan keempat daripada SRE di Netflix, yang hanya mempunyai 5 pekerja utama SRE di 190 negara. Sangat menarik untuk melihat semua ini, kerana sama seperti DevOps bermakna perkara yang sangat berbeza kepada syarikat yang berbeza dan juga pasukan yang berbeza, SRE mempunyai tanggungjawab yang sangat berbeza, walaupun dalam syarikat yang mempunyai saiz yang sama.

2 lagi pautan mengenai prinsip kejuruteraan huru-hara: (1), (2). Dan pada akhirnya terdapat 3 senarai dari siri Senarai Awesome tentang kejuruteraan huru-hara, kira-kira SRE dan kira-kira Kit alat SRE. Senarai di SRE sangat besar, tidak perlu melalui semuanya, terdapat kira-kira 200 artikel. Saya sangat mengesyorkan artikel dari sana tentang perancangan kapasiti dan tentang postmortem yang tidak bersalah.

Artikel menarik: SRE sebagai pilihan hidup

Terima kasih kerana mendengar saya selama ini. Harap anda telah belajar sesuatu. Harap anda mempunyai bahan yang mencukupi untuk belajar lebih banyak lagi. Dan jumpa awak. Semoga pada bulan Februari.
Webinar itu dihoskan oleh Eduard Medvedev.

PS: bagi yang suka membaca, Eduard berikan senarai rujukan. Mereka yang lebih suka memahami secara praktikal dialu-alukan Slurme SRE.

Sumber: www.habr.com