Agente IA di monitoraggio e triage dei bug segnalati dagli utenti

Un bug in produzione non si segnala mai al momento giusto. Arriva tramite un errore perso in un flusso di log che nessuno guarda in tempo reale, o tramite un ticket support aperto da un cliente che descrive il sintomo senza conoscerne la causa tecnica. Tra i due, spesso non c'è alcun collegamento automatico: il team engineering scopre il problema quando il support finisce per fare escalation, talvolta ore dopo che i primi utenti lo hanno incontrato. Un agente IA autonomo che sorveglia i due flussi contemporaneamente colma questo scarto.

Il problema

Il tempo che gli sviluppatori passano a correggere bug, invece che a scrivere codice nuovo, resta una delle perdite di produttività meglio documentate dell'ingegneria del software. Un'indagine globale condotta da Rollbar su 950 sviluppatori (tramite Propeller Insights) mostrava già che il 32% degli sviluppatori dedica fino a 10 ore a settimana a correggere bug invece che scrivere codice, e che il 38% vi dedica fino a un quarto del proprio tempo di lavoro totale (fonte). Questa indagine risale al 2021 e merita di essere letta come un ordine di grandezza più che una misura aggiornata, ma l'osservazione che documenta, una quota significativa del tempo di ingegneria assorbita dalla correzione invece che dalla costruzione, ricorre in modo costante negli studi più recenti sulla produttività degli sviluppatori.

La vera posta in gioco non è solo il tempo di correzione, è il ritardo tra la comparsa di un problema e il suo rilevamento. Il rapporto DORA State of DevOps 2024 fissa punti di riferimento precisi su questo aspetto: i team più performanti ripristinano un servizio degradato in meno di un'ora, i team molto performanti in meno di un giorno, i team intermedi tra un giorno e una settimana, e i team meno performanti possono impiegare tra una settimana e un mese (fonte). Lo scarto tra l'alto e il basso di questa scala si misura quindi in settimane, non in ore, e questo ritardo dipende direttamente dalla rapidità con cui un'anomalia viene rilevata e correttamente priorizzata, ancora prima di essere corretta.

Questo ritardo ha un costo diretto quando il problema tocca la produzione. Lo studio ITIC 2024, condotto su oltre 1.000 aziende nel mondo tra novembre 2023 e marzo 2024, indica che il costo medio di un'ora di indisponibilità supera i 300.000 dollari per oltre il 90% delle aziende di medie e grandi dimensioni, e che il 41% delle grandi aziende valuta questo costo orario tra 1 e 5 milioni di dollari (fonte). Queste cifre riguardano guasti importanti e non si applicano a ogni singolo bug isolato, ma mostrano l'ordine di grandezza di ciò che è in gioco quando un problema che avrebbe potuto essere rilevato presto resta invisibile troppo a lungo, sommerso in un flusso di log che nessuno sorveglia in continuo.

Un punto merita di essere chiarito per non confondere due usi vicini. Il monitoraggio CI, che riguarda i fallimenti di build e di test prima che un deployment raggiunga la produzione, è un problema diverso da quello trattato qui. Questa pagina copre la sorveglianza dopo il deployment: errori che si verificano realmente presso gli utenti, e ticket support che questi aprono per descriverli, due flussi che spesso raccontano lo stesso incidente senza mai essere incrociati automaticamente.

Questa mancanza di incrocio ha un effetto concreto sulla priorizzazione. Un bug che genera cinque errori tecnici discreti nei log ma provoca venti ticket support identici merita un trattamento urgente, mentre un bug che genera cento errori tecnici senza che un solo cliente se ne lamenti può spesso aspettare il ciclo successivo. Senza incrociare le due fonti, un team engineering priorizza alla cieca, sul solo volume tecnico, il che non riflette sempre l'impatto reale vissuto dagli utenti.

Cosa fa l'agente, passo dopo passo

L'agente sorveglia in continuo i flussi di errori di produzione, le metriche di latenza e i log applicativi, la stessa materia prima di uno strumento di monitoraggio classico. La differenza inizia alla fase successiva: sorveglia in parallelo i ticket support aperti dagli utenti, per individuare le segnalazioni che descrivono un'anomalia tecnica in linguaggio comune invece che in stack trace. Raggruppa poi gli errori e i ticket che descrivono lo stesso problema, invece di trattare ogni occorrenza isolatamente come farebbe un sistema di alerting grezzo. A partire da questo raggruppamento, valuta la frequenza, l'impatto utente stimato e la criticità dell'anomalia. Crea un'issue strutturata in GitHub o Linear con la descrizione del problema, la stack trace, una stima di impatto e un livello di priorità già impostato. Notifica il team interessato su Slack con questo contesto già raccolto, e fa escalation verso la reperibilità solo se le soglie di criticità definite in anticipo sono superate.

Le integrazioni utilizzate

Il rilevamento si appoggia su Datadog, o su Sentry per i team che preferiscono uno strumento specializzato nel monitoraggio di errori e stack trace. La correlazione con l'esperienza utente passa da Intercom, o Zendesk a seconda dello strumento di support già in uso, per incrociare i ticket aperti con gli errori tecnici rilevati sul lato monitoraggio. La creazione dell'issue avviene in GitHub o Linear a seconda dello strumento di gestione del team, con la descrizione, la stack trace e il livello di priorità già compilati. Slack porta le notifiche di team, e un'escalation verso PagerDuty può essere attivata per gli incidenti la cui criticità supera la soglia definita.

Ciò che resta all'essere umano

Il team engineering definisce le soglie di criticità e le regole di escalation durante la configurazione dell'agente, un inquadramento iniziale che determina poi cosa attiva o meno un'allerta alla reperibilità. Riceve issue già selezionate e contestualizzate, stack trace e impatto stimato compresi, e non deve far altro che scrivere il correttivo invece di ricostruire il contesto a partire da log grezzi. Adegua le regole di priorizzazione man mano che il prodotto evolve, un nuovo modulo o una nuova integrazione cambia necessariamente ciò che conta come critico in un dato momento. Il correttivo stesso, l'arbitraggio su ciò che merita un hotfix immediato piuttosto che una correzione pianificata, resta interamente una decisione umana.

Risultato misurabile

Il beneficio più diretto è un ritardo ridotto tra la comparsa di un problema in produzione e la sua emersione sotto forma di issue utilizzabile, invece di essere sommersa in un flusso di log o dispersa tra più ticket support che descrivono lo stesso sintomo senza essere collegati. Dato lo scarto documentato dal rapporto DORA tra un ripristino del servizio in meno di un'ora per i team più performanti e diversi giorni per i team intermedi, ridurre il tempo di rilevamento e triage agisce direttamente sulla capacità di un team di avvicinarsi alla parte alta di questa scala invece di restare bloccato nella media. Il secondo beneficio è meno rumore per la reperibilità: facendo emergere solo le anomalie la cui criticità supera una soglia definita, l'agente riduce le interruzioni inutili per errori minori, un punto particolarmente sensibile per i team ridotti che non hanno una rotazione di reperibilità allargata e dove ogni risveglio notturno pesa direttamente sulla disponibilità e la concentrazione del giorno dopo, con un effetto cumulativo su più settimane se il rumore resta mal filtrato.