Panduan Lengkap Template Post-Mortem Insiden NOC untuk Tim Operasional

Masih inget banget insiden pertama yang bikin aku dapet "durian runtuh" dari atasan? Waktu itu tahun 2021, aku masih NOC junior dengan pengalaman baru setahun. Jam 2 pagi, HP bergetar gak berhenti. Client telpon panik, server produksi down total, dan tim butuh 3 jam buat recovery padahal target SLAnya cuma 1 jam. Capek, panik, setengah sadar — tapi ternyata itu cuma bagian awalnya.

Yang paling sakit ternyata bukan downtimenya. Bukan juga client yang ngamuk. Yang paling sakit itu meeting post-mortem keesokan harinya. Bayangin deh, meeting dua jam, tapi isinya cuma saling lempar kesalahan. Admin bilang network-nya yang bermasalah, network bilang aplikasinya yang gak bisa dibenerin, ujung-ujungnya gak ada satu catatan pun yang layak jadi pelajaran. Dari situ aku sadar satu hal — masalahnya bukan di teknis, tapi kami gak punya template post-mortem insiden NOC yang bener.

Ibaratnya begini, nek kecelakaan motor, motornya dibetulin terus dipakai lagi tanpa investigasi — kecelakaan yang sama hampir pasti kebawa lagi, mungkin malah lebih parah. Post-mortem insiden NOC itu fungsinya persis kayak investigasi kecelakaan: cari akar masalah, tentukan apa yang harus diubah, dan pastikan insiden gak kejadian dua kali. Masalahnya, banyak tim yang ngelewatin bagian ini karena kesannya ribet, males nulis, atau takut ketauan kalau-kalau ada kesalahan yang harus diakui. Padahal justru di situlah nilainya. Tanpa post-mortem yang terstruktur, setiap insiden cuma jadi pengulangan drama yang sama, dengan waktu recovery yang sama lamanya, dan mood tim yang makin buruk tiap kali. Kalau sampeyan kerja di tim yang gak pernah bikin post-mortem, aku yakin kamu ngerti banget perasaan ini.

Nah, gejala tim yang gak punya template yang bener itu gampang dikenali. Setiap insiden, pertanyaan yang sama muncul lagi: "Kok bisa down lagi?" Padahal dua bulan lalu insiden yang mirip udah pernah terjadi. Gak ada dokumentasi, gak ada follow-up, dan yang ada cuma janji lisan "next time diperhatiin". Eh, next time-nya datang, error yang sama muncul, dan siklusnya berulang terus. Capek, kan?

Kenapa siklus itu terus berulang? Biasanya karena tiga hal. Pertama, gak ada template yang jelas — orang nulis asal-asalan, intinya kabur-kaburan dan gak ada yang bisa di-track. Kedua, budaya saling menyalahkan — post-mortem jadi ajang pengadilan, bukan ajang belajar, jadi orang malah milih diem dan gak mau ngaku. Ketiga, gak ada action item yang konkret dan di-track — rapat selesai, semuanya lupa, deadline gak pernah ada. Dampaknya ya begitu-begitu aja: insiden yang sama terulang, MTTR gak pernah turun, client makin sering komplain, dan management mulai questioning kenapa tim NOC kok gak pernah improve. Padahal sebenarnya gampang banget buat mulai dari satu template yang baik. Gak perlu sempurna, cukup konsisten, dan dari sana tim bisa terus berkembang.

Kenapa Post-Mortem Sering Gagal di Lapangan?

Sebelum masuk ke template-nya, monggo kita bedah dulu kenapa post-mortem sering banget gagal. Kalau kita paham akar kegagalannya, kita jadi ngerti kenapa struktur template itu penting. Dari pengalamanku ngikutin banyak post-mortem — baik yang dipimpin aku maupun orang lain — kegagalan itu selalu berujung ke tiga pola yang sama.

Budaya yang Menyalahkan, Bukan Belajar

