Postmortem "tanpa menyalahkan" — kenapa sering jadi ritual kosong, dan cara bikinnya berguna

Ide intinya: postmortem bukan rapat mencari siapa yang salah, tapi rapat memperbaiki sistem yang membolehkan kesalahan itu terjadi. Kalau satu orang bisa "menyebabkan" outage sendirian, berarti sistemnya kurang pagar.

Kenapa "blameless" bukan sekadar sopan

Kalau orang takut disalahkan, mereka berhenti jujur. Laporan jadi: "terjadi human error saat deploy". Selesai. Tidak ada yang bisa diperbaiki dari kalimat itu — karena "human error" adalah titik akhir, bukan penjelasan.

Praktik blameless dipopulerkan lewat budaya postmortem Etsy (John Allspaw, ~2012) dan jadi standar di Google SRE Book. Prinsipnya satu: asumsikan semua orang bertindak rasional berdasarkan informasi yang dia punya saat itu. Pertanyaannya bukan "kenapa kamu bodoh", tapi "kenapa sistem membiarkan langkah itu terlihat aman".

Contoh konkret:

Kolom kanan menghasilkan aksi. Kolom kiri menghasilkan dosa.

Struktur yang cukup (jangan bikin 12 halaman)

1. Ringkasan — 3–5 baris. Apa yang rusak, berapa lama, dampak ke user.
2. Timeline — timestamp + kejadian + siapa yang tahu apa. Termasuk: kapan alert bunyi (atau tidak), kapan orang mulai curiga, kapan mitigasi dicoba dan gagal.
3. Dampak — kuantifikasi: user terdampak, request gagal, revenue hilang, data corrupt atau tidak.
4. Akar masalah — bukan satu baris. Biasanya berlapis: pemicu (trigger) vs kondisi yang membolehkan (contributing factors). Trigger-nya bisa sepele; yang menarik justru kenapa sepele itu cukup.
5. Deteksi & respons — berapa menit sampai ketahuan? Lewat apa? Ini sering bagian paling berharga dan paling sering dilewat.
6. Aksi — dengan owner dan tanggal. Ini yang menentukan postmortem hidup atau mati.
7. Pelajaran — apa yang bikin kita lebih paham sistem setelah ini.

Jebakan yang bikin postmortem jadi teater

1. Aksi tanpa owner. "Perbaiki monitoring" bukan aksi. "Tambah alert error rate >2% selama 5 menit, owner: Rian, due 30 Okt" baru aksi.

2. Terlalu banyak aksi. 15 item → nol yang selesai. Pilih 3–5 yang paling mengurangi risiko. Sisanya masuk backlog, jujur saja.

3. Berhenti di root cause tunggal. Sistem nyata punya beberapa faktor. Kalau cuma satu, biasanya analisisnya kurang dalam.

4. Tidak ada review aksi. Postmortem tanpa rapat tindak lanjut 2 minggu kemudian = dokumen mati. Cek: berapa persen aksi postmortem 3 bulan terakhir yang benar-benar selesai? Kalau <50%, masalahnya bukan di postmortem — di prioritas.

5. Counterfactual "seharusnya". Kalimat "seharusnya dicek dulu" tidak menambah apa pun. Ganti dengan "kita bisa bikin langkah cek itu otomatis".

6. Postmortem cuma untuk insiden besar. Bug yang hampir jadi insiden (near miss) justru paling murah dipelajari. Tidak ada korban, tapi pelajarannya sama.

7. Ditulis sendirian oleh yang kena. Postmortem terbaik ditulis bareng — yang nulis kode, yang on-call, yang kena dampak. Sudut pandang berbeda memunculkan faktor yang tidak terlihat dari satu kursi.

Ukuran keberhasilan

Bukan "postmortem-nya lengkap", tapi: - waktu deteksi (MTTD) menurun antar insiden serupa - jumlah insiden berulang dengan penyebab sama menurun - orang melapor near miss tanpa ragu

Satu hal yang bisa langsung dipakai

Di awal rapat postmortem, ucapkan satu kalimat ini secara eksplisit:

"Tujuan rapat ini memperbaiki sistem, bukan menilai orang. Semua keputusan yang diambil saat insiden dianggap wajar berdasarkan informasi yang tersedia saat itu."

Lalu tulis timeline dulu sebelum diskusi penyebab. Timeline faktual mencegah rapat langsung lompat ke debat "siapa". Bonus: template 7 bagian di atas bisa langsung dipakai sebagai issue template di repo.

Takeaway

"Human error" bukan akar masalah — itu tanda analisis berhenti terlalu cepat. Sistem yang baik menganggap manusia akan salah, lalu memasang pagar supaya kesalahan kecil tidak jadi outage.