Post-Mortem Culture: Cara Aman Belajar dari Kegagalan Sistem

Ketika sistem mengalami gangguan, prioritas utama perusahaan biasanya sangat jelas: pulihkan layanan secepat mungkin.

Developer memeriksa log. Tim infrastruktur menambah resource. Database dikembalikan dari backup. Deployment terakhir di-rollback. Customer support menjawab pertanyaan pengguna, sementara manajemen menunggu kepastian kapan operasional kembali normal.

Setelah sistem berhasil dipulihkan, tekanan mulai menurun.

Tim menyampaikan bahwa masalah telah selesai, pengguna dapat kembali bekerja, dan aktivitas bisnis berjalan seperti biasa. Semua orang kemudian kembali ke pekerjaan sebelumnya.

Beberapa minggu atau bulan kemudian, gangguan serupa muncul kembali.

Penyebab teknisnya mungkin terlihat berbeda. Kali ini database kehabisan koneksi, sebelumnya queue menumpuk, dan pada insiden berikutnya deployment gagal. Namun, pola dasarnya sama: monitoring tidak cukup, perubahan tidak diuji pada kondisi yang relevan, dependency tidak dipahami, atau keputusan sementara tidak pernah ditindaklanjuti.

Perusahaan berhasil memulihkan layanan, tetapi gagal mempelajari insidennya.

Inilah alasan perusahaan membutuhkan post-mortem culture.

Post-mortem culture adalah budaya dan proses yang memastikan setiap insiden penting tidak hanya ditutup setelah layanan pulih, tetapi dianalisis secara terstruktur untuk memahami apa yang terjadi, mengapa mekanisme perlindungan gagal, dan perubahan apa yang harus dilakukan agar kejadian serupa tidak terulang.

Tujuannya bukan menemukan siapa yang melakukan kesalahan.

Tujuannya adalah mengubah insiden menjadi pengetahuan organisasi.

Tanpa proses tersebut, pengalaman hanya tersimpan dalam ingatan beberapa orang yang terlibat. Ketika anggota tim berpindah, proyek berkembang, atau tekanan bisnis kembali meningkat, perusahaan berisiko mengulangi kesalahan yang sama.

Apa Itu Incident Post-Mortem?

Google Cloud mendefinisikan post-mortem sebagai catatan tertulis mengenai insiden, dampaknya, tindakan yang dilakukan untuk memulihkan layanan, penyebabnya, dan tindak lanjut yang diperlukan untuk mencegah kejadian berulang.

Proses ini juga dikenal dengan beberapa nama lain:

• Post-incident review.
• Incident review.
• After-action review.
• Learning review.
• Root cause analysis.
• Incident retrospective.
• Problem review.

Nama yang digunakan tidak terlalu penting. Hal yang lebih penting adalah apakah proses tersebut menghasilkan pembelajaran dan perubahan nyata.

Sebuah post-mortem yang baik setidaknya menjawab lima pertanyaan:

1. Apa yang sebenarnya terjadi?
2. Apa dampaknya terhadap pengguna dan bisnis?
3. Bagaimana tim mendeteksi dan memulihkan layanan?
4. Kondisi apa saja yang memungkinkan insiden terjadi?
5. Apa yang akan diubah setelah insiden?

Post-mortem bukan sekadar laporan kronologi.

Dokumen yang hanya menyebut waktu sistem mati, nama engineer yang melakukan rollback, dan waktu layanan kembali normal belum tentu menghasilkan pembelajaran.

Perusahaan perlu memahami bagaimana desain sistem, proses, tools, komunikasi, monitoring, dan keputusan organisasi berkontribusi terhadap insiden tersebut.

Incident Management dan Post-Mortem Memiliki Fungsi Berbeda

Incident management dan post-mortem sering dianggap sebagai proses yang sama. Padahal, keduanya memiliki fokus berbeda.

Incident management berfokus pada pengendalian situasi ketika gangguan masih berlangsung.

Pertanyaan utamanya adalah:

• Apa yang terdampak?
• Siapa yang harus dilibatkan?
• Bagaimana layanan dipulihkan?
• Apakah perubahan perlu di-rollback?
• Bagaimana pengguna diberi informasi?
• Apa prioritas selama insiden?

Post-mortem dilakukan setelah kondisi stabil.

Pertanyaannya berubah menjadi:

• Mengapa sistem dapat mencapai kondisi tersebut?
• Mengapa monitoring tidak mendeteksinya lebih awal?
• Mengapa tindakan tertentu dianggap benar saat itu?
• Apa yang memperlambat proses pemulihan?
• Perlindungan apa yang seharusnya tersedia?
• Bagaimana mencegah atau mengurangi dampak kejadian berikutnya?

Perusahaan dapat memiliki proses incident response yang cepat tetapi tetap mengalami insiden berulang jika hasil pembelajarannya tidak pernah diterapkan.

Sebaliknya, analisis panjang juga tidak memberikan nilai jika layanan tidak dapat dipulihkan dengan efektif.

Keduanya harus menjadi bagian dari satu siklus yang utuh.

Mengapa Banyak Perusahaan Mengulang Insiden yang Sama?

Fokus Berhenti pada Pemulihan Layanan

Ketika sistem kembali normal, insiden sering dianggap selesai.

Padahal, pemulihan hanya menghilangkan gejala yang sedang terlihat. Penyebab dan kondisi yang memungkinkan kegagalan mungkin masih berada di dalam sistem.

Sebagai contoh, restart server dapat mengembalikan layanan. Namun, tindakan tersebut tidak menjawab mengapa memory terus bertambah, mengapa alert tidak aktif, atau mengapa sistem tidak dapat pulih secara otomatis.

Tim Terlalu Cepat Menyimpulkan Human Error

Kalimat seperti “engineer salah menjalankan script” atau “developer lupa memeriksa konfigurasi” terlihat seperti penjelasan.

Namun, penjelasan tersebut menghentikan analisis terlalu dini.

Perusahaan seharusnya melanjutkan pertanyaannya:

• Mengapa script berbahaya dapat dijalankan tanpa validasi?
• Mengapa tidak tersedia preview perubahan?
• Mengapa satu orang dapat mengeksekusi tindakan kritis tanpa approval?
• Mengapa environment production mudah tertukar?
• Mengapa backup atau rollback tidak dapat digunakan dengan cepat?
• Mengapa risiko tersebut tidak diketahui sebelumnya?

Kesalahan manusia mungkin menjadi bagian dari kronologi, tetapi jarang menjadi satu-satunya penyebab insiden kompleks.

Tidak Ada Dokumentasi yang Terstruktur

Diskusi setelah insiden sering dilakukan melalui chat atau meeting singkat.

Informasi tersebar di banyak tempat:

• Log aplikasi.
• Percakapan grup.
• Ticket support.
• Riwayat deployment.
• Monitoring dashboard.
• Catatan pribadi engineer.
• Email kepada manajemen.
• Laporan vendor.

Tanpa satu dokumen terpusat, perusahaan sulit membangun gambaran yang utuh dan menggunakan insiden sebagai referensi pada masa depan.

Action Item Tidak Memiliki Owner

Post-mortem mungkin menghasilkan daftar rekomendasi seperti:

• Tingkatkan monitoring.
• Perbaiki proses deployment.
• Tambahkan testing.
• Evaluasi database.
• Tingkatkan dokumentasi.

Masalahnya, rekomendasi tersebut terlalu umum.

Tidak jelas siapa yang bertanggung jawab, apa hasil akhirnya, kapan harus selesai, dan bagaimana perusahaan memastikan bahwa tindakan tersebut benar-benar mengurangi risiko.

Akibatnya, action item kalah prioritas dari pengembangan fitur dan tidak pernah diselesaikan.

Perusahaan Menghukum Orang yang Terbuka

Post-mortem membutuhkan informasi yang jujur.

