Post-mortem

Apa itu Post-mortem

• Dokumen dan proses review setelah insiden untuk memahami apa yang terjadi dan mencegahnya berulang
• Bukan sidang untuk mencari siapa yang salah — melainkan investigasi untuk memperbaiki sistem
• Disebut juga "incident review" atau "retrospective" di beberapa tim

Mengapa Post-mortem Penting

• Insiden yang sama cenderung berulang jika tidak dipelajari dengan baik
• Membangun institutional knowledge tentang bagaimana sistem bekerja (dan gagal)
• Memberi tim rasa aman untuk melaporkan masalah tanpa takut dihukum
• Menghasilkan action items konkret yang meningkatkan reliability

Prinsip Blameless Post-mortem

• Asumsi dasar: semua orang yang terlibat bertindak dengan niat baik dan pengetahuan terbaik yang mereka miliki saat itu
• Orang tidak gagal — sistem dan proses yang gagal, atau sistem tidak memberi cukup sinyal untuk mencegah kegagalan
• Fokus pada "bagaimana kita bisa membuat ini tidak mungkin terjadi lagi" bukan "siapa yang deploy kode buggy ini"
• Hukuman mendorong menyembunyikan masalah — blameless culture mendorong transparansi

Struktur Dokumen Post-mortem

1. Summary

• Ringkasan singkat: apa yang terjadi, berapa lama, apa dampaknya

2. Impact

• Berapa lama layanan down atau degradasi?
• Berapa pengguna terdampak?
• Dampak ke bisnis (revenue, SLA, reputasi)?

3. Timeline

• Kronologi kejadian dengan timestamp
• Termasuk: kapan mulai, kapan terdeteksi, setiap langkah respons, kapan resolved

4. Root Cause Analysis

• Apa penyebab langsung insiden?
• Gunakan teknik "5 Whys" untuk gali lebih dalam
• Identifikasi contributing factors (bukan hanya satu penyebab)

5. Contributing Factors

• Faktor apa yang memungkinkan insiden ini terjadi atau membuatnya lebih parah?
• Contoh: tidak ada alerting, runbook tidak ada, test coverage kurang, deployment tanpa review

6. What Went Well

• Apa yang berjalan baik dalam respons?
• Penting untuk diakui agar praktik baik dipertahankan

7. Action Items

• Apa yang akan dilakukan untuk mencegah insiden ini berulang?
• Setiap action item harus memiliki: deskripsi, owner, deadline
• Prioritaskan berdasarkan dampak potensial

Teknik 5 Whys

Teknik sederhana untuk menemukan root cause dengan bertanya "mengapa" secara berulang:

Insiden: API payment down selama 20 menit

Kenapa? → Database connection exhausted
Kenapa? → Aplikasi tidak menutup connection dengan benar
Kenapa? → Connection pool tidak dikonfigurasi dengan benar setelah upgrade library
Kenapa? → Tidak ada review konfigurasi sebelum deploy
Kenapa? → Tidak ada checklist deployment yang memeriksa konfigurasi kritis

Root cause: Tidak ada proses untuk memeriksa konfigurasi kritis sebelum deployment

Rapat Post-mortem

• Lakukan dalam 48-72 jam setelah insiden, selagi memori masih segar
• Durasi: 60-90 menit
• Peserta: semua yang terlibat dalam respons + perwakilan stakeholder yang relevan
• Fasilitator: sebaiknya bukan IC di insiden tersebut agar lebih objektif
• Bagikan draft dokumen sebelum rapat agar peserta bisa persiapan

Tindak Lanjut Action Items

• Masukkan action items ke backlog dengan prioritas yang jelas
• Review progress action items di rapat mingguan
• Jika action item tidak dikerjakan: eskalasi atau deprioritaskan secara eksplisit
• Jangan biarkan action items menumpuk tanpa ditindaklanjuti — ini merusak kepercayaan proses

Praktik Terbaik

• Publish post-mortem ke seluruh organisasi (bukan hanya tim) — transparansi membangun kepercayaan
• Buat template standar agar konsisten dan mudah dikerjakan
• Lakukan walaupun insiden "kecil" — pola baru terlihat dari akumulasi data
• Rayakan post-mortem yang baik — ini tanda tim yang mature dan belajar