I team di ingegneria dell'affidabilità del sito (SRE) e DevOps sono esausti. L'aumento delle risorse IT, il sovraccarico di strumenti e la natura di reperibilità del lavoro, giocano tutti un ruolo in un problema generale: lo stress da avvisi.
Lo stress da avvisi (a volte chiamato affaticamento da avviso) si riferisce a "uno stato di esaurimento mentale e operativo causato da un numero schiacciante di avvisi". Compromette la reattività e l'efficacia di DevOps, del Security Operations Center (SOC), dell'ingegneria dell'affidabilità del sito (SRE) e di altri team responsabili delle prestazioni e della sicurezza IT nonché rappresenta un problema diffuso e sequenziale.
Il rapporto "2023 State of Threat Detection" di Vectra (basato su un'intervistato di 2.000 analisti della sicurezza IT presso aziende con 1.000 o più dipendenti) ha rilevato che i team SOC ricevono una media di 4.484 avvisi al giorno. Di questi, il 67% viene ignorato a causa dell'elevato volume di falsi positivi e dello stress da avvisi. Il rapporto ha anche rilevato che il 71% degli analisti ritiene che la propria organizzazione possa essere già stata "compromessa a loro insaputa, a causa della mancanza di visibilità e fiducia nelle funzionalità di rilevamento delle minacce".
Sebbene il rapporto Vectra si concentri specificamente sulla sicurezza, i team incaricati del monitoraggio delle prestazioni delle applicazioni e dell'infrastruttura devono affrontare un sovraccarico simile. Ad esempio, un singolo errore di configurazione può causare centinaia o migliaia di avvisi relative alle prestazioni, una "vera e propria tempesta di avvisi" che può distrarre o desensibilizzare i team IT e causare risposte ritardate agli avvisi critici e ai problemi reali. Questi problemi reali possono essere costosi.
Che cosa causa questo burnout e l'agentic AI può fare parte di una soluzione scalabile?
Newsletter di settore
Resta al passo con le tendenze più importanti e interessanti del settore relative ad AI, automazione, dati e altro con la newsletter Think. Leggi l'Informativa sulla privacy IBM.
L'abbonamento sarà fornito in lingua inglese. Troverai un link per annullare l'iscrizione in tutte le newsletter. Puoi gestire i tuoi abbonamenti o annullarli qui. Per ulteriori informazioni, consulta l'Informativa sulla privacy IBM.
Esistono sono diversi colpevoli e un enorme volume di telemetria spesso viene citato come uno di questi, ma l'attenzione al volume dei dati oscura specificamente un problema fondamentale: la qualità dei dati e il contesto.
Quando i team hanno a che fare con un'elevata quantità di dati di scarsa qualità e poveri di contesto, alimentando dozzine di diversi feed di threat intelligence o di prestazioni, sono destinati a incontrare problemi. Questo è il tipo di ambiente in cui proliferano falsi positivi e avvisi ridondanti e il rumore di bassa priorità distrae da minacce reali e problemi di prestazioni. Questi "falsi allarmi" possono mettere a dura prova i team IT, DevOps e di sicurezza.
Anche semplicemente inserire questi enormi flussi di telemetria in un modello linguistico di grandi dimensioni (LLM) non è una soluzione praticabile. Per prima cosa, è uno spreco di risorse di calcolo. È anche un ottimo modo per produrre allucinazioni.
Una soluzione pratica inizia con lo sviluppo di un workflow che sintetizza i dati non elaborati e aggrega questi dati di qualità superiore e ricchi di contesto all'interno di una piattaforma centralizzata. Lì possono essere utilizzati per l'observability a livello aziendale e la formazione di modelli AI locali.
Le aziende spesso utilizzano numerose soluzioni di monitoraggio delle prestazioni e della sicurezza: le grandi aziende dispongono in media di 76 strumenti di sicurezza. Questi strumenti possono essere specifici del team o del prodotto o specifici per un determinato ambiente IT (soluzioni on-premise e soluzioni cloud, ad esempio).
Ognuno di questi strumenti potrebbe essere responsabile del monitoraggio di dozzine o centinaia di applicazioni, di application programming interface (API) o server, ognuno dei quali alimenta la propria pipeline di dati. Con tali silos, strumenti separati possono generare più avvisi derivanti dallo stesso problema di base. Questa mancanza di integrazione limita la visibilità, il che a sua volta ostacola la correlazione e l'analisi della causa principale. Gli SRE perdono tempo a inseguire tutti questi avvisi prima di individuare le ridondanze.
Quando i flussi di dati non sono integrati in un sistema di monitoraggio completo, i team IT non dispongono dell'observability necessaria per una correlazione efficiente degli avvisi, l'analisi della causa principale e la correzione.
Quel che è peggio, questa mancanza di integrazione ostacola l'efficacia degli strumenti di automazione per la gestione degli avvisi, come i workflow di correlazione e assegnazione delle priorità degli avvisi, configurati per agevolare il rilevamento e la risoluzione e riduzione del volume degli avvisi. Ai team spetta il compito di collegare manualmente i punti, un compito arduo e dispendioso in termini di tempo (se non addirittura impossibile).
Un sondaggio citato nel rapporto "Adaptive Defense: Custom Alerts for Modern Threats" di Deloitte ha rilevato che una "mancanza di visibilità o contesto degli strumenti di sicurezza ha fatto sì che il 47% degli attacchi venisse perso in un periodo di 12 mesi."
Sebbene i singoli agenti non richiedano necessariamente la centralizzazione, una piattaforma centralizzata in cui i dati degli agenti sono aggregati facilita l'analisi, lo storage e la visualizzazione a livello di sistema.
Sì... con una strategia mirata.
Un recente rapporto del MIT ha scatenato una polverone perché ha affermato che "il 95% delle organizzazioni sta ottenendo un rendimento zero" dai propri investimenti in materia di AI generativa.
Mettendo da parte il vespaio di polemiche e la cascata di opinioni che il rapporto ha suscitato, il rapporto mette in evidenza un tema prezioso: numerosi progetti di AI falliscono a causa di "workflow fragili, mancanza di apprendimento contestuale e disallineamento con le operazioni". Come ha osservato Marina Danilevsky, Senior Research Scientist di IBM, in un recente podcast di Mixture of Experts, le implementazioni di maggior successo sono "focalizzate, definite e rispondono a un punto dolente".
Il rapporto del MIT rafforza la convinzione che le aziende che considerano l'AI come una sorta di panacea o un qualcosa che può essere inserito a casaccio in un processo, probabilmente non noteranno un ritorno sul loro investimento. Le organizzazioni in grado di implementare strategicamente gli strumenti di AI nei propri workflow per risolvere un problema specifico e rafforzare questi strumenti, nel tempo dimostreranno una maggiore adattabilità al successo.
Una soluzione di observability o sicurezza che può incorporare la machine learning adattiva, la definizione delle priorità contestuali, l'AI spiegabile, l'automazione basata su AI e l'intelligenza in tempo reale in una strategia integrata può consentire ai team di creare workflow più solidi che aiutano a correlare, assegnare priorità e correggere gli avvisi sulle prestazioni o sulla sicurezza.
Gli agenti AI possono migliorare i sistemi tradizionali che si basano su regole statiche e soglie preimpostate portando fattori come l'importanza degli asset, le garanzie di prestazioni, i profili di rischio e le tendenze storiche.
Ad esempio, considera un workflow di rilevamento e correzione successivo a un incidente e come un agente AI potrebbe assistere un team di progettazione dell'affidabilità del sito (SRE).
Una notifica arriva al sistema di avvisi che segnala un utilizzo elevato della CPU per un nodo in un cluster Kubernetes. In un sistema tradizionale, gli SRE potrebbero dover esaminare i dati MELT (metriche, eventi, registri, tracce) e le dipendenze per identificare la causa principale.
In questo ipotetico workflow, l'agente utilizza il grafico di conoscenza dello strumento di observability, e la correlazione basata sulla topologia, per estrarre solo la telemetria relativa all'avviso (come i log dei servizi in esecuzione su quel nodo, le implementazioni recenti, la telemetria dal server API del cluster o i load balancer che indirizzano il traffico verso il nodo o il cluster). Con queste informazioni aggiuntive, l'agente può arricchire gli avvisi non elaborati e offrire una telemetria ricca di contesto a un modello AI locale addestrato sui dati delle prestazioni e sui benchmark dell'azienda.
L'agente esclude le informazioni irrilevanti, come i registri di servizi non correlati che vengono eseguiti sullo stesso cluster. Durante questa raccolta di contesto, l'agente può inoltre identificare i segnali correlati e mettere in relazione gli avvisi che probabilmente derivano dalla stessa causa principale per poi raggruppare questi avvisi ed essere analizzati come un unico incidente.
Con queste informazioni, il modello può proporre un'ipotesi. L'agente può inoltre richiedere ulteriori informazioni (magari controllando le configurazioni dei container o i dati delle serie temporali relative al picco di utilizzo) per verificare e perfezionare l'ipotesi del modello, aggiungendo ulteriore contesto prima di proporre una probabile causa principale.
L'uso di agenti e dell'AI spiegabili è fondamentale per risolvere il problema della fiducia, per "vedere dentro la black box", ovvero il funzionamento interno di uno strumento di AI.
L'AI spiegabile (XAI) "è un insieme di processi e metodi che consente agli utenti umani di comprendere e fidarsi dei risultati e dei risultati creati dagli algoritmi di apprendimento automatico."
Oltre alla probabile causa principale, l'agente può fornire spiegabilità attraverso la sua catena di pensiero, il suo processo di ragionamento, insieme a prove di supporto che dimostrano come è arrivato alla probabile causa principale proposta. Questa spiegabilità e le prove a supporto:
- Consente all'essere umano di vedere perché qualcosa è stato raccomandato o filtrato in un determinato modo
- Fornisce la trasparenza necessaria per esaminare l'analisi e la proposta dell'agente e giudicare se ci si può fidare
L'analisi SRE e la valutazione delle raccomandazioni degli agenti possono essere reimmesse nel modello per migliorarne ulteriormente la precisione.
Esistono diverse strade per giungere alla risoluzione. I team possono decidere quanta autonomia fornire a un agente o definire questa autonomia in base al tipo di incidente, alla gravità, all'ambiente o ad altri fattori. I prossimi passi includono:
- Convalida: un agente può generare passaggi per aiutare i team SRE e DevOps a convalidare che la causa principale che l'agente ha identificato sia corretta. Questo aiuta a mantenere l'input umano nel sistema.
- Runbook: una volta convalidato, l'agente può produrre una guida dettagliata delle fasi di correzione (un runbook). Si tratta di uno script che i membri del team possono seguire per risolvere il problema.
- Script di automazione: l'agente può anche intraprendere le azioni suggerite e creare workflow (script di automazione). Può trasformare questi passaggi del runbook in uno snippet di playbook di Ansible con la sintassi dei comandi e i parametri per i passaggi.
- Documentazione: gli agenti possono produrre una documentazione automatica, ad esempio una recensione successiva a un incidente, che riassume l'incidente, le azioni intraprese e i motivi per intervenire. Un agente può anche produrre un riepilogo in corso che aiuti chi è nuovo nell'attività a capire rapidamente che cosa sta succedendo. Questa documentazione può essere utilizzata per l'apprendimento per rinforzo.
Tutti questi passaggi contribuiscono a ottimizzare la risposta agli incidenti e a ridurre il tempo medio di riparazione. Per un video tutorial di una simile ipotesi, fai clic qui.
I framework di AI possono essere utilizzati per migliorare vari aspetti dello stress da avvisi, come la priorità degli avvisi attuabili in un ambiente IT.
In un articolo del 2023 intitolato "That Escalated Quickly: An ML Framework for Alert Prioritization", Gelman et al introducono un framework di apprendimento automatico (ML) progettato per ridurre lo stress da avvisi con modifiche minime ai workflow esistenti attraverso un sistema di punteggio di azionabilità a livello di avviso e di incidente. Eseguito su dati reali, il modello TEQ ha ridotto i tempi di risposta agli incidenti attuabili del 22,9% e ha soppresso il 54% dei falsi positivi (con un tasso di rilevamento del 95,1%). Ha inoltre ridotto del 14% il numero di avvisi all'interno di singoli incidenti.1
In "Advancing Autonomous Incident Response: Leveraging LLMs and Cyber Threat Intelligence," Tellache et al dimostrano come un framework basato sulla retrieval-augmented generation (RAG) può migliorare la risoluzione degli incidenti integrando i dati provenienti da fonti di threat intelligence.2 Una soluzione simile che utilizza gli agenti per basarsi sull'approccio RAG potrebbe essere utilizzata per aggiungere un contesto più ampio ai dati di performance, ad esempio recuperando le soglie di prestazioni concordate dagli accordi sul livello di servizio (SLA) aziendali per aiutare a decidere quali avvisi di applicazione dare priorità.
Un team IT potrebbe utilizzare diversi agenti per migliorare i processi di avvisi, ciascuno progettato per affrontare un diverso aspetto dello stress da avvisi, come un agente di triage degli incidenti che estrae le minacce critiche per attirare l'attenzione immediata o un agente di routing che inserisce gli avvisi con priorità e li indirizza al team appropriato insieme alla documentazione e all'analisi.
Instradando i dati in un hub centralizzato, le aziende possono contribuire a eliminare i punti ciechi e offrire agli agenti una conoscenza più completa dell'ambiente in cui operano. L'AI è più efficace quando si lavora con dati affidabili e di alta qualità e una piattaforma centralizzata può contribuire a garantire l'applicazione uniforme degli standard di governance dei dati. Man mano che le organizzazioni ampliano le soluzioni di AI, questa piattaforma svolge un ruolo fondamentale nel mantenere la coerenza nella gestione dei dati e nella distribuzione degli agenti tra le unità di business.
Un'organizzazione può semplicemente "utilizzare l'AI" e neutralizzare la pioggia di avvisi? No. Modelli e agenti ben addestrati possono aiutare a sintetizzare e analizzare la telemetria e l'assegnazione di priorità degli avvisi per concedere una pausa ai team IT? Ecco un motivo in più per essere ottimisti.
L'uso efficace dell'AI e degli agenti per alleviare lo stress da avvisi dipende da alcuni fattori chiave: il targeting di un caso d'uso, l'implementazione strategica e la capacità dell'AI di apprendere e migliorare insieme ad ambienti dinamici. I dirigenti aziendali devono capire cosa viene richiesto, essere disposti ad apportare i cambiamenti culturali e assegnare le risorse necessarie per far funzionare il sistema e trovare un fornitore i cui strumenti possano essere personalizzati in base alle proprie esigenze.
1 "That Escalated Quickly: An ML Framework for Alert Prioritization," Gelman, Taoufiq, Vörös, Berlin, 15 February 2023
2 "Advancing Autonomous Incident Response: Leveraging LLMs and Cyber Threat Intelligence," Tellache, Korba, Mokhtari, Moldovan, Ghamri-Doudane, 14 August 2025