Jika engineer merasa bahwa pengakuan terhadap kesalahan dapat merusak karier atau reputasinya, ia memiliki insentif untuk menyederhanakan kronologi, menyembunyikan detail, atau mengalihkan tanggung jawab.

Perusahaan akhirnya mendapatkan laporan yang aman secara politik, tetapi tidak akurat secara teknis.

Pengetahuan Tidak Disebarkan

Satu tim mungkin sudah memahami pelajaran dari sebuah insiden, tetapi tim lain tidak pernah membaca hasilnya.

Beberapa bulan kemudian, pola kegagalan yang sama muncul pada produk berbeda.

Tanpa repository dan proses berbagi pengetahuan, perusahaan hanya menciptakan pembelajaran lokal, bukan pembelajaran organisasi.

Apa Arti Blameless Post-Mortem?

Blameless post-mortem adalah proses analisis insiden yang tidak berfokus pada menyalahkan individu.

Pendekatan ini mengasumsikan bahwa orang yang terlibat mengambil keputusan berdasarkan informasi, tekanan, tools, dan kondisi yang tersedia saat itu.

Google SRE dan Atlassian menggunakan pendekatan blameless agar tim dapat membicarakan insiden secara jujur dan memahami bagaimana sistem serta proses memungkinkan kesalahan terjadi.

Blameless bukan berarti tidak ada tanggung jawab.

Perusahaan tetap membutuhkan:

• Owner untuk setiap layanan.
• Standar yang harus dipenuhi.
• Action item yang harus diselesaikan.
• Review terhadap keputusan.
• Perbaikan proses.
• Konsekuensi untuk pelanggaran yang disengaja.
• Eskalasi terhadap risiko yang diabaikan.

Perbedaannya terletak pada fokus analisis.

Pendekatan yang menyalahkan bertanya:

“Siapa yang membuat sistem gagal?”

Pendekatan blameless bertanya:

“Mengapa tindakan tersebut masuk akal bagi orang yang melakukannya, dan mengapa sistem tidak mencegah atau membatasi dampaknya?”

Misalnya, seorang developer melakukan deployment yang menyebabkan outage.

Analisis yang dangkal akan menyimpulkan bahwa developer tersebut kurang teliti.

Analisis blameless akan memeriksa:

• Apakah perubahan melalui code review?
• Apakah automated test tersedia?
• Apakah deployment dilakukan bertahap?
• Apakah feature flag digunakan?
• Apakah rollback dapat dilakukan dengan cepat?
• Apakah environment production memiliki perlindungan?
• Apakah developer berada di bawah tekanan deadline?
• Apakah perubahan serupa pernah berhasil sebelumnya?
• Apakah dokumentasi deployment sudah jelas?

Pertanyaan tersebut menghasilkan kontrol yang dapat melindungi seluruh tim, bukan hanya peringatan agar satu orang lebih berhati-hati.

Blameless Bukan Berarti Root Cause Tidak Penting

Post-mortem tetap membutuhkan analisis penyebab.

Namun, istilah “root cause” dapat menyesatkan apabila perusahaan mencari satu penyebab tunggal untuk sistem yang kompleks.

Insiden biasanya terbentuk dari kombinasi beberapa faktor:

• Bug pada aplikasi.
• Konfigurasi yang tidak tepat.
• Monitoring yang tidak lengkap.
• Dependency yang gagal.
• Prosedur yang tidak jelas.
• Test coverage yang kurang.
• Beban yang tidak pernah diuji.
• Komunikasi yang terlambat.
• Akses yang terlalu luas.
• Kurangnya mekanisme rollback.

Bug mungkin menjadi pemicu langsung. Namun, insiden menjadi besar karena beberapa lapisan perlindungan gagal secara bersamaan.

Karena itu, post-mortem sebaiknya membedakan:

Trigger

Peristiwa yang memulai insiden.

Contoh: deployment versi baru.

Direct Cause

Mekanisme teknis yang menyebabkan layanan gagal.

Contoh: perubahan schema membuat aplikasi tidak dapat membaca data.

Contributing Factors

