Alerting Frontend dan Bot Triase Berbantuan AI
Alerting berbasis perubahan relatif pada telemetri, plus chat bot berbantuan LLM yang mengubah sebuah alert menjadi dugaan akar masalah, langsung di thread tempat tim sudah bekerja.
- Stack
- SQL · Alerting service · LLM API · Kubernetes · Internal chat bot
Masalahnya
Penurunan senyap saat serah-terima ke pihak ketiga baru ketahuan berhari-hari kemudian lewat layanan pelanggan. Alert-nya berbasis ambang batas dan berisik, sehingga orang terbiasa mengabaikannya.
Pendekatannya
- Baseline relatif, bukan ambang batas statis. Layanan alerting menjalankan SQL ke penyimpanan telemetri dan membandingkan setiap metrik dengan jam yang sama minggu lalu. Penurunan 20% berarti sesuatu pada pukul 3 pagi di satu wilayah dan pada tengah hari di wilayah lain, dan fluktuasi trafik global tidak lagi memicu alarm palsu.
- Alert yang datang dengan konteks. Saat alert menyala, sebuah kartu insiden diposting ke chat tim. Worker di latar belakang lalu mengumpulkan error frontend terbaru, versi konfigurasi yang aktif, dan log deployment, kemudian mengirimkannya sebagai prompt terstruktur ke LLM API.
- Ringkasan di thread. Bot membalas dengan dugaan akar masalah, misalnya: konversi satu langkah turun di satu wilayah, ada error null-pointer di wrapper native, perubahan konfigurasi dirilis 15 menit sebelumnya, dan sebuah layanan hilir mengalami timeout.
Hasilnya
Waktu deteksi turun dari hitungan jam atau hari menjadi menit, waktu mitigasi menurun, dan alert menjadi sesuatu yang dipercaya orang. Saya juga melacak signal-to-noise alert (porsi alert yang sesuai dengan insiden nyata) dan mean time between failures untuk modul frontend.
Mengapa dengan cara ini
Alert biasa hanya memberi tahu ada yang rusak. Mengumpulkan data secara otomatis lalu merangkumnya menutup jarak antara sebuah metrik dan orang yang memahaminya, dan di situlah sebagian besar waktu respons terbuang.