Gangguan sistem jarang datang saat semua orang sedang santai. Biasanya muncul ketika trafik naik, ada deployment yang baru selesai, atau tepat beberapa menit sebelum laporan harian harus dikirim. Di situ runbook troubleshooting terasa bedanya. Bukan sebagai dokumen pajangan, tapi pegangan agar tim tidak mulai dari nol setiap kali alarm berbunyi.
Runbook yang baik membantu operator menjawab tiga hal dengan cepat: apa yang sedang terjadi, pemeriksaan apa yang aman dilakukan lebih dulu, dan kapan masalah harus dieskalasi. Kedengarannya sederhana, tetapi ini sering menentukan apakah insiden selesai dalam 15 menit atau berlarut-larut sampai berganti shift.
Runbook troubleshooting bukan sekadar daftar perintah
Banyak tim punya dokumen berisi command server, query database, atau tautan dashboard. Itu berguna, tapi belum tentu bisa disebut runbook. Saat insiden terjadi, orang butuh konteks. Misalnya, alarm CPU tinggi di aplikasi pembayaran: apakah lonjakan itu normal karena proses settlement? Dashboard mana yang perlu dibuka? Boleh restart pod atau harus cek antrean lebih dulu? Siapa yang harus dihubungi jika transaksi mulai gagal?
Runbook troubleshooting menjawab pertanyaan tersebut dalam urutan yang masuk akal. Dokumen ini mengubah pengetahuan yang biasanya tersimpan di kepala engineer senior menjadi langkah kerja yang bisa dipakai anggota tim lain, termasuk saat mereka sedang on-call pukul dua pagi.
Masalah yang sering terjadi tanpa runbook
Tanpa runbook, respons insiden mudah bergantung pada orang tertentu. Ketika orang itu cuti, pindah tim, atau sedang tidak bisa dihubungi, investigasi ikut tersendat. Tim lalu mencari-cari percakapan lama di Slack, membuka tiket insiden terdahulu, atau mencoba tindakan yang belum tentu aman.
- Diagnosis awal berbeda-beda antaroperator sehingga waktu pemulihan sulit konsisten.
- Tindakan cepat seperti restart dilakukan terlalu dini dan bukti penting dari insiden hilang.
- Eskalasi terlambat karena tidak jelas batas kapan operator harus meminta bantuan.
- Shift berikutnya menerima konteks setengah jadi dan harus mengulang pemeriksaan.
- Masalah berulang ditangani dengan cara yang sama, tetapi tidak pernah didokumentasikan.
Yang paling melelahkan biasanya bukan insidennya sendiri, melainkan kebingungan di menit-menit pertama. Runbook yang ringkas dan tepat sasaran membantu memangkas fase itu.
Isi runbook yang benar-benar berguna saat insiden
Fokusnya bukan membuat dokumen tebal. Fokusnya membuat langkah awal dapat dijalankan dengan aman oleh orang yang sedang bertugas. Untuk satu jenis alert, satu runbook idealnya menjelaskan hal-hal berikut.
- Gejala dan dampak. Jelaskan arti alert dalam bahasa operasional. Contoh: error rate API naik di atas 5% selama lima menit, yang berpotensi membuat pengguna gagal checkout.
- Pemeriksaan awal. Tulis dashboard, log, metrik, atau query yang perlu dilihat terlebih dahulu. Sertakan apa yang dianggap normal dan apa yang perlu dicurigai.
- Hipotesis umum. Tidak perlu memaksakan semua kemungkinan. Cukup penyebab yang paling sering: database connection pool penuh, dependency timeout, disk hampir penuh, atau deployment bermasalah.
- Tindakan mitigasi yang aman. Misalnya scale out worker, aktifkan mode read-only, rollback rilis tertentu, atau flush antrean dengan syarat yang jelas. Cantumkan risiko tindakan tersebut.
- Kriteria eskalasi. Contoh: eskalasi ke tim database jika latency query tetap tinggi setelah connection pool diperiksa, atau ke developer jika error baru muncul setelah versi tertentu dirilis.
- Informasi handover. Format singkat untuk mencatat waktu kejadian, dampak, langkah yang sudah dicoba, hasilnya, dan pemilik tindak lanjut.
Catatan kecil yang sering menyelamatkan waktu: jangan hanya menulis command. Tulis juga tujuan command itu dan bentuk output yang perlu diperhatikan. Orang yang sedang panik jauh lebih terbantu oleh kalimat “cek apakah consumer lag bertambah terus” daripada sekadar baris perintah tanpa konteks.
Contoh sederhana dari kasus antrean yang menumpuk
Bayangkan alert menunjukkan antrean pemrosesan pesanan mulai menumpuk. Operator baru mungkin langsung tergoda me-restart worker. Padahal restart bisa memperparah keadaan jika worker sebenarnya sedang menunggu database yang lambat.
Runbook yang baik bisa mengarahkan urutannya: cek consumer lag, lihat jumlah worker aktif, periksa error log dalam 15 menit terakhir, lalu cek latency database dan status dependency pembayaran. Jika worker sehat tetapi query database melambat, jalur eskalasinya jelas. Jika worker mati karena deployment gagal, rollback mungkin menjadi mitigasi yang lebih tepat.
Urutan ini penting karena troubleshooting bukan lomba mengetik command. Tujuannya mengurangi dampak tanpa menciptakan masalah baru.
Runbook juga memperbaiki kerja shift dan proses on-call
Tim operasional bekerja dengan konteks yang mudah putus: ada pergantian shift, rotasi on-call, dan perubahan sistem yang cukup cepat. Runbook menjadi titik temu yang lebih stabil daripada ingatan personal atau chat lama.
Bagi engineer baru, runbook memberi jalur belajar yang praktis. Mereka bisa memahami pola gangguan nyata tanpa harus menunggu senior online. Bagi engineer senior, dokumen ini mengurangi pertanyaan berulang dan membuat pengetahuan operasional tidak berhenti di satu orang.
Namun, runbook bukan pengganti keputusan teknis. Ada insiden yang memang tidak cocok dengan pola lama. Dalam kondisi seperti itu, runbook tetap berguna sebagai titik awal: apa yang sudah diketahui, pemeriksaan mana yang aman, dan siapa yang punya konteks sistem.
Cara menjaga runbook tetap hidup
Masalah utama runbook biasanya bukan tidak ada, melainkan sudah tidak relevan. Nama dashboard berubah, command lama tidak lagi berlaku, atau arsitektur sudah pindah tetapi dokumentasinya tertinggal. Runbook usang bisa lebih berbahaya daripada tidak punya dokumen sama sekali karena memberi rasa aman palsu.
- Perbarui runbook setiap selesai insiden yang menghasilkan temuan baru.
- Jadikan perubahan runbook bagian dari definisi selesai untuk perubahan sistem yang berdampak operasional.
- Pasang pemilik dokumen, tetapi tetap buka kontribusi dari operator dan developer.
- Uji langkah penting secara berkala, terutama rollback, failover, dan prosedur akses darurat.
- Buang langkah yang tidak lagi dipakai; dokumen pendek yang akurat lebih berguna daripada dokumen lengkap tetapi basi.
Saya cenderung lebih percaya runbook yang dipakai dan diperbaiki setelah insiden daripada dokumen yang terlihat rapi tetapi tidak pernah disentuh. Bekas catatan lapangan sering justru menyimpan detail yang paling berguna.
Penutup
Runbook troubleshooting membantu tim operasional IT merespons gangguan dengan lebih tenang, konsisten, dan aman. Nilainya bukan pada banyaknya halaman, melainkan pada kemampuannya memandu orang mengambil langkah yang tepat ketika informasi belum lengkap dan waktu terus berjalan.
Mulailah dari alert yang paling sering muncul atau layanan yang paling kritis. Tulis pemeriksaan awal, mitigasi aman, dan jalur eskalasinya. Setelah itu, rawat dokumennya dari setiap insiden. Sedikit demi sedikit, runbook akan berubah dari dokumentasi biasa menjadi bagian penting dari ketahanan operasional tim.
