A post-mortem examination, also known as an autopsy, is the examination of a body after death. The aim of a post-mortem is to determine the cause of death.

Tidak, saya tidak berbicara tentang post mortem untuk jenasah tapi saya akan membahas post mortem di pengembangan software. Kami di Qlue menggunakan Post Mortem Report.

Apa Itu Post Mortem Report?

Mirip dengan autopsi jenasah, post mortem report ini akan berisi penyebab kegagalan atau insiden yang terjadi di suatu produk, feature, atau infrastruktur.

Laporan akan berisi siapa yang membuat, apa yang terjadi, action apa yang dilakukan, status insiden, rekomendasi yang sebaiknya dilakukan di masa depan agar insiden tidak terjadi lagi.

Kenapa Harus Dibuat?

Tujuan utama penulisan postmortem adalah untuk memastikan bahwa insiden tersebut didokumentasikan, bahwa semua akar penyebab yang berkontribusi dipahami dengan baik, dan, terutama, tindakan pencegahan yang efektif dilakukan untuk mengurangi kemungkinan dan / atau dampak dari pengulangan.

Siapa Yang Membuat?

Laporan ini dibuat oleh para developer yang terkait dengan insiden tersebut, bisa lebih dari satu orang. Tapi idealnya hanya 1 dokumen yang dibuat tapi dibahas bersama-sama, bukan setiap orang membuat dokumen yang sama untuk insiden yang sama.

Siapa Yang Harus Review Postmortem?

Product Managers, Lead Engineer.

Postmortem Report Ini Untuk Siapa?

Dibuat untuk para stakeholders. Semua yang terlibat dan berkepentingan dengan produk tersebut.

Apakah Ini Cara Untuk Menyalahkan atau Mempermalukan Diri Sendiri dan Orang Lain?

Tidak.

Postmortem harusnya blameless, alias tidak menjurus atau menyalahkan orang lain. Budaya ini yang harus dibangun. Agar postmortem benar-benar tidak bersalah, ia harus fokus pada pengidentifikasian penyebab insiden tersebut tanpa mendakwa individu atau tim mana pun atas perilaku buruk atau tidak pantas. Postmortem yang ditulis dengan tidak menyalahkan orang lain dan mengasumsikan bahwa setiap orang yang terlibat dalam suatu insiden memiliki niat baik dan melakukan hal yang benar dengan informasi yang mereka miliki.

Sangat tidak baik jika menyalahkan orang lain, hal ini akan membuat orang lain (atau bahkan kita sendiri) tidak bisa mengakui kesalahan dan tidak belajar dari kesalahan.

Budaya blameless ini kalau tidak salah berasal dari industri kesehatan dan penerbangan. Mereka pada pelaku industri tersebut melihat kesalahan sebagai peluang untuk memperbaiki celah yang mungkin akan menyebabkan nyawa manusia hilang.

Budaya ini bisa diimplementasikan di dunia pengembangan software juga. Kesalahan itu memang merugikan, tapi belajar dari kesalahan dan tidak mengulangi kesalahan yang sama sepertinya lebih baik daripada menghakimi.

Kita tidak bisa “memperbaiki” orang lain, tapi setidaknya kita bisa mempunyai sistem dan proses yang mendukung orang lain membuat pilihan yang baik dan belajar dari pengalaman.

Blaming atau menyalahkan orang lain hanya masalah bagaimana kita menuliskannya.

“Backendnya hancur! jelek. Spaghetti code semua. Harusnya ditulis ulang. Kalau sejak awal ditulis ulang gak akan kejadian kayak gini! Saran saya, tulis ulang biar gak kejadian lagi.”

dibandingkan dengan

“Kita punya technical debts yang banyak, action item selanjutnya adalah merencanakan untuk rewrite backend dengan melibatkan stakeholders untuk membahas fitur-fitur apa yang menjadi prioritas untuk dijual selama proses rewrite. Banyak ruang untuk pengembangan di backend, terutama memperbaiki struktur endpoint dan payload yang diterima”

Ada Contoh Format?

Contoh format yang digunakan di Qlue seperti di bawah ini. Bisa gunakan format lain yang lebih baik atau lebih enak dibaca.

Referensi Bacaan

https://landing.google.com/sre/sre-book/chapters/postmortem-culture/