Oncall Bot e monitoraggio del frontend

Il problema

Gli abbandoni silenziosi nei passaggi verso terze parti, come i controlli NFC, venivano scoperti giorni dopo tramite l’assistenza clienti. I nostri avvisi si basavano su soglie fisse ed erano rumorosi, quindi tutti avevano imparato a ignorarli.

L’approccio

• Linee di base relative, non soglie fisse. Il servizio di avvisi esegue SQL su ClickHouse e confronta ogni metrica con la stessa ora della settimana precedente. Un calo della conversione del 20% ha un significato diverso alle 3 di notte a Tokyo e a mezzogiorno a Berlino, e le oscillazioni del traffico globale non generano più falsi allarmi.
• Un avviso che arriva con il contesto. Quando scatta un avviso, pubblica una scheda di incidente sulla piattaforma di chat interna. Poi un worker in background raccoglie gli stack trace recenti degli errori frontend da ClickHouse, la versione di configurazione attiva dal servizio di configurazione e i log di deploy di Kubernetes, e li invia come prompt strutturato a un’API LLM aziendale.
• Un riepilogo nel thread. Il bot risponde con una causa probabile, per esempio: conversione del passaggio 3 calata del 32% in Giappone, un errore di puntatore nullo nel wrapper del bridge NFC, una modifica di configurazione rilasciata 15 minuti prima e il gateway di un fornitore in timeout nel backend.

Il risultato

Il tempo di rilevamento è sceso da ore o giorni a meno di 5 minuti, il tempo di mitigazione del 65% e i falsi allarmi dell’80%. Sono stati monitorati anche il rapporto segnale-rumore degli avvisi (la quota legata a incidenti reali) e il tempo medio tra i guasti dei moduli frontend.

Perché così

Un avviso normale dice solo che qualcosa si è rotto. Raccogliere i dati in automatico e riassumerli colma la distanza tra una metrica e una persona che la capisce, ed era lì che se ne andava la maggior parte del tempo di risposta.