Ini pembunuh nomor satu. Post-mortem yang isinya "siapa yang salah" itu udah mati sebelum mulai. Orang bakal defensif, nutup-nutupin, dan pada akhirnya root cause yang sebenernya gak pernah kebuka. Padahal di infrastruktur yang sehat, hampir gak ada insiden yang murni kesalahan satu orang. Selalu ada rantai faktor: dokumentasi yang kurang, monitoring yang telat nge-alert, runbook yang gak diupdate, atau proses handover yang buruk. Nah, template yang baik itu dirancang biar fokus ke sistem dan proses, bukan ke individu. Setiap bagiannya harus ditulis dengan asumsi "kita semua tim yang sama".

Template yang Terlalu Rumit

Ada juga yang bikin post-mortem setebal buku tesis. Dua puluh halaman, tabel bertebaran, bahasa formal semua. Hasilnya? Ditulis sekali, gak pernah dibaca lagi. Post-mortem itu bukan buat dipajang, tapi buat dibaca — terutama dibaca ulang pas insiden berikutnya terjadi. Kalau template-nya gak ringkas, orang malas. Solusinya: buat versi yang gak lebih dari 1-2 halaman inti, dengan section yang bisa diisi cepat. Detail tambahan boleh, tapi di lampiran.

Action Item yang Gak Pernah Dikejar

Ini yang paling bikin aku sebal. Post-mortem kelar, meeting bubar, terus action item-nya diem di meja. Gak ada pemilik, gak ada deadline, gak ada follow-up di standup berikutnya. Enam bulan kemudian insiden yang sama kejadian lagi dan semua orang bengong: "kan udah dibahas waktu itu?" Ya, dibahas, tapi gak dieksekusi. Template yang baik wajib punya bagian action item dengan kolom pemilik, deadline, dan status — dan itu harus dicek di meeting rutin tim.

Template Post-Mortem Insiden NOC: Struktur Lengkap 7 Bagian

Ini dia intinya. Template yang kubagikan di bawah ini adalah hasil iterasi dari post-mortem yang pernah kutulis pas masih junior sampai yang sekarang kupakai buat nge-lead tim. Strukturnya tujuh bagian, dan tiap bagian punya fungsi spesifik. Kalau ada bagian yang gak relevan di insiden tertentu, tinggal isi "tidak berlaku" — tapi jangan dihapus, biar strukturnya tetap konsisten. Konsistensi itu penting banget, soalnya nanti tim bisa bandingin satu insiden sama insiden lain dalam format yang sama.

POST-MORTEM: [Judul singkat insiden]
===================================
1. RINGKASAN
   Ringkasan 2-3 kalimat.
   Kategori: Availability | Performance | Security | Data Loss
   Severity: SEV-1 s/d SEV-4
   Durasi: [mulai] - [selesai]
   Dampak: [ringkasan dampak]

2. KRONOLOGI (timeline, semua dalam UTC)
   [waktu] - [kejadian]
   [waktu] - [kejadian]
   ...

3. DAMPAK
   - % request gagal / error rate
   - durasi downtime total
   - jumlah user / layanan terpengaruh

4. ROOT CAUSE
   Satu kalimat penyebab paling dalam.

5. FAKTOR KONTRIBUSI
   - hal yang memperparah
   - hal yang bikin deteksi telat

6. ACTION ITEMS
   | # | Tindakan | Pemilik | Deadline | Status |

7. LESSONS LEARNED
   - pelajaran utama
   - yang bakal kami ubah di proses

1. Ringkasan Eksekutif

Bagian pertama ini buat siapa aja yang gak sempat baca detail — management, client, atau rekan dari tim lain. Tulis 2-3 kalimat yang menjawab: apa yang terjadi, kenapa itu penting, dan apa yang udah dilakukan biar gak kejadian lagi. Kategori dan severity langsung ditaruh di sini biar orang langsung bisa prioritasin. Kalau ada insiden yang parah, bagian ini juga yang biasanya dikirim ke client sebagai bentuk transparansi.

2. Kronologi Insiden

Timeline adalah tulang punggung post-mortem. Tanpa kronologi yang bener, kita gak akan bisa jawab pertanyaan krusial kayak "kenapa butuh 3 jam padahal masalahnya ketemu jam pertama?". Wajib semua timestamps dalam UTC biar gak bingung antara zona waktu on-call yang beda-beda. Dari pengalaman, kronologi paling baik diambil dari alert history, chat group, dan log. Jadi mulai sekarang biasain semua komunikasi insiden lewat satu channel, biar nanti gampang di-rekonstruksi. Nah, bagian ini juga tempatmu nulis delay-detect: kapan insiden mulai terjadi vs kapan tim baru sadar. Selisih itu sering jadi temuan paling berharga.