Kondisi yang memperbesar kemungkinan atau dampak kegagalan.

Contoh: tidak tersedia compatibility test, deployment langsung dilakukan ke seluruh pengguna, dan rollback membutuhkan proses manual.

Detection Gap

Alasan masalah tidak diketahui lebih cepat.

Contoh: alert hanya memantau CPU, sementara error aplikasi meningkat tanpa terdeteksi.

Recovery Gap

Alasan pemulihan membutuhkan waktu lebih lama.

Contoh: runbook tidak tersedia dan hanya satu engineer memahami proses rollback.

Struktur tersebut menghasilkan pemahaman yang lebih lengkap daripada sekadar mencatat “deployment error”.

Kapan Perusahaan Perlu Melakukan Post-Mortem?

Tidak semua error kecil membutuhkan meeting dan laporan panjang.

Perusahaan perlu menetapkan kriteria sebelum insiden terjadi agar keputusan tidak bergantung pada suasana setelah gangguan.

Google Cloud merekomendasikan post-mortem untuk kondisi seperti downtime atau degradasi yang terlihat pengguna, kehilangan data, rollback atau intervensi on-call, waktu pemulihan yang melewati batas, serta kegagalan monitoring.

Kriteria perusahaan dapat mencakup:

• Layanan tidak tersedia lebih dari batas tertentu.
• Pengguna tidak dapat menyelesaikan proses kritis.
• Data hilang, rusak, atau tidak konsisten.
• Terjadi pelanggaran keamanan.
• Deployment harus di-rollback.
• Transaksi harus diperbaiki secara manual.
• SLA tidak terpenuhi.
• Incident commander harus diaktifkan.
• Gangguan berdampak pada banyak divisi.
• Masalah baru diketahui melalui laporan pelanggan.
• Insiden berpotensi terjadi lagi.
• Near miss memiliki potensi dampak besar.

Near miss juga layak dianalisis.

Sebagai contoh, engineer mungkin menemukan kesalahan konfigurasi sebelum deployment menyebabkan outage. Karena tidak ada pengguna yang terdampak, perusahaan dapat mengabaikannya.

Padahal, near miss memberikan kesempatan belajar dengan biaya yang jauh lebih rendah.

Tentukan Tingkat Kedalaman Berdasarkan Risiko

Post-mortem tidak harus selalu menjadi dokumen puluhan halaman.

Pendekatan berbasis risiko menjaga proses tetap proporsional.

Jika setiap error kecil membutuhkan prosedur berat, tim akan menganggap post-mortem sebagai beban administratif. Sebaliknya, jika hanya outage besar yang dianalisis, perusahaan kehilangan banyak kesempatan belajar.

Struktur Dokumen Post-Mortem

1. Ringkasan Eksekutif

Jelaskan insiden dalam bahasa yang dapat dipahami pembaca nonteknis.

Ringkasan mencakup:

• Apa yang terganggu?
• Siapa yang terdampak?
• Berapa lama gangguan berlangsung?
• Bagaimana layanan dipulihkan?
• Apa penyebab utamanya?
• Apa tindakan terpenting setelah insiden?

2. Dampak Bisnis dan Pengguna

Jangan hanya mencatat CPU, error, dan server.

Ukur dampak nyata, seperti:

• Jumlah pengguna terdampak.
• Transaksi gagal.
• Waktu operasional yang hilang.
• Cabang atau divisi terdampak.
• Data yang perlu diperbaiki.
• Pelanggaran SLA.
• Pendapatan yang tertunda atau hilang.
• Ticket customer support.
• Aktivitas manual selama recovery.

Bagian ini membantu manajemen memahami prioritas tindak lanjut.

3. Timeline

Buat kronologi berdasarkan waktu.

Contohnya:

Timeline harus berbasis fakta dari log, alert, chat, dan riwayat deployment.

Hindari menyesuaikan kronologi agar terlihat lebih rapi daripada kondisi sebenarnya.

4. Detection

Jelaskan bagaimana insiden diketahui.

