Perintah dan konteks
Selama insiden produksi, engineer on-call menginginkan respons tingkat keparahan tinggi sementara product owner melihat dampaknya terbatas. Anda tidak memiliki data yang lengkap, namun menunda eskalasi dapat memperluas radius dampak (blast radius). Jelaskan bagaimana Anda melangkah maju, mengomunikasikan dampak kepada pengguna, dan meningkatkan proses penentuan tingkat keparahan setelahnya.
Hal yang diuji oleh pewawancara
- Melindungi pengguna di tengah ketidakpastian sebelum membahas kesalahan atau kepemilikan masalah.
- Mengganti jabatan atau dominasi suara dengan sinyal yang dapat diamati dan ambang batas eskalasi.
- Mengubah perbedaan pendapat menjadi catatan, tindakan nyata, dan perbaikan proses.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Dampak, pengguna, dan jalur kritis (critical paths) mana saja yang terkonfirmasi saat ini?
- Apa yang dinyatakan oleh aturan tingkat keparahan, wewenang on-call, dan waktu eskalasi saat ini?
- Apakah ada metrik yang tertunda, celah observabilitas (observability gaps), atau sinyal bisnis yang perlu diverifikasi?
Jawaban 30 detik
Saya akan menempatkan fakta yang diketahui, hal-hal yang belum diketahui, dan risiko terburuk dalam satu linimasa, lalu mengusulkan tindakan perlindungan singkat yang dibatasi waktu (time-boxed) serta ambang batas eskalasi. Jika risiko terhadap pengguna atau rollback tinggi, saya akan memulai respons tingkat keparahan yang lebih tinggi dan mencatatnya sebagai keputusan perlindungan yang dapat dibatalkan (reversible). Saya akan menunjuk seorang koordinator, menetapkan ritme pembaruan status, dan menyimpan log keputusan. Setelah pemulihan, tinjauan tanpa menyalahkan (blameless review) akan memeriksa sinyal, aturan keparahan, dan penyelesaian tindakan, alih-alih melimpahkan perselisihan tersebut kepada individu tertentu.
Pembahasan mendalam langkah demi langkah
1. Menetapkan fakta bersama
Buat daftar peringatan (alerts), proses deploy, tingkat kesalahan (error rates), laporan pengguna, dan tindakan yang diambil beserta penanda waktunya (timestamps). Pisahkan hasil observasi secara jelas dari hipotesis. Jangan memperlakukan "tampaknya parah" sebagai bukti, tetapi jangan pula menunggu data yang sempurna sebelum melindungi pengguna.
2. Mengambil keputusan risiko sementara
Tulis kondisi eskalasi sebagai sinyal yang dapat diamati: kesalahan yang berlanjut pada jalur kritis, bertambahnya tenant yang terdampak, integritas data yang tidak pasti, atau jendela waktu rollback yang makin sempit. Saat terjadi perselisihan, mulailah pada tingkat yang lebih tinggi jika diperlukan, tetapkan titik tinjauan sepuluh menit atau lebih cepat, dan buat ketentuan penurunan tingkat keparahan (downgrade) secara eksplisit.
3. Memperjelas peran dan ritme pembaruan
Tentukan seorang incident lead, technical owner, scribe (pencatat), dan penanggung jawab komunikasi. Arahkan pembaruan lainnya ke satu saluran atau tiket dan publikasikan status internal secara berkala dengan ritme tetap. Pembaruan eksternal harus menyatakan dampak yang terkonfirmasi, mitigasi yang dilakukan, dan waktu pembaruan berikutnya, bukan tebakan tentang akar masalah (root cause).
4. Menawarkan opsi yang sebanding kepada tim produk
Jelaskan biaya eskalasi, risiko menunggu, dan pemicu untuk mengubah arah alih-alih memperdebatkan siapa yang lebih memahami insiden. Pilihan yang dapat diambil mencakup menunda rilis yang berisiko, beralih ke mode read-only, atau melakukan rollback, masing-masing dengan penanggung jawab dan tenggat waktu.
5. Mencatat perbedaan pendapat saat bertindak
Log keputusan mencatat bukti, perbedaan pendapat, tindakan yang dipilih, dan waktu peninjauan kembali. Hal ini memungkinkan sesi retrospektif untuk menguji kualitas keputusan alih-alih menggunakan hasil akhir untuk menentukan siapa yang benar. Risiko baru harus memiliki jalur langsung untuk dievaluasi ulang.
6. Menjalankan tinjauan tanpa menyalahkan (Blameless review)
Panduan tinjauan insiden dari GitLab berfokus pada pemahaman sistem, alasan/cara pengambilan keputusan, dan tindakan pencegahan. Sertakan linimasa, faktor-faktor yang berkontribusi, celah deteksi, komunikasi pengguna, dan rencana tindakan (action items). Mengatakan "seseorang seharusnya lebih berhati-hati" bukanlah bentuk perbaikan proses.
7. Membuat perbaikan yang dapat diverifikasi
Berikan pemilik, tenggat waktu, dan metrik penilaian untuk matriks tingkat keparahan, pemantauan, simulasi (drills), atau runbook. Simulasi berikutnya harus mereproduksi perselisihan tersebut dan memverifikasi bahwa ambang batas, izin, dan templat komunikasi benar-benar mengurangi keterlambatan alih-alih hanya menambah jumlah halaman pada sebuah dokumen.
Contoh jawaban model
Saya akan menempatkan dampak yang terkonfirmasi, ketidaktahuan, dan risiko terburuk pada sebuah linimasa serta mengusulkan tindakan perlindungan singkat dengan batasan waktu. Jika jalur kritis atau integritas data terancam, saya akan memulai respons keparahan yang lebih tinggi, menetapkannya sebagai keputusan yang dapat dibatalkan, dan meninjaunya kembali dalam sepuluh menit menggunakan tingkat kesalahan, cakupan pengguna, dan progres rollback. Saya akan membagi peran koordinasi, teknis, pencatatan, dan komunikasi serta mempublikasikan pembaruan faktual. Setelah pemulihan, tinjauan tanpa menyalahkan akan memeriksa peringatan, aturan keparahan, dan komunikasi, lalu menetapkan penanggung jawab serta metrik verifikasi untuk setiap perbaikan.
Kesalahan umum
- Menunggu kelengkapan data sehingga melewatkan jendela waktu perlindungan.
- Menggunakan senioritas untuk mengesampingkan rekan kerja tanpa adanya sinyal yang dapat ditinjau.
- Mengubah saluran insiden menjadi ajang tebak-tebakan akar masalah dan saling menyalahkan.
- Menulis "tingkatkan pemantauan" tanpa penanggung jawab, tanggal, atau metrik penerimaan.
- Memperlakukan hasil akhir sebagai satu-satunya bukti kualitas keputusan.
Pertanyaan lanjutan dan responsnya
Bagaimana jika eskalasi memicu on-call lintas tim yang berbiaya mahal?
Bandingkan biaya tersebut dengan risiko kerugian akibat menunggu, lalu gunakan batasan waktu singkat dengan kriteria penurunan tingkat keparahan yang eksplisit. Eskalasi perlindungan bersifat reversible jika jalur peninjauan dan keluarnya terlihat jelas.
Bagaimana jika product owner bersikeras pada tingkat keparahan rendah?
Minta mereka mengonfirmasi asumsi dampak tersebut, lalu catat sinyal risiko, mitigasi, dan ambang batasnya. Ikuti jalur eskalasi resmi untuk risiko keselamatan, integritas data, atau kepatuhan, serta beri tahu pemilik terkait.
Bagaimana jika sinyal pemantauan saling bertentangan?
Tandai adanya masalah kualitas data, gunakan asumsi dampak pengguna yang konservatif (paling aman), ambil tindakan perlindungan berisiko rendah, dan tugaskan tim untuk memverifikasi log, sampel pengguna, dan dependensi. Jangan menyembunyikan bukti yang bertentangan.
Bagaimana cara menjaga budaya tanpa menyalahkan agar tidak menjadi alasan hilangnya akuntabilitas?
Budaya tanpa menyalahkan (blamelessness) berfokus pada pembelajaran dan faktor-faktor sistem, bukan ketiadaan rasa tanggung jawab. Setiap tindakan memiliki penanggung jawab, tenggat waktu, dan verifikasi; pengabaian berulang terhadap risiko yang diketahui akan mengikuti tata kelola normal.
Kapan tinjauan insiden harus dipublikasikan?
Gunakan dampak pengguna, kontrak, dan kebijakan untuk memutuskannya. Ringkasan publik harus mencakup dampak, linimasa, perbaikan, dan pencegahan, sekaligus menghapus data pribadi yang tidak perlu serta spekulasi yang belum diverifikasi.
Bagaimana cara membuktikan bahwa pendekatan ini berhasil?
Lacak keterlambatan eskalasi, tingkat eskalasi palsu, ketepatan waktu pembaruan pengguna, penyelesaian tindakan, dan hasil simulasi di berbagai insiden atau latihan. Satu contoh keberhasilan saja bukanlah bukti yang cukup.