Pikirkan SRE: lihat proyek melalui mata seorang insinyur SRE

Dalam ulasan Slurm, Kubernetes membunyikan frasa: "Kubernet ternyata lebih mudah daripada yang saya kira." Sekarang tidak lagi terdengar, mitos kompleksitas k8 tidak lagi. Dia pindah ke kategori alat yang mudah dipelajari, sulit dikuasai.

Kami ingin mengulangi hal yang sama dengan SRE. Tunjukkan bahwa SRE lebih mudah dan lebih mudah dipahami daripada yang terdengar. Pergeseran paradigma: biarkan orang melihat proyek melalui mata seorang insinyur SRE.

Seperti biasa di awal, ada banyak yang tidak diketahui dalam persamaan. Dan seperti biasa di awal, yang paling menarik adalah yang pertama.

Pada 3-5 Februari, kami akan menyelenggarakan Slurm SRE di Moskow. Tiket intensif tiga hari berharga 60 ribu. Apa yang akan diperoleh peserta untuk uangnya?

Ketika saya memberi tahu teman dan kolega tentang SRE, saya menemukan skeptisisme yang sehat:

• Untuk pertama kalinya saya mendengar tentang SRE, ini semacam alkimia.
• Menerapkan SRE sulit, untuk raksasa seperti Google.
• Itu mahal dan panjang, mereka tidak akan memberi waktu, mereka tidak akan mengalokasikan anggaran.
• Apa yang Anda gambarkan terlalu bagus untuk menjadi kenyataan.

Saya ingin melihat pertanyaan-pertanyaan ini.

Sudah waktunya untuk mencari tahu apa itu SRE.

Pada tingkat slogan: SRE adalah salah satu implementasi dari DevOps. Itu muncul 10+ tahun yang lalu di Google, tetapi baru-baru ini mulai menembus pasar "reguler", terutama karena buku Site Reliability Engeneering, yang dirilis oleh Google pada tahun 2016.

Koneksi antara SRE dan DevOps dijelaskan dengan baik dalam video ini:

Yang buruk adalah bahwa slogan tidak ada artinya. Yah DevOps, baik, implementasi, selanjutnya "untuk semua baik versus semua buruk".

Anda dapat membaca buku (dan itu sangat berharga). Tetapi pembaca akan menemukan dirinya dalam posisi seseorang mempelajari karate dari gambar. Buku ini menjelaskan konsep tanpa aplikasi realitas. Guru memimpin tangan di sepanjang jalur tertentu dan menunjukkan kesalahan dalam proses.

Harga sudah termasuk tinjauan cepat dan mendalam tentang pendekatan dan alat SRE.

Menerapkan SRE lebih mudah daripada kedengarannya

Pada Slurm kita akan menyentuh SRE dengan tangan kita: kita akan memilih metrik, mengkonfigurasi pengukuran mereka, peringatan, mengalami insiden, menyelesaikan dan menganalisisnya, membangun kembali proyek sesuai dengan semua kanre SRE.

Artinya, kami akan memberikan petunjuk langkah demi langkah yang dapat Anda terapkan sendiri setelah kembali dari intensif.

Saya bohong Faktanya, kami tidak akan memberikan instruksi, tetapi sampel dari mana Anda dapat menarik banyak ide dan solusi.

Harga sudah termasuk sampel untuk implementasi.

Masalah utama adalah bahwa Anda harus meyakinkan mereka yang belum pernah ke Slurm. Oleh karena itu, idealnya, ada baiknya datang secara intensif sebagai satu tim. Karena itu, kami memberikan diskon besar untuk grup.

Akan menyenangkan untuk datang ke Slerm yang dipimpin oleh stasiun layanan. Dan CEO juga bermanfaat, dan tentang bagian ini ...

... cara meyakinkan manajemen puncak bahwa SRE bermanfaat dan perlu.

Biasanya ada konflik tugas antara CEO (manajemen puncak), STO (manajemen TI), pengembang dan operasi.

Saya sengaja tidak mengatakan "konflik kepentingan", justru konflik tugas.

CEO membutuhkan kinerja keuangan. STO - situasi yang dapat dimengerti, dikelola dan senyaman mungkin. Artinya, tugas yang dapat dipahami dengan nilai bisnis yang dapat dipahami, memenuhi tenggat waktu, tumpukan normal, lebih banyak fitur, dan lebih sedikit fakaps. Pengembang perlu meluncurkan lebih banyak fitur, dan eksploitasi - untuk memastikan aksesibilitas (yang jelas bertentangan dengan "lebih banyak fitur").

