Ceritakan insiden production terburuk anda dan 30 minit pertamanya.

Question

IT Interview Practice · Accepted Answer

**Jawapan yang baik menunjukkan cara anda mengurangkan kesan kepada pelanggan, membuat keputusan dengan bukti yang belum lengkap dan mencegah kejadian berulang.** Jelaskan peranan sendiri tanpa menggambarkan seluruh usaha pasukan sebagai hasil kerja anda seorang.

Gunakan insiden yang benar-benar pernah anda alami. Senario di bawah ialah rekaan untuk menunjukkan susunan jawapan; gantikannya dengan tindakan sebenar dan hasil yang disahkan ketika temu duga. Pembahagian masa ini hanyalah contoh, bukan tempoh wajib bagi semua insiden.

## 1. Terangkan keadaan dan tanggungjawab anda

Katakan saya ketua backend yang bertugas apabila kegagalan checkout meningkat tidak lama selepas satu keluaran. Pelanggan masih boleh melayari laman tetapi sebahagiannya tidak dapat menyelesaikan pesanan. Pada peringkat ini, masa kejadian menjadikan keluaran itu satu hipotesis, bukan punca yang terbukti.

Saya akan menjelaskan tanggungjawab saya: menyelaras pemulihan teknikal, membahagikan kerja siasatan dan memaklumkan ketua insiden. Jika saya juga mengetuai insiden, saya akan menyatakannya dengan jelas dan menyerahkan komunikasi atau siasatan langsung kepada orang lain supaya saya tidak menghalang kelancaran kerja.

## 2. Lima minit pertama: sahkan kesan dan susun tindak balas

Semak ralat checkout, kependaman dan pesanan yang berjaya untuk mengetahui siapa yang terjejas dan sama ada masalah masih berlaku. Buka satu saluran insiden, tetapkan tanggungjawab, hentikan sementara perubahan yang tidak berkaitan dan mulakan garis masa pemerhatian serta tindakan.

Penyusunan ini mempunyai tujuan praktikal: beberapa orang membuat perubahan secara berasingan boleh mengaburkan punca atau memburukkan insiden. Kemas kini perlu membezakan fakta yang disahkan daripada hipotesis dan menyatakan masa kemas kini seterusnya. Lihat [panduan tindak balas insiden Google](https://sre.google/workbook/incident-response/).

## 3. Sepuluh minit berikutnya: pilih cara selamat untuk mengurangkan kesan

Katakan siasatan mendapati sambungan pangkalan data telah tepu dan keluaran baharu menambah laluan pelaporan yang menggunakan banyak sumber. Saya akan membandingkan pengembalian versi dengan mematikan laluan itu buat sementara sambil mengekalkan checkout.

- Semak sama ada pengembalian versi serasi dengan perubahan skema atau data yang sudah dibuat. Versi aplikasi lama tidak semestinya selamat digunakan dengan pangkalan data semasa.
- Jika suis yang telah diuji boleh mematikan pelaporan pilihan, gunakannya untuk mengurangkan beban dan perhatikan sama ada checkout pulih.
- Tugaskan seseorang menyiasat tekanan sambungan sementara orang lain mengesahkan langkah pemulihan, supaya siasatan diteruskan tanpa melambatkan tindakan pengurangan kesan yang munasabah.

Keputusan perlu berdasarkan bukti sedia ada dan kebolehan membatalkan tindakan. Saya tidak akan menunggu kepastian penuh tentang punca sementara pelanggan masih terhalang, tetapi saya akan merekodkan sebab tindakan tersebut dijangka membantu.

## 4. Sehingga minit ketiga puluh: sahkan perkhidmatan berguna telah pulih

Graf CPU yang menurun belum mencukupi. Sahkan percubaan checkout sebenar berjaya, kependaman kembali ke julat yang boleh diterima dan kerja dalam baris gilir berkurang tanpa menimbulkan tekanan baharu. Pantau sistem selepas tindakan pemulihan dan jangan mengisytiharkan pulih hanya kerana satu permintaan berjaya.

Untuk keputusan pembayaran yang tidak pasti, padankan rekod dengan sistem pembayaran sebelum mencuba caj semula. Tamat masa boleh berlaku walaupun pembayaran sudah selesai. Maklumkan bahagian yang sudah pulih, perkara yang masih belum pasti dan tindakan pelanggan, tanpa mereka-reka masa pemulihan yang tidak disokong bukti.

## 5. Selepas pemulihan: ubah keadaan yang membolehkan kegagalan berlaku

Dalam senario rekaan ini, siasatan mungkin menunjukkan pelaporan dan checkout berkongsi had sambungan, manakala laporan tidak mempunyai had kerja yang berkesan. Tindakan susulan perlu membetulkan mekanisme tersebut, bukan berakhir dengan pesanan “lebih berhati-hati”.

- Hadkan kerja dan keserentakan laporan supaya satu ciri tidak menghabiskan seluruh sumber bersama.
- Nilai pengasingan sumber apabila perlu dan uji pelaporan bersama checkout dengan beban yang mewakili penggunaan sebenar.
- Wujudkan amaran berdasarkan kejayaan checkout dan kependaman, serta latih prosedur pengurangan kesan atau pengembalian versi.
- Tetapkan pemilik, tarikh siap dan cara mengesahkan penyelesaian bagi setiap tindakan pembetulan.

Dalam temu duga sebenar, akhiri dengan hasil pemulihan yang benar-benar berlaku dan bukti daripada ujian susulan atau operasi selepas itu. Jika sesuatu ukuran tidak dikumpulkan, nyatakan perkara itu dan bukannya memberikan angka yang mengagumkan. Pengajaran perlu berkait terus dengan perubahan yang anda bantu laksanakan dan sahkan.

1. Terangkan keadaan dan tanggungjawab anda

2. Lima minit pertama: sahkan kesan dan susun tindak balas

3. Sepuluh minit berikutnya: pilih cara selamat untuk mengurangkan kesan

4. Sehingga minit ketiga puluh: sahkan perkhidmatan berguna telah pulih

5. Selepas pemulihan: ubah keadaan yang membolehkan kegagalan berlaku

Soalan berkaitan