Lakukan debugging dengan hipotesis yang dapat diuji

Jelaskan kegagalan sebelum mengusulkan perbaikan

Permintaan debugging yang berguna menyatakan perilaku yang diharapkan, perilaku yang diamati, dan lingkup terdampak. Sertakan versi, input terkait, dan error. Hapus kredensial serta data privat dari log sebelum memberikannya kepada alat AI.

“Ekspor rusak” tidak memberi banyak arah. Deskripsi yang lebih baik: “Ekspor berhasil secara lokal. Di staging, permintaan manajer yang sama mengembalikan 403 setelah deployment terbaru. Route lain masih berfungsi.”

Deskripsi ini tidak membuktikan penyebabnya. Deskripsi ini mengidentifikasi perbedaan yang dapat memandu penyelidikan.

Pertahankan beberapa kemungkinan penjelasan

Minta agen menyusun beberapa penyebab yang masuk akal beserta bukti masing-masing. Jangan memintanya menetapkan penjelasan pertama yang terdengar meyakinkan.

Untuk kegagalan ekspor fiktif ini, kemungkinan penyebab mencakup izin identitas layanan yang kurang, pemetaan peran yang berubah, atau permintaan yang dikirim ke lingkungan yang salah. Setiap penjelasan memprediksi bukti berbeda.

Tabel ini adalah titik awal. Respons 403 dapat berasal dari lapisan berbeda. Identifikasi komponen yang menghasilkannya sebelum menganggap otorisasi aplikasi gagal.

Pilih pengamatan yang aman

Mulai dari pengamatan yang dapat membedakan penjelasan dengan biaya rendah. Bandingkan versi yang di-deploy dan konfigurasi nonrahasia. Periksa error serta pengenal permintaan terkait. Reproduksi masalah di lingkungan uji yang diizinkan jika memungkinkan.

Jangan memberikan izin luas hanya untuk melihat apakah error hilang. Tindakan itu mengubah batas keamanan dan dapat menyembunyikan izin yang sebenarnya kurang. Jangan menempelkan log produksi lengkap ke model jika pesan error yang sudah dibersihkan dari informasi sensitif dan jalur permintaan sudah cukup.

Nyatakan apa yang dapat melemahkan setiap hipotesis. Ini membantu agen memperbarui penjelasannya, alih-alih mempertahankan jawaban pertama.

Ubah satu penyebab dalam satu waktu

Setelah bukti menunjukkan kemungkinan penyebab, lakukan perbaikan terarah. Hindari menggabungkan perubahan izin, pembaruan pustaka, dan penulisan ulang handler. Jika gejala hilang, Anda tidak akan tahu perubahan mana yang berpengaruh.

Verifikasi kondisi kegagalan awal. Periksa juga batas terkait. Jika memperbaiki akses manajer, pastikan pengguna yang tidak berwenang tetap ditolak.

Untuk cacat berulang, tambahkan pemeriksaan regresi pada lapisan yang dapat mendeteksinya. Unit test tidak dapat mendeteksi setiap kesalahan konfigurasi deployment. Sebagian kegagalan memerlukan pemeriksaan integrasi atau verifikasi terkendali setelah deployment.

Hentikan percobaan berulang tanpa bukti baru

Agen dapat menghasilkan banyak variasi perbaikan. Lebih banyak percobaan belum tentu memperbaiki diagnosis. Jika kegagalan yang sama berulang, tanyakan pengamatan baru apa yang akan diberikan percobaan berikutnya.

Tetapkan batas waktu atau jumlah percobaan untuk penyelidikan yang belum pasti. Saat batas tercapai, laporkan bukti saat ini, hipotesis yang ditolak, dan pertanyaan yang belum terjawab. Catatan ini memungkinkan orang lain melanjutkan tanpa mengulang percobaan yang sama.

Setelah pemulihan, catat penyebab dan kondisi yang membuat masalah mencapai lingkungan terdampak. Perbaikan menghilangkan cacat langsung. Tindak lanjut yang berguna mengurangi kemungkinan kegagalan yang sama terulang.