Pada 21 Mei, kursus intensif SRE akan dimulai di Slurme. Selama tiga hari penuh, peserta akan membenamkan diri dalam teori dan praktik mendukung layanan beban tinggi. Tidak ada tugas kerja, tidak ada urusan keluarga - hanya belajar. Di bawah pemotongan, kami memberi tahu Anda apa yang menanti Anda jika Anda memutuskan untuk bergabung.
Bantuan SRE
Site Reliability Engineering (SRE) - memastikan keandalan sistem informasi. Ini adalah pendekatan baru untuk mendukung situs, layanan, dan aplikasi dengan ribuan dan jutaan pengguna. Pendekatan ini berasal dari Google dan sekarang menyebar ke seluruh dunia. Di Rusia, SRE telah diterapkan di Yandex, Mail.ru, Sberbank, Tinkoff, MTS, Megafon, dan perusahaan lain.
Pengembang dan administrator sistem berpengalaman menjadi insinyur SRE: pengetahuan mendalam tentang sistem operasi server, operasi jaringan, alat pemantauan, serta keterampilan pemrograman itu penting. Semua keterampilan keras ini ditumpangkan pada metodologi SRE - praktik khusus yang membantu memastikan keandalan yang tinggi.
“SRE bukan tentang peringatan dan postmortem. Ini tentang fakta bahwa kode yang merusak di malam hari tidak mencapai produksi. "
Dari komunikasi dengan insinyur yang menerapkan SRE
Sejak lama, sumber utama ilmu pengetahuan tentang SRE adalah buku dengan nama yang sama dari Google. Sekarang ada beberapa program pelatihan bahasa Inggris dan Rusia. Salah satunya adalah SRE intensif di Slurme.
Format intensif
Kursus intensif berlangsung online dan terdiri dari ceramah dan sesi praktek. Akan ada siaran di Zoom dan Telegram chat dengan speaker.
Dua jenis latihan. Latihan praktis terdiri dari dua jenis: penyesuaian dengan contoh dan mengerjakan tugas, yang solusinya belum ditentukan sebelumnya. Dalam kursus intensif, mereka disebut kasus .
Kerja tim dalam layanan nyata. Untuk menangani kasus-kasus tersebut, peserta intensif disatukan dalam tim beranggotakan 5-8 orang. Setiap tim menerima stan dengan aplikasi - beberapa VDS, yang menjadi tuan rumah situs web untuk memesan tiket .
Sebuah layanan untuk memesan tiket, operasi yang stabil akan dipastikan oleh peserta Simulasi Kegagalan Intensif
.Selama intensif, beberapa kegagalan besar akan terjadi dalam pekerjaan situs, dan tugas tim adalah menemukan penyebabnya, menghilangkan, dan mencegahnya terulang kembali. Kasus-kasus tersebut didasarkan pada pengalaman nyata: para pembicara mengumpulkan masalah-masalah yang mereka hadapi selama latihan SRE mereka dan menciptakan lingkungan untuk mensimulasikan masalah-masalah tersebut.
Pembicara berpengalaman. Program intensif dikembangkan dan dilakukan oleh:
- Ivan Kruglov, Staf Insinyur Perangkat Lunak di Databricks.
- Artyom Artemiev, Pimpinan SRE di TangoMe.
- Pavel Selivanov, Insinyur DevOps Senior di Mail.ru Cloud Solutions.
Dukung. Kurator akan membantu bersatu dalam tim dan mengatur kerja bersama. Pembicara dan teknisi dukungan teknis dari Slurm akan mendukung Anda dalam memecahkan masalah yang kompleks.
Format jarak jauh. Ceramah disiarkan di Zoom, diskusi tugas berlangsung di Slack. Semua catatan perkuliahan akan disimpan dan akan tersedia setelah intensif, berguna untuk mengembalikannya setelah beberapa saat, sudah dalam suasana yang lebih tenang.
Tiga hari perendaman penuh. Intensif dirancang selama tiga hari penuh, dari pukul 10:00 hingga 18:00 waktu Moskow. Akan ada istirahat singkat antara kuliah dan makan siang.
Mulai tanggal 21 Mei. Masih ada ruang.
Pelajari lebih lanjut dan daftar
Di bawah ini adalah program intensif penuh.
Hari 1: Mengenal teori SRE, menyiapkan pemantauan dan peringatan
Di hari pertama, Anda akan mengenal teori SRE, mempelajari cara mengatur monitoring dan alert, serta bekerjasama dengan peserta lain secara intensif.
Mari kita bicara tentang metrik SLO, SLI, SLA dan bagaimana keterkaitannya dengan persyaratan bisnis. Kami akan membagikan Praktik Terbaik untuk menyiapkan pemantauan dan aturan untuk pemadam kebakaran. Kami akan memberikan kasus praktis pertama.
Topik 1: Pemantauan
- Mengapa Anda membutuhkan pemantauan,
- Gejala vs Penyebab,
- Kotak Hitam vs. Pemantauan Kotak Putih,
- Sinyal Emas,
- Persentil,
- Memperingatkan,
- Observabilitas.
Latihan: Membuat dasbor dasar dan mengatur peringatan yang diperlukan.
Topik 2: Teori SRE
- SLO, SLI, SLA,
- Daya tahan,
- Anggaran kesalahan.
Latihan: Menambahkan peringatan SLO / SLI + ke dasbor.
Latihan: Pemuatan pertama sistem.
Kasus 1: kecanduan hilir. Dalam sistem yang besar, ada banyak layanan yang saling bergantung, dan mereka tidak selalu bekerja dengan baik. Ini terutama menyinggung ketika layanan Anda beres, dan layanan tetangga, tempat Anda bergantung, turun secara berkala. Proyek pelatihan akan menemukan dirinya dalam kondisi seperti itu, dan Anda akan membuatnya sehingga tetap memberikan kualitas pada tingkat setinggi mungkin.
Topik 3: Manajemen Insiden
- Rekayasa Ketahanan,
- Bagaimana regu pemadam kebakaran berbaris
- Seberapa efektif tim Anda dalam insiden tersebut,
- 7 aturan untuk pemimpin insiden,
- 5 aturan untuk petugas pemadam kebakaran,
- HiPPO - opini orang dengan bayaran tertinggi. Pemimpin Komunikasi.
Kasus 2: kecanduan hulu. Itu satu hal ketika Anda bergantung pada layanan dengan SLO rendah. Ini masalah lain ketika layanan Anda seperti itu untuk bagian lain dari sistem. Ini terjadi jika kriteria evaluasi tidak disetujui: misalnya, Anda menanggapi permintaan dalam satu detik dan menganggapnya berhasil, tetapi layanan yang bergantung hanya menunggu 500 waktu Moskow dan pergi dengan kesalahan. Dalam hal ini, kita akan membahas pentingnya rekonsiliasi metrik dan belajar melihat kualitas dari sudut pandang klien.
Topik 4: SRE memasukkan proyek
Di perusahaan besar, tidak jarang membentuk tim SRE terpisah, yang mengambil dukungan layanan dari departemen lain. Namun tidak semua layanan siap untuk didukung. Kami akan memberi tahu Anda persyaratan apa yang harus dipenuhi.
Hari 2: Memecahkan masalah dengan lingkungan dan arsitektur
Hari kedua hampir seluruhnya dibangun untuk menyelesaikan dua kasus: masalah dengan lingkungan (akan ada analisis rinci tentang Pemeriksaan Kesehatan) dan masalah dengan arsitektur. Pembicara akan berbicara tentang bekerja dengan post mortem dan memberikan template yang dapat Anda gunakan dalam tim Anda.
Topik 5: Pemeriksaan Kesehatan
- Health Check di Kubernetes,
- Apakah layanan kami hidup?
- Exec probe,
- initialDelaySeconds,
- Pelabuhan Kesehatan Sekunder,
- Server Kesehatan Sidecar,
- Probe Tanpa Kepala,
- Pemeriksaan Perangkat Keras.
Kasus 3: masalah lingkungan dan pemeriksaan kesehatan yang benar. Tugas Healthcheck adalah mendeteksi layanan downtime dan memblokir lalu lintas ke sana sehingga pengguna tidak menghadapi masalah. Dan jika menurut Anda itu cukup untuk melakukan root pada permintaan ke layanan dan mendapatkan jawaban, maka Anda salah: meskipun layanan merespons, ini tidak menjamin kinerjanya - mungkin ada masalah di lingkungan. Melalui kasus ini, Anda akan belajar cara mengonfigurasi Healthcheck yang benar dan tidak membiarkan lalu lintas pergi ke tempat yang tidak dapat diproses.
Topik 6: Praktek bekerja dengan postmortem - kita menulis postmortem berdasarkan kasus sebelumnya dan menganalisanya dengan pembicara.
Topik 7: Mengatasi Masalah Infrastruktur
- Memantau MySQL,
- SLO / SLI untuk MySQL,
- Deteksi anomali.
Kasus 4: masalah dengan database. Basis data juga bisa menjadi sumber masalah. Misalnya, jika Anda tidak memantau relai replikasi, replika tersebut akan menjadi usang dan aplikasi akan mengembalikan data lama. Selain itu, sangat sulit untuk men-debug kasus seperti itu: sekarang datanya tidak konsisten, tetapi setelah beberapa detik data itu hilang, dan apa penyebab masalahnya tidak jelas. Melalui kasus ini, Anda akan merasakan sakitnya debugging dan belajar bagaimana mencegah masalah tersebut.
Hari 3: perisai lalu lintas dan pelepasan kenari
Ada dua kasus tentang ketersediaan produksi yang tinggi: perisai lalu lintas dan penyebaran kenari. Anda akan belajar tentang pendekatan ini dan belajar bagaimana menerapkannya. Kami tidak merencanakan tuning hardcore dengan tangan, meskipun siapa tahu.
Topik 8: Perisai lalu lintas
- perilaku grafik pertumbuhan jumlah permintaan dan operasi bisnis
- perencanaan kejenuhan dan kapasitas
- traffic shielding rate limiting
- sidecar rate-limiting 100
5: traffic shielding. ? , 100 , 1000. , , , . , .
9: Canary Deployment
- k8s (Rolling Update vs Recreate),
- canary blue-green ,
- blue-gree/canary release k8s,
- canary release GitLab CI/CD,
- canary release,
- .gitlab-ci.yml.
6: . ,
, - . , . Canary Deployment, .