Oncall Bot dan Monitoring Frontend

Masalahnya

Pengguna yang diam-diam berhenti saat serah terima ke pihak ketiga, seperti pengecekan NFC, baru ketahuan berhari-hari kemudian lewat customer support. Alert kami berbasis ambang batas dan berisik, sehingga orang terbiasa mengabaikannya.

Pendekatannya

• Baseline relatif, bukan ambang statis. Layanan alert menjalankan SQL ke ClickHouse dan membandingkan setiap metrik dengan jam yang sama minggu lalu. Penurunan konversi 20% punya arti berbeda pada jam 3 pagi di Tokyo dan siang hari di Berlin, dan naik-turun trafik global tidak lagi memicu alarm palsu.
• Alert yang datang beserta konteks. Saat alert menyala, ia memposting kartu insiden ke platform chat internal. Worker di latar belakang lalu mengumpulkan stack trace error frontend terbaru dari ClickHouse, versi konfigurasi aktif dari layanan konfigurasi, dan log deployment Kubernetes, lalu mengirimkannya sebagai prompt terstruktur ke API LLM enterprise.
• Ringkasan di dalam thread. Bot membalas dengan dugaan akar masalah, misalnya: konversi langkah 3 turun 32% di Jepang, error null-pointer di wrapper bridge NFC, perubahan konfigurasi yang dideploy 15 menit sebelumnya, dan gateway vendor yang timeout di backend.

Hasilnya

Waktu deteksi turun dari hitungan jam atau hari menjadi di bawah 5 menit, waktu mitigasi turun 65% dan alert positif palsu turun 80%. Saya juga memantau rasio sinyal terhadap noise alert (porsi alert yang terkait insiden nyata) dan rata-rata waktu antar kegagalan untuk modul frontend.

Mengapa begini

Alert biasa hanya memberi tahu ada yang rusak. Mengumpulkan data secara otomatis dan merangkumnya menutup jarak antara sebuah metrik dan seseorang yang memahaminya, dan di situlah sebagian besar waktu respons habis.