3. Penilaian Dampak

Angka yang jujur itu penting. Jangan dilebih-lebihin, jangan juga dikurangi. Catat berapa persen request yang gagal, berapa lama downtime, berapa user atau layanan yang terpengaruh. Kalau dampaknya soal data, sebutkan estimasi kehilangan datanya. Angka-angka ini yang bakal dipakai buat nentuin prioritas action item — makin parah dampaknya, makin cepat harus dieksekusi. Buat tim yang sudah pakai panduan monitoring server produksi, angka ini biasanya bisa diambil langsung dari dashboard.

4. Analisis Akar Masalah

Ini bagian yang paling sering dilewatin, padahal paling penting. Root cause bukan berarti "apa yang pertama kali keliatan salah", tapi "kenapa rantai kejadiannya sampai terjadi". Teknik favoritku adalah 5 Whys: tanya "kenapa?" lima kali berturut-turut dari gejala yang paling luar. Contoh: server down karena disk penuh → kenapa disk penuh? karena log gak di-rotate → kenapa log gak di-rotate? karena cron rotasi mati → kenapa cron mati? karena update package restart service tanpa cek — nah, di situ baru keliatan akar yang sebenernya. Root cause yang bagus itu biasanya bukan "human error", tapi proses atau sistem yang gagal nangkep human error.

5. Faktor yang Berkontribusi

Gak semua insiden punya satu penyebab tunggal. Sering ada beberapa faktor yang masing-masing gak fatal, tapi kalau digabung jadi bencana. Misalnya: monitoring yang threshold-nya kekecilan, ditambah on-call yang gak dapat alert karena filter email nyasar ke spam, ditambah runbook yang udah usang. Nulis ketiga faktor ini di bagian terpisah itu penting biar perbaikannya gak cuma nambal satu lubang doang. Semua faktor yang dicatat di sini harus punya action item-nya masing-masing nanti.

6. Action Items

Bagian ini yang bikin post-mortem beda dari sekadar catatan curhat. Setiap temuan harus diterjemahin jadi action item yang spesifik, punya pemilik, punya deadline, dan status yang jelas. Gak ada "kita harus lebih hati-hati" — itu bukan action item. Yang benar: "update cron rotasi log di server-01, owner: [nama], deadline: [tanggal], status: open". Track semua action item ini di kanban atau spreadsheet bersama, dan bahas di meeting rutin tiap minggu sampai semua closed. Kalau perlu, pakai setup alerting Grafana dan Prometheus sebagai bagian dari perbaikan biar deteksi berikutnya lebih cepet.

7. Pelajaran yang Diambil

Terakhir, refleksi singkat: apa yang paling berharga dari insiden ini? Ini bisa berupa insight teknis, bisa juga insight proses — misalnya "ternyata handover shift kita bolong di jam 3 pagi". Bagian ini biasanya jadi bahan buat update runbook. Kalau tim kamu belum punya runbook, ini momen yang pas buat mulai nyusun runbook insiden response tim NOC biar insiden berikutnya penanganannya lebih terarah.

Ini dia template post-mortem insiden NOC lengkap yang tadi kusebut. Biar lebih jelas, mari kita lihat gambarannya secara visual — struktur ini bisa dicetak atau dijadikan checklist digital buat tim.

Contoh Post-Mortem Singkat yang Pernah Kubuat

Biar makin kebayang, nih contoh post-mortem singkat dari insiden yang pernah kutangani di 2023. Server aplikasi client down jam 2 pagi karena disk penuh. Yang menarik, bukan disknya yang jadi masalah besar — tapi berapa lama tim baru sadar.

POST-MORTEM: High Disk Usage Caused Outage (2023)
==================================================
1. RINGKASAN
   Server web down 45 menit karena disk penuh. Log yang
   membengkak akibat tidak ada rotasi cron. Deteksi telat
   karena alert threshold salah. Fix sudah dipasang.

