Alerting frontend e un bot di triage assistito dall’IA
Un alerting basato sulle variazioni relative della telemetria, più un chatbot assistito da un LLM che trasforma un alert in una probabile causa radice, nel thread in cui il team già lavora.
- Stack
- SQL · Alerting service · LLM API · Kubernetes · Internal chat bot
Il problema
Gli abbandoni silenziosi durante i passaggi di consegne a terze parti venivano scoperti giorni dopo tramite l’assistenza clienti. Gli alert erano basati su soglie fisse e rumorosi, così le persone avevano imparato a ignorarli.
L’approccio
- Riferimenti relativi, non soglie statiche. Il servizio di alerting esegue SQL sullo storage di telemetria e confronta ogni metrica con la stessa ora della settimana precedente. Un calo del 20% significa qualcosa alle 3 di notte in una regione e a mezzogiorno in un’altra, e le oscillazioni del traffico globale non causano più falsi allarmi.
- Un alert che arriva con il contesto. Quando scatta un alert, pubblica una scheda di incidente nella chat del team. Un worker in background raccoglie poi gli errori frontend recenti, la versione di configurazione attiva e i log di deploy, e li invia come prompt strutturato a un’API LLM.
- Un riepilogo nel thread. Il bot risponde con una probabile causa radice, ad esempio: la conversione di un passaggio cala in una regione, c’è un errore di puntatore nullo in un wrapper nativo, una modifica di configurazione è uscita 15 minuti prima e un servizio a valle va in timeout.
Il risultato
Il tempo di rilevamento è sceso da ore o giorni a minuti, il tempo di mitigazione è diminuito e gli alert sono diventati alert di cui ci si fida. Ho anche monitorato il rapporto segnale-rumore degli alert (la quota che corrisponde a incidenti reali) e il tempo medio tra i guasti dei moduli frontend.
Perché in questo modo
Un alert normale ti dice che qualcosa si è rotto. Raccogliere i dati automaticamente e riassumerli colma il divario tra una metrica e una persona che la comprende, ed era lì che andava gran parte del tempo di risposta.