Amaran Frontend dan Bot Triaj Berbantukan AI
Amaran berasaskan perubahan relatif pada telemetri, ditambah bot sembang berbantukan LLM yang menukarkan sesuatu amaran kepada punca akar yang mungkin, dalam utas tempat pasukan sudah bekerja.
- Stack
- SQL · Alerting service · LLM API · Kubernetes · Internal chat bot
Masalahnya
Kejatuhan senyap semasa serah-terima kepada pihak ketiga hanya dikesan beberapa hari kemudian melalui sokongan pelanggan. Amaran berasaskan ambang dan bising, jadi orang sudah terbiasa mengabaikannya.
Pendekatannya
- Garis asas relatif, bukan ambang statik. Perkhidmatan amaran menjalankan SQL pada storan telemetri dan membandingkan setiap metrik dengan jam yang sama minggu lepas. Penurunan 20% bermakna sesuatu pada pukul 3 pagi di satu wilayah dan pada tengah hari di wilayah lain, dan turun naik trafik global tidak lagi menyebabkan penggera palsu.
- Amaran yang datang bersama konteks. Apabila amaran dicetuskan, kad insiden dihantar ke sembang pasukan. Pekerja di latar belakang kemudian mengumpulkan ralat frontend terkini, versi konfigurasi aktif dan log penggunaan, lalu menghantarnya sebagai gesaan berstruktur kepada API LLM.
- Ringkasan dalam utas. Bot membalas dengan punca akar yang mungkin, contohnya: penukaran satu langkah menurun di satu wilayah, terdapat ralat null-pointer dalam pembungkus native, perubahan konfigurasi dikeluarkan 15 minit sebelumnya dan satu perkhidmatan hiliran tamat masa.
Hasilnya
Masa pengesanan turun daripada beberapa jam atau hari kepada beberapa minit, masa mitigasi berkurang, dan amaran menjadi sesuatu yang dipercayai orang. Saya juga menjejaki nisbah isyarat-kepada-hingar amaran (bahagian amaran yang sepadan dengan insiden sebenar) dan purata masa antara kegagalan bagi modul frontend.
Mengapa cara ini
Amaran biasa hanya memberitahu ada sesuatu yang rosak. Mengumpul data secara automatik lalu meringkaskannya merapatkan jurang antara metrik dengan orang yang memahaminya, dan di situlah kebanyakan masa tindak balas terbazir.