Postmortem #
Setiap tim engineering yang cukup lama bekerja akan mengalami incident — production down, data corruption, performa yang tiba-tiba memburuk, atau deployment yang menyebabkan masalah yang tidak terduga. Yang membedakan tim yang matang dari yang tidak bukan apakah mereka mengalami incident, melainkan apa yang mereka lakukan setelahnya. Postmortem adalah mekanisme sistematis untuk mengubah setiap kegagalan menjadi pengetahuan kolektif: bukan untuk mencari siapa yang bersalah, melainkan untuk memahami bagaimana sistem — proses, tooling, komunikasi, dan arsitektur — bisa didesain lebih baik agar hal yang sama tidak terulang. Artikel ini membahas filosofi di balik postmortem yang efektif, bagaimana memimpinnya, bagaimana mendokumentasikannya, dan anti-pattern yang paling sering merusak nilainya.
Apa Itu Postmortem? #
Postmortem adalah proses refleksi terstruktur yang dilakukan setelah sebuah incident signifikan — biasanya dalam 24–72 jam setelah incident resolved — dengan tujuan memahami apa yang terjadi, mengapa terjadi, dan bagaimana mencegah hal yang sama terulang.
Postmortem bukan:
✗ Sesi untuk mencari siapa yang bersalah
✗ Laporan ke manajemen tentang siapa yang "tidak perform"
✗ Ritual formalitas yang dilakukan demi compliance
✗ Evaluasi kinerja individual
✗ Kesempatan untuk mempermalukan engineer yang membuat kesalahan
Postmortem adalah:
✓ Analisis kolektif tentang kegagalan sistem
✓ Kesempatan untuk belajar dari kondisi yang jarang terjadi di production
✓ Proses untuk mengidentifikasi perbaikan sistemik yang nyata
✓ Cara untuk membangun kepercayaan dalam tim bahwa berbicara jujur itu aman
✓ Dokumentasi yang membantu mencegah kegagalan yang sama di masa depan
Filosofi Blameless Postmortem #
Konsep “blameless postmortem” dipopulerkan oleh Google SRE dan menjadi standar di industri software engineering modern. Idenya sederhana tapi implikasinya dalam: ketika sesuatu gagal, kita tidak mencari orang untuk disalahkan — kita mencari sistem yang perlu diperbaiki.
Mengapa Blame Tidak Berguna #
Skenario postmortem berbasis blame:
Incident: Engineer A men-deploy kode yang menyebabkan downtime 2 jam
Postmortem: "Engineer A tidak testing dengan benar sebelum deploy"
Action item: "Engineer A harus lebih berhati-hati"
Hasil: Engineer A merasa malu, tim yang lain lega bukan mereka yang kena
Masalah sistemik tidak teridentifikasi:
→ Tidak ada staging environment yang representative
→ Tidak ada automated rollback
→ Deployment dilakukan manual tanpa checklist
→ Tidak ada monitoring yang mendeteksi masalah lebih awal
Bulan berikutnya: Engineer B membuat kesalahan yang sama
Blame mengalihkan perhatian dari pertanyaan yang benar-benar penting. Pertanyaan yang benar bukan “siapa yang melakukan ini?” melainkan “apa yang membuat sistem kita memungkinkan hal ini terjadi?”
Prinsip Blameless Postmortem #
ASUMSI DASAR:
→ Semua engineer bertindak dengan niat baik berdasarkan informasi
yang mereka miliki saat itu
→ Kesalahan adalah gejala dari masalah sistemik, bukan penyebabnya
→ Engineer yang paling dekat dengan incident adalah sumber informasi
terbaik — mereka harus merasa aman untuk berbicara jujur
IMPLIKASINYA:
→ Nama individu tidak muncul dalam konteks negatif di postmortem document
→ Fokus pada "apa yang terjadi" bukan "siapa yang melakukan ini"
→ Root cause analysis berakhir pada kelemahan sistem, bukan kelemahan individu
→ Engineer yang membuat kesalahan aktif diundang untuk berkontribusi
dalam postmortem — mereka punya informasi paling berharga
Blameless bukan berarti tanpa akuntabilitas. Jika seseorang secara konsisten membuat keputusan yang buruk meski sudah ada sistem yang mendukung keputusan yang baik, itu adalah masalah yang perlu ditangani — tapi melalui proses manajemen performa, bukan melalui postmortem publik. Postmortem fokus pada sistem; performa individu dibahas di forum yang berbeda.
Perbedaan Postmortem dan RCA #
Kedua istilah ini sering digunakan secara bergantian, tapi sebenarnya punya perbedaan yang penting.
ROOT CAUSE ANALYSIS (RCA):
→ Teknik analisis untuk menemukan akar penyebab masalah
→ Bersifat teknis dan investigatif
→ Menjawab: "Mengapa masalah ini terjadi secara teknis?"
→ Bisa dilakukan oleh satu atau dua orang
→ Contoh output: "DB connection pool exhausted karena query N+1
yang tidak terdeteksi di load test"
POSTMORTEM:
→ Proses refleksi dan dokumentasi yang lebih komprehensif
→ Mencakup RCA sebagai salah satu bagiannya
→ Menjawab: "Apa yang terjadi, mengapa, apa dampaknya, apa yang dipelajari,
dan apa yang akan diubah?"
→ Melibatkan semua pihak yang terdampak atau terlibat
→ Output: dokumen lengkap + action items + perubahan sistemik
Hubungan keduanya:
RCA adalah input untuk postmortem, bukan penggantinya.
Postmortem yang hanya berisi RCA teknis tanpa refleksi proses
dan action item konkret adalah postmortem yang tidak lengkap.
Kapan Postmortem Perlu Dilakukan #
Tidak semua masalah perlu postmortem formal. Panduan umum:
WAJIB POSTMORTEM:
□ Production downtime yang mempengaruhi user (durasi apapun)
□ Data loss atau data corruption, sekecil apapun
□ Security incident atau potensi breach
□ Performa degradasi signifikan yang berdampak ke user experience
□ Deployment yang harus di-rollback karena menyebabkan masalah
□ SLA violation
PERTIMBANGKAN POSTMORTEM (judgment call):
□ Near-miss yang berhasil ditangkap sebelum berdampak ke user
□ Incident yang berlangsung singkat tapi memiliki root cause menarik
□ Masalah yang sama muncul untuk ketiga kalinya atau lebih
TIDAK PERLU POSTMORTEM FORMAL:
□ Bug yang ditemukan dan difix dalam sprint tanpa dampak ke production
□ Masalah konfigurasi minor yang diselesaikan dalam menit
□ Incident yang sudah ada postmortem serupa dan root cause-nya identik
Memimpin Sesi Postmortem #
Persiapan Sebelum Sesi #
Postmortem yang efektif dimulai jauh sebelum semua orang duduk di ruangan yang sama. Persiapan yang baik adalah yang memastikan sesi itu sendiri bisa fokus pada analisis dan diskusi, bukan pada pengumpulan fakta.
Persiapan yang harus dilakukan sebelum sesi (oleh facilitator):
1. Kumpulkan data mentah
→ Timeline kejadian dari log, monitoring, dan alert
→ Screenshot dashboard pada waktu incident
→ Thread Slack atau komunikasi yang terjadi selama incident
→ Command atau kode yang dieksekusi selama investigasi dan fix
2. Identifikasi peserta yang tepat
→ Engineer yang on-call saat incident terjadi (wajib)
→ Engineer yang melakukan deployment atau perubahan terkait
→ Engineer yang mengeksekusi fix
→ Tech lead atau manager sebagai context provider (optional, tapi tidak sebagai judge)
→ Perwakilan dari tim yang terdampak (misal: QA, CS jika user-facing)
3. Buat draft timeline awal
→ Berdasarkan data yang dikumpulkan
→ Timeline ini akan diverifikasi dan dikoreksi bersama dalam sesi
4. Kirim pre-read material
→ Incident summary singkat (bukan analisis)
→ Timeline draft
→ Link ke log atau monitoring yang relevan
→ Minimal 24 jam sebelum sesi
Menjalankan Sesi Postmortem #
Struktur sesi postmortem (60–90 menit):
OPENING (5 menit)
Facilitator menegaskan ground rules:
→ "Ini adalah blameless postmortem — fokus kita pada sistem, bukan individu"
→ "Semua perspektif dihargai — tidak ada yang salah untuk disampaikan"
→ "Goal kita hari ini: memahami apa yang terjadi dan membuat sistem lebih baik"
TIMELINE REVIEW (20–30 menit)
→ Berjalan melalui timeline bersama secara kronologis
→ Verifikasi dan koreksi dari peserta yang hadir
→ Tandai: kapan masalah mulai, kapan terdeteksi, kapan eskalasi, kapan resolved
→ Tandai juga: keputusan yang diambil dan alasannya saat itu
ROOT CAUSE ANALYSIS (20–25 menit)
→ Gunakan "5 Whys" atau Fishbone untuk menggali lebih dalam
→ Cari contributing factors, bukan hanya trigger
→ Identifikasi: apa yang memungkinkan masalah ini terjadi?
→ Hindari berhenti di jawaban pertama — terus tanya "mengapa"
APA YANG BERJALAN BAIK (10 menit)
→ Bagian ini sering dilewatkan tapi penting
→ Sistem atau proses apa yang membantu deteksi atau mitigasi?
→ Keputusan apa yang tepat dilakukan dalam tekanan?
→ Ini bukan sesi pujian — ini identifikasi hal yang perlu dipertahankan
ACTION ITEMS (15–20 menit)
→ Berdasarkan root cause dan contributing factors
→ Setiap action item: deskripsi jelas, owner, deadline
→ Kategorikan: immediate fix, short-term improvement, long-term prevention
→ Realistis — lebih baik 3 action item yang dikerjakan dari 10 yang diabaikan
Teknik 5 Whys dalam Postmortem #
5 Whys adalah teknik sederhana tapi powerful untuk menggali beyond symptom menuju akar masalah yang sesungguhnya.
Contoh penggunaan 5 Whys dalam postmortem:
Incident: Production API down selama 45 menit
Why 1: Kenapa API down?
→ Database connection pool exhausted
Why 2: Kenapa connection pool exhausted?
→ Ada lonjakan query yang berjalan sangat lambat
Why 3: Kenapa query berjalan lambat?
→ Query tidak menggunakan index — full table scan
Why 4: Kenapa query tidak menggunakan index?
→ Index yang seharusnya digunakan hilang setelah migration kemarin
Why 5: Kenapa migration menghapus index tanpa terdeteksi?
→ Migration script tidak di-review untuk dampak performa
→ Tidak ada automated check untuk memverifikasi index setelah migration
→ Staging database tidak memiliki data yang representative sehingga
masalah performa tidak terdeteksi saat testing
ROOT CAUSE YANG DITEMUKAN:
Bukan "engineer menulis query yang salah"
Melainkan: "proses migration review tidak mencakup verifikasi performa,
dan staging environment tidak representative untuk mendeteksi masalah ini"
ACTION ITEMS YANG TEPAT:
→ Tambahkan automated check: verifikasi index setelah setiap migration
→ Buat staging database dengan data volume yang lebih representative
→ Tambahkan migration review checklist yang mencakup dampak performa
Postmortem Document #
Postmortem document adalah output utama dari proses postmortem — dokumen yang mendokumentasikan seluruh analisis dan keputusan yang dibuat, sehingga bisa dijadikan referensi di masa depan dan diakses oleh orang yang tidak hadir dalam sesi.
Prinsip Postmortem Document yang Baik #
JELAS:
→ Dapat dipahami oleh engineer yang tidak terlibat langsung dalam incident
→ Tidak mengasumsikan pengetahuan yang tidak universal
FAKTUAL:
→ Berdasarkan data dan timeline yang terverifikasi
→ Bukan spekulasi atau asumsi yang tidak didukung bukti
→ Bedakan antara "yang terjadi" dan "yang mungkin terjadi"
ACTIONABLE:
→ Setiap action item konkret, ada owner, ada deadline
→ Bukan "perlu lebih hati-hati" — tapi "tambahkan automated test untuk X"
BLAMELESS:
→ Nama individu tidak muncul dalam konteks negatif
→ Jika perlu menyebut role, gunakan role bukan nama:
"on-call engineer" bukan "Engineer A"
RINGKAS TAPI LENGKAP:
→ Tidak perlu menulis novel — cukup untuk dipahami dengan baik
→ Timeline detail, root cause jelas, action items konkret
Template Postmortem Document #
Berikut template lengkap yang bisa langsung digunakan:
# Postmortem: [Judul Singkat Incident]
**Tanggal Incident:** YYYY-MM-DD
**Tanggal Postmortem:** YYYY-MM-DD
**Severity:** Critical / High / Medium
**Durasi Incident:** [waktu mulai] – [waktu resolved] ([total durasi])
**Status:** Draft | In Review | Final
**Author:** [Nama Facilitator]
**Reviewer:** [Nama Tech Lead / Engineering Manager]
**Peserta Sesi:** [daftar role, bukan nama individual]
---
## Ringkasan Eksekutif
[2–3 kalimat yang merangkum: apa yang terjadi, dampaknya, dan apa
yang akan dilakukan. Ditulis untuk pembaca yang tidak punya waktu
membaca dokumen lengkap.]
Contoh:
"Pada 2026-01-27 pukul 14:32, API payment mengalami downtime selama
47 menit akibat database connection pool yang habis setelah migration
deployment. Sekitar 3.200 transaksi terdampak selama periode tersebut.
Kami akan menambahkan automated verification untuk index database dan
meningkatkan representasi data di staging environment."
---
## Timeline
Gunakan format yang konsisten dan mudah dibaca:
| Waktu (WIB) | Event |
|---|---|
| 14:32 | Deployment sprint 42 selesai ke production |
| 14:38 | Alert pertama muncul: error rate /api/payment meningkat ke 15% |
| 14:41 | On-call engineer menerima PagerDuty alert |
| 14:45 | Investigasi dimulai: log menunjukkan DB connection timeout |
| 14:52 | Identifikasi: connection pool exhausted karena slow queries |
| 15:01 | Query lambat ditemukan, trace ke missing index setelah migration |
| 15:08 | Rollback deployment dimulai |
| 15:14 | Rollback selesai, index kembali ada |
| 15:19 | Error rate kembali normal, layanan fully restored |
| 15:30 | All-clear dikonfirmasi, monitoring dipantau 30 menit tambahan |
**Durasi total:** 47 menit (14:32 – 15:19)
**Time to detect:** 6 menit
**Time to identify root cause:** 26 menit
**Time to resolve:** 47 menit
---
## Dampak
**User yang terdampak:**
- ~3.200 transaksi payment gagal selama periode incident
- Error rate endpoint /api/payment mencapai puncak 87% pada 14:45
**Sistem yang terdampak:**
- payment-service (primary)
- order-service (downstream, orders tertunda tapi tidak hilang)
- notification-service (email konfirmasi tidak terkirim)
**Data impact:**
- Tidak ada data loss
- 3.200 transaksi failed perlu di-retry (sudah dikonfirmasi idempotent)
---
## Root Cause Analysis
### Trigger (Penyebab Langsung)
Migration script di deployment sprint 42 secara tidak sengaja
menghapus composite index `idx_payments_user_status_created` dari
tabel `payments`. Tanpa index ini, query listing payment history
melakukan full table scan pada tabel dengan 8.4 juta baris.
### Contributing Factors (Faktor Pendukung)
**1. Migration review tidak mencakup dampak performa**
Migration script di-review untuk correctness (apakah schema-nya benar)
tapi tidak ada checklist atau tooling yang memverifikasi bahwa index
yang ada sebelumnya masih ada setelah migration.
**2. Staging environment tidak representative**
Staging database hanya memiliki ~5.000 baris di tabel payments.
Full table scan pada data sekecil itu tidak menunjukkan masalah
performa yang signifikan, sehingga lolos dari testing.
**3. Alert threshold terlalu longgar**
Alert untuk error rate dikonfigurasi untuk trigger di 25%.
Dengan threshold ini, alert baru muncul 6 menit setelah masalah mulai —
cukup lambat untuk masalah yang berkembang secepat ini.
**4. Tidak ada automated verification post-deployment**
Tidak ada automated check yang memverifikasi bahwa schema dan index
production sesuai dengan yang diharapkan setelah deployment.
### 5 Whys
Kenapa payment API down? → DB connection pool exhausted
Kenapa connection pool exhausted? → Query berjalan sangat lambat (full table scan)
Kenapa query full table scan? → Index yang digunakan query tersebut tidak ada
Kenapa index tidak ada? → Migration script menghapusnya secara tidak sengaja
Kenapa migration yang menghapus index tidak terdeteksi? → Migration review tidak memeriksa dampak ke index yang ada → Staging tidak memiliki data yang cukup untuk mendeteksi masalah performa → Tidak ada automated check post-deployment untuk verifikasi schema
---
## Apa yang Berjalan Baik
- **Deteksi relatif cepat:** Alert muncul dalam 6 menit, on-call engineer
merespons dalam 3 menit setelah alert
- **Komunikasi stakeholder efektif:** Status page diupdate dalam 10 menit
setelah incident teridentifikasi, CS tim di-notify sebelum banyak tiket masuk
- **Idempotency mencegah duplikasi:** Semua transaksi yang failed bisa
di-retry tanpa risiko duplikasi karena payment flow sudah idempotent
- **Rollback berjalan lancar:** Proses rollback selesai dalam 6 menit,
documented dan terlatih
---
## Action Items
### Immediate (dalam 1 minggu)
| # | Action | Owner | Deadline |
|---|---|---|---|
| 1 | Tambahkan migration checklist yang wajib mencakup verifikasi index | Tech Lead | 2026-02-03 |
| 2 | Turunkan alert threshold error rate dari 25% ke 5% untuk endpoint payment | On-call Engineer | 2026-02-03 |
| 3 | Buat tiket untuk retry 3.200 transaksi yang failed (sudah diverifikasi idempotent) | Backend Engineer | 2026-01-29 |
### Short-term (dalam 1 bulan)
| # | Action | Owner | Deadline |
|---|---|---|---|
| 4 | Buat automated test: verifikasi index yang diharapkan ada setelah migration | Backend Engineer | 2026-02-28 |
| 5 | Setup data seeding di staging untuk minimal 500K baris di tabel kritis | DevOps Engineer | 2026-02-28 |
| 6 | Review semua migration script yang ada — apakah ada yang berpotensi masalah serupa? | Tech Lead | 2026-02-20 |
### Long-term (dalam 1 kuartal)
| # | Action | Owner | Deadline |
|---|---|---|---|
| 7 | Implementasi post-deployment automated smoke test suite yang mencakup performa query kritis | Backend Engineer | 2026-03-31 |
| 8 | Evaluasi tooling untuk schema drift detection di production | Tech Lead | 2026-03-31 |
---
## Pembelajaran
[Bagian ini berisi insight yang dapat diaplikasikan lebih luas,
bukan hanya untuk incident ini.]
1. **Migration review perlu mencakup dampak performa, bukan hanya correctness**
Setiap migration yang mengubah, menghapus, atau menambahkan index
harus melalui review performa eksplisit.
2. **Staging environment yang tidak representative memberi false confidence**
Data volume di staging harus cukup untuk merepresentasikan pola
query production — terutama untuk tabel dengan jutaan baris.
3. **Alert threshold perlu disesuaikan dengan criticality endpoint**
Endpoint payment membutuhkan threshold yang jauh lebih ketat
dibanding endpoint non-critical lainnya.
---
## Appendix
**Link ke monitoring dashboard saat incident:**
[URL Grafana snapshot]
**Link ke incident thread di Slack:**
[URL thread]
**Link ke deployment yang terkait:**
[URL GitHub Actions run]
**Log error yang relevan:**
[2026-01-27 14:38:12] ERROR: HikariPool timeout after 30000ms [2026-01-27 14:38:12] ERROR: Connection pool exhausted (max: 50, active: 50) [2026-01-27 14:40:55] WARN: Query execution time: 28.4s (threshold: 1s) [2026-01-27 14:40:55] WARN: Full table scan detected on payments (8.4M rows)
Cara Menulis Setiap Bagian dengan Efektif #
Ringkasan Eksekutif #
Ditulis terakhir, setelah seluruh analisis selesai. Harus bisa dipahami oleh seseorang yang tidak terlibat dalam incident dan tidak punya konteks teknis mendalam. Tiga hal yang wajib ada: apa yang terjadi, dampaknya, dan apa yang akan dilakukan.
// ✗ Ringkasan eksekutif yang terlalu teknis:
"DB connection pool exhausted akibat full table scan pada payments
table karena missing index post-migration yang menyebabkan HikariCP
timeout dan cascade failure ke downstream services."
// ✓ Ringkasan eksekutif yang bisa dipahami semua orang:
"Pada Selasa 27 Januari, layanan pembayaran mengalami gangguan selama
47 menit yang menyebabkan sekitar 3.200 transaksi gagal. Penyebabnya
adalah perubahan database yang tidak sengaja menghapus pengaturan yang
membantu query berjalan cepat. Semua transaksi yang gagal sudah
dipastikan bisa diproses ulang tanpa duplikasi, dan kami sedang
menambahkan pemeriksaan otomatis untuk mencegah kejadian serupa."
Timeline #
Timeline harus akurat dan berdasarkan data, bukan rekonstruksi dari ingatan. Sumber terbaik: log server, alert history, dan thread Slack.
Hal yang perlu dicatat di timeline:
✓ Kapan masalah benar-benar mulai (bukan kapan terdeteksi)
✓ Kapan alert pertama kali muncul
✓ Kapan engineer mulai merespons
✓ Hipotesis yang dicoba dan mengapa tidak berhasil
✓ Kapan root cause teridentifikasi
✓ Kapan fix dimulai dan selesai
✓ Kapan layanan fully restored dan dikonfirmasi
Catatan penting:
→ Bedakan antara "waktu server" dan "waktu lokal" jika tim tersebar
→ Gunakan timezone yang konsisten di seluruh timeline
→ Jika ada gap di timeline, catat: "investigasi berlangsung, tidak ada
update signifikan selama periode ini"
Root Cause Analysis #
Bagian paling substansial dari postmortem document. Paling sering ditulis terlalu dangkal (“human error”) atau terlalu teknis tanpa konteks.
Struktur RCA yang baik:
1. Trigger — apa yang memicu masalah secara langsung?
Bukan root cause, tapi starting point analisis
Contoh: "Deployment sprint 42 menghapus index database"
2. Root cause — apa yang memungkinkan trigger itu terjadi?
Ini jawaban dari 5 Whys terakhir
Contoh: "Tidak ada mekanisme untuk mendeteksi index yang hilang
setelah migration, baik di review maupun di deployment pipeline"
3. Contributing factors — kondisi apa yang memperparah situasi?
Ini faktor-faktor yang, kalau diperbaiki, akan membuat sistem
lebih resilient meski trigger yang sama terjadi lagi
Contoh: "Staging tidak representative", "Alert threshold terlalu longgar"
ANTI-PATTERN dalam menulis RCA:
✗ "Human error" — ini bukan root cause, ini gejala
✗ "Engineer tidak berhati-hati" — ini blame, bukan analisis
✗ "Sistem gagal" — terlalu general, tidak actionable
✗ Berhenti di Why ke-2 atau ke-3 sebelum mencapai akar yang sesungguhnya
Action Items #
Ini adalah bagian yang paling menentukan apakah postmortem memberikan dampak nyata atau hanya menjadi dokumen arsip.
Karakteristik action item yang efektif:
SPESIFIK:
✗ "Perbaiki proses review migration"
✓ "Tambahkan checklist migration review yang mencakup: (1) verifikasi
semua index yang ada sebelum migration masih ada setelah migration,
(2) query plan comparison untuk query kritis"
TERUKUR:
✗ "Tingkatkan monitoring"
✓ "Turunkan alert threshold error rate endpoint /api/payment dari 25% ke 5%"
ADA OWNER:
✗ "Tim perlu menyelesaikan ini"
✓ "[Role] bertanggung jawab untuk menyelesaikan ini"
ADA DEADLINE:
✗ "Segera diselesaikan"
✓ "Selesai sebelum 2026-02-03"
REALISTIS:
Lebih baik 3 action item yang dikerjakan
daripada 10 action item yang diabaikan karena terlalu banyak
Cara Mendistribusikan dan Menindaklanjuti Postmortem #
Postmortem document yang selesai ditulis tapi tidak dibaca atau tidak ditindaklanjuti adalah postmortem yang gagal. Ada dua hal yang perlu dilakukan setelah dokumen final:
Distribusi #
Distribusi postmortem document:
Internal tim engineering:
→ Kirim link ke channel engineering utama dengan summary singkat
→ Bukan untuk menghukum — tapi untuk belajar bersama
Stakeholder yang terdampak:
→ Summary non-teknis (ringkasan eksekutif saja)
→ Apa yang terjadi, dampak ke mereka, dan apa yang sudah/akan dilakukan
Format pengiriman:
"Hi semua, postmortem untuk incident [nama] sudah final.
Ringkasan: [2-3 kalimat]
Full doc: [link]
Action items utama yang sedang dikerjakan: [list singkat]"
Menindaklanjuti Action Items #
Mekanisme follow-up yang efektif:
1. Semua action items masuk ke backlog sebagai tiket resmi
→ Bukan hanya dicatat di postmortem document
→ Ada sprint assignment atau priority yang jelas
2. Review progress di sprint berikutnya
→ Tech lead atau Scrum Master mencek: "Action item dari postmortem
X — ada update?"
3. Update postmortem document saat action item selesai
→ Tandai setiap action item dengan status: ✓ Done, ⟳ In Progress, ✗ Blocked
→ Dokumen jadi "living document" sampai semua action item selesai
4. Verifikasi efektivitas
→ Setelah action items selesai, apakah sistem benar-benar lebih resilient?
→ Jika memungkinkan, lakukan chaos engineering atau drill untuk verifikasi
Simpan semua postmortem document di satu tempat yang terindeks dengan baik — misalnya folder “Postmortems” di Notion atau Confluence, dengan format nama YYYY-MM-DD — [Nama Incident]. Ketika incident baru terjadi, cek dulu apakah ada postmortem lama dengan root cause yang mirip. Seringkali pattern yang sama muncul lagi dalam bentuk berbeda, dan postmortem lama bisa memberikan insight yang berharga.Anti-Pattern Postmortem yang Harus Dihindari #
Postmortem yang Berisi Blame Terselubung #
Blame yang paling berbahaya bukan yang eksplisit — melainkan yang terselubung dalam bahasa “netral”:
// ✗ Blame terselubung:
"Engineer yang bertugas deployment tidak memverifikasi migration
script dengan cukup teliti sebelum menjalankannya di production"
→ Ini masih blame — menyiratkan bahwa ini adalah kegagalan individu
"Tim QA gagal mendeteksi masalah ini selama testing"
→ Ini blame ke tim QA — mengabaikan bahwa sistem testing-nya yang perlu diperbaiki
// ✓ Framing yang blameless:
"Migration script tidak memiliki automated verification untuk
memastikan index yang ada sebelumnya tetap ada setelah migration"
"Testing di staging tidak mendeteksi masalah performa karena
volume data staging tidak representative dengan production"
→ Fokus pada kelemahan sistem, bukan individu
Action Items yang Tidak Realistis atau Tidak Ditindaklanjuti #
Postmortem yang menghasilkan daftar action items panjang tapi tidak ada yang dikerjakan lebih buruk dari tidak ada postmortem sama sekali — ia menciptakan siklus di mana tim merasa sudah “menyelesaikan” masalah padahal tidak ada yang berubah.
// ✗ Action items yang tidak dikerjakan:
Postmortem Sprint 10: 12 action items
Postmortem Sprint 15: 8 action items baru (plus 9 dari Sprint 10 belum selesai)
Postmortem Sprint 20: "Kita sudah punya banyak action items yang belum selesai..."
→ Tim kehilangan kepercayaan pada proses postmortem
// ✓ Pendekatan yang lebih realistis:
Identifikasi 3 action items yang paling impactful
Commit ke timeline yang realistis berdasarkan kapasitas tim
Review progress di setiap sprint sampai semua selesai
→ 3 action items yang diselesaikan lebih berharga dari 12 yang diabaikan
Postmortem yang Terlalu Lama Setelah Incident #
Postmortem yang dilakukan terlalu lama setelah incident kehilangan keakuratan timeline, detail teknis yang penting, dan momentum untuk perubahan.
Timing yang disarankan:
Sesi postmortem: dalam 24–72 jam setelah incident resolved
Draft document: dalam 48 jam setelah sesi
Document final: dalam 1 minggu setelah incident
Mengapa timing penting:
→ Ingatan tentang detail teknis memudar cepat
→ Urgensi untuk memperbaiki sistem masih terasa
→ Engineer yang terlibat masih memiliki konteks yang segar
→ Action items lebih mudah di-prioritize saat incident masih relevan
Postmortem yang Tidak Pernah Dilakukan Karena “Tidak Ada Waktu” #
Ini adalah anti-pattern yang paling umum — dan yang paling merugikan jangka panjang.
// ✗ Alasan yang sering didengar:
"Kita skip postmortem kali ini karena sprint lagi padat"
"Incident-nya sudah resolve, tidak perlu dibahas lagi"
"Kita sudah tahu root cause-nya, tidak perlu formal"
// Dampak jangka panjang:
Sprint 5: Incident A — tidak ada postmortem
Sprint 8: Incident B dengan root cause serupa
Sprint 12: Incident C dengan root cause yang sama lagi
→ Tim mengulangi kesalahan yang sama karena tidak ada pembelajaran sistematis
// ✓ Pendekatan yang benar:
Postmortem untuk setiap incident signifikan adalah non-negotiable
Investasi 2–3 jam untuk postmortem bisa mencegah incident berikutnya
yang mungkin membutuhkan berhari-hari untuk diselesaikan
Postmortem sebagai Bagian dari Ekosistem Dokumentasi #
Postmortem paling efektif ketika ia terhubung dengan praktik dokumentasi yang lebih luas:
HUBUNGAN POSTMORTEM DENGAN DOKUMEN LAIN:
RFC / Design Doc:
→ Postmortem yang menemukan kelemahan arsitektur → RFC untuk perbaikannya
→ RFC yang direview post-incident bisa memberikan konteks "mengapa keputusan
ini dibuat" yang relevan untuk postmortem
Release Document:
→ Deployment yang menyebabkan incident → link dari release doc ke postmortem
→ Postmortem action items bisa muncul sebagai item di release doc sprint berikutnya
Reference Document:
→ Pattern atau standar yang muncul dari postmortem → didokumentasikan ke reference doc
→ Contoh: "Setelah postmortem X, kita sepakati bahwa semua migration harus
mencantumkan daftar index yang ada sebelum dan sesudah migration"
Knowledge Sharing Session:
→ Setiap postmortem signifikan → KSS post-mortem dalam 1–2 minggu setelahnya
→ KSS memberikan ruang diskusi yang lebih luas tentang learning dari incident
On-call Runbook:
→ Jika incident menghasilkan playbook baru untuk penanganan masalah serupa,
runbook diupdate dan dilinkkan dari postmortem
Checklist Postmortem #
SETELAH INCIDENT RESOLVED:
□ Tentukan apakah incident ini memerlukan postmortem formal
□ Assign facilitator (biasanya Tech Lead atau senior engineer yang tidak
terlibat langsung dalam incident)
□ Schedule sesi dalam 24–72 jam
□ Identifikasi peserta yang perlu hadir
PERSIAPAN SEBELUM SESI:
□ Kumpulkan timeline dari log, monitoring, dan alert
□ Screenshot dashboard dan log relevan disimpan
□ Draft timeline disiapkan dan dikirim sebagai pre-read
□ Ground rules blameless dikomunikasikan sebelum sesi
SELAMA SESI:
□ Facilitator menegaskan blameless ground rules di awal
□ Timeline di-review dan diverifikasi bersama
□ 5 Whys atau teknik RCA lain digunakan untuk menggali root cause
□ Contributing factors — bukan hanya trigger — diidentifikasi
□ "Apa yang berjalan baik" tidak dilewatkan
□ Action items konkret disepakati: owner, deadline, kategori
POSTMORTEM DOCUMENT:
□ Ringkasan eksekutif bisa dipahami non-engineer
□ Timeline akurat dan berdasarkan data, bukan ingatan
□ Root cause menyebut sistem, bukan individu
□ Contributing factors lebih dari satu (hampir selalu ada lebih dari satu)
□ Action items spesifik, ada owner, ada deadline
□ Pembelajaran ditulis sebagai insight yang bisa diaplikasikan lebih luas
□ Dokumen di-review oleh orang yang tidak terlibat untuk memastikan clarity
SETELAH DOKUMEN FINAL:
□ Dokumen dibagikan ke seluruh tim engineering
□ Summary non-teknis dikirim ke stakeholder yang terdampak
□ Semua action items masuk ke backlog sebagai tiket resmi
□ Dokumen disimpan di tempat yang mudah ditemukan (format: YYYY-MM-DD — Nama)
□ Progress action items di-review di sprint berikutnya
□ KSS post-mortem dijadwalkan jika incident cukup signifikan
Ringkasan #
- Postmortem bukan tentang siapa yang bersalah — ia tentang sistem yang perlu diperbaiki — blameless bukan berarti tanpa akuntabilitas, melainkan bahwa fokusnya pada proses dan tooling, bukan pada menghukum individu.
- RCA adalah input untuk postmortem, bukan penggantinya — postmortem yang hanya berisi analisis teknis tanpa refleksi proses dan action items konkret adalah postmortem yang tidak lengkap.
- 5 Whys membantu menemukan root cause yang sesungguhnya — jangan berhenti di jawaban pertama. “Human error” bukan root cause — itu gejala dari sistem yang gagal mendukung manusia di dalamnya.
- Timeline harus berdasarkan data, bukan ingatan — log, monitoring, dan alert history adalah sumber kebenaran. Rekonstruksi dari ingatan tidak akurat dan tidak bisa diandalkan.
- “Apa yang berjalan baik” sama pentingnya dengan “apa yang gagal” — mengidentifikasi yang berhasil membantu mempertahankan dan memperkuat praktik yang efektif, bukan hanya memperbaiki yang rusak.
- Action items yang tidak dikerjakan lebih buruk dari tidak ada action items — lebih baik 3 action item yang diselesaikan dari 10 yang diabaikan. Prioritas dan komitmen lebih penting dari kelengkapan daftar.
- Timing postmortem sangat penting — lakukan dalam 24–72 jam setelah incident resolved, saat detail masih segar dan momentum untuk berubah masih ada.
- Postmortem document adalah living document — perbarui status action items secara berkala sampai semua selesai. Dokumen yang berhenti diupdate kehilangan nilai accountability-nya.
- Simpan semua postmortem di satu tempat terindeks — pola yang berulang dari postmortem yang berbeda adalah sinyal kuat tentang kelemahan sistemik yang lebih dalam.
- Postmortem yang efektif terhubung dengan ekosistem dokumentasi lain — RFC untuk perbaikan arsitektur, reference document untuk standar baru, dan KSS untuk menyebarkan pembelajaran ke seluruh tim.