Oncall Bot dan Pemantauan Frontend

Masalahnya

Pengguna yang tercicir secara senyap semasa serahan kepada pihak ketiga, seperti semakan NFC, hanya ditemui berhari-hari kemudian melalui khidmat pelanggan. Amaran kami berasaskan ambang dan bising, jadi orang sudah terbiasa mengabaikannya.

Pendekatannya

• Garis dasar relatif, bukan ambang statik. Perkhidmatan amaran menjalankan SQL pada ClickHouse dan membandingkan setiap metrik dengan jam yang sama minggu lepas. Penurunan penukaran 20% membawa maksud berbeza pada pukul 3 pagi di Tokyo dan tengah hari di Berlin, dan turun naik trafik global tidak lagi mencetuskan amaran palsu.
• Amaran yang datang bersama konteks. Apabila amaran dicetuskan, ia menghantar kad insiden ke platform sembang dalaman. Pekerja latar belakang kemudian mengumpul jejak tindanan ralat frontend terkini daripada ClickHouse, versi konfigurasi yang aktif daripada perkhidmatan konfigurasi dan log penggunaan Kubernetes, lalu menghantarnya sebagai gesaan berstruktur kepada API LLM perusahaan.
• Ringkasan dalam thread. Bot membalas dengan punca sebenar yang mungkin, contohnya: penukaran langkah 3 turun 32% di Jepun, ralat null-pointer dalam pembalut jambatan NFC, perubahan konfigurasi yang digunakan 15 minit sebelumnya dan get laluan vendor yang tamat masa di backend.

Hasilnya

Masa mengesan turun daripada beberapa jam atau hari kepada kurang 5 minit, masa mitigasi berkurang 65% dan amaran positif palsu berkurang 80%. Saya juga menjejaki nisbah isyarat kepada hingar amaran (bahagian amaran yang berkait dengan insiden sebenar) dan purata masa antara kegagalan bagi modul frontend.

Mengapa begini

Amaran biasa hanya memberitahu ada sesuatu yang rosak. Mengumpul data secara automatik dan meringkaskannya merapatkan jurang antara satu metrik dan seseorang yang memahaminya, dan di situlah kebanyakan masa respons dihabiskan.