Menulis Postmortem Insiden yang Tidak Menyalahkan Orang

Setiap tim yang mengelola sistem produksi, cepat atau lambat, akan mengalami insiden. Server down tengah malam, deployment yang ternyata membawa bug, atau integrasi pihak ketiga yang tiba-tiba berubah perilaku. Yang membedakan tim yang membaik dari waktu ke waktu dengan tim yang mengulang kesalahan yang sama bukan seberapa jarang insiden terjadi, tapi apa yang dilakukan setelahnya. Di sinilah postmortem masuk, dan di sinilah juga banyak tim terjebak menulis dokumen yang justru kontraproduktif: dokumen yang, sadar atau tidak, mencari siapa yang salah.

Saya banyak bekerja di sistem yang menyentuh layanan klinis, di mana insiden bisa berarti antrean pasien macet atau data rekam medis telat tersinkron. Tekanan untuk cepat menemukan "siapa yang menyebabkan ini" selalu ada. Tapi dari pengalaman berulang menangani insiden semacam ini, saya semakin yakin bahwa postmortem yang menyalahkan orang justru membuat sistem lebih rapuh, bukan lebih kuat.

Kenapa mencari kambing hitam itu kontraproduktif

Ketika postmortem berujung pada "siapa yang deploy kode itu" atau "siapa yang lupa cek konfigurasi", dua hal buruk terjadi. Pertama, orang yang terlibat jadi defensif, dan detail penting soal apa yang sebenarnya mereka lihat dan pikirkan saat itu jadi tidak terungkap sepenuhnya. Padahal detail itu justru yang paling berharga untuk mencegah insiden serupa.

Kedua, dan ini lebih berbahaya jangka panjang, budaya menyalahkan membuat orang enggan melaporkan anomali kecil atau mengakui kesalahan lebih awal. Kalau setiap kesalahan berujung penilaian personal, insting alaminya adalah menyembunyikan, bukan melaporkan. Sistem yang tidak tahu masalah kecilnya sendiri akan kaget ketika masalah kecil itu menumpuk jadi insiden besar.

Prinsip blameless postmortem bukan berarti tidak ada akuntabilitas. Akuntabilitasnya dipindah: bukan "siapa yang harus disalahkan", tapi "siapa yang bertanggung jawab memperbaiki sistem supaya kelas kesalahan ini tidak mungkin terjadi lagi". Itu pergeseran kecil di kalimat, tapi besar di dampak.

Struktur postmortem yang berguna

Format yang saya pakai relatif sederhana, dan sengaja saya jaga tetap ringan supaya benar-benar ditulis, bukan jadi beban administratif:

• Ringkasan dan dampak. Apa yang terjadi, berapa lama, dan siapa/apa yang terdampak, ditulis netral tanpa opini.
• Linimasa (timeline). Urutan kejadian berdasarkan fakta yang bisa diverifikasi, dari log atau monitoring, bukan ingatan orang.
• Akar masalah. Di sini penting menahan diri berhenti di jawaban pertama. "Query lambat karena index hilang" itu benar, tapi tanya lagi: kenapa index bisa hilang tanpa terdeteksi? Kenapa tidak ada alert sebelum jadi insiden?
• Apa yang berjalan baik. Bagian yang sering dilewatkan. Kalau monitoring berhasil mendeteksi lebih cepat dari biasanya, atau rollback berjalan mulus, itu layak dicatat dan diperkuat.
• Tindak lanjut konkret. Item yang jelas siapa pemiliknya dan bisa dicek statusnya, bukan sekadar "akan lebih hati-hati ke depannya".

Bahasa yang dipakai juga penting. Bandingkan "developer lupa menambahkan validasi" dengan "proses review tidak menangkap kasus tepi ini karena checklist review belum mencakup validasi input eksternal". Kalimat kedua tetap jujur soal apa yang terjadi, tapi mengarahkan solusinya ke proses, bukan ke orang.

Menjaga kebiasaan ini tetap hidup

Di tim kecil, godaan terbesar adalah melewati postmortem sama sekali kalau insidennya "kecil" atau cepat diperbaiki. Menurut saya justru insiden kecil yang paling murah untuk dipelajari, karena belum menimbulkan kepanikan yang mengaburkan detail. Saya biasa menetapkan aturan sederhana: kalau sebuah insiden butuh intervensi manual di luar jam kerja normal, atau berdampak ke pengguna, dia layak dapat postmortem singkat, sekalipun cuma tiga sampai lima paragraf.

Hal lain yang membantu adalah memisahkan sesi "apa yang terjadi" dari sesi "siapa yang mengerjakan perbaikan". Kalau digabung dalam satu rapat, diskusi teknis mudah bercampur dengan nada personal. Memberi jeda, meski cuma sehari, membuat semua pihak bisa melihat kejadian lebih tenang sebagai masalah sistem, bukan sebagai masalah pribadi.

Intinya

Postmortem yang baik bukan soal siapa yang salah, tapi soal membuat sistem, proses, dan tim lebih siap menghadapi kelas masalah yang sama di masa depan. Begitu budaya blameless ini terbentuk, laporan insiden justru jadi lebih jujur dan lebih detail, karena orang tidak lagi takut melapor. Dan pada akhirnya, itulah yang benar-benar mengurangi jumlah insiden dari waktu ke waktu, bukan mencari siapa yang harus dipersalahkan setiap kali sesuatu rusak.