Apakah alert mendeteksinya, tim operasional melapor, atau pelanggan yang pertama kali memberi tahu?

Jika pelanggan menemukan masalah sebelum monitoring, perusahaan perlu mengevaluasi detection gap.

5. Response dan Recovery

Catat tindakan yang dilakukan selama insiden:

• Siapa yang memimpin?
• Siapa yang dilibatkan?
• Hipotesis apa yang diperiksa?
• Mitigasi apa yang dicoba?
• Tindakan mana yang berhasil?
• Tindakan mana yang memperlambat recovery?
• Bagaimana komunikasi dilakukan?
• Apakah runbook tersedia?

Post-mortem tidak hanya mengevaluasi penyebab teknis. Efektivitas incident response juga perlu diperiksa.

6. Trigger dan Faktor Pendukung

Pisahkan pemicu langsung dari kondisi yang memungkinkan dampak membesar.

Contohnya:

Trigger: perubahan konfigurasi database.

Faktor pendukung:

• Tidak ada validation check.
• Perubahan tidak diuji pada data production-like.
• Deployment tidak menggunakan phased rollout.
• Monitoring tidak memeriksa error aplikasi.
• Rollback masih manual.
• Dokumentasi konfigurasi tidak lengkap.

7. Hal yang Berjalan Baik

Post-mortem tidak hanya mencari kegagalan.

Catat hal-hal yang membantu tim, misalnya:

• Engineer merespons alert dengan cepat.
• Backup dapat digunakan.
• Komunikasi lintas tim berjalan baik.
• Feature flag membantu membatasi dampak.
• Runbook mempercepat recovery.
• Customer support memberikan informasi yang konsisten.

Praktik yang berhasil perlu dipertahankan dan diterapkan ke sistem lain.

8. Hal yang Perlu Diperbaiki

Identifikasi kelemahan secara spesifik.

Hindari kalimat umum seperti “tim perlu lebih berhati-hati”.

Gunakan pernyataan yang dapat ditindaklanjuti, seperti:

• Alert tidak mencakup peningkatan error pada endpoint pembayaran.
• Rollback membutuhkan akses manual dari engineer tertentu.
• Tidak tersedia pengujian backward compatibility untuk perubahan schema.
• Contact list incident response sudah tidak diperbarui.
• Dashboard tidak menampilkan backlog queue.

9. Action Item

Setiap action item harus memiliki:

• Tindakan spesifik.
• Owner.
• Deadline.
• Prioritas.
• Status.
• Bukti penyelesaian.
• Risiko yang dikurangi.

Contohnya:

Atlassian menyarankan action item ditulis sebagai tindakan spesifik yang dimulai dengan kata kerja. “Tambahkan alert” lebih jelas daripada “investigasi monitoring”.

Proses Post-Mortem yang Praktis

Tahap 1: Tunjuk Satu Owner

Setelah insiden selesai, tunjuk satu orang untuk mengoordinasikan post-mortem.

Owner bukan pihak yang disalahkan dan tidak harus menulis seluruh dokumen sendiri.

Tugasnya adalah memastikan informasi terkumpul, meeting dijadwalkan, stakeholder dilibatkan, dan action item dilacak.

PagerDuty menekankan pentingnya satu owner agar tanggung jawab tidak hilang karena semua orang mengira orang lain akan mengerjakannya.

Tahap 2: Kumpulkan Fakta Saat Masih Segar

Segera kumpulkan:

• Log.
• Screenshot monitoring.
• Timeline chat.
• Riwayat deployment.
• Ticket support.
• Perubahan konfigurasi.
• Keputusan selama insiden.
• Metrik bisnis.

Jangan mengandalkan ingatan beberapa hari kemudian.

Tahap 3: Susun Draft Sebelum Meeting

Meeting akan lebih efektif jika peserta sudah memiliki timeline dan fakta awal.

Waktu meeting sebaiknya digunakan untuk menguji asumsi, menemukan contributing factors, dan menyepakati action item—bukan membaca kronologi dari awal.

Tahap 4: Buka Meeting dengan Prinsip Blameless

