Webinar memiliki suara yang buruk, jadi kami mendekripsinya.
Nama saya Edward Medvedev. Hari ini saya akan berbicara tentang apa itu SRE, bagaimana SRE muncul, untuk apa kriteria para insinyur SRE bekerja, sedikit tentang kriteria keandalan, sedikit tentang pemantauannya. Kami akan naik ke atas, karena Anda tidak akan memberi tahu banyak dalam satu jam, tapi saya akan memberikan materi untuk kenalan tambahan, dan kami semua menunggu Anda di Slerm SRE . di Moskow pada akhir Januari.
Pertama, mari kita bicara tentang apa SRE - Rekayasa Keandalan Situs. Dan bagaimana itu muncul sebagai posisi yang terpisah, sebagai arah yang terpisah. Semuanya berawal dari fakta bahwa di lingkaran pengembangan tradisional, Dev dan Ops adalah dua tim yang sepenuhnya berbeda, biasanya dengan dua gol yang sama sekali berbeda. Tujuan tim pengembangan adalah untuk meluncurkan fitur-fitur baru dan memenuhi kebutuhan bisnis. Tujuan dari tim Ops adalah agar semuanya berfungsi dan tidak ada yang rusak. Jelas, tujuan-tujuan ini secara langsung bertentangan satu sama lain: agar semuanya berfungsi dan tidak ada yang rusak, meluncurkan fitur-fitur baru adalah sesedikit mungkin. Karena itu, ada 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 yang lalu, dan sejauh ini bagian DevOps telah dimulai dengan presentasi "Apa itu DevOps". Pada 2017, devo hampir 10 tahun, tapi kami masih berdebat apa itu. Dan ini adalah situasi yang sangat aneh yang coba diselesaikan Google beberapa tahun lalu.
Pada 2016, Google merilis sebuah buku berjudul Site Reliability Engineering. Dan sebenarnya, dari buku inilah gerakan SRE dimulai. SRE adalah opsi spesifik untuk mengimplementasikan paradigma DevOps di perusahaan tertentu. Insinyur SRE menetapkan tujuan untuk memastikan kinerja sistem yang andal. Mereka terutama diambil dari pengembang, kadang-kadang dari administrator dengan latar belakang pengembangan yang kuat. Dan mereka melakukan apa yang administrator sistem lakukan sebelumnya, tetapi latar belakang yang kuat dalam pengembangan dan pengetahuan sistem dalam hal kode mengarah pada fakta bahwa orang-orang ini tidak rentan terhadap pekerjaan administrasi rutin, tetapi cenderung otomatisasi.
Ternyata paradigma DevOps dalam tim SRE diimplementasikan oleh fakta bahwa ada insinyur SRE yang memecahkan masalah struktural. Ini dia, koneksi antara Dev dan Ops yang sudah dibicarakan orang selama 8 tahun. Peran SRE mirip dengan peran seorang arsitek dalam arti bahwa pendatang baru ke SRE tidak. Orang-orang di awal karir belum memiliki pengalaman, tidak memiliki luas pengetahuan yang diperlukan. Karena SRE membutuhkan pengetahuan yang sangat baik tentang apa yang sebenarnya dan kapan tepatnya bisa salah. Oleh karena itu, beberapa pengalaman diperlukan di sini, sebagai aturan, baik di dalam perusahaan maupun di luar.
Mereka bertanya apakah perbedaan antara SRE dan devops akan dijelaskan. Dia baru saja dijelaskan. Kita dapat berbicara tentang tempat SRE di organisasi. Tidak seperti pendekatan DevOps klasik ini, di mana Ops masih merupakan departemen yang terpisah, SRE adalah bagian dari tim pengembangan. Mereka terlibat dalam pengembangan produk. Bahkan ada pendekatan di mana SRE adalah peran yang bergerak dari satu pengembang ke pengembang lainnya. Mereka berpartisipasi dalam ulasan kode dengan cara yang sama seperti, misalnya, desainer UX, pengembang sendiri, dan kadang-kadang manajer produk. SRE bekerja pada level yang sama. Kami membutuhkan pembaruan mereka, kami membutuhkan ulasan mereka, sehingga untuk setiap penyebaran SRE dikatakan: “Ya, penyebaran ini, produk ini tidak akan memengaruhi keandalan secara negatif. Dan jika ya, maka sampai batas tertentu. ” Kami juga akan membicarakan hal ini.
Dengan demikian, SRE memiliki hak veto untuk mengubah kode. Dan secara umum, ini juga mengarah pada beberapa jenis konflik kecil jika SRE diterapkan secara tidak benar. Dalam buku yang sama tentang Rekayasa Keandalan Situs, banyak bagian, bahkan tidak satu pun, menceritakan cara menghindari konflik ini.
Mereka bertanya bagaimana SRE terkait dengan keamanan informasi. SRE tidak terlibat langsung dalam keamanan informasi. Pada dasarnya, di perusahaan besar, individu, penguji, dan analis melakukan ini. Tetapi SRE juga berinteraksi dengan mereka dalam arti bahwa beberapa operasi, beberapa melakukan, beberapa penyebaran yang mempengaruhi keamanan juga dapat mempengaruhi ketersediaan produk. Oleh karena itu, SRE secara keseluruhan berinteraksi dengan tim mana pun, termasuk tim keamanan, termasuk analis. Oleh karena itu, sebagian besar SRE diperlukan ketika mereka mencoba menerapkan DevOps, tetapi pada saat yang sama beban pada pengembang menjadi terlalu besar. Artinya, tim pengembangan itu sendiri tidak bisa lagi menghadapi kenyataan bahwa sekarang mereka harus bertanggung jawab atas Ops juga. Dan peran yang terpisah muncul. Peran ini direncanakan dalam anggaran. Terkadang peran ini diletakkan dalam ukuran tim, orang yang terpisah muncul, kadang-kadang menjadi salah satu pengembang. Jadi SRE pertama muncul di tim.
Kompleksitas sistem, yang dipengaruhi oleh SRE, kompleksitas yang memengaruhi keandalan kerja, perlu dan acak. Kompleksitas yang diperlukan adalah ketika kompleksitas suatu produk meningkat sejauh yang diperlukan fitur produk baru. Kompleksitas acak adalah ketika kompleksitas sistem meningkat, tetapi fitur produk dan persyaratan bisnis tidak secara langsung memengaruhi ini. Ternyata pengembang melakukan kesalahan di suatu tempat, atau algoritme tidak optimal, atau beberapa minat tambahan diperkenalkan yang meningkatkan kompleksitas produk tanpa kebutuhan khusus. SRE yang baik harus selalu memotong situasi ini. Artinya, komit apa pun, sebaran apa pun, permintaan tarikan mana pun yang menambah kompleksitas karena penambahan acak harus diblokir.
Pertanyaannya adalah, mengapa tidak hanya merekrut seorang insinyur, seorang administrator sistem dengan banyak pengetahuan dalam tim. Seorang pengembang dalam peran seorang insinyur, kami diberitahu, bukanlah solusi penempatan staf terbaik. Pengembang yang berperan sebagai insinyur tidak selalu merupakan solusi penempatan staf terbaik, tetapi intinya di sini adalah bahwa pengembang yang berurusan dengan Ops memiliki keinginan yang lebih besar untuk otomatisasi, memiliki sedikit lebih banyak pengetahuan dan keterampilan untuk menerapkan otomatisasi ini. Dan karenanya, kami mengurangi tidak hanya waktu untuk operasi tertentu, tidak hanya rutin, tetapi juga parameter bisnis penting seperti MTTR (Mean Time To Recovery, waktu pemulihan). Dengan demikian, dan ini juga akan sedikit kemudian, kami menghemat uang untuk organisasi.
Sekarang mari kita bicara tentang kriteria untuk pekerjaan SRE. Dan pertama-tama tentang reliabilitas. Di perusahaan kecil, startup, sangat sering terjadi bahwa orang berasumsi bahwa jika layanan ditulis dengan baik, jika produk ditulis dengan baik dan benar, itu akan berfungsi, itu tidak akan rusak. Itu saja, kami menulis kode yang baik, jadi tidak ada yang perlu dipatahkan. Kode ini sangat sederhana, tidak ada yang bisa dilanggar. Ini adalah tentang orang yang sama yang mengatakan bahwa kita tidak memerlukan tes, karena, lihat, ini adalah tiga metode VPI, mengapa harus dilanggar.
Ini semua salah, tentu saja. Dan orang-orang ini sangat sering menggigit kode dalam praktek, karena hal-hal yang rusak. Hal-hal kadang-kadang pecah dengan cara yang paling tidak terduga. Terkadang orang mengatakan tidak, ini tidak akan pernah terjadi. Dan itu semua terjadi persis. Ini sering terjadi. Dan karena itu, tidak ada yang pernah berusaha untuk ketersediaan 100%, karena ketersediaan 100% tidak pernah terjadi. Ini adalah norma. Dan karena itu, ketika kita berbicara tentang ketersediaan layanan, kita selalu berbicara tentang sembilan. 2 nin, 3 nin, 4 nin, 5 nin. Jika Anda menerjemahkan ini ke dalam downtime, maka, misalnya, 5 nines, maka ini lebih dari 5 menit downtime per tahun, 2 nines adalah 3,5 hari downtime.
Tetapi jelas bahwa pada titik tertentu ada penurunan POI, laba atas investasi. Beralih dari dua sembilan menjadi tiga sembilan, ini berarti mengurangi waktu henti hingga lebih dari 3 hari. Pergi dari empat sembilan menjadi lima mengurangi downtime 47 menit setahun. Dan ternyata untuk bisnis ini mungkin tidak kritis. Dan secara umum, keandalan yang diperlukan bukan masalah teknis, pertama-tama, ini adalah masalah bisnis, ini adalah masalah produk. Level downtime apa yang dapat diterima oleh pengguna produk, apa yang mereka harapkan, berapa banyak yang mereka bayarkan, misalnya, berapa banyak uang yang hilang, berapa banyak uang yang hilang sistem.
Pertanyaan penting dalam hal ini adalah apa keandalan komponen yang tersisa. Karena perbedaan antara 4 dan 5 nines tidak akan terlihat pada smartphone dengan keandalan 2 nines. Secara kasar, jika sesuatu rusak pada smartphone di layanan Anda 10 kali setahun, kemungkinan besar 8 kali kegagalan terjadi tepat di sisi OS. Pengguna terbiasa dengan ini, dan tidak akan memperhatikan setahun sekali. Hal ini diperlukan untuk mengkorelasikan harga peningkatan keandalan dan peningkatan laba.
Hanya dalam buku tentang SRE ada contoh yang baik untuk meningkatkan menjadi 4 nines dari 3 nines. Ternyata peningkatan ketersediaan sedikit kurang dari 0,1%. Dan jika pendapatan layanan adalah $ 1 juta per tahun, maka peningkatan pendapatan adalah $ 900. Jika peningkatan aksesibilitas sembilan biaya kami kurang dari $ 900 per tahun, peningkatan ini masuk akal secara finansial. Jika biayanya lebih dari $ 900 setahun, itu tidak lagi masuk akal, karena pertumbuhan pendapatan sama sekali tidak mengimbangi biaya tenaga kerja, biaya sumber daya. Dan 3 sembilan akan cukup untuk kita.
Ini tentu saja merupakan contoh yang disederhanakan di mana semua kueri sama. Dan dari 3 nines ke 4 nines itu cukup mudah untuk berganti, tetapi pada saat yang sama, misalnya, beralih dari 2 nines ke 3 sudah merupakan penghematan 9 ribu dolar, itu bisa masuk akal secara finansial. Secara alami, pada kenyataannya, kegagalan permintaan registrasi lebih buruk daripada kegagalan untuk menampilkan halaman, permintaan memiliki bobot yang berbeda. Mereka mungkin memiliki kriteria yang sangat berbeda dari sudut pandang bisnis, tetapi masih, sebagai aturan, jika kita tidak berbicara tentang layanan spesifik, ini adalah perkiraan yang cukup dapat diandalkan.
Kami mendapat pertanyaan apakah SRE adalah salah satu koordinator ketika memilih solusi arsitektur untuk layanan. Mari kita asumsikan dalam hal integrasi ke dalam infrastruktur yang ada sehingga tidak ada kerugian dalam stabilitasnya. Ya, SRE memiliki efek yang sama pada permintaan tarik, melakukan, rilis, mereka mempengaruhi arsitektur, pengenalan layanan baru, layanan mikro, dan pengenalan solusi baru. Mengapa saya katakan sebelumnya bahwa saya perlu pengalaman, saya perlu kualifikasi. Bahkan, SRE adalah salah satu suara yang menghalangi dalam setiap solusi arsitektur dan perangkat lunak. Oleh karena itu, SRE sebagai seorang insinyur harus, pertama-tama, tidak hanya memahami, tetapi juga memahami bagaimana solusi spesifik apa pun akan memengaruhi keandalan, stabilitas, dan memahami bagaimana ini berkaitan dengan kebutuhan bisnis, dan dari sudut pandang apa hal itu dapat terjadi. itu diizinkan, dan dengan apa yang tidak.
Oleh karena itu, sekarang kita dapat berbicara tentang kriteria keandalan, yang dalam SRE secara tradisional didefinisikan sebagai SLA (Service Level Agreement). Kemungkinan besar istilah yang akrab. SLI (Indikator Tingkat Layanan). SLO (Sasaran Tingkat Layanan). Perjanjian Tingkat Layanan mungkin merupakan istilah tengara, terutama jika Anda telah bekerja dengan jaringan, dengan penyedia, dengan hosting. Ini adalah perjanjian umum yang menggambarkan kinerja seluruh layanan Anda, penalti, beberapa penalti untuk kesalahan, metrik, kriteria. Dan SLI adalah metrik ketersediaan itu sendiri. Artinya, apa yang mungkin SLI: waktu respons dari layanan, jumlah kesalahan dalam persentase. Ini bisa menjadi bandwidth jika menyangkut beberapa jenis hosting file. Jika kita berbicara tentang algoritma pengenalan, indikator mungkin, misalnya, bahkan kebenaran jawabannya. SLO (Service Level Objective) adalah kombinasi dari indikator SLI, nilainya dan periode masing-masing.
Katakanlah SLA bisa seperti itu. Layanan tersedia 99,95% dari waktu sepanjang tahun. Atau 99 tiket dukungan kritis akan ditutup dalam waktu 3 jam per kuartal. Atau 85% dari permintaan akan dijawab dalam 1,5 detik setiap bulan. Artinya, kita secara bertahap mulai memahami bahwa kesalahan dan kegagalan adalah hal yang normal. Ini adalah situasi yang dapat diterima, kami sedang merencanakannya, kami bahkan mengandalkannya sampai batas tertentu. Artinya, SRE membangun sistem yang dapat membuat kesalahan, yang seharusnya merespons secara normal kesalahan yang harus memperhitungkannya. Dan jika mungkin, mereka harus menangani kesalahan sedemikian rupa sehingga pengguna tidak memperhatikan atau pemberitahuan, tetapi ada beberapa solusi karena semuanya tidak akan jatuh sepenuhnya.
Misalnya, jika Anda mengunggah video ke YouTube, dan YouTube tidak dapat segera mengonversinya, jika video terlalu besar, jika formatnya tidak optimal, maka permintaan secara alami tidak akan gagal, YouTube tidak akan memberikan kesalahan 502, YouTube akan mengatakan: "Kami telah menciptakan segalanya, Video Anda sedang diproses. Ini akan siap dalam waktu sekitar 10 menit. " Ini adalah prinsip degradasi yang anggun, yang akrab, misalnya, dalam pengembangan frontend, jika Anda pernah melakukan ini.
Istilah berikut yang akan kita bicarakan yang sangat penting untuk bekerja dengan keandalan, dengan kesalahan, dengan harapan adalah MTBF dan MTTR. MTBF adalah waktu rata-rata di antara kegagalan. MTTR Mean Time To Recovery, waktu rata-rata untuk pemulihan. Yaitu, berapa banyak waktu telah berlalu sejak kesalahan terdeteksi, dari saat kesalahan muncul hingga saat layanan sepenuhnya pulih ke normal. MTBF sebagian besar diperbaiki dengan bekerja pada kualitas kode. Artinya, bahwa SRE dapat mengatakan tidak. Dan Anda perlu pemahaman seluruh tim bahwa ketika SRE mengatakan "tidak", dia mengatakan ini bukan karena dia berbahaya, bukan karena dia jahat, tetapi karena kalau tidak semua orang akan menderita.
Sekali lagi, ada banyak artikel, banyak metode, banyak cara, bahkan di buku yang sering saya referensikan, bagaimana mencegah pengembang lain mulai membenci SRE. MTTR, di sisi lain, sedang mengerjakan SLO Anda (Service Level Objective). Dan ini sebagian besar otomatisasi. Karena, misalnya, SLO kami adalah uptime 4 nines per kuartal. Ini berarti bahwa dalam 3 bulan kita dapat membiarkan 13 menit downtime. Dan ternyata kami tidak dapat memiliki MTTR selama lebih dari 13 menit. Jika kami bereaksi selama setidaknya 1 downtime selama 13 menit, ini berarti bahwa kami telah menghabiskan seluruh anggaran untuk kuartal tersebut. Kami melanggar SLO. 13 menit untuk reaksi dan memperbaiki kegagalan banyak untuk mobil, tetapi sangat sedikit untuk seseorang. Karena selama peringatan datang ke seseorang, sementara dia bereaksi, sampai dia mengerti kesalahannya, ini sudah beberapa menit. Sampai seseorang mengerti bagaimana cara memperbaikinya, apa yang harus diperbaiki, apa yang harus dilakukan, maka ini adalah beberapa menit lagi. Dan pada kenyataannya, bahkan jika Anda hanya perlu me-reboot server, ternyata, atau meningkatkan node baru, maka MTTR manual sudah sekitar 7-8 menit. Saat mengotomatiskan suatu proses, MTTR sangat sering mencapai sedetik, terkadang milidetik. Google biasanya berbicara tentang milidetik, tetapi dalam kenyataannya, tentu saja, semuanya tidak begitu baik.
Idealnya, SRE harus mengotomatisasi pekerjaannya hampir sepenuhnya, karena secara langsung memengaruhi MTTR, metriknya, SLO seluruh layanan, dan karenanya menguntungkan bisnis. Jika waktu terlampaui, tanyakan kepada kami apakah kesalahannya terletak pada SRE. Demi kebaikan, tidak ada yang bisa disalahkan. Dan ini adalah budaya terpisah yang disebut balmeless postmortem, yang tidak akan kita bicarakan hari ini, tetapi kita akan menganalisa Slurme. Ini adalah topik yang sangat menarik yang bisa dibicarakan banyak. Secara kasar, jika waktu yang ditentukan untuk seperempat terlampaui, maka setiap orang harus disalahkan sedikit, yang berarti menyalahkan setiap orang tidak produktif, mari kita sebaliknya, mungkin tidak menyalahkan siapa pun, tetapi perbaiki situasi dan bekerja dengan apa yang kita miliki. Dalam pengalaman saya, pendekatan ini untuk sebagian besar tim, terutama di Rusia, agak asing, tetapi masuk akal dan bekerja dengan sangat baik. Oleh karena itu, saya akan merekomendasikan di akhir artikel dan literatur yang dapat dibaca tentang topik ini. Atau datang ke Slurm SRE.
Saya akan jelaskan. Jika waktu SLO per kuartal terlampaui, jika downtime bukan 13 menit, tetapi 15, siapa yang bisa disalahkan untuk ini? Tentu saja, SRE bisa disalahkan, karena dia jelas membuat semacam komitmen atau penyebaran yang buruk. Administrator pusat data dapat disalahkan atas hal ini, karena, mungkin, beberapa pemeliharaan terjadwal dilakukan. Jika administrator pusat data yang harus disalahkan, orang Ops yang tidak menghitung pemeliharaan saat mengoordinasikan SLO adalah yang harus disalahkan. Manajer, direktur teknis atau seseorang yang menandatangani kontrak pusat data dan tidak memperhatikan fakta bahwa pusat data SLA tidak dirancang untuk waktu henti yang dipersyaratkan. Dengan demikian, sedikit demi sedikit setiap orang harus disalahkan atas situasi ini. Dan itu berarti tidak masuk akal untuk menyalahkan siapa pun dalam situasi ini. Tapi tentu saja Anda harus memperbaikinya. Karena itu, ada post-mortem. Dan jika Anda membaca, misalnya, post-mortem Github, yang selalu merupakan kisah yang sangat menarik, kecil, dan tidak terduga dalam setiap kasus tertentu, Anda dapat menggantikannya bahwa tidak ada yang pernah mengatakan bahwa orang tertentu yang harus disalahkan. Rasa bersalah selalu ditugaskan untuk proses tidak sempurna tertentu.
Mari kita beralih ke pertanyaan berikutnya. Otomasi Saya biasanya, ketika berbicara tentang otomatisasi dalam konteks lain, sangat sering merujuk ke tabel yang memberi tahu berapa lama Anda dapat bekerja mengotomatiskan tugas sehingga tidak membutuhkan waktu lebih lama untuk mengotomatiskannya daripada yang biasanya Anda simpan. Ada halangan. Tangkapannya adalah ketika SRE mengotomatiskan beberapa tugas, mereka tidak hanya menghemat waktu, mereka menghemat uang, karena otomatisasi secara langsung memengaruhi MTTR. Mereka menyimpan, dengan kata lain, moral karyawan dan pengembang, yang juga merupakan sumber daya yang lengkap. Mereka mengurangi rutinitas. Dan semua ini secara positif mempengaruhi pekerjaan dan, sebagai konsekuensinya, bisnis, bahkan jika tampaknya otomatisasi tidak masuk akal dalam hal biaya waktu.
Bahkan, hampir selalu demikian, dan ada beberapa kasus ketika tidak layak mengotomatisasi sesuatu dalam peran SRE. Selanjutnya kita akan berbicara tentang apa yang disebut anggaran kesalahan, anggaran untuk kesalahan. Bahkan, ternyata jika semuanya jauh lebih baik untuk Anda daripada SLO yang Anda tetapkan untuk diri sendiri, ini juga tidak terlalu baik. Ini agak buruk, karena SLO bekerja tidak hanya sebagai batas bawah, tetapi juga sebagai perkiraan batas atas. Ketika Anda menetapkan sendiri SLO dalam aksesibilitas 99%, dan ternyata Anda memiliki 99,99%, ternyata Anda memiliki ruang untuk bereksperimen yang tidak akan membahayakan bisnis sama sekali, karena Anda sendiri yang menentukan ini bersama-sama, dan Anda adalah ruang jangan gunakan. Anda memiliki anggaran untuk kesalahan yang tidak dikeluarkan dalam kasus Anda.
Apa yang kita lakukan dengannya. Kami menggunakannya secara harfiah untuk semuanya. Untuk pengujian dalam kondisi produksi, untuk meluncurkan fitur baru yang dapat memengaruhi kinerja, rilis, pemeliharaan, dan waktu henti yang dijadwalkan. Aturan sebaliknya juga berlaku: jika anggaran habis, kami tidak dapat membongkar sesuatu yang baru, karena jika tidak, SLO akan terlampaui. Anggaran sudah habis, kami belum merilis sesuatu, jika itu akan berdampak negatif pada produktivitas, yaitu, jika bukan semacam perbaikan yang secara langsung meningkatkan SLO, maka kami melampaui anggaran, dan ini adalah situasi yang buruk, perlu dianalisis , post-mortem, dan mungkin semacam perbaikan proses.
Yaitu, ternyata jika layanan itu sendiri bekerja dengan buruk, dan SLO dihabiskan dan anggaran dihabiskan bukan untuk percobaan, bukan pada beberapa rilis, tetapi dengan sendirinya, maka alih-alih perbaikan yang menarik bagi pengembang, alih-alih fitur menarik, alih-alih yang menarik rilis. Alih-alih segala jenis karya kreatif, Anda harus melakukan perbaikan bodoh untuk mengembalikan anggaran ke pesanan, atau mengedit SLO, dan ini juga merupakan proses yang tidak boleh terjadi terlalu sering.
Oleh karena itu, ternyata dalam situasi di mana kami memiliki lebih banyak anggaran untuk kesalahan, semua orang tertarik: baik SRE dan pengembang. Untuk pengembang, anggaran besar untuk kesalahan berarti bahwa Anda dapat menangani rilis, tes, dan eksperimen. Untuk SRE, anggaran untuk kesalahan dan masuk ke dalam anggaran ini berarti mereka benar-benar melakukan pekerjaan mereka dengan baik secara langsung. Dan ini mempengaruhi motivasi untuk beberapa jenis kolaborasi. Jika Anda mendengarkan SRE sebagai pengembang, Anda akan memiliki lebih banyak ruang untuk pekerjaan yang baik dan jauh lebih sedikit rutin.
Ternyata eksperimen dalam produksi adalah bagian yang cukup penting dan hampir tidak terpisahkan dari SRE dalam tim besar. Dan biasanya disebut chaos ingeneering, yang berasal dari tim Netflix yang merilis utilitas bernama Chaos Monkey.
Chaos Monkey terhubung ke pipa CI / CD dan secara acak menjatuhkan server dalam produksi. Sekali lagi, dalam struktur SRE, kita berbicara tentang fakta bahwa server macet itu sendiri tidak buruk, seperti yang diharapkan. Dan jika dimasukkan dalam anggaran, itu dapat diterima dan tidak membahayakan bisnis. , , , , , .
- , , Chaos Gorilla, . , -, , , , . , , , . , , , - , , , , , . . , , , , , CI/CD . , , , , , , , . , , , . , .
: ? . , . , SRE . , , . , , SRE , , , , , , , . SRE , - . , SRE, - .
, , . , SRE , , . , , . , , , , , , .
, . SRE , . , , SLA, SLI, SLO. , SLA SLO, . - , , , - , , . 4 , IT , . , - .
. , - , , Objectives, , 3 .
, , . SLA, SLI, SLO, , , Objectives, SLA. , : - , , . . , -. , , , , , -, , : - . -, , . , SRE , , .
3 . , , . – , . , , , . – , . , - , - , , . – , , , . , - - , . - . , , .
, , , , , . , . . . . . , .
, Observability. . , . , Observability . - , , , . : , . , , , . , - Kubernetes, , . Observability MTTR. Observability , , , , MTTR.
, , , , SRE. . , , , SRE . , - . , , -, SRE . , , , - . , . SRE . . .
, , , . - , - . SRE, -, , . , , , .
. , , , , , , . . , . canary, , , , - , , , . , , , , .
SRE. , - , SRE, . - , - , , , canary A/B . SRE , . SRE . , , . SRE , , , , 50 50 , , SRE . . , .
. - . , SRE . , , . , , , , , , . SRE.
SRE — , , , , , , . . . Booking.com . , . - . .
, . SRE. , 2 SRE, . SLA, SLI, SLO , . 3 SRE . – Keys to SRE , . — SRE . SRE . SRE , 5 SRE 190 . , DevOps , SRE , .
2 chaos ingeneering: (1) , (2) . 3 Awesome Lists chaos ingeneering , SRE SRE . SRE , , 200 . capacity planning blameless postmortem.
: SRE as a life choice
, . , - . , , . . .
.
PS: bagi yang suka membaca, Edward memberikan daftar referensi. Mereka yang lebih suka memahami dalam praktik dipersilakan di Slörme SRE .