SRE mengatakan bahwa semua peserta dalam proses memiliki satu tugas: kebahagiaan pengguna. Pengguna senang dengan keseimbangan yang sehat antara fitur-fitur baru dan keandalan layanan. Pengguna senang membayar lebih banyak uang. Untuk mengelola kebahagiaan pengguna, Anda membutuhkan alat khusus.

Selain itu, SRE, yang didasarkan pada metrik, memungkinkan Anda menerjemahkan indikator keuangan menjadi indikator target berbagai metrik, dan mereka, pada gilirannya, menjadi tugas tim DevOps.

Memungkinkan Anda menerjemahkan - Saya melebih-lebihkan. Kehadiran metrik ini memungkinkan Anda untuk menemukan hubungan antara keadaan metrik dan indikator keuangan. Ini adalah tugas besar yang terpisah tetapi bisa dimengerti.

Ada proyek DORA, DevOps Research & Assessmentments , yang merilis studi tahunan tentang nilai untuk bisnis dan ROI DevOps dan SRE subkelasnya. Kami sekarang menerjemahkan laporan saat ini ke dalam bahasa Rusia. Ada formula evaluasi yang dapat diterapkan pada perusahaan Anda dengan tingkat akurasi tertentu.

Ringkasan: SRE memberi peluang pada bisnis untuk mengelola kinerja keuangan dengan menetapkan target metrik, dan tim DevOps, dengan melihat nilai-nilai metrik saat ini, dengan jelas memahami apa yang perlu dilakukan untuk manfaat maksimal bagi kinerja keuangan. CEO mana yang akan menolak alat semacam itu?

Sangat mungkin untuk mendapatkan sumber daya untuk implementasi SRE.

Harga kursus termasuk seperangkat argumen yang mendukung beralih ke SRE dan DevOps.

Dan bahkan di perusahaan kecil ada tempat untuk SRE.

SRE dibagi menjadi alat, budaya dan struktur organisasi.

Beberapa alat, misalnya, Service Mesh, diperlukan untuk proyek-proyek besar dan kompleks. Tetapi coba lagi, backoff, injeksi gagal, degradasi anggun dapat diimplementasikan dalam proyek-proyek kecil, dan mereka memberikan pengembalian besar.

Budaya juga bermanfaat di perusahaan mana pun. Administrator klasik, mengatur Prometheus, akan bertindak sesuai dengan standar: itu akan mencakup pemantauan memori dan konsumsi disk, dan pemantauan lain yang akrab. Insinyur SRE pertama akan membahas indikator kunci dari proses bisnis dengan bisnis, dan kemudian mengatur pemantauan mereka. Sangat jelas bahwa budaya SRE-engineering berguna bahkan di startup mikro.

Tetapi struktur organisasi di perusahaan kecil mungkin tidak diperlukan dan bahkan berbahaya. Ketika semua karyawan adalah generalis, tidak perlu mengalokasikan perintah SRE secara paksa.

Semua yang kami jelaskan sudah berfungsi

Kursus ini dibuat oleh mereka yang telah lama menerapkan SRE di tim mereka dan telah lama hidup dalam paradigma ini. Ivan Kruglov dan Ben Tyler, keduanya adalah Pengembang Utama di Booking.com. Eugene Varavva, pengembang profil luas di Google Eduard Medvedev, CTO di Tungsten Labs, yang tumbuh dari seorang insinyur SRE.

Edward memegang webinar "SRE - HYIP atau masa depan?" 12 Desember pukul 11:00.

Tentang program ini

Adapun programnya. Saya sudah mendapatkan umpan balik dari ahli bahwa program ini tidak berjuang: terlalu lebar dan terkadang tidak masuk akal. Memang benar.

Bahkan, kami memiliki kerangka kerja untuk program ini, serangkaian ide yang ingin kami ungkapkan. Kami memiliki dua bulan kerja keras di depan kami, saat kami mempersiapkan, program akan diklarifikasi: kami menghapus yang tidak perlu dan menentukan sisanya.

Namun sudah dalam bentuk saat ini, program ini jelas menunjukkan arah di mana kami bekerja.

Apakah semua hal di atas sepadan dengan uangnya?

PS. Apa hubungan hub Kubernet dengan hal itu

Semua latihan dilakukan di Kubernetes. Mereka yang memiliki Kubernetes memiliki jalan langsung ke insinyur SRE. Bagi mereka yang tidak memiliki, pergi ke kursus Kubernetes kami.

Registrasi untuk Slurm SRE