Saya Berhenti Menggali Log

Untuk waktu yang lama, debugging berarti membuka log terlebih dahulu. Itu terasa seperti hal yang benar untuk dilakukan. Alert berbunyi, log ada di sana, jadi saya membacanya. Seiring waktu, saya menyadari sebagian besar energi saya tidak dihabiskan untuk memperbaiki bug. Itu dihabiskan untuk mencari.

Jadi saya berhenti menggali log.

Sekarang saya mulai dari error itu sendiri, mengirimkannya ke agen AI yang bisa membaca database observabilitas kami, dan membiarkannya melakukan pencarian. Perbedaannya tidak halus. Root cause muncul lebih cepat. Jalan buntu lebih sedikit. Stres berkurang.

Ini bukan tentang AI ajaib. Ini tentang mengubah dari mana debugging dimulai.

Masalahnya log adalah pecahan bukan cerita utuh

Log adalah pecahan. Satu baris di sini. Stack trace di sana. Timestamp yang hampir cocok dengan yang lain.

Alat observabilitas memberikan visibilitas, tetapi mereka tidak memberikan struktur secara default. Engineer masih harus menjahit semuanya di kepala mereka. Jahitan itu mahal.

Alur lama terlihat seperti ini:

alert berbunyi
buka log
cari berdasarkan request id
lompat antar service
buka kode
bentuk hipotesis
ulangi

Sebagian besar waktu habis untuk navigasi, bukan penalaran. Debugging menjadi masalah atensi.

Pergeseran: berhenti membaca mulai mengkorelasikan

Alih-alih mulai dengan log, saya sekarang mulai dengan error.

Ketika error muncul, saya mengirim payload error plus konteks minimal ke asisten AI. Asisten itu memiliki akses read-only ke database observabilitas kami. Log, trace, dan data error historis semuanya ada di sana.

Tugas AI itu sederhana. Korelasikan semua yang mungkin terkait dengan error ini.

Tugas saya tetap sama. Putuskan apa yang harus dilakukan selanjutnya.

Satu perubahan ini menghilangkan banyak kebisingan. Saya tidak lagi menggulir log berharap sesuatu menonjol. Saya meninjau bukti yang sudah dikelompokkan dan terhubung.

Apa yang sebenarnya dilakukan AI

Tidak ada sihir yang terlibat. Langkah-langkahnya mekanis.

Pertama, AI mem-parsing payload error dan mengekstrak field kunci seperti timestamp, nama service, tipe error, dan identifier request.

Selanjutnya, ia menanyakan database observabilitas untuk error serupa. Tanda tangan sama, service sama, payload mirip, jendela waktu berdekatan.

Lalu ia mengkorelasikan trace lintas service untuk melihat di mana kegagalan berkumpul. Ia mencari jalur yang berulang, bukan noise satu kali.

Setelah itu, ia memeriksa deploy atau commit terbaru yang menyentuh jalur kode yang terlibat.

Outputnya adalah laporan singkat dengan bukti. Trace yang berulang. Log yang sejajar. Jalur kode yang berubah baru-baru ini.

Ini tidak memberi saya perbaikan (fix). Ini memberi saya tempat yang tepat untuk melihat.

Pagar pembatas: akses tanpa eksposur

Bagian ini lebih penting daripada AI itu sendiri.

AI hanya memiliki akses read-only. Tidak ada write. Tidak ada mutasi. Tidak ada efek samping.

Mode privasi diaktifkan. Data tidak digunakan untuk training. Itu digunakan hanya untuk inferensi di sesi ini.

Akses dibatasi (scoped). Hanya field yang dibutuhkan untuk debugging yang diekspos. Tidak ada akses database luas. Tidak ada payload yang tidak perlu.

Setiap query dan hasil dapat diaudit.

Tujuannya bukan untuk memberi AI lebih banyak kekuatan. Tujuannya adalah memberinya cukup konteks agar berguna, tanpa menciptakan risiko baru.

Apa yang berubah bagi saya

Beberapa hal menjadi sangat jelas setelah beralih workflow.

Waktu ke root cause turun secara signifikan. Kami melewati fase berkeliaran.

Pull request menjadi lebih kecil dan lebih terfokus. Perbaikan menargetkan masalah sebenarnya alih-alih tebakan di sekitarnya.

Investigasi palsu turun. Lebih sedikit situasi di mana berjam-jam dihabiskan hanya untuk menyimpulkan itu tidak terkait.

Alert terasa lebih tenang. Ketika sesuatu rusak, langkah pertama terstruktur, bukan reaktif.

Apa yang tidak berubah

Engineer masih membuat keputusan.

AI tidak mengerti konteks produk. Ia tidak tahu prioritas bisnis atau strategi rollout.

Penilaian (judgement) masih diperlukan. Seberapa berisiko perbaikannya. Apakah harus rollback. Apakah harus hotfix atau menunggu.

AI mempersempit ruang pencarian. Manusia masih memiliki hasilnya.

Workflow yang bisa Anda tiru

Alert berbunyi
Tangkap payload error dan konteks minimal
Kirim ke asisten AI dengan akses read-only terbatas
Tinjau bukti yang dikembalikannya
Validasi hipotesis
Implementasikan perbaikan
Observasi

Tidak ada penyelaman log buta.

Ke mana ini bisa pergi selanjutnya

Satu ide yang saya simpan di belakang kepala saya adalah mendorong workflow ini satu langkah lebih jauh.

Ketika alert berbunyi, agen bisa secara otomatis mengumpulkan bukti, melacak kegagalan lintas service, memeriksa jalur kode relevan, dan mengusulkan perbaikan.

Bukan untuk merge sendiri. Hanya untuk membuka pull request.

Pull request itu akan berisi:

dugaan root cause
trace dan log pendukung
perubahan kode
tes yang membenarkan perbaikan

Pada titik itu, engineer tidak lagi menggali atau mengetik secara default. Tugasnya menjadi me-review, menilai risiko, dan memutuskan apakah perubahan harus dikirim.

Itu adalah workflow yang sebenarnya ingin saya maintain.

Penutup: kenapa ini sebenarnya penting

Ini bukan tentang menggantikan engineer. Ini tentang menghapus pekerjaan yang tidak perlu.

Log adalah bahan mentah. Mereka bukan jawabannya. Kecepatan datang dari merakit konteks dengan cepat, bukan membaca lebih cepat.

Jika Anda menjalankan sistem pada skala besar dan masih mulai debugging dengan membuka log, cobalah membalik urutannya. Mulai dengan error. Biarkan mesin melakukan pencarian. Gunakan atensi Anda di tempat yang sebenarnya penting.