Templat Postmortem Engineering (Tanpa Menyalahkan, Bisa Ditindaklanjuti)

Mengapa postmortem berubah jadi ajang saling menyalahkan

Postmortem gagal dengan cara yang spesifik: ruangan mulai menetapkan penyebab sebelum ruangan memiliki linimasa bersama. Seseorang berkata "deploy ini yang menyebabkannya" sebelum waktu deployment dikonfirmasi. Orang lain berkata "alert tidak berbunyi" tanpa tahu apakah alert dikonfigurasi untuk skenario itu. Percakapan berubah menjadi perdebatan tentang kausalitas sebelum ada yang menetapkan apa yang sebenarnya terjadi, dalam urutan apa.

Perbaikannya bersifat struktural: susun linimasa insiden bersama-sama di awal postmortem, sebelum ada yang menyebut root cause. Begitu seluruh ruangan telah melihat urutan peristiwa — apa yang berubah kapan, siapa melihat apa pada waktu berapa — penyebab jauh lebih mudah dibahas dan jauh lebih kecil kemungkinan runtuh menjadi saling menyalahkan. Inilah kesalahan pengurutan yang dibuat kebanyakan templat: mereka menempatkan root cause sebelum linimasa karena root cause-lah tujuan templat itu. Tetapi linimasa-lah yang membuat root cause menjadi jujur.

Agendanya (salin-tempel ini)

Durasi: 60 menit untuk insiden yang lugas; 90 menit untuk kegagalan multi-sistem yang kompleks
Format: Difasilitasi; semua responder dan engineer on-call hadir; siapkan secara asinkron dengan dokumen pra-baca

Bagian 1 — Ringkasan insiden (5 menit)

Tanggal dan durasi insiden
Klasifikasi tingkat keparahan dan sistem yang terdampak
Siapa yang mendeteksinya dan bagaimana (laporan pelanggan, alert, engineer, monitoring)
Bagian ini hanya faktual; belum ada analisis

Bagian 2 — Linimasa (20 menit)

Susun linimasa secara kolaboratif di layar — bukan dokumen yang sudah ditulis sebelumnya
Urutan: apa yang berubah, apa yang teramati, siapa yang bertindak, apa yang diputuskan
Setiap timestamp harus bersumber (baris log, PagerDuty, pesan Slack)
Ketika linimasa selesai, tanyakan: apakah semua sepakat inilah yang terjadi? Selesaikan perbedaan pendapat sebelum lanjut

Bagian 3 — Ringkasan dampak (5 menit)

Dampak pelanggan: siapa yang terdampak, berapa lama, dengan cara apa
Dampak bisnis: pendapatan, SLA, reputasi
Dampak internal: jam on-call, gangguan tim
Jaga tetap faktual; ini menjadi jangkar bagi pertanyaan "seberapa parah" tanpa mengomentari secara subjektif

Bagian 4 — Root cause dan faktor kontributor (20 menit)

Root cause: perubahan atau kondisi paling proksimal yang memungkinkan insiden terjadi
Faktor kontributor: kondisi yang memperburuknya, mempersulit deteksinya, atau memperlambat penyelesaiannya
Postmortem yang paling berguna mengidentifikasi 3-5 faktor kontributor di samping root cause; memperbaiki hanya root cause kerap melewatkan kondisi sistemiknya
Untuk setiap faktor, tanyakan: apakah ada individu atau tim yang membuat keputusan yang tampak masuk akal mengingat informasi yang tersedia? Jika ya, faktornya bersifat sistemik, bukan personal

Bagian 5 — Apa yang berjalan baik (5 menit)

Deteksi atau respons apa yang berjalan lebih baik dari perkiraan?
Proses atau alat yang sudah ada apa yang membatasi radius ledakan?
Ini praktik yang layak diformalkan — jika runbook menghemat 20 menit, catat itu agar runbook terpelihara

Bagian 6 — Action item (15 menit)