2. KRONOLOGI (UTC)
   19:10 - Disk mencapai 95%, alert threshold belum terpicu
   19:15 - Disk 100%, proses nulis gagal, service restart-loop
   19:40 - On-call sadar dari monitoring eksternal
   19:55 - Investigasi: df -h menunjukkan disk 100%
   20:10 - Bersihkan log + pasang rotasi, service normal
   20:25 - Monitoring recovery

3. DAMPAK
   - 45 menit downtime
   - Error rate 100% selama downtime
   - 0 user terpengaruh signifikan (jam 2 pagi lokal)

4. ROOT CAUSE
   Cron rotasi log tidak terpasang sejak migrasi server.

5. FAKTOR KONTRIBUSI
   - Alert threshold disk di setting 95%, terlambat.
   - Tidak ada tes restore/handover setelah migrasi.

6. ACTION ITEMS
   | 1 | Pasang logrotate semua server | [nama] | +3 hari | open |
   | 2 | Ubah alert disk ke 80%          | [nama] | +2 hari | open |
   | 3 | Tambah cek servis restart-loop  | [nama] | +7 hari | open |

7. LESSONS LEARNED
   Setelah migrasi, selalu verifikasi cron dan alert yang
   ikut terpindah. Jangan anggap konfigurasi ikut dengan
   sendirinya.

Nah, dari contoh di atas, perhatiin gimana tiap bagian diisi singkat tapi lengkap. Setiap action item punya pemilik dan deadline. Dan yang penting, root cause-nya bukan "admin lupa", tapi proses migrasi yang gak ada checklist verifikasinya. Itu yang bikin post-mortem ini gak terasa kayak nyalahin orang.

Tabel Referensi Cepat Bagian Template

Kalau sampeyan butuh ringkasan cepat, tabel di bawah ini merangkum fungsi tiap bagian dan contoh isinya. Simpan atau cetak tabel ini buat dijadikan acuan pas nulis post-mortem pertama kali.

Tips Menulis Post-Mortem yang Gak Buang-Buang Waktu

Kumpulan pengalaman ini semoga membantu. Beberapa hal yang menurutku penting banget pas nulis post-mortem, berdasarkan kesalahan yang sering kulihat di lapangan:

• Nulis segera — jangan nunggu seminggu. Memory tim masih segar maksimal 48 jam setelah insiden. Setelah itu, detail penting mulai hilang dan orang mulai lupain urutan kejadian. Idealnya draft pertama kelar sebelum meeting.
• Bikin blameless — aturan main: siapapun boleh salah, dan gak ada yang dihukum karena root cause. Post-mortem yang bagus malah bikin orang berani lapor error lebih cepet, karena tahu gak bakal disalahin.
• Kronologi dari data, bukan ingatan — ambil dari alert history, log, dan chat. Ingatan manusia itu gak bisa dipercaya pas lagi panik.
• Jangan terlalu panjang — inti 1-2 halaman. Detail teknis taruh di lampiran.
• Action item yang bisa dieksekusi — spesifik, terukur, ada pemiliknya. Dan follow-up terus sampai closed.

Oh ya, satu lagi — kalau insidennya sampai bikin client nanya-nanya, post-mortem versi public (bisa dibaca client) dan versi internal itu beda. Versi internal boleh se-ngeri apa pun, versi public cukup ringkas dan fokus ke transparansi dampak plus perbaikan. Tapi intinya tetep struktur yang sama, biar konsisten.

FAQ

Wis gitu aja ceritanya. Post-mortem yang baik itu sebenernya gak susah — yang susah itu konsisten nulisnya. Tapi percaya deh, dari pengalamanku yang sekarang udah lewat puluhan insiden, investasi waktu 30-60 menit per insiden itu jauh lebih murah daripada nge-handle insiden yang sama dua kali. Mulai dari insiden terakhir yang timmu tangani, isi template ini, dan lihat gimana perbedaannya di insiden berikutnya. Kalau kamu punya pengalaman post-mortem yang seru — entah yang paling parah atau yang paling berhasil — share di kolom komentar ya, aku juga pengen denger ceritanya. Matur nuwun udah baca sampai sini.