Konteks dan cakupan
Ini adalah pertanyaan perilaku mengenai penilaian dan kolaborasi, bukan permintaan untuk menceritakan kembali detail pemadaman sistem (outage). Jelaskan bagaimana pemicu yang telah disepakati sebelumnya membantu mengevaluasi dampak terhadap pengguna, kualitas respons, risiko keberulangan, dan nilai pembelajaran, kemudian mengubah keputusan tersebut menjadi tinjauan yang bermanfaat dan tanpa saling menyalahkan (blameless). Google SRE merekomendasikan postmortem untuk peristiwa-peristiwa yang tidak diinginkan dan signifikan; pemicu umumnya mencakup penurunan performa yang terlihat oleh pengguna, kehilangan data, intervensi rollback, resolusi yang melampaui ambang batas waktu, dan kegagalan pemantauan (monitoring). Pemangku kepentingan mana pun juga dapat memintanya.
Hal yang dievaluasi oleh pewawancara
- Apakah Anda menerjemahkan “dampak kecil” menjadi metrik yang dapat diamati dan ambang batas yang eksplisit.
- Apakah Anda memisahkan penanganan insiden (containment) dari pembelajaran dan menghindari perlakuan postmortem sebagai ajang saling menyalahkan atau kompetisi menulis.
- Apakah Anda dapat mengusulkan cakupan ringan (lightweight) dan penuh alih-alih sekadar pilihan biner.
- Apakah setiap tindakan memiliki penanggung jawab (owner), tenggat waktu, dan bukti verifikasi.
- Apakah Anda berkomunikasi dengan penuh rasa hormat dan menjadikan hasil pembelajaran berharga bagi tim-tim terkait.
Pertanyaan klarifikasi yang perlu diajukan
- Berapa proporsi permintaan, pengguna, error budget SLO, dan nilai bisnis yang terpengaruh selama 18 menit tersebut?
- Apakah insiden tersebut memerlukan rollback, intervensi manual, luput dari pemantauan, atau mengulang kegagalan serupa sebelumnya?
- Apakah tim sudah memiliki kriteria postmortem, tingkat keparahan (severity), dan pelacakan tindakan perbaikan?
- Siapa yang membutuhkan hasilnya, dan apakah ada keterlibatan privasi, kepatuhan (compliance), atau komunikasi eksternal?
- Apakah diperlukan laporan lengkap, atau apakah tinjauan singkat sudah cukup untuk menjawab pertanyaan-pertanyaan penting?
Jawaban 30 detik
“Saya tidak akan memutuskan hanya berdasarkan 'hanya 18 menit'. Saya akan menerapkan kriteria yang telah disepakati sebelumnya terkait rasio dampak, visibilitas pengguna, error budget, intervensi rollback, kualitas pemantauan, dan risiko keberulangan. Karena pengguna melihat adanya kegagalan dan terjadi rollback, saya setidaknya akan menjalankan tinjauan singkat tanpa saling menyalahkan yang mencakup lini masa, dampak, respons, dan dua atau tiga tindakan bernilai tinggi; bukti yang ditemukan dapat mengembangkannya menjadi laporan lengkap. Setiap tindakan membutuhkan penanggung jawab, tenggat waktu, dan sinyal verifikasi, kemudian dimasukkan ke dalam backlog tim atau proses on-call hingga selesai.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Terapkan standar pemicu
Tempatkan insiden tersebut ke dalam model tingkat keparahan yang ada: dampak pengguna, durasi, konsumsi error budget, integritas data, rollback manual, kegagalan pemantauan, dan respons lintas tim. Tentukan ambang batas sebelum insiden terjadi agar tidak diubah-ubah demi kepentingan tim tertentu setelah kejadian. Delapan belas menit bukanlah sebuah kesimpulan; kegagalan parsial ditambah rollback sudah memenuhi pemicu tinjauan ringan di banyak tim.
Langkah 2: Tentukan kedalaman tinjauan
Postmortem lengkap mencakup lini masa, penilaian dampak, akar penyebab dan faktor pendukung, efektivitas respons, serta tindakan pencegahan. Jika dampaknya kecil dan penyebab tunggalnya dipahami dengan baik, mulailah dengan tinjauan berbatas waktu 30 menit untuk menguji risiko keberulangan, lalu perluas hanya jika bukti mengharuskannya. Ringan berarti lebih sedikit peserta, halaman, dan tindakan, bukan berarti mengabaikan fakta.
Langkah 3: Tetap tanpa menyalahkan dan berlandaskan bukti
Asumsikan setiap orang membuat pilihan yang masuk akal berdasarkan informasi yang tersedia saat itu dan tanyakan bagaimana sistem mempermudah terjadinya kegagalan: pengaman rilis, peringatan (alerts), izin akses, runbook, atau kurangnya konteks. Hindari kesimpulan seperti “seseorang lupa memeriksa” yang tidak dapat memperbaiki sistem. Rujuk log, riwayat perubahan, dan riwayat komunikasi, serta tandai hal-hal yang belum diketahui alih-alih mengisinya dengan tebakan.
Langkah 4: Buat tindakan yang dapat dieksekusi
Cantumkan penanggung jawab, tenggat waktu, prioritas, dependensi, dan bukti penyelesaian untuk setiap tindakan. Contohnya mencakup pemeriksaan kesehatan pra-rilis, simulasi rollback, atau perbaikan ambang batas peringatan. “Lebih berhati-hati” dan “menambah pengujian” bukanlah kriteria penerimaan. Masukkan tindakan ke dalam backlog dan tinjau berdasarkan SLO yang disepakati; Google SRE mencatat bahwa postmortem tanpa tindakan tindak lanjut tidak akan meningkatkan keandalan sistem.
Langkah 5: Selesaikan perbedaan pendapat antar pemangku kepentingan
Jelaskan biaya pelaksanaan tinjauan dan nilai pencegahan keberulangan kepada product manager, serta jelaskan batasan dampak kepada engineer yang meminta laporan panjang. Tawarkan pembatasan waktu (time-box): publikasikan satu halaman fakta dan tindakan terlebih dahulu, lalu perluas jika bukti membenarkannya. Jika ada pemangku kepentingan yang meyakini peristiwa tersebut layak ditinjau, catat alasannya dan sertakan dalam penilaian daripada membiarkan hierarki memvetonya.
Langkah 6: Verifikasi penyelesaian dan batasan pembagian informasi
Setelah dipublikasikan, periksa status tindakan, peringatan yang berulang, rilis serupa, dan tren error budget. Hapus pengenal pengguna dan detail sensitif untuk audiens pembaca sambil tetap membagikan kesimpulan kepada tim yang dapat memanfaatkannya. Tinjauan tidak boleh menjadi ajang mempermalukan orang di depan umum, tetapi pembatasan akses yang berlebihan juga memperbesar kemungkinan terjadinya kegagalan berulang. Simpan bukti dan versi final untuk kebutuhan audit dan pembelajaran di masa mendatang.
Contoh jawaban berkualitas tinggi
“Saya akan menerapkan tingkat keparahan dan pemicu postmortem yang telah ditentukan sebelum insiden terjadi daripada mengambil keputusan hanya berdasarkan durasi 18 menit. Kegagalan yang terlihat oleh pengguna dan intervensi rollback membenarkan dilakukannya setidaknya tinjauan berbatas waktu tanpa saling menyalahkan yang mencakup dampak, lini masa, respons, dan risiko keberulangan. Saya akan merujuk log dan riwayat perubahan, memisahkan akar penyebab dari faktor pendukung, dan hanya memperluasnya menjadi laporan penuh jika pemantauan, pengaman rilis, atau runbook menunjukkan adanya celah sistemik. Setiap tindakan akan mendapatkan penanggung jawab, tenggat waktu, prioritas, dan sinyal verifikasi di dalam backlog. Saya akan menjelaskan biaya dan nilai pencegahan keberulangan kepada product manager, menjaga cakupan tetap terkendali bagi engineer yang meminta laporan panjang, dan membagikan hasil yang telah disunting dari data sensitif kepada tim yang membutuhkannya. Penyelesaian membutuhkan bukti bahwa tindakan telah tuntas dan insiden serupa menurun.”
Kesalahan umum
- Hanya mempertimbangkan durasi sembari mengabaikan rasio pengguna, error budget, rollback, dan kegagalan pemantauan.
- Mengubah postmortem menjadi investigasi untuk mencari kesalahan yang membuat staf on-call menyembunyikan informasi.
- Mendaftar puluhan tindakan hanya demi kelengkapan tanpa penanggung jawab atau bukti penyelesaian.
- Mengganti kriteria penerimaan dengan kalimat seperti “perbanyak pengujian” atau “lebih berhati-hati”.
- Membatalkan tinjauan hanya karena salah satu pemangku kepentingan produk mengatakan itu tidak perlu.
- Menulis dokumen tanpa melacak tindakan perbaikannya atau tanpa memeriksa apakah insiden serupa berkurang.
Pertanyaan lanjutan dan jawabannya
Bagaimana jika tim tidak memiliki standar postmortem bersama?
Paparkan bukti yang ada saat ini: dampak pengguna, error budget, rollback, pemantauan, dan risiko keberulangan. Gunakan insiden ini untuk mengusulkan daftar periksa pemicu minimal dan sepakati versi berikutnya bersama tim. Jangan membuat kebijakan yang rumit di tengah-tengah insiden.
Bagaimana jika tinjauan menemukan bahwa satu orang melakukan kesalahan yang jelas?
Catat informasi dan batasan sistem di balik keputusan tersebut, lalu tanyakan bagaimana proses, alat, atau pelatihan dapat mengurangi kemungkinan terulangnya kesalahan tersebut. Pelanggaran kebijakan yang disengaja atau masalah keselamatan dapat mengikuti proses manajemen terpisah; jaga postmortem tetap bebas dari saling menyalahkan agar tujuan pembelajarannya tetap jelas.
Bagaimana Anda membuktikan bahwa tinjauan singkat sudah memadai?
Tinjauan tersebut harus menjawab dampak, lini masa, respons, hipotesis akar penyebab, dan tindakan, kemudian memeriksa bukti tindakan serta metrik serupa pada waktu yang telah disepakati. Dampak yang belum diketahui, dependensi lintas tim, atau risiko keberulangan harus memperluas cakupannya; panjang laporan yang singkat saja bukan tanda bahwa proses telah selesai.