Rekayasa Keandalan Situs - kursus 65.000 gosok. dari Slurm, pelatihan, Tanggal 1 Januari 2024.
Miscellanea / / November 29, 2023
KEORANG-ORANG
Seorang insinyur SRE dapat menjadi insinyur operasi atau pengembang. Selama kursus intensif, Anda akan banyak berlatih, dan keterampilan serta pengetahuan yang Anda peroleh dapat diadaptasi dan diterapkan di bidang apa pun.
BISNIS
SRE memecahkan masalah yang sama seperti DevOps: SRE meningkatkan kecepatan rilis fitur baru dan meningkatkan proses dalam tim. Namun tugas utama SRE adalah memastikan stabilitas dan keandalan layanan, tidak termasuk situasi di mana pengguna mengeluh tentang kegagalan, dan teknisi memiliki jadwal ramah lingkungan.
Kami sedang membangun:
Situs pelatihan kami terdiri dari beberapa layanan mikro. Ini mengumpulkan data tentang pertunjukan, harga dan kursi yang tersedia dari semua bioskop, menampilkan pengumuman film, memungkinkan Anda memilih bioskop, pertunjukan, aula dan tempat, memesan dan membayar tiket.
Kami akan merumuskan indikator SLO, SLI, SLA untuk situs ini, mengembangkan arsitektur dan infrastruktur yang akan mendukungnya, menyiapkan pemantauan dan peringatan.
Kesalahan pengembang, kegagalan infrastruktur, masuknya pengunjung, dan serangan DoS menyebabkan memburuknya SLO.
Kami menganalisis stabilitas, anggaran kesalahan, praktik pengujian, manajemen interupsi, dan beban operasional.
Ada kecelakaan. Layanan pemrosesan pembayaran sedang down. Bagaimana cara bertindak untuk memulihkan fungsionalitas dalam waktu sesingkat mungkin?
Kami mengatur pekerjaan tim tanggap darurat: melibatkan kolega, memberi tahu pemangku kepentingan, menetapkan prioritas. Kami berlatih untuk bekerja di bawah tekanan dalam kondisi waktu yang sangat terbatas.
Mari kita lihat pendekatan situs ini dari sudut pandang SRE. Kami menganalisis insiden (penyebab terjadinya, kemajuan eliminasi). Kami mengambil keputusan untuk mencegahnya lebih lanjut: kami meningkatkan pemantauan, mengubah arsitektur, pendekatan terhadap pengembangan dan pengoperasian, serta peraturan. Kami mengotomatiskan proses.
— Kami memiliki lusinan infrastruktur yang dibangun dan ratusan pipeline CI/CD tertulis,
— Administrator Kubernetes Bersertifikat,
— Penulis beberapa kursus tentang Kubernetes dan DevOps,
— Pembicara reguler di konferensi TI Rusia dan internasional.
HARI 1: Sesi pembukaan AMA
Kami akan membahas maksud dan tujuan kursus, serta memberi tahu Anda apa itu SRE dan membaginya menjadi beberapa tim.
Pembukaan 2 topik teori:
Topik 1: Pemantauan
- Mengapa pemantauan diperlukan?
- Persentil
- Memperingatkan
- Observabilitas
Topik 2: Teori SRE
- SLO, SLI, SLA
- Daya tahan
- Anggaran yang salah
HARI 2: analisis praktik dan kasus
Praktik: Membuat dasbor dasar dan mengatur peringatan yang diperlukan
Praktik: Menambahkan peringatan SLO/SLI + ke dasbor
Praktik: Pemuatan sistem pertama
Solusi kasus 1: ketergantungan hilir.
Dalam sistem yang besar, terdapat banyak layanan yang saling bergantung, dan layanan tersebut tidak selalu berfungsi dengan baik. Ini sangat menjengkelkan ketika layanan Anda baik-baik saja, tetapi layanan tetangga, tempat Anda bergantung, turun secara berkala.
Proyek pendidikan akan berada dalam kondisi seperti ini, dan Anda akan memastikan bahwa proyek tersebut masih menghasilkan kualitas pada tingkat setinggi mungkin.
HARI 3: Sesi AMA, pertanyaan terjawab
Akses ke modul teori ke-2 terbuka:
Memecahkan masalah dengan lingkungan dan arsitektur
Modul kedua dibangun untuk menyelesaikan dua kasus: ketergantungan upstream dan masalah arsitektur. Pembicara akan berbicara tentang manajemen insiden, peraturan pemadam kebakaran dan bekerja dengan pemeriksaan mayat serta memberikan template yang dapat Anda gunakan di tim Anda.
Topik 3: Manajemen Insiden
- Rekayasa Ketahanan
- Bagaimana pemadam kebakaran terbentuk
- Seberapa efektifkah tim Anda dalam insiden tersebut?
- 7 aturan untuk pemimpin insiden
- 5 aturan untuk petugas pemadam kebakaran
- HiPPO - opini orang dengan bayaran tertinggi. Pemimpin Komunikasi
TTema 4: Alat Varrum dan manajemen peringatan.
Praktik terbaik perusahaan lain dalam mengatur manajemen insiden.
HARI 4: analisis praktik dan kasus
Solusi untuk kasus 2: ketergantungan upstream.
Jika Anda bergantung pada layanan dengan SLO rendah adalah satu hal. Hal lain adalah ketika layanan Anda sama untuk bagian lain dari sistem. Hal ini terjadi jika kriteria evaluasi tidak konsisten: misalnya, Anda merespons permintaan dalam satu detik dan menganggapnya berhasil, namun layanan dependen hanya menunggu 500 waktu Moskow dan keluar dengan kesalahan.
Dalam kasus ini, kita akan membahas pentingnya menyelaraskan metrik dan belajar melihat kualitas dari sudut pandang klien.
Solusi untuk kasus 3: masalah dengan database.
Basis data juga bisa menjadi sumber masalah. Misalnya, jika Anda tidak memantau relai replikasi, replika akan menjadi usang dan aplikasi akan mengembalikan data lama. Selain itu, men-debug kasus seperti itu sangatlah sulit: sekarang datanya tidak konsisten, tetapi setelah beberapa detik tidak lagi konsisten, dan tidak jelas apa penyebab masalahnya.
Melalui kasus ini, Anda akan merasakan semua kesulitan dalam melakukan debugging dan belajar bagaimana mencegah masalah tersebut.
Praktik: Kami menulis postmortem mengenai kasus sebelumnya dan mendiskusikannya dengan para pembicara.
HARI 5: Sesi AMA, pertanyaan terjawab
Sesi AMA dan jawaban atas pertanyaan tentang topik sebelumnya.
Akses ke modul teori ke-3 terbuka:
Pelindung lalu lintas dan pelepasan burung kenari
Pada modul ketiga kita akan menganalisis kasus yang didedikasikan untuk masalah lingkungan (akan ada analisis rinci tentang Kesehatan Checking), dan kami juga akan menganalisis langkah demi langkah bagaimana penerapan SRE di perusahaan dan mempelajari pengalaman perusahaan tempat pembicara bekerja. intensif
Topik 5: Pemeriksaan Kesehatan
- Pemeriksaan Kesehatan di Kubernetes
- Apakah layanan kami masih hidup?
- Probe eksekutif
- Penundaan AwalDetik
- Pelabuhan Kesehatan Sekunder
- Server Kesehatan Sidecar
- Penyelidikan Tanpa Kepala
- Pemeriksaan Perangkat Keras
Topik 6: Metode penerapan
Topik 7: Orientasi proyek SRE
Perusahaan besar sering kali membentuk tim SRE terpisah, yang mengambil layanan dari departemen lain untuk mendapatkan dukungan. Namun tidak semua layanan siap menerima dukungan. Kami akan memberi tahu Anda persyaratan apa yang harus dipenuhi. Para pembicara juga akan berbagi pengalamannya, bagaimana mereka menerapkan SRE dan kesalahan apa saja yang mereka lakukan.
HARI 6: analisis praktik dan kasus
Solusi kasus 4: ada masalah lingkungan, tidak mungkin membeli tiket.
Tugas Healthcheck adalah mendeteksi layanan yang rusak dan memblokir lalu lintas ke layanan tersebut. Dan jika Anda berpikir bahwa untuk ini cukup membuat permintaan ke layanan dengan root dan menerima tanggapan, maka Anda Anda salah: meskipun layanan merespons, ini tidak menjamin pengoperasiannya - masalah mungkin timbul lingkungan.
Melalui kasus ini, Anda akan mempelajari cara mengonfigurasi Healthcheck yang benar dan tidak mengizinkan lalu lintas menuju ke tempat yang tidak dapat diproses.
Meringkas