Perintah dan konteks
Anda menemukan bahwa runbook insiden yang sering digunakan berisi langkah-langkah untuk layanan yang sudah dihapus dan dapat memperparah pemadaman (outage). Jelaskan bagaimana Anda melindungi tim on-call tanpa mengganggu cakupan saat ini, memvalidasi pengganti, mempensiunkan atau menulis ulang runbook, dan membuktikan bahwa peningkatan tersebut telah diadopsi.
Hal yang diuji oleh pewawancara
- Mengurangi risiko tindakan tidak aman sebelum memperdebatkan siapa pemilik dokumentasi tersebut.
- Mengubah "dokumen sudah usang" menjadi rencana migrasi yang dapat direproduksi dan diverifikasi.
- Menggunakan metode STAR untuk menjelaskan dampak, kolaborasi, kompromi (trade-offs), dan metrik tindak lanjut.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Langkah mana yang tidak valid, dan apakah langkah tersebut dapat menghapus data, memperluas lalu lintas, atau menghambat pemulihan?
- Di mana para insinyur on-call sebenarnya membuka runbook tersebut, termasuk tautan tembolok (cached links) dan bot?
- Siapa pemilik dari pengganti tersebut, sandbox apa yang tersedia, dan bagaimana cara kerja rollback darurat?
Jawaban 30 detik
Saya akan menandai risiko tersebut di bagian atas runbook, memberi tahu tim on-call dan pemilik insiden, serta menyediakan jalur sementara yang terverifikasi agar tidak ada yang mengulangi langkah yang tidak valid tersebut. Saya akan menguji penggantinya di sandbox, memperbarui tautan, izin, dan panduan rollback bersama pemilik layanan, lalu memublikasikan dan mendepresiasi versi lama. Adopsi akan diukur melalui akses tautan, keberhasilan latihan (drill), berkurangnya tindakan yang salah, dan tindak lanjut yang diselesaikan, bukan hanya sekadar perubahan dokumentasi yang digabungkan (merged).
Pembahasan mendalam langkah demi langkah
1. Mengisolasi langkah-langkah berbahaya
Identifikasi perintah atau keputusan dengan dampak yang tidak dapat diubah (irreversible). Tambahkan peringatan yang terlihat jelas, nonaktifkan tautan otomatis, atau pindahkan versi lama ke arsip eksplisit sambil tetap mempertahankan jalur sementara yang disetujui oleh pemilik on-call.
2. Merekonstruksi jalur akses yang sebenarnya
Periksa indeks on-call, hasil pencarian, pesan bot, izin, dan bookmark yang tersimpan dalam cache untuk menemukan versi yang benar-benar digunakan oleh para insinyur. Hanya mengedit repositori sumber akan membiarkan tautan yang disalin tetap beredar.
3. Memvalidasi pengganti
Jalankan langkah-langkah baru di sandbox atau jendela berisiko rendah dan catat prasyarat, sinyal, kondisi berhenti (stop conditions), dan rollback. GitLab mendeskripsikan runbook sebagai identifikasi awal dan penanganan rutin, dengan playbook atau jalur eskalasi untuk kasus yang lebih kompleks; batasan dokumen harus sesuai dengan tanggung jawab nyata.
4. Menulis ulang bersama tim pemilik
Minta pemilik layanan, perwakilan on-call, serta peninjau keamanan atau kepatuhan untuk memeriksa perubahan tersebut. Pisahkan fakta, asumsi, dan pemeriksaan terbuka alih-alih menulis ulang perintah kritis dari ingatan. Setiap langkah menyatakan cakupan dan titik masuk eskalasi ketika terjadi kegagalan.
5. Merencanakan publikasi dan masa pensiun
Publikasikan versi baru sebagai kandidat dan berikan tanggal depresiasi serta tautan pengganti pada versi lama. Jika jalur lama dapat menyebabkan bahaya serius, hapus izin eksekusi atau jadikan hanya-baca (read-only) sebelum mengikuti proses perubahan. Pastikan rollback tetap selaras dengan izin deployment dan versi terakhir yang dapat digunakan.
6. Menguji adopsi dengan latihan (drill)
Minta seseorang yang tidak menulis runbook tersebut untuk menyelesaikan latihan. Amati apakah mereka menemukan titik masuk, mengenali prasyarat, dan melakukan eskalasi pada kondisi berhenti. Catat waktu, langkah yang salah, dan pertanyaan alih-alih mengganti penggunaan nyata dengan pengujian mandiri oleh penulis.
7. Menambahkan pemicu pemeliharaan
Tetapkan pemilik, tanggal peninjauan, dan pemicu seperti perubahan topologi, nama peringatan (alert-name), atau izin. Dokumentasi yang usang dapat mengindikasikan bahwa tinjauan perubahan kurang memeriksa dokumentasi; tambahkan ini ke daftar periksa rilis dan tindakan pascainsiden.
Contoh jawaban
Saya akan mengonfirmasi risiko dari langkah yang tidak valid, menambahkan peringatan, memberi tahu tim on-call dan pemilik insiden, serta menyediakan jalur sementara yang telah dikonfirmasi. Saya akan memeriksa tautan yang sebenarnya digunakan orang, menguji penggantinya di sandbox lengkap dengan prasyarat, kondisi berhenti, dan rollback, serta meninjaunya bersama pemilik layanan dan perwakilan on-call. Kemudian saya akan memublikasikan versi baru, mendepresiasi versi lama, dan menjalankan latihan bersama seseorang yang bukan penulisnya. Metrik penerimaan akan mencakup kemudahan menemukan entri, tindakan yang salah, waktu eskalasi, dan penyelesaian migrasi, disertai pemicu pemeliharaan dalam proses perubahan.
Kesalahan umum
- Menghapus runbook lama tanpa jalur pengganti yang aman.
- Mengedit repositori sambil mengabaikan tautan yang tersimpan dalam cache, bot, dan bookmark.
- Menyatakan sukses hanya setelah penulis sendiri yang menyelesaikan latihan.
- Menaruh setiap prosedur kegagalan ke dalam runbook tanpa batasan playbook atau eskalasi.
- Menghitung penggabungan (merge) dokumentasi alih-alih tindakan yang salah dan hasil latihan.
Pertanyaan lanjutan dan tanggapan
Bagaimana jika insiden sudah aktif terjadi?
Minta pemimpin insiden mengonfirmasi jalur sementara dan risikonya, hentikan penyebaran langkah yang tidak valid, dan tambahkan perbaikan dokumentasi ke daftar tindakan insiden. Jangan melakukan penulisan ulang skala besar yang belum teruji di tengah penanganan masalah kritis (firefight).
Bagaimana jika pemilik layanan menyangkal bahwa runbook tersebut usang?
Tunjukkan langkah yang tepat, perubahan terkini, dan bukti kegagalan yang dapat direproduksi, lalu usulkan latihan kecil. Fokuskan diskusi pada risiko pengguna dan kepemilikan pemeliharaan, bukan pada individunya.
Bagaimana jika banyak tim eksternal menggunakan runbook lama?
Pertahankan pengalihan (redirect) yang stabil atau catatan kompatibilitas, beri tahu pengguna, dan tetapkan tenggat waktu migrasi. Batasi izin perintah berisiko tinggi terlebih dahulu, lalu konfirmasikan migrasi tim demi tim.
Kapan Anda harus menghapus versi lama sepenuhnya?
Hanya setelah penggantinya lulus latihan, memiliki pemilik, semua titik masuk penting telah dipindahkan, dan rollback tersedia. Ikuti aturan retensi yang lebih ketat jika diwajibkan oleh standar keamanan atau kepatuhan.
Bagaimana jika pengganti gagal dalam latihan?
Hentikan publikasi, catat prasyarat dan sinyal yang gagal, perbaiki prosedurnya, dan jalankan kembali latihan. Kegagalan adalah bukti bahwa kriteria rilis belum terpenuhi, bukan alasan untuk mencari-cari pembenaran.
Bagaimana Anda menceritakan pengalaman ini dengan metode STAR?
Jelaskan risiko dan tugas yang konkret, lalu langkah-langkah pemberitahuan, validasi, kolaborasi, dan publikasi. Akhiri dengan berkurangnya tindakan yang salah, tingkat kelulusan latihan, atau penyelesaian migrasi ditambah mekanisme pemeliharaan yang Anda tambahkan.