Tim kami menyukai eksperimen. Setiap Slurm bukanlah pengulangan statis dari Slurm sebelumnya, melainkan refleksi pengalaman dan transisi dari baik ke lebih baik. Tetapi dengan kami memutuskan untuk menerapkan format yang benar-benar baru - untuk memberikan kondisi yang sedekat mungkin dengan "pertempuran" kepada para peserta.
Jika kita uraikan secara singkat apa yang kami lakukan selama kursus intensif: “Kami membangun, kami menghancurkan, kami memperbaiki,
kami sedang belajar." SRE hanya bernilai sedikit dalam teori - hanya praktik, solusi nyata, masalah nyata.
Para peserta dibagi menjadi beberapa tim sehingga semangat kompetitif yang kuat tidak membuat siapa pun tertidur atau meluncurkan “Angry Birds” di iPhone, mengikuti contoh Dmitry Anatolyevich.
Permasalahan, glitch, bug dan tugas diberikan kepada peserta oleh empat orang mentor. Ivan Kruglov, Pengembang Utama di Booking.com (Belanda). Ben Tyler, Pengembang Utama di Booking.com (AS). Eduard Medvedev, CTO di Tungsten Labs (Jerman). Evgeniy Varavva, pengembang umum di Google (San Francisco).
Apalagi para peserta dibagi menjadi beberapa tim dan saling bersaing. Menarik?
Ivan, Ben, Eduard dan Evgeniy melihat para peserta Slurm SRE yang malang dengan pandangan mata Leninis yang baik hati sebelum kompetisi dimulai.
Jadi tugasnya:
Kita adalah milik kita, kita akan membangun dunia baru...
Ada situs web agregator tiket film. Insiden diciptakan oleh mentor sesuai dengan skenario yang telah dikerjakan sebelumnya (walaupun tidak ada yang mengecualikan improvisasi yang sangat canggih dan berbahaya), kinerja situs dijelaskan oleh berbagai metrik. Masalahnya bisa sangat berbeda: tiket teater Moulin Rouge tidak dimasukkan ke dalam database; poster film dan pertunjukan dimuat ke database dalam waktu lebih dari 10 detik; deskripsi sebuah film terhenti; 0,1% pesanan sudah dipesan; Dari waktu ke waktu sistem pemrosesan pembayaran terhenti selama satu atau dua menit. Dan masih banyak lagi hal-hal tidak menyenangkan yang bisa menimpa seorang peserta Slurm SRE di pekerjaannya yang sebenarnya.
Kami siap menangani apa pun...dan semua orang.
Situs web kami yang sudah lama menderita terdiri dari beberapa layanan mikro. Tugasnya adalah mengumpulkan data tentang pertunjukan, harga, dan kursi yang tersedia dari semua bioskop; ini menampilkan pengumuman film, memungkinkan Anda memilih bioskop, pertunjukan, aula dan tempat, memesan dan membayar tiket. Secara umum, segala sesuatu yang hanya bisa diimpikan oleh pemirsa. Namun pengguna bahkan tidak curiga betapa besar perjuangan yang terjadi di dalamnya untuk stabilitas dan aksesibilitas situs.
Untuk situs intensif, kami membuat indikator SLO, SLI, SLA, mengembangkan arsitektur dan infrastruktur, menerapkan situs, menyiapkan pemantauan dan peringatan. Dan kita berangkat.
SLO, SLI, SLA
SLI - indikator tingkat layanan. SLO adalah sasaran tingkat layanan. SLA - perjanjian tingkat layanan.
SLA adalah istilah metodologi ITIL yang menunjukkan perjanjian formal antara pelanggan layanan dan pemasoknya, yang berisi deskripsi layanan, hak dan kewajiban para pihak dan, yang paling penting, tingkat kualitas yang disepakati untuk penyediaan layanan ini. melayani.
SLO adalah tujuan tingkat layanan: nilai target atau rentang nilai untuk tingkat layanan yang diukur dengan SLI. Nilai normal SLO adalah “SLI ≤ Target” atau “Batas Bawah ≤ SLI ≤ Batas Atas”.
SLI adalah indikator tingkat layanan—ukuran kuantitatif yang didefinisikan secara cermat mengenai satu aspek tingkat layanan yang diberikan. Untuk sebagian besar layanan, SLI utama dianggap sebagai latensi permintaan - berapa lama waktu yang diperlukan untuk mengembalikan respons terhadap permintaan. SLI umum lainnya mencakup tingkat kesalahan, sering kali dinyatakan sebagai sebagian kecil dari semua permintaan yang diterima, dan throughput sistem, biasanya diukur dalam permintaan per detik.
Pertama-tama, kita akan menghancurkan pesawatnya, lalu gadis-gadis itu, dan kemudian gadis-gadis itu...
Faktor internal dan eksternal mulai “merusak” SLO sejak menit pertama. Segalanya menjadi tanggung jawab administrator—kesalahan pengembang, kegagalan infrastruktur, masuknya pengunjung, dan serangan DDoS. Segala sesuatu yang memperburuk SLO.
“- Para peserta yang terhormat, saya segera menyenangkan Anda, hal pertama yang Anda gagal adalah... semuanya!”
Dalam perjalanannya, para pembicara membahas tentang stabilitas, error budget, praktik pengujian, manajemen interupsi dan beban operasional.
Kami bukan tukang api, bukan tukang kayu...
Kemudian para peserta mulai membenahi keadaan – yang utama adalah memahami apa yang harus diambil terlebih dahulu.
“- Tuhan, aku belum pernah melihatnya pecah seperti ini, dalam bentuk dan posisi seperti ini!”
Jadi, terjadi kecelakaan. Layanan pemrosesan pembayaran sedang down. Bagaimana cara bertindak untuk memulihkan fungsionalitas dalam waktu sesingkat mungkin?
Para ahli sambil menatap penuh kasih sayang kepada para peserta sedang mempersiapkan trik lain.
Setiap tim mengatur kerja kelompok untuk menghilangkan kecelakaan - melibatkan rekan kerja, memberi tahu pihak yang berkepentingan (stakeholder). Pada saat yang sama, prioritas ditetapkan. Dengan cara ini, para peserta dilatih untuk bekerja di bawah tekanan dalam kondisi waktu yang sangat terbatas.
“Kengerian macam apa yang muncul?!”
Buang napas... dan selesaikan latihannya
Bersama para pembicara, setelah setiap masalah terselesaikan dan lokasi distabilkan untuk sementara, tim mempelajari insiden tersebut dari sudut pandang SRE. Kami menganalisis masalah secara rinci - penyebab terjadinya, kemajuan eliminasi. Setelah itu, baik tim demi tim maupun secara kolektif, kami mengambil keputusan tentang cara mencegahnya lebih lanjut: cara meningkatkan pemantauan, cara mengubah arsitektur secara bijaksana, cara menyesuaikan pendekatan terhadap pengembangan dan pengoperasian, cara memperbaiki peraturan. Para pembicara mendemonstrasikan praktik melakukan visum.
“Siapa lagi yang menginginkan siksaan! - SAYA!"
Keberhasilan tim dicatat secara ketat dan jelas di papan skor elektronik.
Untuk tempat pertama - bonus dari pemangku kepentingan.
Sumber: www.habr.com