Perintah dan skenario penggunaan
Jelaskan insiden produksi yang pernah Anda bantu tinjau: bagaimana Anda merekonstruksi fakta, menghindari menyalahkan individu, mendorong tindakan nyata, dan memverifikasi bahwa perubahan tersebut mengurangi risiko terulangnya masalah? Jawaban harus menunjukkan komunikasi, pertukaran (trade-off), kolaborasi, dan tindak lanjut di bawah tekanan.
Hal yang diuji oleh pewawancara
- Apakah Anda dapat menjelaskan dampak, keputusan, dan pemulihan dengan garis waktu dan bukti.
- Apakah Anda membedakan budaya tanpa menyalahkan (blameless culture) dari menghindari akuntabilitas serta berfokus pada sistem dan proses.
- Apakah Anda mengubah "meningkatkan pemantauan" menjadi penanggung jawab, batas waktu, dan sinyal penerimaan.
- Apakah Anda mengakui kesalahan penilaian Anda sendiri dan menunjukkan tindak lanjut serta verifikasi lintas tim.
Pertanyaan untuk diklarifikasi sebelum menjawab
- Pengguna, SLO, atau alur bisnis mana yang terpengaruh, dan untuk berapa lama?
- Peran apa yang Anda mainkan, dan keputusan apa yang Anda buat secara langsung?
- Fakta apa yang diketahui pada saat itu, dan kesimpulan mana yang merupakan pemahaman setelah kejadian (hindsight)?
- Bagaimana tindakan diprioritaskan, dimiliki, diverifikasi, dan diukur?
Kerangka jawaban 30 detik
Saya akan menjawab dengan "situasi, tindakan, hasil, postmortem." Pertama, kuantifikasi dampak dan target pemulihan pada garis waktu, lalu jelaskan tanggung jawab operasional dan komunikasi saya. Dalam peninjauan, diskusikan kondisi sistem yang dapat diamati, sinyal, dan konteks keputusan alih-alih melimpahkan kesalahan pribadi. Terakhir, persempit rencana menjadi beberapa tindakan prioritas tinggi, masing-masing dengan penanggung jawab, batas waktu, dan sinyal yang dapat diukur, serta verifikasi hasilnya melalui rilis, replay peringatan, atau game day.
Pembahasan mendalam langkah demi langkah
1. Menetapkan batasan faktual
Kumpulkan peringatan, log, catatan perubahan, dan dampak pengguna, lalu buat garis waktu yang memperhitungkan zona waktu. Pisahkan fakta yang diamati, hipotesis yang dipegang saat itu, dan pemahaman setelah kejadian agar informasi di kemudian hari tidak digunakan untuk menghakimi keputusan sebelumnya.
2. Nyatakan peran Anda
Sampaikan apakah Anda seorang engineer yang bertugas (on-call), koordinator, penanggung jawab rilis, atau responder pendukung, dan jelaskan wewenang serta jalur eskalasi Anda. Pewawancara menginginkan kontribusi konkret Anda, bukan sekadar daftar pencapaian semua orang.
3. Jelaskan pemulihan, bukan kepahlawanan
Jelaskan bagaimana Anda mengurangi dampak, menjeda perubahan berisiko, meminta bantuan, dan memperbarui informasi kepada pemangku kepentingan. Jika Anda melakukan rollback, mendegradasi fitur, atau menerima kompromi (trade-off), hubungkan hal itu dengan sinyal dan risiko yang diketahui saat itu.
4. Tetapkan aturan diskusi tanpa menyalahkan
Fokuslah pada kondisi sistem, umpan balik alat, celah proses, dan konteks keputusan, bukan label seperti ceroboh atau tidak bertanggung jawab. Pendekatan tanpa menyalahkan menjaga kualitas pembelajaran; ini tidak menghapus akuntabilitas terkait izin, pelatihan, atau kepatuhan.
5. Temukan faktor sistem yang dapat diubah
Pecah penyebab menjadi pemicu, penguat, keterlambatan deteksi, hambatan pemulihan, dan kendala organisasi. Ambang batas tunggal bisa menjadi celah deteksi sekaligus masalah desain kapasitas; jangan menyederhanakannya menjadi "seseorang melewatkan peringatan."
6. Tulis tindakan yang dapat diterima
Setiap tindakan membutuhkan operasi, penanggung jawab, batas waktu, prioritas, dan sinyal penerimaan. Tulis ulang "tambahkan pemantauan" menjadi kueri, ambang batas, aturan perutean, dan tanggal latihan agar sebuah harapan tidak disamarkan sebagai rencana.
7. Tangani perbedaan pendapat
Ketika prioritas berbeda, kembalilah ke dampak pengguna, pengurangan risiko, biaya implementasi, dan dependensi. Catat saran yang ditolak beserta alasannya; jalankan eksperimen kecil jika berguna daripada berdebat secara abstrak.
8. Verifikasi siklus perbaikan
Setelah rilis, pantau peringatan serupa, waktu pemulihan, dan metrik pengguna, lalu jadwalkan latihan kegagalan atau rollback. Jika metrik tidak membaik, buka kembali item tindakan tersebut. Penyelesaian berarti adanya bukti pengurangan risiko, bukan sekadar dokumen yang dikumpulkan.
Pertukaran (trade-off) dan batasan
- Detail postmortem yang lebih banyak tidak otomatis lebih baik; simpan bukti yang mengubah keputusan atau mengurangi risiko.
- Diskusi tanpa menyalahkan meningkatkan kualitas informasi, tetapi perilaku jahat, kepatuhan, atau penyalahgunaan hak istimewa tetap mengikuti investigasi formal.
- Terlalu banyak tindakan akan melemahkan eksekusi; sampaikan dalam kelompok-kelompok kecil (batch) berdasarkan risiko dan reversibilitas.
- Latihan (drill) mengungkap celah proses tetapi tidak dapat membuktikan bahwa setiap kegagalan ekstrem telah tertangani; nyatakan apa yang masih belum diverifikasi.
Rencana implementasi dan bukti
- Bekukan garis waktu, dampak, dan bukti penting setelah insiden dan konfirmasikan dengan peran yang terlibat.
- Jalankan tinjauan tanpa menyalahkan yang memisahkan fakta, hipotesis, faktor sistem, dan persepsi pribadi.
- Lacak tindakan dengan penanggung jawab, batas waktu, prioritas, dan metrik penerimaan.
- Verifikasi tindakan melalui rilis, replay peringatan, rollback, atau game day.
- Periksa siklus pembelajaran terhadap panduan Google SRE Postmortem Culture dan AWS Game Days.
Kesalahan umum dan pertanyaan lanjutan
Kesalahan 1: Menceritakan kisah pahlawan pribadi
Menekankan perbaikan semalam suntuk tanpa menjelaskan sinyal, kolaborasi, dan perubahan sistem tidak menunjukkan pengurangan risiko tim.
Kesalahan 2: Menggunakan pendekatan tanpa menyalahkan untuk menghindari akuntabilitas
Tinjauan tanpa menyalahkan melindungi proses pembelajaran; ini tidak menghapus tanggung jawab izin, pelatihan, atau kepatuhan. Jelaskan bagaimana pencarian fakta dan perbaikan berjalan beriringan.
Kesalahan 3: Mendaftar slogan sebagai tindakan
"Tingkatkan pemantauan" dan "tingkatkan cakupan pengujian" tidak memiliki penanggung jawab atau syarat penerimaan. Tulis ulang menjadi tugas yang dapat dieksekusi dan diukur.
Pertanyaan lanjutan: Bagaimana jika pemilik tindakan menolak suatu tindakan?
Selaraskan bukti dampak dan prioritas risiko, catat ketidaksepakatan tersebut, dan jalankan eksperimen berbiaya rendah dengan tanggal peninjauan daripada membiarkan konflik tersebut hanya berada di catatan rapat.
Pertanyaan lanjutan: Bagaimana Anda membuktikan bahwa postmortem berhasil?
Bandingkan peringatan serupa, MTTR, keberhasilan rollback, dan dampak pengguna, lalu gunakan game day atau injeksi kesalahan (fault injection). Jika metrik tetap stagnan, nilai kembali hipotesis dan tindakannya.