CapordiaJelaskan dampak sebelum mengusulkan penyebab
Berikan satu kalimat yang dapat diamati: sejumlah pekerjaan tidak lagi menghasilkan keluaran, akses yang diizinkan ditolak, atau ekspor tidak dapat dibaca lagi. Sebutkan cakupan yang terdampak dan apa yang masih berfungsi. "Server rusak" dengan cepat menjadi kesimpulan yang terlalu luas ketika hanya satu jalur keluaran yang gagal. Hitung hasil yang diterima, tidak lengkap, dan tidak diluncurkan dengan kategori yang saling eksklusif.
Tunjuk seorang penanggung jawab koordinasi dan seseorang yang berwenang untuk bertindak. Panduan manajemen insiden Google SRE membedakan koordinasi dari operasi dan komunikasi. Dalam tim kecil, satu orang dapat memegang beberapa peran, tetapi setiap orang harus tahu siapa yang memutuskan. Tetapkan titik informasi berikutnya secara internal; organisasi ini tidak menciptakan jaminan waktu respons dari penyedia.
Simpan kronologi yang membedakan fakta
Catat situasi terakhir yang diketahui benar, gejala pertama, dan perubahan yang terjadi di antara keduanya. Berikan zona waktu dan sumber setiap waktu: log, pengamatan langsung, atau ingatan yang perlu dikonfirmasi. Tanggal yang disalin ke tangkapan layar belum tentu memiliki acuan yang sama dengan log aplikasi. Jika salah satu batas tidak ada, simpan rentang ketidakpastian daripada mengarang menit yang tepat.
Untuk setiap tindakan, catat pelakunya, cakupannya, tujuannya, dan hasilnya. "Restart telah dilakukan" tidak lengkap tanpa mengetahui proses mana yang terlibat dan apakah gejalanya berubah. Pisahkan observasi, hipotesis, dan keputusan. Pemisahan ini memungkinkan rekonstruksi apa yang benar-benar membantu dan mencegah beberapa orang mencoba solusi yang saling bertentangan secara bersamaan.
Contoh fiktif: ekspor sebagian, bukan kegagalan GPU yang terbukti
Dalam sel fiktif « Cartes du rivage », dua puluh dokumen harus dikirim. Empat belas keluaran telah dibuka dan diterima, empat pekerjaan melaporkan penolakan penulisan, dan dua masih harus dijalankan. Jadi enam hasil belum dapat dikirim, tetapi adalah keliru untuk mengumumkan dua puluh hasil hilang. Tidak ada insiden nyata maupun server Capordia yang dijelaskan oleh contoh ini.
Kronologi di bawah ini mengarah pada permintaan pemeriksaan terarah terhadap jalur keluaran. Kronologi ini belum membuktikan penyebabnya: perubahan yang berdekatan dalam waktu dapat terkait dengan gejala tanpa menjelaskannya. Tim mempertahankan keempat belas keluaran yang diterima dan hanya menangguhkan pengajuan baru yang bersangkutan. Jam-jamnya bersifat fiktif dan berada dalam zona waktu yang sama, dipilih untuk menghindari ambiguitas pembacaan.
| Waktu | Fakta yang dicatat | Penafsiran yang diizinkan |
|---|---|---|
| 9.40 | Keluaran terakhir yang berhasil dibuka | Batas operasi yang diketahui |
| 9.42 | Tujuan keluaran diubah | Perubahan yang perlu diperiksa |
| 9.43 | Penolakan penulisan pertama yang dicatat | Awal gejala yang teramati |
| 9.48 | Pengajuan baru yang bersangkutan ditangguhkan | Langkah pembatasan dampak |
| 10.05 | Penolakan yang sama dengan berkas fiktif kecil | Reproduksi lebih kecil, penyebab masih harus dikonfirmasi |
Memperkecil reproduksi tanpa menghapus cacat
Carilah masukan terkecil yang mempertahankan gejala dan jalur relevan yang sama: jenis berkas, tujuan, identitas teknis, atau pengaturan. Gantilah konten bisnis dengan data sintetis bila memungkinkan. Jika penggantian membuat kesalahan hilang, dokumentasikan batasan tersebut. Jangan menyajikan sebagai reproduksi yang setia sebuah perintah yang disederhanakan yang tidak lagi melewati bagian yang dicurigai.
Lanjutkan dengan hipotesis yang dapat diverifikasi. Bab pemecahan masalah Google SRE merekomendasikan pengujian yang memungkinkan pemisahan penyebab dan mengingatkan bahwa instrumentasi atau pengujian dapat memengaruhi sistem. Karena itu, catatlah hasil negatif sama telitinya dengan keberhasilan. Hindari menjalankan ulang secara berulang suatu pemrosesan yang menerbitkan keluaran atau memperburuk penyimpanan; penanggung jawab terlebih dahulu menetapkan cakupan uji yang diizinkan.
Menyiapkan bukti yang mudah dibaca dan sudah disunting
Berkas serah terima memuat versi yang berguna, prosedur minimal, waktu, pesan kesalahan yang tepat, dan kutipan log di sekitar gejala. Tambahkan pengenal pekerjaan dan referensi berkas yang bersangkutan bila hal itu memudahkan pencocokan. Sisihkan sisa log jika tidak ada yang membutuhkannya untuk memahami situasi. Simpan dokumen asli dalam cakupan tim yang diizinkan.
OWASP mengingatkan bahwa log tidak boleh menampilkan antara lain kata sandi, token akses, atau kunci. Periksa juga jalur, nama berkas, dan argumen yang dapat mengungkap proyek. Gunakan penggantian yang konsisten, seperti PROJET_A, sambil tetap mempertahankan struktur yang diperlukan untuk diagnosis. Bukti yang sudah disunting harus menyatakan apa yang telah dihapus; bukti itu tidak boleh mengubah pesan kesalahan yang menentukan maupun menghilangkan kondisi penting.
Merumuskan permintaan eskalasi yang memungkinkan tindakan
Bukalah permintaan dengan dampak dan pertanyaan yang tepat: memeriksa penolakan akses, mengonfirmasi properti alokasi, atau membantu melokalisasi selisih yang dapat direproduksi. Lampirkan kronologi dan reproduksi yang sudah disunting. Sebutkan tindakan yang sudah dicoba, yang tidak mengubah apa pun, dan operasi yang harus dihindari. Penerima harus dapat mengetahui apa yang diharapkan tanpa menjelajahi berkas tangkapan layar yang tidak diberi keterangan.
Dalam contoh, permintaannya dapat berbunyi: « Jalur keluaran yang baru digunakan menolak penulisan di bawah identitas pemrosesan; mohon periksa hak yang berlaku untuk jalur ini. Empat belas keluaran tetap tervalidasi; empat pekerjaan melaporkan penolakan penulisan, dan penolakan ini telah direproduksi dengan masukan fiktif. » Teks ini tidak menuduh GPU maupun operator. Teks ini memaparkan apa yang diketahui dan membiarkan penyebab tetap terbuka sampai diperiksa.
Memeriksa hasil sebelum menutup
Sebuah kesalahan yang tidak terulang lagi tidak selalu cukup. Verifikasi hasil yang lengkap dengan identitas yang sama, kondisi penentu yang sama, dan tujuan yang ditinjau ulang. Periksa kemudian elemen-elemen yang terdampak: apakah output yang sudah diterima tetap dipertahankan, apakah output parsial terisolasi dengan baik dan pekerjaan yang tersisa teridentifikasi dengan benar? Penanggung jawab hasil harus mengonfirmasi pemulihan yang bermanfaat, secara terpisah dari keberhasilan perintah teknis.
Migrasi adalah perubahan yang terorganisir sebelum pemindahan pekerjaan; insiden dimulai dari penyimpangan yang tidak terduga. Jika penyelesaiannya menuntut pemindahan data atau melanjutkan pemrosesan yang terhenti, gunakan berkas migrasi yang sudah ada untuk operasi tersebut. Kronologi insiden mempertahankan alasan keputusan ini; kronologi tersebut tidak menulis ulang metode peralihan atau catatan batch.
Pertahankan kesimpulan yang dapat digunakan, meskipun penyebabnya masih terbuka
Tutup dengan dampak akhir, hasil verifikasi, penyebab yang terbukti atau masih belum diketahui, dan tindakan yang diputuskan. Sebuah solusi sementara dapat memulihkan hasil tanpa menyelesaikan masalah yang mendasar: nyatakan hal itu dengan jelas dan sebutkan penanggung jawab pemantauannya. Tidak adanya bukti tidak boleh menjadi "tidak ada insiden"; kemiripan dengan kasus lama tidak boleh menjadi penyebab yang pasti.
Peninjauan ulang akhir harus memungkinkan orang lain membedakan apa yang telah diamati, apa yang telah dicoba, dan apa yang masih perlu diverifikasi. Peninjauan ini berfungsi untuk memperbaiki prosedur, kontrol, atau pesan kesalahan, bukan untuk menyusun narasi tanpa ketidakpastian. Tidak ada jumlah tangkapan layar, volume log, atau tingkat urgensi yang dapat menggantikan kualitas penyampaian ini.
Pertanyaan untuk memutuskan
Apakah harus menunggu sampai mengetahui penyebabnya untuk melaporkan insiden?
Tidak. Laporkan dampak yang dapat diverifikasi dan cakupan yang diketahui, lalu pisahkan hipotesis dengan jelas. Kronologi dan reproduksi yang terarah sering kali dapat membantu sebelum penyebabnya terbukti. Sebutkan juga langkah-langkah yang sudah diambil untuk membatasi dampak.
Bisakah saya mengirim semua log saya untuk menghemat waktu?
Siapkan dulu kutipan yang berguna dan tinjau ulang. Log lengkap dapat memuat rahasia dan data proyek tanpa membantu diagnosis. Simpan berkas asli di ruang yang diizinkan dan jelaskan penggantian yang dilakukan pada versi yang dikirim.
Kapan berkas dianggap selesai?
Setelah kontrol atas hasil yang diharapkan dan keputusan yang tegas dari penanggung jawab. Bedakan perbaikan yang terkonfirmasi dari solusi sementara. Penutupan dapat mempertahankan penyebab yang belum diketahui, dengan syarat menyebutkan batasannya, kontrol yang dilakukan, dan tindakan yang masih terbuka.