Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.
Memakai agen AI saat insiden tanpa membuat keadaan lebih buruk: bukti sebelum hipotesis, menguji origin bukan CDN, dan hook yang memblokir perintah merusak.
Matthews Wong
Software Engineer
Ringkasan Utama
Agen AI sangat baik dalam mengumpulkan bukti insiden secara paralel dan berbahaya ketika bertindak berdasarkan tebakan. Pola yang aman adalah investigasi hanya-baca dengan hook PreToolUse yang memblokir perintah merusak, menguji origin secara langsung alih-alih lewat CDN, dan mewajibkan hipotesis dinyatakan sebelum ada perubahan.
Situsnya hidup, deploy melaporkan sukses, dan halaman di browser tertinggal dua versi. Tidak ada yang salah di log aplikasi, karena memang tidak ada yang salah di aplikasinya. Insiden itu selesai dalam dua puluh menit dengan bantuan agen dan akan memakan satu jam kalau saya sendirian, tetapi ia juga menunjukkan persis di mana melepas agen di mesin produksi bisa berakhir buruk.
Ini metode kerja yang akhirnya saya pakai: apa yang sebaiknya dilakukan agen saat insiden, apa yang harus dicegah, dan urutan bukti yang menjaga kami berdua tetap jujur.
Penanganan insiden sebagian besar adalah pengumpulan bukti di bawah tekanan waktu, dan itu cocok bagi sesuatu yang bisa menjalankan sepuluh perintah sementara Anda memikirkan yang kesebelas.
Yang tidak ia kuasai adalah mengetahui kapan dirinya keliru. Hipotesis keliru yang percaya diri ditambah akses shell adalah cara insiden kecil menjadi besar, dan karena itulah pagar pengaman di bawah ini bukan opsional.
Kalau sebuah situs berada di belakang CDN atau proxy cache, hal pertama yang harus dipastikan adalah lapisan mana yang menjawab. Respons dari edge memberi tahu apa yang diingat edge, bukan apa yang sedang dilakukan aplikasi, dan berjam-jam bisa hilang untuk men-debug kode yang sudah benar.
# Rule one of debugging a site behind a CDN: stop asking the CDN.
curl -sI https://www.example.com/ | head -20 # what the world sees
curl -sI --resolve www.example.com:443:127.0.0.1 \
https://www.example.com/ | head -20 # what the origin says
# If those disagree, the bug is in the cache layer and no amount of
# reading application code will find it.
# Same discipline for the redirect chain, which hides a surprising
# number of "the site is down" reports.
curl -sIL http://example.com/ | grep -E '^(HTTP|location:)'Disiplin yang sama berlaku untuk rantai redirect dan nama host. Aturan yang mengarahkan domain telanjang ke host www, atau aplikasi yang hanya mendengarkan salah satunya, menghasilkan gejala yang tampak seperti gangguan padahal sebenarnya konfigurasi. Menelusuri rantainya secara eksplisit mengubah misteri menjadi satu baris keluaran.
Tuliskan perbandingan origin versus edge ke dalam runbook sebagai langkah pertama secara harfiah, lengkap dengan perintah persisnya. Saat insiden tak seorang pun menemukan diagnostik yang bagus; mereka menjalankan apa pun yang bisa diingat, dan yang bisa diingat adalah apa pun yang tertulis.
Inilah kasus yang paling banyak mengajari saya, disusun ulang dari perintah-perintah yang benar-benar penting. Aplikasinya berjalan di container, pipeline deploy-nya hijau, dan konten yang disajikan basi.
# The incident: a deploy "succeeded", the site kept serving old content.
# The evidence that mattered, in the order it was gathered:
docker compose ps # container up, restarts: 0
docker compose logs --tail=100 web # no errors, no recent boot line
ss -tlnp | grep :3000 # PID owning the port is the OLD process
curl -s localhost:3000/ | grep -o 'build-[a-z0-9]*' # old build id
# Root cause: the new process failed to bind because the previous one had
# never exited. The deploy script only checked that its own command
# returned zero, so it reported success while nothing had changed.Pelajarannya berlaku jauh melampaui tumpukan teknologi ini. Skrip deploy yang hanya memeriksa exit code-nya sendiri sedang mengukur hal yang salah: yang penting adalah apakah proses yang berjalan adalah proses yang baru. Sejak itu setiap deploy saya diakhiri dengan menegaskan bahwa pengenal build yang disajikan lewat HTTP cocok dengan yang baru saja dibangun — pemeriksaan dua baris yang akan mengubah insiden ini menjadi pipeline yang gagal.
Jangan pernah membiarkan agen merestart, memangkas, atau men-deploy ulang sebagai tindakan pertamanya saat insiden. Merestart menghancurkan bukti yang menjelaskan kegagalannya, dan separuh waktu ia juga tampak memperbaiki masalahnya, yang menjamin insiden yang sama kembali minggu depan tanpa jejak diagnostik apa pun.
Ini instruksi yang saya simpan di berkas memori proyek agar berlaku di setiap sesi insiden tanpa perlu diketik ulang.
Kebiasaan terakhir itu layak dieja karena pernah menghasilkan kesimpulan palsu bagi saya: keluaran yang tampak menggambarkan repositori remote ternyata menggambarkan yang lokal, dan saya memercayai sebuah merge yang sebenarnya tidak pernah terjadi.
Dialog izin melindungi Anda selama Anda membacanya. Saat insiden tak seorang pun membacanya, dan justru saat itulah Anda menginginkan aturan yang tidak bisa dibujuk. Hook PreToolUse yang memeriksa perintah lalu menolak sedikit daftar operasi yang tak bisa dibatalkan adalah asuransi termurah yang tersedia.
// A PreToolUse hook is the difference between an assistant that can
// investigate production and one that can break it. This one refuses
// the small set of commands nobody should run during an incident.
#!/bin/bash
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command')
if echo "$cmd" | grep -Eq 'rm -rf /|docker system prune|DROP TABLE|truncate '; then
echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse",
"permissionDecision":"deny",
"permissionDecisionReason":"destructive command blocked during incident"}}'
exit 0
fi
echo '{}'Pasangkan dengan mode izin yang dipilih sengaja untuk sesi itu. Investigasi berjalan hanya-baca; begitu perbaikannya disepakati, itu menjadi sesi terpisah yang lebih sempit dengan perubahan yang ditinjau manusia sebelum dijalankan. Mencampur investigasi dan remediasi dalam satu sesi longgar adalah persiapan untuk insiden kedua.
Enam langkah, dalam urutan ini, setiap kali.
Langkah keenam itulah yang berbunga. Hampir setiap insiden yang saya alami dua kali adalah insiden yang kejadian pertamanya menghasilkan perbaikan tanpa pemeriksaan, dan perbaikan tanpa pemeriksaan adalah ingatan yang punya masa kedaluwarsa.
Keluaran sebuah insiden seharusnya paling tidak satu penegasan otomatis, bukan hanya satu paragraf. Insiden deploy basi menjadi pemeriksaan pengenal build setelah deploy. Insiden cache menjadi permintaan sintetis yang melewati edge. Insiden disk penuh menjadi ambang alarm yang berbunyi sebelum layanannya berbunyi.
Di sinilah agen justru layak berperan setelah insiden alih-alih saat insiden: menulis pemeriksaannya, alarmnya, dan entri runbook-nya adalah persis pekerjaan membosankan dan terspesifikasi jelas yang ia kerjakan dengan andal, tepat pada momen ketika Anda terlalu lelah mengerjakannya dengan baik.
Agen AI memangkas separuh pengumpulan bukti dari sebuah insiden secara dramatis dan menambah risiko pada separuh tindakannya. Pisahkan kedua separuh itu — investigasi hanya-baca dengan perintah merusak diblokir, lalu perubahan yang disengaja dan ditinjau — dan Anda mendapat kecepatannya tanpa membeli gangguan kedua.