Fasilitator perlu menjelaskan bahwa tujuan meeting adalah memperbaiki sistem dan proses.

Peserta harus dapat membicarakan keputusan secara jujur tanpa takut dipermalukan.

Tahap 5: Bedakan Fakta dan Interpretasi

Contoh fakta:

Error rate meningkat menjadi 20% setelah deployment.

Contoh interpretasi:

Developer tidak cukup berhati-hati.

Post-mortem perlu memulai dari fakta yang dapat diverifikasi sebelum menyusun causal chain.

Tahap 6: Tetapkan Action Item yang Proporsional

Tidak semua insiden memerlukan rewrite sistem.

Google Cloud mengingatkan agar tim tidak menciptakan solusi yang terlalu kompleks untuk kejadian yang kecil kemungkinan terulang.

Tindakan perlu disesuaikan dengan kemungkinan dan dampaknya.

Tahap 7: Review dan Publikasikan

Post-mortem perlu ditinjau oleh service owner, tim terdampak, dan stakeholder yang relevan.

Setelah disetujui, dokumen disimpan dalam repository yang dapat dicari oleh tim lain.

Tahap 8: Pantau hingga Action Item Selesai

Post-mortem belum selesai ketika meeting berakhir.

Proses selesai ketika action item penting telah diimplementasikan, diuji, dan diverifikasi.

Mengapa Action Item Sering Gagal?

Terlalu Umum

“Perbaiki monitoring” tidak memiliki definisi selesai.

Ubah menjadi:

Tambahkan alert ketika p95 response time endpoint checkout melebihi dua detik selama lima menit.

Tidak Dikaitkan dengan Risiko

Action item teknis kalah prioritas karena manajemen tidak memahami dampaknya.

Jelaskan insiden atau risiko apa yang dikurangi oleh setiap tindakan.

Tidak Memiliki Deadline

Pekerjaan tanpa deadline akan terus kalah dari fitur baru.

Terlalu Besar

“Rewrite seluruh backend” sulit diselesaikan sebagai tindak lanjut satu insiden.

Pecah menjadi tindakan awal yang realistis, seperti memisahkan modul kritis, menambah test, atau mengurangi dependency tertentu.

Tidak Pernah Diverifikasi

Ticket ditutup setelah kode ditulis, tetapi kontrol tidak pernah diuji.

Alert perlu disimulasikan. Rollback perlu dicoba. Backup perlu dipulihkan. Runbook perlu digunakan oleh orang yang tidak menulisnya.

Metrik untuk Menilai Post-Mortem Culture

Repeat Incident Rate

Berapa banyak insiden yang berasal dari pola penyebab yang pernah ditemukan sebelumnya?

Insiden berulang menunjukkan pembelajaran atau action item belum efektif.

Action Item Completion Rate

Berapa persen action item selesai sesuai deadline?

Pisahkan action item kritis dari perbaikan minor.

Time to Complete Post-Mortem

Berapa lama waktu dari layanan pulih hingga dokumen dan review selesai?

Post-mortem yang terlalu lama ditunda kehilangan konteks.

Time to Complete Priority Actions

Berapa lama tindakan pencegahan utama benar-benar diterapkan?

Detection Source

Berapa banyak insiden ditemukan oleh monitoring dibandingkan laporan pengguna?

Mean Time to Detect dan Mean Time to Restore

Apakah pembelajaran membuat perusahaan mendeteksi dan memulihkan gangguan lebih cepat?

Recurring Contributing Factors

Kelompokkan pola seperti:

• Monitoring.
• Deployment.
• Capacity.
• Dependency.
• Database.
• Access control.
• Documentation.
• Testing.
• Communication.

Jika banyak insiden memiliki faktor yang sama, perusahaan membutuhkan perbaikan lintas sistem, bukan patch lokal.

Kesalahan yang Membuat Post-Mortem Tidak Efektif

Menggunakan Post-Mortem sebagai Sidang

Meeting berubah menjadi usaha membuktikan siapa yang bersalah.

