Prinsip ini dalam pilar keandalan dari Google Cloud Architecture Framework memberikan rekomendasi untuk membantu Anda melakukan postmortem yang efektif setelah kegagalan dan insiden.
Prinsip ini relevan dengan area fokus pembelajaran keandalan.
Ringkasan prinsip
Postmortem adalah catatan tertulis tentang insiden, dampaknya, tindakan yang diambil untuk memitigasi atau menyelesaikan insiden, akar penyebabnya, dan tindakan lanjutan untuk mencegah insiden terulang. Tujuan postmortem adalah untuk belajar dari kesalahan dan bukan mencari-cari kesalahan.
Diagram berikut menunjukkan alur kerja postmortem:
Alur kerja postmortem mencakup langkah-langkah berikut:
- Membuat postmortem
- Menangkap fakta
- Mengidentifikasi dan menganalisis akar masalah
- Merencanakan masa depan
- Menjalankan rencana
Lakukan analisis postmortem setelah peristiwa besar dan peristiwa non-besar seperti berikut:
- Downtime atau penurunan kualitas yang terlihat oleh pengguna di luar batas tertentu.
- Segala jenis kehilangan data.
- Intervensi dari engineer yang siap siaga, seperti rollback rilis atau perubahan rute traffic.
- Waktu penyelesaian di atas nilai minimum yang ditentukan.
- Kegagalan pemantauan, yang biasanya menyiratkan penemuan insiden manual.
Rekomendasi
Tentukan kriteria post-mortem sebelum insiden terjadi sehingga semua orang tahu kapan post-mortem diperlukan.
Untuk melakukan postmortem yang efektif, pertimbangkan rekomendasi dalam subbagian berikut.
Melakukan postmortem tanpa menyalahkan
Postmortem yang efektif berfokus pada proses, alat, dan teknologi, serta tidak menyalahkan individu atau tim. Tujuan analisis post-mortem adalah untuk meningkatkan teknologi dan masa depan Anda, bukan untuk menemukan siapa yang bersalah. Semua orang pasti pernah melakukan kesalahan. Sasarannya adalah menganalisis kesalahan dan belajar darinya.
Contoh berikut menunjukkan perbedaan antara masukan yang menyalahkan dan masukan yang tidak menyalahkan:
- Masukan yang menyalahkan: "Kita perlu menulis ulang seluruh sistem backend yang rumit. Aplikasi ini mengalami error setiap minggu selama tiga kuartal terakhir dan saya yakin kita semua sudah lelah memperbaikinya secara terpisah. Serius, jika saya dipanggil lagi, saya akan menulis ulang sendiri…"
- Feedback tanpa menyalahkan: "Item tindakan untuk menulis ulang seluruh sistem backend mungkin benar-benar mencegah halaman ini terus terjadi. Manual pemeliharaan untuk versi ini cukup panjang dan sangat sulit untuk dilatih sepenuhnya. Saya yakin engineer piket kami di masa mendatang akan berterima kasih kepada kami."
Membuat laporan postmortem dapat dibaca oleh semua audiens yang dituju
Untuk setiap informasi yang ingin Anda sertakan dalam laporan, nilai apakah informasi tersebut penting dan diperlukan untuk membantu audiens memahami apa yang terjadi. Anda dapat memindahkan data dan penjelasan tambahan ke lampiran laporan. Peninjau yang memerlukan informasi lebih lanjut dapat memintanya.
Menghindari solusi yang rumit atau terlalu canggih
Sebelum Anda mulai mempelajari solusi untuk suatu masalah, evaluasi pentingnya masalah dan kemungkinan terjadinya masalah tersebut lagi. Menambahkan kompleksitas ke sistem untuk memecahkan masalah yang tidak mungkin terjadi lagi dapat menyebabkan peningkatan instabilitas.
Bagikan laporan post-mortem seluas mungkin
Untuk memastikan masalah tidak tetap tidak terselesaikan, publikasikan hasil postmortem kepada audiens yang luas dan dapatkan dukungan dari manajemen. Nilai post-mortem sebanding dengan pembelajaran yang terjadi setelah post-mortem. Jika lebih banyak orang belajar dari insiden, kemungkinan kegagalan serupa terulang akan berkurang.