Selamat malam semuanya!
Intensitas peluncuran kami bervariasi dari bulan ke bulan. Sebelum siswa September menyelesaikan bulan kedua kursus
"Devops - Praktik dan Alat" , kami membuka aliran berikutnya. Jadi kami siap lagi untuk membagikan materi yang bermanfaat tentang topik ini dengan Anda dan menunggu
pelajaran terbuka yang tidak kalah bermanfaat.
Hari ini kita akan melihat bagian pertama artikel tentang bagaimana dokumentasi memungkinkan tim SRE untuk mengelola layanan baru dan yang sudah ada.
SRE (rekayasa keandalan situs, secara kasar diterjemahkan sebagai “memastikan keandalan sistem informasi”, spesialis di bidang ini memiliki singkatan yang sama) - disiplin khusus, pemikiran, dan serangkaian pendekatan teknis yang bertujuan memastikan kelancaran pengoperasian produk dan layanan web. SRE berada di persimpangan pengembangan perangkat lunak dan rekayasa sistem, menyelesaikan masalah operasional, dan mengembangkan solusi yang dapat diukur, andal, dan efisien untuk desain, pembuatan, dan pengoperasian sistem terdistribusi skala besar.
Tujuan utama SRE:
- Pemantauan dan pengumpulan metrik - menentukan perilaku layanan yang diinginkan, mempelajari perilaku layanan yang sebenarnya, dan menghilangkan perbedaan.
- Respons insiden - deteksi dan respons efektif terhadap kegagalan layanan untuk menjaga ketersediaan layanan sesuai dengan SLA (perjanjian tingkat layanan).
- Perencanaan kapasitas - memperkirakan permintaan di masa depan dan menyediakan sumber daya komputasi dalam jumlah yang diperlukan di lokasi yang sesuai untuk memenuhi permintaan ini.
- Penskalaan layanan - penyebaran yang dapat diprediksi dan penghilangan daya komputasi suatu layanan di pusat data, seringkali sebagai akibat dari perencanaan kapasitas.
- Ubah manajemen - mengubah perilaku layanan tanpa kehilangan keandalannya.
- Kinerja - desain, pengembangan, dan rekayasa yang terkait dengan penskalaan, isolasi, latensi, throughput, dan efisiensi.
Fokus SRE adalah pada siklus hidup layanan: dari ide dan desain hingga penyebaran, operasi, peningkatan kinerja, dan, pada akhirnya, penonaktifan.
Sebelum meluncurkan layanan SRE, mereka mendukungnya dengan berkonsultasi di bidang arsitektur sistem, mengembangkan platform perangkat lunak, kerangka kerja dan rencana kapasitas, dan melakukan tinjauan peluncuran.
Ketika layanan sudah berjalan, SRE mendukungnya sebagai berikut:
- Mereka mengukur dan memantau ketersediaan, latensi, dan kondisi keseluruhan sistem.
- Periksa perubahan sistem yang direncanakan.
- Mereka mengukur stabilitas sistem menggunakan beberapa mekanisme, misalnya, otomatisasi.
- Perbaiki sistem dengan mempromosikan perubahan yang bertujuan untuk meningkatkan keandalan dan kecepatan.
- Melakukan respons insiden dan post-mortem “tidak bersalah”.
Ketika kehidupan layanan akan berakhir, SRE akan menonaktifkannya dengan cara yang dapat diprediksi dengan penjelasan yang jelas dan dokumentasi lengkap.
Tim SRE yang matang selalu memiliki dokumentasi lengkap untuk setiap fungsi SRE. Jika Anda mengelola tim SRE atau berencana untuk mengaturnya, artikel ini akan membantu Anda memahami jenis dokumentasi yang dibutuhkan tim Anda, yang akan membantu Anda merencanakan dan memprioritaskan pekerjaan pada dokumentasi secara paralel dengan tugas-tugas lain dari tim.
Sejarah SRE
Sebelum membahas nuansa dokumentasi SRE, mari kita lihat satu hari dalam kehidupan Zoe, SRE yang baru dibuat.
Pergeseran kedua Zoe dalam peran SRE sedang berlangsung di proyek utama AcmeSale di Acme Inc. Sementara dia hanya beradaptasi dengan tim, dia mengamati pekerjaan rekan-rekannya dan membuat catatan. Tapi sekarang dia masih memiliki pager.
Seperti keberuntungan, pager menelepon jam 2:30 pagi. Pesan itu mengatakan "Ayub Ragnarok bersandar", Zoe tidak tahu apa artinya itu. Dia membuka-buka catatannya dan menemukan tautan ke halaman dasbor utama. Semuanya terlihat baik-baik saja. Dia mencoba menemukan beberapa dokumen yang mereferensikan Ragnarok di intranet Acme, dan setelah beberapa menit yang berharga dia menemukan dokumen yang sudah ketinggalan zaman pada arsitektur layanan, yang ternyata menjadi ketergantungan kritis untuk AcmeSale.
Untungnya, ada tautan ke halaman “Ragnarok Ops” di disko, yang menemukan tautan ke dasbor dengan grafik yang bermanfaat. Halaman itu juga menyebutkan skrip ragtool, mungkin bisa membantu menyelesaikan masalah, tetapi Zoe mendengarnya untuk pertama kali. Karena itu, ia mengirimkan permintaan bantuan pager ke SRE lain dengan pengalaman bertahun-tahun dalam layanan dan alat ini. Sayangnya, tidak ada jawaban. Zoe memeriksa surat dan melihat pesan bahwa rekannya sedang offline selama satu jam karena masalah kesehatan. Setelah mempertimbangkan semua pro dan kontra, dia memanggil techlie-nya, tetapi panggilan masuk ke voicemail. Semuanya menunjukkan bahwa Anda harus menyelesaikan masalah ini sendiri.
Setelah menghabiskan waktu mencari informasi tentang skrip ragtool misterius, ia menemukan dokumen dengan deskripsi singkat tentang parameter baris perintahnya, serta di mana ia dapat ditemukan. Dia meluncurkan ragtool — mulai kembali dan menyilangkan jari-jarinya dengan harapan. Tidak ada yang berubah, lalu lintas turun lebih banyak lagi. Dia putus asa melihat sisa opsi baris perintah, tetapi tidak yakin bahwa mereka tidak akan lebih berbahaya. Akhirnya, ia memutuskan untuk menggunakan ragtool –rebalance e - dc = atlanta, karena jelas dari grafik bahwa masalahnya terutama terlihat di pusat data Atlanta. Grafik lalu lintas mulai perlahan merayap naik, dan Zoe bersukacita karena kemenangan. MTTR (berarti waktu untuk memperbaiki) adalah 45 menit.
Keesokan harinya, Zoe melakukan diskusi post-mortem tentang insiden tersebut. Ini karena masalahnya ternyata sangat besar dan mengakibatkan hilangnya pendapatan, ditambah manajer meminta lebih banyak sesi post-mortem. Dia bertanya kepada tim bagaimana sisa peserta akan menyelesaikan masalah ini, dan dia mendengar tiga pendekatan berbeda. Ternyata proses pemecahan masalah tunggal tidak ada. Rekan-rekannya juga mengakui bahwa pemberitahuan "bersandar" bukan nama terbaik, dan kegagalan terjadi karena bug yang dikenal yang bukan prioritas.
Akhirnya, Steve, techlid-nya, bertanya: "Versi ragtool apa yang Anda dapatkan?", Dan kemudian mencatat bahwa versi yang digunakan sudah sangat tua. Versi baru dirilis seminggu yang lalu, bersama dengan dokumentasi yang benar-benar baru yang menggambarkan semua fitur dan bahkan menjelaskan bagaimana menyelesaikan masalah "Job Ragnarok bersandar". Versi ini akan mengurangi MTTR hingga lima menit.
Keberadaan versi baru ragtool merupakan kejutan bagi separuh tim, sementara separuh lainnya kurang lebih mengetahui versi dan panduan baru. Versi terbaru skrip terletak di direktori home Steve, jelas di folder / bin. Zoe menambahkan ini ke catatannya untuk digunakan di masa depan, berharap untuk dengan tenang memperbaiki sisa shift. Dia bertanya-tanya apakah techlide atau salah satu tim akan menangani masalah yang dibahas di post-mortem, atau apakah semua SRE masa depan harus melalui pengalaman yang menyakitkan.
Kemudian pada hari itu, Zoe berpartisipasi dalam pertemuan di mana tim SRE berkomunikasi dengan tim pengembangan tentang transfer layanan. Steve memimpin rapat, mengajukan beberapa pertanyaan yang diajukan sebelumnya tentang prosedur operasi dan masalah keandalan layanan saat ini, meminta pengembang untuk melakukan perubahan sebelum tim SRE dapat bertanggung jawab atas layanan tersebut. Zoe telah menghadiri beberapa demonstrasi yang diadakan oleh Steve dan SRE senior lainnya. Dia mengerti bahwa pertanyaan yang diajukan dan tugas yang didistribusikan oleh pengembang sangat berbeda, tergantung pada siapa yang mengadakan pertemuan dan masalah apa yang ditangani tim SRE minggu lalu.
Diam-diam Zoe memimpikan standar dan prosedur yang lebih konsisten, tetapi belum mengerti bagaimana mencapai tujuan ini. Kemudian, dia mendengar dua pengembang menertawakan mesin kopi, bahwa banyak pertanyaan terkait dengan pager secara longgar, dan mereka umumnya tidak mengerti dari mana mereka berasal. Zoe ingin para pengembang memahami bahwa SRE tidak hanya membawa pager bersama mereka. Kembali ke tempat kerja, Zoe menemukan beberapa tiket yang perlu disortir, dan tidak lagi memikirkannya.
Untungnya, semua karakter dan peristiwa dalam cerita ini dibuat-buat. Namun demikian, pikirkan apakah ini mirip dengan sesuatu yang Anda temui dalam kenyataan. Solusi untuk masalah tim fiksi ini sangat jelas, dan di bagian selanjutnya kita akan membahasnya secara lebih rinci.
Pentingnya dokumentasi
Pada tahap awal keberadaan tim SRE, organisasi sangat bergantung pada pekerjaan individu yang sangat berkualifikasi dalam tim. Tim menyimpan konsep dan prinsip-prinsip penting eksploitasi sebagai partikel "pengetahuan kesukuan" yang ditransmisikan secara lisan kepada anggota tim baru. Jika prinsip-prinsip ini tidak disatukan dan tidak didokumentasikan, kemungkinan besar, pada suatu saat prinsip-prinsip itu harus diajarkan dengan menyakitkan lagi melalui coba-coba. Terkadang anggota tim melakukan prosedur operasional sebagai urutan langkah yang ketat yang ditentukan oleh pendahulunya di masa lalu, tanpa memahami hubungan sebab-akibat dari langkah-langkah ini. Jika ini tidak dihentikan, prosesnya menjadi terfragmentasi dan merosot, hanya biaya tim untuk mulai tumbuh untuk memecahkan masalah baru.
Tim SRE dapat mencegah proses ini dengan membuat dokumentasi berkualitas tinggi yang akan berfungsi sebagai fondasi bagi pertumbuhan tim-tim tersebut dan memperkenalkan pendekatan sistematis untuk mengelola layanan baru dan asing. Dokumen-dokumen ini menyimpan pengetahuan suku dalam bentuk yang mudah ditemukan, dipelihara, dan mencarinya. Anggota tim baru dilatih melalui program yang sistematis dan bijaksana. Ini adalah keunggulan dari tim SRE yang matang.
Sisa dari artikel ini menjelaskan berbagai jenis dokumen yang dibuat SRE selama siklus layanan yang didukung.
AKHIR
Pada bagian
selanjutnya, kami akan mempertimbangkan semua jenis ini secara terperinci, tetapi untuk saat ini kami sedang menunggu komentar dan pertanyaan Anda, dan kami juga mengundang Anda ke
pelajaran terbuka .