Webinar memiliki audio yang buruk, jadi kami telah menyalinnya.
Nama saya Medvedev Eduard. Hari ini saya akan membahas tentang apa itu SRE, bagaimana SRE muncul, apa saja kriteria kerja yang dimiliki para insinyur SRE, sedikit tentang kriteria keandalan, sedikit tentang pemantauannya. Kami akan berjalan ke atas, karena Anda tidak dapat bercerita banyak dalam satu jam, tetapi saya akan memberikan materi untuk ulasan tambahan, dan kami semua menunggu Anda di . di Moskow pada akhir Januari.
Pertama, mari kita bahas tentang apa itu SRE - Rekayasa Keandalan Situs. Dan bagaimana hal itu muncul sebagai posisi yang terpisah, sebagai arah yang terpisah. Semuanya dimulai dengan fakta bahwa dalam lingkaran pengembangan tradisional, Dev dan Ops adalah dua tim yang sangat berbeda, biasanya dengan dua tujuan yang sangat berbeda. Tujuan tim pengembangan adalah meluncurkan fitur-fitur baru dan memenuhi kebutuhan bisnis. Tujuan tim Operasi adalah memastikan semuanya berfungsi dan tidak ada yang rusak. Tentu saja, tujuan-tujuan ini saling bertentangan: agar semuanya berfungsi dan tidak ada yang rusak, luncurkan fitur-fitur baru sesedikit mungkin. Oleh karena itu, terdapat banyak konflik internal yang coba diselesaikan oleh metodologi yang sekarang disebut DevOps.
Masalahnya adalah kita tidak memiliki definisi yang jelas tentang DevOps dan implementasi DevOps yang jelas. Saya berbicara di sebuah konferensi di Yekaterinburg 2 tahun lalu, dan hingga saat ini bagian DevOps dimulai dengan laporan βApa itu DevOpsβ. Pada tahun 2017, Devops hampir berusia 10 tahun, namun kami masih berdebat tentang apa itu. Dan ini adalah situasi yang sangat aneh yang coba dipecahkan oleh Google beberapa tahun lalu.
Pada tahun 2016, Google merilis buku berjudul Site Reliability Engineering. Dan nyatanya, dengan buku inilah gerakan SRE dimulai. SRE adalah implementasi spesifik dari paradigma DevOps di perusahaan tertentu. Insinyur SRE berkomitmen untuk memastikan bahwa sistem beroperasi dengan andal. Mereka sebagian besar berasal dari pengembang, terkadang administrator dengan latar belakang pengembangan yang kuat. Dan mereka melakukan apa yang biasa dilakukan oleh administrator sistem, tetapi latar belakang yang kuat dalam pengembangan dan pengetahuan sistem dalam hal kode mengarah pada fakta bahwa orang-orang ini tidak cenderung melakukan pekerjaan administratif rutin, tetapi cenderung melakukan otomatisasi.
Ternyata paradigma DevOps di tim SRE diterapkan dengan adanya insinyur SRE yang memecahkan masalah struktural. Ini dia, hubungan yang sama antara Dev dan Ops yang telah dibicarakan orang selama 8 tahun. Peran SRE sama dengan arsitek, yaitu pendatang baru tidak menjadi SRE. Orang-orang di awal karirnya belum memiliki pengalaman, belum memiliki pengetahuan yang luas. Karena SRE memerlukan pengetahuan yang sangat halus tentang apa dan kapan tepatnya kesalahan bisa terjadi. Oleh karena itu, beberapa pengalaman diperlukan di sini, sebagai suatu peraturan, baik di dalam perusahaan maupun di luar.
Mereka menanyakan apakah perbedaan antara SRE dan devops akan dijelaskan. Dia baru saja dijelaskan. Kita bisa membicarakan tempat SRE dalam organisasi. Berbeda dengan pendekatan DevOps klasik ini, di mana Ops masih merupakan departemen terpisah, SRE adalah bagian dari tim pengembangan. Mereka terlibat dalam pengembangan produk. Bahkan ada pendekatan dimana SRE adalah peran yang berpindah dari satu pengembang ke pengembang lainnya. Mereka berpartisipasi dalam peninjauan kode dengan cara yang sama seperti, misalnya, desainer UX, pengembang itu sendiri, dan terkadang manajer produk. SRE bekerja pada tingkat yang sama. Kita perlu menyetujuinya, kita perlu meninjaunya, sehingga untuk setiap penerapan SRE mengatakan: βOke, penerapan ini, produk ini tidak akan berdampak negatif terhadap keandalan. Dan jika ya, maka dalam batas yang dapat diterima. Kami juga akan membicarakan hal ini.
Oleh karena itu, SRE mempunyai hak veto untuk mengubah kode tersebut. Dan secara umum, hal ini juga menimbulkan semacam konflik kecil jika SRE diterapkan secara tidak benar. Dalam buku yang sama tentang Rekayasa Keandalan Situs, banyak bagian, bahkan tidak satu pun, yang menjelaskan cara menghindari konflik ini.
Mereka bertanya bagaimana hubungan SRE dengan keamanan informasi. SRE tidak terlibat langsung dalam keamanan informasi. Pada dasarnya di perusahaan besar hal ini dilakukan oleh individu, penguji, analis. Namun SRE juga berinteraksi dengan mereka dalam arti bahwa beberapa operasi, beberapa komitmen, beberapa penerapan yang memengaruhi keamanan juga dapat memengaruhi ketersediaan produk. Oleh karena itu, SRE secara keseluruhan berinteraksi dengan tim mana pun, termasuk tim keamanan, termasuk analis. Oleh karena itu, SRE sangat dibutuhkan ketika mereka mencoba mengimplementasikan DevOps, namun pada saat yang sama, beban pada pengembang menjadi terlalu besar. Artinya, tim pengembangan sendiri tidak dapat lagi mengatasi kenyataan bahwa kini mereka juga harus bertanggung jawab atas Operasi. Dan ada peran tersendiri. Peran ini direncanakan dalam anggaran. Terkadang peran ini ditentukan oleh ukuran tim, seseorang muncul, terkadang salah satu pengembang mengambil alih peran tersebut. Beginilah tampilan SRE pertama di tim.
Kompleksitas sistem yang dipengaruhi oleh SRE, kompleksitas yang mempengaruhi keandalan operasi, bersifat perlu dan tidak disengaja. Kompleksitas yang diperlukan adalah ketika kompleksitas suatu produk meningkat hingga mencapai batas yang dibutuhkan oleh fitur produk baru. Kompleksitas acak adalah ketika kompleksitas sistem meningkat, namun fitur produk dan persyaratan bisnis tidak secara langsung mempengaruhi hal ini. Ternyata pengembang melakukan kesalahan di suatu tempat, atau algoritmanya tidak optimal, atau ada beberapa kepentingan tambahan yang meningkatkan kompleksitas produk tanpa kebutuhan khusus. SRE yang baik harus selalu menghentikan situasi ini. Artinya, setiap penerapan, penerapan apa pun, permintaan penarikan apa pun, yang tingkat kesulitannya meningkat karena penambahan acak, harus diblokir.
Pertanyaannya adalah mengapa tidak mempekerjakan seorang insinyur, seorang administrator sistem dengan banyak pengetahuan ke dalam tim. Kami diberitahu bahwa pengembang yang berperan sebagai insinyur bukanlah solusi kepegawaian terbaik. Pengembang yang berperan sebagai insinyur tidak selalu merupakan solusi kepegawaian terbaik, namun intinya di sini adalah bahwa pengembang yang bergerak di bidang Operasi memiliki keinginan yang lebih besar untuk otomatisasi, memiliki lebih banyak pengetahuan dan keahlian untuk mengimplementasikan otomatisasi ini. Oleh karena itu, kami tidak hanya mengurangi waktu untuk beberapa operasi tertentu, tidak hanya operasi rutin, tetapi juga parameter bisnis penting seperti MTTR (Mean Time To Recovery, waktu pemulihan). Jadi, dan kita juga akan membicarakan hal ini nanti, kita menghemat uang untuk organisasi.
Sekarang mari kita bicara tentang kriteria pengoperasian SRE. Dan pertama-tama, tentang keandalan. Di perusahaan kecil, startup, sering terjadi orang beranggapan jika layanannya ditulis dengan baik, jika produknya ditulis dengan baik dan benar, maka akan berfungsi, tidak akan rusak. Itu saja, kami menulis kode yang bagus, jadi tidak ada yang rusak. Kodenya sangat sederhana, tidak ada yang perlu dipecahkan. Ini tentang orang-orang yang sama yang mengatakan bahwa kita tidak memerlukan tes, karena lihat, ini adalah tiga metode VPI, mengapa harus dihentikan di sini.
Tentu saja ini semua salah. Dan orang-orang ini sangat sering tergigit oleh kode seperti itu dalam praktiknya, karena ada yang rusak. Terkadang segala sesuatunya rusak dengan cara yang paling tidak terduga. Terkadang orang berkata tidak, itu tidak akan pernah terjadi. Dan itu terjadi setiap saat. Hal ini cukup sering terjadi. Dan itulah mengapa tidak ada seorang pun yang mengupayakan ketersediaan 100%, karena ketersediaan 100% tidak pernah terjadi. Ini adalah norma. Oleh karena itu, ketika kita berbicara tentang ketersediaan suatu layanan, kita selalu berbicara tentang sembilan. 2 sembilan, 3 sembilan, 4 sembilan, 5 sembilan. Jika kita menerjemahkannya ke dalam waktu henti, maka, misalnya, 5 sembilan, maka ini adalah waktu henti lebih dari 5 menit per tahun, 2 sembilan adalah waktu henti 3,5 hari.
Namun yang jelas pada suatu saat terjadi penurunan POI, laba atas investasi. Beralih dari dua sembilan menjadi tiga sembilan berarti lebih sedikit waktu henti lebih dari 3 hari. Beralih dari empat jam sembilan ke lima mengurangi waktu henti sebesar 47 menit per tahun. Dan ternyata untuk bisnis, hal ini mungkin tidak penting. Dan secara umum, keandalan yang dibutuhkan bukanlah masalah teknis, pertama-tama, ini adalah masalah bisnis, ini adalah masalah produk. Berapa tingkat waktu henti yang dapat diterima oleh pengguna produk, apa yang mereka harapkan, berapa banyak mereka membayar, misalnya, berapa banyak uang yang hilang, berapa banyak uang yang hilang dari sistem.
Pertanyaan penting di sini adalah seberapa andal komponen lainnya. Pasalnya, perbedaan antara 4 dan 5 sembilan tidak akan terlihat pada smartphone dengan keandalan 2 sembilan. Secara kasar, jika terjadi kerusakan pada smartphone di layanan Anda 10 kali dalam setahun, kemungkinan besar 8 kali kerusakan tersebut terjadi pada sisi OS. Pengguna sudah terbiasa dengan hal ini, dan tidak akan memperhatikannya sekali lagi dalam setahun. Penting untuk mengkorelasikan harga peningkatan keandalan dan peningkatan keuntungan.
Di buku SRE saja ada contoh bagus tentang peningkatan menjadi 4 sembilan dari 3 sembilan. Ternyata peningkatan ketersediaannya sedikit kurang dari 0,1%. Dan jika pendapatan layanan adalah $1 juta per tahun, maka peningkatan pendapatannya adalah $900. Jika kita memerlukan biaya kurang dari $900 per tahun untuk meningkatkan keterjangkauan sebesar sembilan dolar, maka peningkatan tersebut masuk akal secara finansial. Jika biayanya lebih dari $900 per tahun, itu tidak masuk akal lagi, karena peningkatan pendapatan tidak mengkompensasi biaya tenaga kerja dan biaya sumber daya. Dan 3 sembilan sudah cukup bagi kita.
Ini tentu saja merupakan contoh sederhana di mana semua permintaan adalah sama. Dan beralih dari 3 sembilan menjadi 4 sembilan cukup mudah, tetapi pada saat yang sama, misalnya, beralih dari 2 sembilan menjadi 3, ini sudah menghemat 9 ribu dolar, dapat masuk akal secara finansial. Tentu saja, pada kenyataannya, kegagalan permintaan registrasi lebih buruk daripada kegagalan menampilkan halaman, permintaan memiliki bobot yang berbeda. Mereka mungkin memiliki kriteria yang sangat berbeda dari sudut pandang bisnis, namun, sebagai suatu peraturan, jika kita tidak berbicara tentang beberapa layanan tertentu, ini adalah perkiraan yang cukup dapat diandalkan.
Kami menerima pertanyaan apakah SRE adalah salah satu koordinator ketika memilih solusi arsitektur untuk layanan tersebut. Katakanlah dalam hal integrasi ke dalam infrastruktur yang ada, sehingga tidak ada kerugian stabilitasnya. Ya, SRE, dengan cara yang sama seperti permintaan tarik, penerapan, rilis memengaruhi arsitektur, pengenalan layanan baru, layanan mikro, implementasi solusi baru. Mengapa saya katakan sebelumnya bahwa pengalaman diperlukan, kualifikasi diperlukan. Faktanya, SRE adalah salah satu suara pemblokiran dalam solusi arsitektur dan perangkat lunak apa pun. Oleh karena itu, seorang SRE sebagai seorang insinyur harus, pertama-tama, tidak hanya memahami, tetapi juga memahami bagaimana beberapa keputusan spesifik akan memengaruhi keandalan, stabilitas, dan memahami bagaimana hal ini berkaitan dengan kebutuhan bisnis, dan dari sudut pandang apa keputusan tersebut dapat diterima dan yang tidak.
Oleh karena itu, sekarang kita hanya dapat berbicara tentang kriteria keandalan, yang secara tradisional didefinisikan dalam SRE sebagai SLA (Service Level Agreement). Kemungkinan besar adalah istilah yang familiar. SLI (Indikator Tingkat Layanan). SLO (Tujuan Tingkat Layanan). Perjanjian Tingkat Layanan mungkin merupakan istilah simbolis, terutama jika Anda pernah bekerja dengan jaringan, dengan penyedia, dengan hosting. Ini adalah perjanjian umum yang menjelaskan kinerja seluruh layanan Anda, penalti, beberapa penalti untuk kesalahan, metrik, kriteria. Dan SLI adalah metrik ketersediaan itu sendiri. Artinya, apa yang dimaksud dengan SLI: waktu respons dari layanan, jumlah kesalahan dalam persentase. Bisa jadi bandwidth jika itu semacam file hosting. Jika menyangkut algoritma pengenalan, indikatornya bisa berupa, misalnya, kebenaran jawaban. SLO (Service Level Objective) masing-masing merupakan kombinasi dari indikator SLI, nilainya dan periodenya.
Katakanlah SLA-nya bisa seperti ini. Layanan ini tersedia 99,95% sepanjang tahun. Atau 99 tiket dukungan kritis akan ditutup dalam waktu 3 jam per kuartal. Atau 85% permintaan akan dijawab dalam waktu 1,5 detik setiap bulannya. Artinya, kami secara bertahap mulai memahami bahwa kesalahan dan kegagalan adalah hal yang wajar. Ini adalah situasi yang dapat diterima, kami sedang merencanakannya, kami bahkan mengandalkannya sampai batas tertentu. Artinya, SRE membangun sistem yang dapat membuat kesalahan, yang harus merespons kesalahan secara normal, dan harus memperhitungkannya. Dan jika memungkinkan, mereka harus menangani kesalahan sedemikian rupa sehingga pengguna tidak menyadarinya, atau menyadarinya, tetapi ada semacam solusi yang membuat semuanya tidak akan gagal sepenuhnya.
Misal anda mengupload video ke youtube, dan youtube tidak bisa langsung mengkonversinya, jika video terlalu besar, jika formatnya kurang maksimal maka request tentu saja tidak akan gagal dengan batas waktu, youtube tidak akan memberikan error 502 , YouTube akan berkata: βKami telah membuat segalanya, video Anda sedang diproses. Ini akan siap dalam waktu sekitar 10 menit." Ini adalah prinsip degradasi yang anggun, yang sudah familiar, misalnya, dari pengembangan front-end, jika Anda pernah melakukannya.
Istilah selanjutnya yang akan kita bahas yang sangat penting untuk bekerja dengan reliabilitas, error, dan ekspektasi adalah MTBF dan MTTR. MTBF adalah waktu rata-rata antara kegagalan. MTTR Mean Time To Recovery, waktu rata-rata hingga pemulihan. Artinya, berapa lama waktu yang telah berlalu sejak kesalahan ditemukan, sejak kesalahan muncul hingga saat layanan dipulihkan ke operasi normal penuh. MTBF terutama diperbaiki dengan mengerjakan kualitas kode. Artinya, faktanya SRE bisa mengatakan "tidak". Dan Anda memerlukan pemahaman dari seluruh tim bahwa ketika SRE mengatakan "tidak", dia mengatakannya bukan karena dia berbahaya, bukan karena dia jahat, tetapi karena jika tidak, semua orang akan menderita.
Sekali lagi, ada banyak artikel, banyak metode, banyak cara bahkan di buku yang sering saya rujuk, bagaimana memastikan pengembang lain tidak mulai membenci SRE. MTTR, di sisi lain, adalah tentang mengerjakan SLO (Service Level Objective) Anda. Dan sebagian besarnya adalah otomatisasi. Sebab misalnya SLO kita uptimenya 4 sembilan per kuartal. Artinya dalam 3 bulan kami dapat memberikan waktu henti selama 13 menit. Dan ternyata MTTR tidak boleh lebih dari 13 menit. Jika kami merespons setidaknya 13 kali downtime dalam 1 menit, ini berarti kami telah menghabiskan seluruh anggaran untuk kuartal tersebut. Kami melanggar SLO. 13 menit untuk bereaksi dan memperbaiki kerusakan adalah waktu yang lama bagi mesin, tetapi sangat singkat bagi manusia. Karena sampai seseorang menerima peringatan, sampai dia bereaksi, sampai dia memahami kesalahannya, itu sudah beberapa menit. Sampai seseorang memahami cara memperbaikinya, apa sebenarnya yang harus diperbaiki, apa yang harus dilakukan, tinggal beberapa menit lagi. Dan nyatanya, meskipun ternyata Anda hanya perlu me-restart server atau menaikkan node baru, maka MTTR secara manual sudah sekitar 7-8 menit. Saat mengotomatiskan proses, MTTR sering kali mencapai satu detik, terkadang milidetik. Google biasanya berbicara tentang milidetik, tetapi kenyataannya, tentu saja, semuanya tidak begitu baik.
Idealnya, SRE harus mengotomatiskan pekerjaannya hampir sepenuhnya, karena hal ini secara langsung memengaruhi MTTR, metriknya, SLO seluruh layanan, dan, karenanya, keuntungan bisnis. Jika waktu terlampaui, kami ditanya apakah SRE salah. Untungnya, tidak ada yang bisa disalahkan. Dan ini adalah budaya terpisah yang disebut postmortem tanpa balsem, yang tidak akan kita bicarakan hari ini, tetapi kita akan menganalisisnya di Slurm. Ini adalah topik yang sangat menarik yang bisa dibicarakan banyak orang. Kasarnya kalau jatah waktu per triwulan terlampaui, maka sedikit dari semua orang yang harus disalahkan, artinya menyalahkan semua orang itu tidak produktif, malah mungkin tidak menyalahkan siapa pun, tapi perbaiki keadaan dan bekerjalah dengan apa yang kita miliki. Menurut pengalaman saya, pendekatan ini agak asing bagi sebagian besar tim, terutama di Rusia, namun masuk akal dan bekerja dengan sangat baik. Oleh karena itu, saya akan merekomendasikan di akhir artikel dan literatur yang dapat Anda baca tentang topik ini. Atau datang ke Slurm SRE.
Biar saya jelaskan. Jika waktu SLO per kuartal terlampaui, jika downtime bukan 13 menit, melainkan 15 menit, siapa yang bisa disalahkan? Tentu saja, SRE mungkin harus disalahkan, karena dia jelas-jelas melakukan komitmen atau penerapan yang buruk. Administrator pusat data mungkin yang harus disalahkan dalam hal ini, karena dia mungkin telah melakukan pemeliharaan yang tidak terjadwal. Jika pengelola pusat data yang disalahkan dalam hal ini, maka pihak Ops yang patut disalahkan, yang tidak menghitung pemeliharaan saat mengoordinasikan SLO. Manajer, direktur teknis, atau seseorang yang menandatangani kontrak pusat data dan tidak memperhatikan fakta bahwa SLA pusat data tidak dirancang untuk waktu henti yang diperlukan adalah penyebabnya. Oleh karena itu, sedikit demi sedikit semua orang harus disalahkan dalam situasi ini. Artinya, tidak ada gunanya menyalahkan siapa pun dalam situasi ini. Namun tentunya perlu diperbaiki. Itu sebabnya ada postmortem. Dan jika Anda membaca, misalnya, postmortem GitHub, dan ini selalu merupakan cerita yang sangat menarik, kecil, dan tidak terduga dalam setiap kasus, Anda dapat menggantinya dengan fakta bahwa tidak ada seorang pun yang mengatakan bahwa orang ini yang harus disalahkan. Kesalahan selalu ditimpakan pada proses tertentu yang tidak sempurna.
Mari kita beralih ke pertanyaan berikutnya. Otomatisasi. Ketika saya berbicara tentang otomatisasi dalam konteks lain, saya sering merujuk pada tabel yang memberi tahu Anda berapa lama Anda dapat bekerja untuk mengotomatisasi suatu tugas tanpa menghabiskan lebih banyak waktu untuk mengotomatiskannya daripada yang sebenarnya Anda hemat. Ada hambatan. Masalahnya adalah ketika SRE mengotomatiskan suatu tugas, mereka tidak hanya menghemat waktu, tetapi juga uang, karena otomatisasi secara langsung memengaruhi MTTR. Bisa dikatakan, hal ini menyelamatkan moral karyawan dan pengembang, yang juga merupakan sumber daya yang tidak ada habisnya. Mereka mengurangi rutinitas. Dan semua ini berdampak positif pada pekerjaan dan, sebagai hasilnya, pada bisnis, meskipun otomatisasi tampaknya tidak masuk akal dalam hal biaya waktu.
Faktanya, hampir selalu demikian, dan sangat sedikit kasus di mana sesuatu tidak boleh diotomatisasi dalam peran SRE. Selanjutnya kita akan membahas apa yang disebut dengan error budget, yaitu anggaran untuk kesalahan. Faktanya, ternyata jika semuanya jauh lebih baik bagi Anda daripada SLO yang Anda tetapkan sendiri, ini juga kurang baik. Ini agak buruk, karena SLO tidak hanya berfungsi sebagai batas bawah, tetapi juga sebagai perkiraan batas atas. Ketika Anda menetapkan sendiri SLO ketersediaan 99%, dan ternyata Anda memiliki 99,99%, ternyata Anda memiliki ruang untuk bereksperimen yang tidak akan merugikan bisnis sama sekali, karena Anda sendiri yang menentukan semuanya, dan Anda ruang ini tidak digunakan. Anda memiliki anggaran untuk kesalahan, yang dalam kasus Anda tidak terpakai.
Apa yang kita lakukan dengannya. Kami menggunakannya untuk segala hal. Untuk pengujian dalam kondisi produksi, untuk meluncurkan fitur baru yang mungkin memengaruhi kinerja, untuk rilis, untuk pemeliharaan, untuk waktu henti yang direncanakan. Aturan sebaliknya juga berlaku: jika anggaran habis, kami tidak dapat mengeluarkan sesuatu yang baru, karena jika tidak, kami akan melebihi SLO. Anggaran telah habis, kami telah merilis sesuatu jika berdampak negatif terhadap kinerja, yaitu jika ini bukan semacam perbaikan yang secara langsung meningkatkan SLO, maka kami melampaui anggaran, dan ini adalah situasi yang buruk , perlu dianalisis, postmortem, dan mungkin beberapa perbaikan proses.
Artinya, ternyata jika layanan itu sendiri tidak berfungsi dengan baik, dan SLO dihabiskan dan anggaran dihabiskan bukan untuk eksperimen, bukan pada beberapa rilis, tetapi dengan sendirinya, maka alih-alih beberapa perbaikan menarik, alih-alih fitur menarik, alih-alih rilis yang menarik. Daripada melakukan pekerjaan kreatif apa pun, Anda harus melakukan perbaikan bodoh untuk mengembalikan anggaran, atau mengedit SLO, dan ini juga merupakan proses yang tidak boleh terjadi terlalu sering.
Oleh karena itu, ternyata dalam situasi di mana kita memiliki lebih banyak anggaran untuk kesalahan, semua orang tertarik: baik SRE maupun pengembang. Bagi pengembang, anggaran besar untuk bug berarti Anda dapat menangani rilis, pengujian, eksperimen. Bagi SRE, anggaran yang salah dan memasukkan anggaran tersebut berarti mereka secara langsung menjalankan tugasnya dengan baik. Dan ini mempengaruhi motivasi kerja sama. Jika Anda mendengarkan SRE Anda sebagai pengembang, Anda akan memiliki lebih banyak ruang untuk pekerjaan yang baik dan lebih sedikit rutinitas.
Ternyata eksperimen dalam produksi merupakan bagian yang cukup penting dan hampir tidak terpisahkan dari SRE dalam tim besar. Dan biasanya disebut chaos engineering, yang berasal dari tim di Netflix yang merilis utilitas bernama Chaos Monkey.
Chaos Monkey terhubung ke pipeline CI/CD dan secara acak membuat server crash dalam produksi. Sekali lagi, dalam struktur SRE, kita berbicara tentang fakta bahwa server yang down itu sendiri tidaklah buruk, seperti yang diharapkan. Dan jika sesuai anggaran, maka dapat diterima dan tidak merugikan usaha. Tentu saja, Netflix memiliki server redundan yang cukup, replikasi yang cukup, sehingga semua ini dapat diperbaiki, dan pengguna secara keseluruhan tidak menyadarinya, dan terlebih lagi tidak ada yang meninggalkan satu server dengan anggaran berapa pun.
Netflix memiliki serangkaian utilitas seperti itu untuk sementara waktu, salah satunya, Chaos Gorilla, mematikan salah satu Availability Zone Amazon sepenuhnya. Dan hal-hal seperti itu membantu mengungkap, pertama, ketergantungan yang tersembunyi, ketika tidak sepenuhnya jelas apa yang memengaruhi apa, apa yang bergantung pada apa. Dan ini, jika Anda bekerja dengan layanan mikro, dan dokumentasinya kurang sempurna, ini mungkin familier bagi Anda. Dan sekali lagi, ini sangat membantu untuk menangkap kesalahan dalam kode yang tidak dapat Anda tangkap pada pementasan, karena pementasan apa pun bukanlah simulasi yang tepat, karena skala muatannya berbeda, pola muatannya berbeda, peralatannya berbeda. juga, kemungkinan besar, lainnya. Beban puncak juga bisa tidak terduga dan tidak dapat diprediksi. Dan pengujian semacam itu, yang sekali lagi tidak melampaui anggaran, sangat membantu untuk menemukan kesalahan dalam infrastruktur yang tidak akan pernah terdeteksi oleh staging, autotest, dan pipeline CI/CD. Dan selama itu semua termasuk dalam anggaran Anda, tidak masalah layanan Anda turun di sana, meskipun tampaknya sangat menakutkan, server turun, sungguh mimpi buruk. Tidak, itu normal, itu bagus, itu membantu menangkap serangga. Jika Anda punya anggaran, maka Anda bisa membelanjakannya.
T: Literatur apa yang dapat saya rekomendasikan? Daftar di akhir. Ada banyak literatur, saya akan menyarankan beberapa laporan. Bagaimana cara kerjanya, dan apakah SRE berfungsi di perusahaan yang tidak memiliki produk perangkat lunak sendiri atau dengan pengembangan minimal. Misalnya pada suatu perusahaan yang aktivitas utamanya bukan perangkat lunak. Di perusahaan yang aktivitas utamanya bukan perangkat lunak, SRE bekerja dengan cara yang sama seperti di tempat lain, karena di perusahaan Anda juga perlu menggunakan, meskipun tidak dikembangkan, produk perangkat lunak, Anda perlu meluncurkan pembaruan, Anda perlu mengubah infrastrukturnya, Anda perlu bertumbuh, Anda perlu memperluas skalanya. Dan SRE membantu mengidentifikasi dan memprediksi kemungkinan masalah dalam proses ini dan mengendalikannya setelah pertumbuhan dimulai dan kebutuhan bisnis berubah. Karena sama sekali tidak perlu terlibat dalam pengembangan perangkat lunak untuk memiliki SRE jika Anda memiliki setidaknya beberapa server dan diharapkan memiliki setidaknya beberapa pertumbuhan.
Hal yang sama berlaku untuk proyek kecil, organisasi kecil, karena perusahaan besar mempunyai anggaran dan ruang untuk bereksperimen. Namun pada saat yang sama, semua hasil eksperimen ini dapat digunakan di mana saja, yaitu SRE, tentu saja, muncul di Google, di Netflix, di Dropbox. Namun di saat yang sama, perusahaan kecil dan startup sudah bisa membaca materi ringkas, membaca buku, melihat laporan. Mereka mulai lebih sering mendengarnya, mereka melihat contoh-contoh spesifik, menurut saya tidak apa-apa, bisa sangat berguna, kita juga membutuhkan ini, bagus.
Artinya, semua pekerjaan utama untuk menstandardisasi proses ini telah dilakukan untuk Anda. Tinggal Anda menentukan peran SRE secara spesifik di perusahaan Anda dan mulai menerapkan semua praktik ini, yang sekali lagi telah dijelaskan. Artinya, dari prinsip-prinsip yang bermanfaat bagi perusahaan kecil, inilah pengertian SLA, SLI, SLO. Jika Anda tidak terlibat dalam perangkat lunak, maka ini akan menjadi SLA internal dan SLO internal, anggaran internal untuk kesalahan. Hal ini hampir selalu mengarah pada beberapa diskusi menarik di dalam tim dan di dalam bisnis, karena mungkin ternyata Anda mengeluarkan uang untuk infrastruktur, untuk pengorganisasian proses yang ideal, saluran pipa yang ideal jauh lebih dari yang diperlukan. Dan 4 sembilan yang Anda miliki di departemen TI ini, Anda tidak terlalu membutuhkannya sekarang. Namun di saat yang sama, Anda bisa membuang waktu, menghabiskan anggaran untuk kesalahan pada hal lain.
Oleh karena itu, pemantauan dan pengorganisasian pemantauan berguna bagi perusahaan dengan ukuran berapa pun. Dan secara umum cara berpikir seperti ini, di mana kesalahan adalah sesuatu yang bisa diterima, di mana ada anggaran, di mana ada Tujuan, sekali lagi berguna untuk perusahaan dengan ukuran berapa pun, mulai dari startup untuk 3 orang.
Nuansa teknis terakhir yang perlu dibicarakan adalah pemantauan. Karena jika kita berbicara tentang SLA, SLI, SLO, kita tidak dapat memahami tanpa memantau apakah kita sesuai dengan anggaran, apakah kita mematuhi Tujuan kita, dan bagaimana kita mempengaruhi SLA akhir. Saya sering melihat pemantauan terjadi seperti ini: ada beberapa nilai, misalnya waktu permintaan ke server, waktu rata-rata, atau jumlah permintaan ke database. Dia memiliki standar yang ditentukan oleh seorang insinyur. Jika metriknya menyimpang dari norma, maka email akan tiba. Ini semua sama sekali tidak berguna, sebagai suatu peraturan, karena ini mengarah pada banyaknya peringatan, banyak pesan dari pemantauan, ketika seseorang, pertama-tama, harus menafsirkannya setiap saat, yaitu menentukan apakah nilai metrik berarti perlunya beberapa tindakan. Dan kedua, dia berhenti memperhatikan semua peringatan ini, padahal pada dasarnya tidak ada tindakan yang diperlukan darinya. Ini adalah aturan pemantauan yang baik dan aturan pertama ketika SRE diterapkan adalah bahwa pemberitahuan hanya boleh diberikan ketika diperlukan tindakan.
Dalam kasus standar, ada 3 level kejadian. Ada peringatan, ada tiket, ada log. Peringatan adalah segala sesuatu yang mengharuskan Anda mengambil tindakan segera. Artinya, semuanya rusak, Anda harus memperbaikinya sekarang juga. Tiket inilah yang memerlukan tindakan tertunda. Ya, Anda perlu melakukan sesuatu, Anda perlu melakukan sesuatu secara manual, otomatisasi gagal, tetapi Anda tidak perlu melakukannya selama beberapa menit ke depan. Log adalah segala sesuatu yang tidak memerlukan tindakan, dan secara umum, jika semuanya berjalan baik, tidak ada yang akan membacanya. Anda hanya perlu membaca log ketika, jika dipikir-pikir, ternyata ada sesuatu yang rusak selama beberapa waktu, kami tidak mengetahuinya. Atau apakah Anda perlu melakukan penelitian. Namun secara umum, segala sesuatu yang tidak memerlukan tindakan apa pun akan dimasukkan ke dalam log.
Sebagai efek samping dari semua ini, jika kita telah menentukan peristiwa apa yang memerlukan tindakan dan telah menjelaskan dengan baik tindakan apa yang seharusnya dilakukan, ini berarti tindakan tersebut dapat diotomatisasi. Itulah yang terjadi. Kami beralih dari waspada. Ayo beraksi. Kami melanjutkan ke deskripsi tindakan ini. Dan kemudian kita beralih ke otomatisasi. Artinya, setiap otomatisasi dimulai dengan reaksi terhadap suatu peristiwa.
Dari pemantauan, kita beralih ke istilah yang disebut Observabilitas. Ada juga sedikit hype seputar kata ini selama beberapa tahun terakhir. Dan hanya sedikit orang yang memahami artinya di luar konteks. Namun poin utamanya adalah Observability adalah metrik untuk transparansi sistem. Jika terjadi kesalahan, seberapa cepat Anda dapat menentukan apa yang sebenarnya salah dan bagaimana keadaan sistem pada saat itu. Dari segi kode: fungsi mana yang gagal, layanan mana yang gagal. Bagaimana keadaannya, misalnya variabel internal, konfigurasi. Dalam hal infrastruktur, di zona ketersediaan mana kegagalan terjadi, dan jika Anda memasang Kubernetes, di pod mana kegagalan terjadi, bagaimana keadaan pod tersebut. Oleh karena itu, Observability memiliki hubungan langsung dengan MTTR. Semakin tinggi Observability suatu layanan, semakin mudah untuk mengidentifikasi kesalahan, semakin mudah untuk memperbaiki kesalahan, semakin mudah untuk mengotomatisasi kesalahan, semakin rendah MTTR.
Beralih ke perusahaan kecil lagi, sangat umum untuk bertanya, bahkan sekarang, bagaimana menangani ukuran tim, dan apakah tim kecil perlu menyewa SRE terpisah. Sudah membicarakan hal ini sedikit sebelumnya. Pada tahap awal pengembangan sebuah startup atau misalnya tim, hal ini sama sekali tidak diperlukan, karena SRE dapat dijadikan peran transisi. Dan ini akan sedikit menghidupkan kembali tim, karena setidaknya ada beberapa keragaman. Ditambah lagi, hal ini akan mempersiapkan masyarakat menghadapi kenyataan bahwa dengan pertumbuhan, secara umum, tanggung jawab SRE akan berubah secara signifikan. Jika Anda mempekerjakan seseorang, tentu saja dia memiliki ekspektasi tertentu. Dan ekspektasi ini tidak akan berubah seiring berjalannya waktu, namun persyaratannya akan banyak berubah. Oleh karena itu cara menyewa SRE cukup sulit pada tahap awal. Menumbuhkan sendiri jauh lebih mudah. Tapi itu layak untuk dipikirkan.
Satu-satunya pengecualian, mungkin, adalah ketika terdapat persyaratan pertumbuhan yang sangat ketat dan jelas. Artinya, dalam kasus startup, ini mungkin semacam tekanan dari investor, semacam perkiraan pertumbuhan beberapa kali lipat sekaligus. Maka mempekerjakan SRE pada dasarnya dibenarkan karena bisa dibenarkan. Kami memiliki persyaratan untuk pertumbuhan, kami membutuhkan seseorang yang akan bertanggung jawab untuk memastikan bahwa dengan pertumbuhan seperti itu tidak ada yang akan rusak.
Satu pertanyaan lagi. Apa yang harus dilakukan ketika beberapa kali pengembang memotong fitur yang lolos pengujian, tetapi merusak produksi, memuat basis, merusak fitur lainnya, proses apa yang harus diterapkan. Oleh karena itu, dalam hal ini, anggaran untuk kesalahanlah yang dimasukkan. Dan beberapa layanan, beberapa fitur sudah diuji dalam produksi. Bisa jadi canary, ketika hanya sejumlah kecil pengguna, tetapi sudah dalam produksi, sebuah fitur diterapkan, tetapi sudah dengan harapan bahwa jika ada yang rusak, misalnya setengah persen dari seluruh pengguna, itu masih akan memenuhi anggaran untuk kesalahan. Oleh karena itu, ya, akan ada kesalahan, bagi beberapa pengguna semuanya akan rusak, tetapi kami telah mengatakan bahwa ini normal.
Ada pertanyaan tentang alat SRE. Yaitu, apakah ada sesuatu yang khusus yang dapat digunakan oleh SRE yang tidak akan digunakan oleh orang lain. Faktanya, ada beberapa utilitas yang sangat terspesialisasi, ada beberapa jenis perangkat lunak yang, misalnya, mensimulasikan beban atau terlibat dalam pengujian A/B canary. Namun pada dasarnya toolkit SRE adalah apa yang sudah digunakan oleh pengembang Anda. Karena SRE berinteraksi langsung dengan tim pengembang. Dan jika Anda memiliki alat yang berbeda, ternyata sinkronisasinya memerlukan waktu. Apalagi jika SRE bekerja dalam tim yang besar, di perusahaan besar yang bisa memiliki beberapa tim, standardisasi seluruh perusahaan akan banyak membantu disini, karena jika 50 utilitas berbeda digunakan dalam 50 tim, berarti SRE harus mengetahuinya. semua. Dan tentu saja hal ini tidak akan pernah terjadi. Dan kualitas kerja, kualitas kontrol setidaknya beberapa tim akan menurun secara signifikan.
Webinar kami akan segera berakhir. Saya berhasil menceritakan beberapa hal mendasar. Tentu saja, tidak ada apa pun tentang SRE yang dapat diceritakan dan dipahami dalam waktu satu jam. Namun saya berharap saya berhasil menyampaikan cara berpikir ini, poin-poin utama. Dan kemudian dimungkinkan, jika tertarik, untuk mempelajari topik tersebut, mempelajarinya sendiri, melihat bagaimana hal itu diterapkan oleh orang lain, di perusahaan lain. Oleh karena itu, pada awal Februari, datanglah kepada kami di Slurm SRE.
Slurm SRE adalah kursus intensif tiga hari yang akan membahas apa yang saya bicarakan sekarang, tetapi dengan lebih mendalam, dengan kasus nyata, dengan praktik, keseluruhan intensif ditujukan untuk kerja praktik. Orang-orang akan dibagi menjadi beberapa tim. Anda semua akan mengerjakan kasus nyata. Oleh karena itu, kami memiliki instruktur Booking.com Ivan Kruglov dan Ben Tyler. Kami memiliki Eugene Barabas yang luar biasa dari Google, dari San Francisco. Dan aku juga akan memberitahumu sesuatu. Jadi pastikan untuk mengunjungi kami.
Jadi, daftar pustaka. Ada referensi tentang SRE. pada buku yang sama, atau lebih tepatnya pada 2 buku tentang SRE yang ditulis oleh Google. Yang lainnya , yang syarat dan penerapannya sedikit lebih detail. 3 berikutnya adalah laporan SRE di perusahaan yang berbeda. Pertama - , ini adalah keynote dari Ben Trainer Google. Kedua - . Yang ketiga lagi . Laporan keempat dari , yang hanya memiliki 5 karyawan utama SRE di 190 negara. Sangat menarik untuk melihat semua ini, karena sama seperti DevOps yang mempunyai arti yang sangat berbeda bagi perusahaan yang berbeda dan bahkan tim yang berbeda, SRE memiliki tanggung jawab yang sangat berbeda, bahkan di perusahaan dengan ukuran yang sama.
2 tautan lagi tentang prinsip-prinsip rekayasa kekacauan: , . Dan di bagian akhir ada 3 daftar dari seri Daftar Luar Biasa tentang , tentang dan tentang . Daftar di SRE sangat banyak, tidak perlu dibaca semuanya, ada sekitar 200 artikel. Saya sangat merekomendasikan artikel dari sana tentang perencanaan kapasitas dan tentang postmortem yang tidak bercela.
Artikel menarik:
Terima kasih telah mendengarkanku selama ini. Semoga Anda telah mempelajari sesuatu. Semoga Anda memiliki cukup materi untuk belajar lebih banyak lagi. Dan sampai jumpa. Semoga di bulan Februari.
Webinar dipandu oleh Eduard Medvedev.
PS: bagi yang suka membaca, Eduard memberikan daftar referensinya. Mereka yang lebih suka memahami dalam praktik dipersilakan .
Sumber: www.habr.com