Pradita Utama
16+ Years Experienced Software Engineer and Tech Leadership at Startups and Corporates
Feb 14, 2019
3 min read
Budaya Post Mortem
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.
Alat Teleportasi Tidak Bisa Mengirimkan Kucing (#TLPRT0001)
Date
2019-02-14
Authors
Data
Worf
Picard
Status
Complete, action items in progress
Summary
Mesin Teleportasi dengan Serial Number TLPRT-001-2033 pagi ini tidak bisa mengirimkan kucing ke pesawat lain. Dugaan awal karena masalah interferensi gelombang elektromagnetic. Setelah ditelusuri penyebabnya adalah listik yang tidak stabil akibat tidak menggunakan stop kontak bukan SNI.
Impact
Dua kucing tidak bisa kembali ke pemilik di pesawat lainnya. Kerugian dua kardus makanan kucing untuk menunggu perbaikan mesin Teleportasi selama 3 jam.
Root Causes
Proses pengadaan alat listrik yang terburu-buru dan budget yang kecil menyebabkan kami membeli alat-alat listrik yang tidak berkualitas. Setelah kita periksa beberapa alat listrik tidak mempunyai logo SNI dan ringkih. Hal ini menyebabkan kelebihan beban pada stop kontak mesin Teleportasi (TLPRT-001-2033) ketika melakukan proses inisialisasi tahap pertama (energy gathering). Stop kontak yang berada didalam kotak terbakar dan memutuskan aliran listrik.
Trigger
Kelebihan beban di stop kontak
Resolution
Karena posisi stop kontak berada di kotak listrik dibelakang mesin TLPRT-001-2033, kami kesulitan untuk menemukan penyebab tidak bekerjanya TLPRT-001-2033. Setelah diagnosa, ditemukan stop kontak terbakar dan kami mengganti stop kontak yang baru.
Detection
Operator mendapatkan pesan dari pemilik kucing bahwa kucingnya belum sampai.
Action Items
Action Item
Type
Owner
Bug
Diagnosa menggunakan SOP-001-2033-XTFG-335.2-1.435
process
Data
n/a DONE
Use flux capacitor to balance load between clusters
prevent
Worf
Bug 5554823 TODO
Schedule cascading failure test during next Phase
process
Worf
n/a TODO
Investigate running index MR/fusion continuously
prevent
Data
Bug 5554824 TODO
Plug file descriptor leak in search ranking subsystem
prevent
Data
Bug 5554825 DONE
Add load shedding capabilities to core engine search
prevent
Data
Bug 5554826 TODO
Build regression tests to ensure servers respond sanely to queries of death
prevent
Worf
Bug 5554827 TODO
Deploy updated search ranking subsystem to prod
prevent
Picard
n/a DONE
Lessons Learned
What went well
Dua kucing selamat
Tidak terjadi gangguan listrik di modul lain
What went wrong
Kami tidak antisipasi kerusakan alat listrik
Kami tidak punya monitoring alat listrik
Where we got lucky
Tidak terjadi kerusakan di tempat lain
Timeline
2019-02-13
Time
Description
06:51
Operator menerima laporan dari pemilik kucing
07.10
Diagnosa sistem dilakukan oleh Data dan Worf
08.45
Worf menemukan penyebab utama, stop kontak terbakar
