Desember adalah saat saya menelusuri kembali log insiden sepanjang tahun. Bukan untuk mengungkit siapa yang merusak apa, tapi untuk mengecek apakah kita benar-benar mendapatkan pelajaran yang lebih murah dari kegagalan kita dibanding biaya yang sudah dikeluarkan. Itulah inti dari postmortem insiden: outage atau peluncuran gagal itu mahal apa pun yang Anda lakukan setelahnya, jadi satu-satunya pertanyaan yang layak diajukan adalah apakah Anda setidaknya membeli sebuah pelajaran dengan biaya itu.

Kebanyakan tim yang saya temui tidak pernah menjalankan postmortem sama sekali, atau menjalankan sesuatu yang terlihat seperti postmortem tapi sebenarnya sesi saling menyalahkan dengan undangan kalender. Keduanya tidak menghasilkan pelajaran apa pun. Kalau tidak ada yang ditulis, root cause yang sama akan muncul lagi enam bulan kemudian dengan gejala yang berbeda. Kalau postmortem berubah jadi ajang mencari siapa yang mendorong config yang salah, orang mulai menyembunyikan near-miss alih-alih melaporkannya, dan Anda kehilangan visibilitas atas kegagalan yang belum terjadi.

Saya menjalankan postmortem untuk setiap insiden produksi dan setiap peluncuran yang meleset dari jadwalnya cukup parah untuk terasa menyakitkan, tanpa saling menyalahkan by design, menggunakan lima pertanyaan yang muat dalam satu halaman dan selesai dalam waktu kurang dari satu jam dengan orang yang tepat di ruangan.

Kenapa "tanpa saling menyalahkan" bukan sekadar basa-basi soft skill

Tanpa saling menyalahkan bukan berarti tidak ada yang bertanggung jawab. Artinya, tugas dokumen ini adalah menemukan kondisi yang membuat kegagalan itu bisa terjadi, bukan orang yang kebetulan sedang memegang pager. Hukum orangnya, dan Anda akan mendapatkan organisasi di mana insiden dilaporkan terlambat, diam-diam, atau tidak dilaporkan sama sekali, karena tidak ada yang mau namanya muncul di timeline. Itu lebih buruk dari outage mana pun: Anda kehilangan sistem peringatan dini Anda sendiri.

Bisnis yang paling cepat pulih dari kegagalan berulang adalah yang budayanya memungkinkan seorang engineer berkata "menurut saya ini gara-gara saya" di sepuluh menit pertama, karena mereka tahu kalimat itu akan mendatangkan bantuan, bukan laporan dengan nama mereka di judul. Itu keputusan budaya, dibuat sekali, yang terbayar di setiap insiden berikutnya.

Template lima pertanyaan

Lewati template rumit dengan dua belas bagian yang tidak akan dibaca siapa pun. Lima pertanyaan, satu halaman, selesai dalam 48 jam selagi ingatan masih segar.

  1. Apa yang terjadi, dalam bahasa yang jelas, lengkap dengan timeline. Waktu deteksi, respons pertama, waktu resolusi. Tanpa jargon, tanpa bahasa yang menyalahkan ("deployment gagal", bukan "seseorang deploy secara ceroboh").
  2. Apa dampak nyata terhadap customer atau bisnis. Menit downtime, transaksi yang hilang, refund yang diterbitkan, tiket yang tercipta. Angka, bukan kata sifat.
  3. Apa root cause-nya, dan apa saja faktor yang berkontribusi. Root cause jarang cuma satu hal. Migrasi yang buruk adalah pemicunya; ketiadaan staging parity dan tidak adanya rencana rollback adalah faktor kontribusi yang mengubah blip lima menit jadi outage dua jam.
  4. Apa yang berjalan baik. Selalu sertakan ini. Ini menunjukkan bagian dari respons insiden Anda yang perlu dipertahankan, dan mencegah dokumen ini terbaca sebagai dakwaan murni.
  5. Apa yang akan kita ubah, lengkap dengan pemilik dan tanggal. Bukan "kita akan memperbaiki monitoring." Spesifik: "Tambahkan alert untuk queue depth di atas 500, dimiliki oleh [nama], selesai pada [tanggal]." Postmortem tanpa action item yang bertanggal adalah catatan harian, bukan perbaikan proses.

Contoh kasus nyata

Sebuah perusahaan multifinance yang pernah saya tangani punya pola berulang: batch settlement job gagal semalaman, baru ketahuan oleh tim operasional jam 8 pagi, lalu dieskalasi dalam keadaan dingin. Tiga insiden dalam dua bulan, tiap postmortem menyalahkan "script-nya." Setelah kami memaksakan format lima pertanyaan, pertanyaan ketiga mengungkap faktor kontribusi sebenarnya setiap kali: tidak ada alerting saat job gagal, sehingga satu-satunya mekanisme deteksi adalah manusia yang menyadari data hilang keesokan paginya. Satu action item, alert saat job gagal, memperbaiki ketiga insiden yang "berbeda-beda" itu karena ternyata berbagi root cause yang sama. Itulah nilai yang diberikan postmortem insiden dan tidak bisa diberikan oleh bug ticket biasa: ia melihat sistem di sekitar kegagalan, bukan sekadar kegagalannya saja.

Menjalankan retro tanpa berubah jadi sidang

Beberapa mekanisme yang menjaga ruangan tetap bebas dari saling menyalahkan dalam praktiknya, bukan cuma di atas kertas:

  • Fasilitator bukan orang yang menyebabkan insiden, dan idealnya bukan juga atasan langsungnya.
  • Tulis timeline dari log dan timestamp lebih dulu, sebelum ada yang bicara, supaya diskusi dimulai dari fakta, bukan dari ingatan dan sikap defensif.
  • Larang frasa "seharusnya" di dalam ruangan. Frasa itu selalu mengarah ke seseorang. Ganti dengan "sistem tidak menangkap ini."
  • Publikasikan postmortem di tempat yang bisa dibaca seluruh tim engineering, bukan cuma leadership. Pelajarannya baru berlipat ganda kalau lebih dari tiga orang mempelajarinya.

Di mana postmortem cocok masuk dalam review akhir tahun Anda

Kalau Anda hanya sempat melakukan satu hal sebelum Januari, tarik semua insiden tahun ini dan cek dua hal: apakah setiap insiden punya action item bertanggal, dan apakah action item itu benar-benar diselesaikan. Kebanyakan tim cukup baik dalam menulis bagian pertama tapi buruk dalam menutup loop bagian kedua. Postmortem insiden dengan action item yang belum selesai adalah pelajaran yang sudah Anda bayar tapi belum Anda cairkan, dan menutup celah itu sering kali lebih murah dibanding tooling baru apa pun yang sedang Anda pertimbangkan untuk tahun depan, topik yang layak dibahas tersendiri saat Anda menentukan prioritas inisiatif teknologi untuk tahun baru.

Kesimpulannya

Postmortem insiden bukan pekerjaan administratif, ini cara memastikan kegagalan mahal hanya terjadi satu kali. Jaga agar tetap tanpa saling menyalahkan, jaga agar tetap lima pertanyaan, dan jangan pernah menutup satu postmortem tanpa pemilik dan tanggal yang jelas. Kalau postmortem Anda selama ini berakhir dengan "kami akan lebih hati-hati," Anda bukan menjalankan postmortem, Anda menjalankan eulogi. Perbaiki itu sebelum outage berikutnya, bukan sesudahnya.