Setiap action item menangani sebuah root cause atau faktor kontributor — bukan perbaikan umum
Satu penanggung jawab per item; tanggal penyelesaian yang mencerminkan tingkat urgensi
Kategorikan: deteksi lebih cepat / pulih lebih cepat / cegah keberulangan
Batasi pada tindakan yang realistis diselesaikan tim sebelum insiden berikutnya, bukan roadmap keandalan yang komprehensif

Apa yang membuat templat postmortem gagal

Pengurutan root-cause-dulu adalah masalah struktural utama — sudah dibahas di atas. Yang kedua adalah memperlakukan "action item" sebagai satu kategori tunggal. Perbaikan deteksi, perbaikan pemulihan, dan perbaikan pencegahan memerlukan penanggung jawab dan linimasa yang berbeda. Mencampurnya menghasilkan daftar yang membentang enam bulan dan tiga tim, yang berarti akuntabilitas menyebar dan tak satu pun terlaksana.

Pola kegagalan ketiga adalah melewatkan "apa yang berjalan baik" karena terasa seperti optimisme yang tidak pantas setelah insiden. Tidak begitu — itulah satu-satunya cara sistematis untuk mengidentifikasi dan memformalkan praktik yang berhasil di bawah tekanan. Jika monitoring yang menangkap masalah tidak ada dalam roadmap siapa pun untuk dibangun, mengetahui bahwa itu berarti layak didokumentasikan. Jika tidak, ia akan diturunkan prioritasnya setelah insiden memudar dan Anda buta pada kejadian berikutnya.

Biaya berlipat dari insiden di mana faktor kontributor dibiarkan, dan runbook yang berhasil tak terpelihara, menumpuk cepat. Pajak rapat membahas bagaimana beban rapat berulang dan utang tinjauan insiden saling berinteraksi.

Mengapa perekaman postmortem secara khusus sulit

Diskusi postmortem menghasilkan konten padat dan tak terstruktur dengan cepat: rekonstruksi linimasa, interpretasi yang bersaing, penugasan action item multi-orang, detail teknis yang tak masuk akal dalam transkrip tanpa konteks. Rekap postmortem yang ditulis dari ingatan atau audio yang disunting hampir selalu tak lengkap, dan catatan postmortem yang tak lengkap tak berguna untuk pengenalan pola lintas insiden.

Pavleur menangkap seluruh diskusi postmortem dan membuat laporan secara otomatis — linimasa sebagaimana direkonstruksi, faktor kontributor sebagaimana disebutkan, action item beserta penanggung jawab dan kategori sebagaimana dinyatakan dalam rapat. Jika seseorang membagikan layarnya untuk menampilkan cuplikan log, grafik monitoring, atau konfigurasi alert yang gagal berbunyi, visual itu menjadi bagian laporan. Alat berbasis audio saja melewatkan ini sepenuhnya; catatan postmortem tanpa grafik adalah catatan tanpa bukti. Siapa pun di tim — termasuk engineer yang bergabung setelah insiden — bisa membaca catatan lengkap yang menyertakan konteks visual tanpa meminta seseorang merekonstruksinya. Untuk perbandingan langsung dengan alat lain soal ini: Pavleur vs. alternatif.

Tentang irama postmortem

Jalankan postmortem dalam 48 jam setelah insiden teratasi selagi detail masih segar. Semakin lama Anda menunggu, semakin rekonstruksi linimasa bergantung pada ingatan alih-alih log, dan ingatan tidak dapat diandalkan di bawah stres. Untuk insiden berkeparahan tinggi, 24 jam lebih baik. Untuk insiden ringan, postmortem asinkron — dokumen bersama dengan pertanyaan terstruktur, ditinjau secara sinkron — bisa lebih efisien daripada rapat penuh. Format rapat paling berharga ketika insidennya cukup ambigu atau bertaruhan tinggi sehingga interpretasi bersama menjadi penting.