Hasilnya adalah informasi yang disaring dan budaya defensif.

Mencari Satu Root Cause

Sistem kompleks biasanya gagal karena beberapa faktor berinteraksi.

Menulis Dokumen Terlalu Panjang tanpa Keputusan

Detail teknis banyak, tetapi tidak ada action item yang jelas.

Membuat Action Item untuk “Lebih Berhati-hati”

Kehati-hatian bukan kontrol sistem yang dapat diukur.

Tidak Mengundang Tim Bisnis

Dampak dan prioritas dapat disalahpahami jika hanya dilihat dari sisi teknis.

Tidak Membahas Hal yang Berjalan Baik

Tim kehilangan kesempatan untuk memperkuat mekanisme yang terbukti membantu.

Menutup Action Item tanpa Pengujian

Kontrol baru dianggap selesai meskipun belum pernah dibuktikan.

Menyimpan Dokumen tetapi Tidak Menyebarkannya

Post-mortem berubah menjadi arsip, bukan pengetahuan organisasi.

Melakukan Post-Mortem untuk Semua Hal secara Berlebihan

Proses menjadi terlalu berat dan akhirnya dihindari.

Gunakan kriteria serta tingkat kedalaman berdasarkan risiko.

Post-Mortem untuk Tim Kecil

Post-mortem culture tidak hanya relevan untuk perusahaan teknologi besar.

Tim kecil dapat memulai dengan proses sederhana:

1. Gunakan satu template.
2. Lakukan review hanya untuk insiden penting.
3. Batasi meeting sekitar 45–60 menit.
4. Tetapkan satu owner.
5. Prioritaskan maksimal tiga action item utama.
6. Simpan dokumen pada lokasi bersama.
7. Review action item setiap minggu.
8. Bagikan pembelajaran pada tim.

Perusahaan tidak membutuhkan platform incident management mahal untuk memulai.

Spreadsheet, task management tool, dan dokumen bersama sudah cukup selama prosesnya konsisten.

Perlukah Post-Mortem Dibagikan kepada Pelanggan?

Tidak semua post-mortem internal harus dipublikasikan.

Dokumen internal dapat memuat detail keamanan, arsitektur, data sensitif, dan informasi yang tidak relevan bagi pelanggan.

Namun, untuk insiden besar, perusahaan dapat membuat versi eksternal yang menjelaskan:

• Apa yang terjadi.
• Periode gangguan.
• Dampak kepada pelanggan.
• Cara layanan dipulihkan.
• Perubahan yang akan dilakukan.
• Langkah pelanggan jika masih terdampak.

Transparansi dapat membantu memulihkan kepercayaan, tetapi isinya harus akurat dan tidak berspekulasi.

Versi eksternal sebaiknya tidak dibuat sebelum fakta utama diverifikasi.

Hubungan Post-Mortem Culture dengan Cost of Change

Artikel Cost of Change menjelaskan bahwa kesalahan yang baru ditemukan setelah production dapat menghasilkan biaya jauh melampaui perubahan kode.

Post-mortem membantu perusahaan mengurangi biaya insiden berikutnya melalui dua cara.

Pertama, action item dapat mencegah penyebab yang sama kembali mencapai production.

Kedua, perbaikan monitoring, runbook, rollback, dan incident response dapat memperkecil dampak jika kegagalan tetap terjadi.

Sebagai contoh, bug mungkin tidak dapat dicegah sepenuhnya. Namun, phased deployment dapat membatasi jumlah pengguna terdampak, alert dapat mempercepat deteksi, dan rollback otomatis dapat memperpendek downtime.

Post-mortem juga dapat menghasilkan perbaikan pada tahap development, seperti:

• Memperkuat code review.
• Menambah automated testing.
• Mengurangi technical debt.
• Memperbaiki observability.
• Menguji skalabilitas.
• Mengontrol akses production.
• Menyempurnakan deployment pipeline.

Dengan demikian, post-mortem bukan hanya proses setelah kegagalan.

