Ceritakan insiden production terburuk Anda dan 30 menit pertamanya.

Question

IT Interview Practice · Accepted Answer

**Jawaban yang kuat menunjukkan cara Anda mengurangi dampak pada pelanggan, mengambil keputusan dengan bukti belum lengkap, dan mencegah kejadian berulang.** Jelaskan peran Anda sendiri dengan jelas, tanpa menganggap seluruh pekerjaan tim sebagai pekerjaan pribadi.

Gunakan insiden yang benar-benar Anda alami. Skenario berikut bersifat fiktif dan menunjukkan struktur jawaban; dalam wawancara, gantilah dengan tindakan nyata serta hasil yang sudah diverifikasi. Rentang waktunya hanya ilustrasi, bukan tenggat respons insiden yang berlaku universal.

## 1. Jelaskan situasi dan tanggung jawab Anda

Misalnya saya adalah lead backend yang sedang bertugas ketika kegagalan checkout meningkat tidak lama setelah rilis. Pelanggan dapat melihat produk, tetapi sebagian tidak dapat menyelesaikan pesanan. Pada tahap ini, kedekatan waktu membuat rilis menjadi hipotesis, bukan penyebab yang terbukti.

Saya akan menjelaskan tanggung jawab saya: mengoordinasikan pemulihan teknis, membagi pekerjaan investigasi, dan memberi informasi kepada pemimpin insiden. Jika saya juga memimpin insiden, saya akan menyebutkannya secara jelas dan mendelegasikan komunikasi atau investigasi langsung agar tidak menjadi penghambat.

## 2. Lima menit pertama: pastikan dampak dan atur respons

Periksa error checkout, latensi, dan pesanan berhasil untuk mengetahui siapa yang terdampak serta apakah masalah masih berlangsung. Buka satu kanal insiden, bagi tanggung jawab, hentikan perubahan yang tidak terkait, dan mulai catatan waktu pengamatan serta tindakan.

Pengaturan ini memiliki alasan praktis: beberapa orang melakukan perubahan independen dapat mengaburkan penyebab atau memperburuk insiden. Pembaruan informasi harus membedakan fakta terkonfirmasi dari hipotesis dan menyebutkan kapan pembaruan berikutnya diberikan. Lihat [panduan respons insiden](https://sre.google/workbook/incident-response/) Google.

## 3. Sepuluh menit berikutnya: pilih cara aman mengurangi dampak

Misalnya investigasi menemukan koneksi database penuh dan rilis menambahkan alur laporan yang mahal. Saya akan membandingkan rollback dengan menonaktifkan sementara alur tersebut sambil mempertahankan checkout.

- Periksa apakah rollback kompatibel dengan perubahan skema atau data yang sudah dilakukan. Versi aplikasi sebelumnya tidak otomatis aman terhadap database saat ini.
- Jika ada sakelar yang sudah diuji untuk menonaktifkan laporan opsional, gunakan untuk mengurangi beban dan amati apakah checkout membaik.
- Tugaskan seseorang memeriksa tekanan koneksi sementara orang lain memverifikasi langkah pemulihan, agar investigasi berlanjut tanpa menunda mitigasi yang masuk akal.

Keputusan harus mengikuti bukti yang tersedia dan kemungkinan membatalkan tindakan. Saya tidak akan menunggu kepastian penuh akar masalah sementara pelanggan tetap terhambat, tetapi akan mencatat alasan tindakan terpilih diperkirakan membantu.

## 4. Sampai menit ketiga puluh: verifikasi layanan berguna sudah pulih

Grafik CPU yang menurun tidak cukup. Pastikan percobaan checkout nyata berhasil, latensi kembali ke rentang yang dapat diterima, dan pekerjaan antrean berkurang tanpa menimbulkan tekanan baru. Amati sistem setelah mitigasi, bukan menyatakan pulih setelah satu request berhasil.

Untuk hasil pembayaran yang ambigu, cocokkan dengan sistem pembayaran sebelum mengulang penagihan. Timeout dapat menyembunyikan pembayaran yang sudah selesai. Komunikasikan apa yang pulih, apa yang masih belum pasti, dan tindakan pelanggan, tanpa mengarang waktu pemulihan yang tidak didukung bukti.

## 5. Setelah pulih: ubah kondisi yang memungkinkan kegagalan

Dalam skenario fiktif ini, investigasi mungkin menunjukkan bahwa laporan dan checkout berbagi anggaran koneksi, sementara laporan tidak memiliki batas pekerjaan yang efektif. Tindak lanjut harus menangani mekanisme tersebut, bukan berhenti pada “lebih berhati-hati”.

- Batasi pekerjaan laporan dan konkurensinya agar satu fitur tidak menghabiskan seluruh sumber daya bersama.
- Evaluasi isolasi sumber daya bila diperlukan dan uji laporan bersama checkout dengan beban representatif.
- Buat peringatan berdasarkan keberhasilan checkout dan latensi, lalu latih prosedur mitigasi atau rollback.
- Berikan penanggung jawab, tenggat, dan cara memverifikasi penyelesaian untuk setiap tindakan perbaikan.

Dalam wawancara nyata, tutup dengan hasil pemulihan sebenarnya dan bukti dari pengujian tindak lanjut atau operasi berikutnya. Jika pengukuran tidak dilakukan, katakan demikian, bukan memberi angka yang mengesankan. Pelajaran harus terkait langsung dengan perubahan yang Anda bantu terapkan dan verifikasi.

1. Jelaskan situasi dan tanggung jawab Anda

2. Lima menit pertama: pastikan dampak dan atur respons

3. Sepuluh menit berikutnya: pilih cara aman mengurangi dampak

4. Sampai menit ketiga puluh: verifikasi layanan berguna sudah pulih

5. Setelah pulih: ubah kondisi yang memungkinkan kegagalan

Pertanyaan terkait