Hasilnya seharusnya mengubah cara perusahaan mendesain, mengembangkan, menguji, dan mengoperasikan sistem sebelum kegagalan berikutnya terjadi.

Dari Dokumen Menjadi Budaya Belajar

Perusahaan belum memiliki post-mortem culture hanya karena memiliki template.

Budaya terbentuk ketika:

• Pemimpin tidak mencari kambing hitam.
• Engineer merasa aman untuk menjelaskan kesalahan.
• Action item memperoleh prioritas.
• Insiden dibahas lintas tim.
• Pembelajaran dapat dicari dan digunakan kembali.
• Orang yang menangani insiden dengan baik mendapatkan apresiasi.
• Tren dari beberapa insiden digunakan untuk menentukan investasi.
• Manajemen menerima bahwa reliability membutuhkan waktu dan anggaran.

Google SRE menggunakan berbagai mekanisme untuk menyebarkan pembelajaran, termasuk pembahasan post-mortem, reading club, dan repository yang membantu tim melihat pola lintas produk.

Perusahaan tidak harus meniru seluruh proses Google.

Prinsip yang dapat diterapkan adalah memastikan pembelajaran tidak berhenti pada orang yang sedang on-call saat insiden terjadi.

Kesimpulan

Insiden sistem tidak selalu dapat dihindari.

Software berubah, pengguna bertambah, dependency mengalami gangguan, dan kondisi yang belum pernah diuji dapat muncul di production.

Perbedaan antara organisasi yang terus mengulang kegagalan dan organisasi yang semakin tangguh terletak pada kemampuannya belajar setelah layanan dipulihkan.

Post-mortem culture memberikan proses terstruktur untuk:

• Mendokumentasikan fakta.
• Memahami dampak.
• Menganalisis trigger dan contributing factors.
• Mengevaluasi incident response.
• Menetapkan action item.
• Menyebarkan pembelajaran.
• Memastikan perbaikan diselesaikan.

Blameless post-mortem bukan berarti menghapus tanggung jawab.

Pendekatan tersebut memindahkan fokus dari mencari orang yang bersalah menjadi membangun sistem, proses, dan kontrol yang lebih kuat.

Post-mortem juga tidak selesai ketika dokumen diterbitkan.

Nilainya baru muncul ketika pembelajaran mengubah sistem dan mengurangi kemungkinan atau dampak insiden berikutnya.

Perusahaan yang hanya memulihkan layanan akan kembali ke kondisi sebelum insiden.

Perusahaan yang mempelajarinya memiliki kesempatan untuk kembali dengan sistem yang lebih tangguh.

Bangun Sistem yang Terus Belajar Bersama Crocodic

Crocodic membantu perusahaan membangun dan mengembangkan custom enterprise software dengan mempertimbangkan tidak hanya kebutuhan fitur, tetapi juga reliability, observability, maintainability, scalability, dan kemampuan sistem untuk dipulihkan ketika terjadi gangguan.

Melalui layanan Custom Enterprise Software, Crocodic membantu perusahaan merancang sistem, integrasi, pengujian, deployment, monitoring, dan dokumentasi yang mendukung operasional jangka panjang.

Untuk sistem yang sudah berjalan, Crocodic juga membantu melakukan assessment dan peningkatan melalui layanan Enterprise System Upgrade.

Peningkatan dapat mencakup evaluasi arsitektur, optimasi performa, observability, integrasi, automated testing, deployment workflow, backup dan recovery, serta perbaikan technical debt berdasarkan risiko bisnis.

Jika perusahaan Anda mengalami gangguan yang berulang, sulit menemukan penyebab masalah, atau belum memiliki proses pembelajaran setelah insiden, langkah pertama bukan hanya menambah server atau memperbaiki bug yang terlihat.

Perusahaan perlu memahami pola kegagalannya dan membangun kontrol yang mencegah insiden serupa kembali menghasilkan dampak yang sama.

Diskusikan kebutuhan pengembangan dan peningkatan ketahanan sistem perusahaan Anda bersama Crocodic.