I team di dati hanno a disposizione più dati di telemetria che mai, ma l’analisi degli incidenti non è diventata significativamente più veloce. Si tende naturalmente a pensare che l’AI sia la soluzione, quindi molte organizzazioni hanno aggiunto un layer di AI definendolo AI site reliability engineering (AI SRE).
Tuttavia, questa corsa a soddisfare le esigenze di affidabilità aziendali e dei clienti fa sì che la maggior parte dell’AI per l’osservabilità sia applicata a posteriori su architetture non progettate per supportarla. I team possono ottenere risultati rapidi, ma scoprire in seguito che mancano informazioni importanti perché gli strumenti non si integrano in modo profondo nella piattaforma dati. E questo non è né efficiente né efficace.
Questo post spiega le caratteristiche che distinguono gli strumenti di AI SRE in grado di migliorare davvero la velocità e la precisione dell’analisi da quelli che si limitano a sintetizzare i dati di telemetria.
Per capire cosa significi davvero essere efficaci, partiamo da quanto costa attualmente il processo di analisi standard.
L’analisi degli incidenti incide sulla produttività dell’engineering
In base alle informazioni raccolte tra i clienti di Observe by Snowflake, le tempistiche medie di analisi per un incidente complesso sono di 10 minuti per il rilevamento, 120 minuti per l’indagine, 15 minuti per il ripristino e 370 minuti per l’analisi della causa radice, con un tasso di completamento di appena il 30%.1 Centinaia di engineer reperibili devono ricostruire il problema utilizzando più strumenti, scrivendo query personalizzate e ricomponendo la catena degli eventi.

Non si tratta di un punto di vista specifico di Observe. In tutto il settore dell’osservabilità, la crescita esponenziale della telemetria creata dai moderni sistemi distribuiti ha generato una sfida comune. I team di engineering non riescono a elaborare gli avvisi e perdono segnali critici; di conseguenza, la risoluzione degli incidenti richiede più tempo. Anche un incidente di media complessità richiede diversi passaggi per individuare il problema e completare il ciclo di analisi.
I motivi per cui l’analisi è diventata più complessa sono strutturali:
Il volume dei dati ha superato le capacità per cui le piattaforme di osservabilità legacy sono state progettate.
Le dipendenze tra i sistemi sono più complesse a causa dell’aumento dei microservizi e dei sistemi interconnessi.
Le competenze sulla causa radice sono concentrate in un numero ridotto di engineer.
Il lavoro effettivo di analisi (la navigazione nelle gerarchie di trace, l’analisi dei log in diverse finestre temporali e la sintesi dei risultati tra i vari servizi) non è facilmente automatizzabile.
La risposta agli incidenti e la gestione delle relative conseguenze possono assorbire una quota consistente della capacità di engineering nelle organizzazioni che gestiscono sistemi complessi. La maggior parte dei team ricorre a un AI SRE come soluzione, ma non tutti gli AI SRE funzionano allo stesso modo.
Un AI SRE deve essere preciso, a bassa latenza ed economicamente efficiente
La capacità di un AI SRE di rispondere a semplici query in linguaggio naturale non basta a determinarne il valore come strumento di osservabilità. La vera questione è se l’infrastruttura dati sia in grado di supportare l’AI SRE implementato per renderlo davvero utile.
Un AI SRE per l’osservabilità deve essere molto più di una semplice funzione di chat sovrapposta ai dati di telemetria o ad altri strumenti di osservabilità. Deve essere abbastanza preciso da potersene fidare, abbastanza veloce da essere usato durante un incidente in corso e abbastanza efficiente da poter essere interrogato senza far lievitare i costi.
La maggior parte degli AI SRE disponibili oggi non è all’altezza perché è stata progettata per fornire risposte rapide a query di base, non per operare in modo autonomo su workload di osservabilità complessi e in rapida evoluzione.
Tre requisiti indispensabili per un AI SRE efficace
Prima di chiederti quale AI SRE utilizzare, determina se disponi dell’infrastruttura dati adeguata per supportarlo:
La telemetria è concentrata in un unico punto o è frammentata in silo tra diversi strumenti?
Il layer di storage è abbastanza conveniente da consentire di conservare i dati necessari per la finestra di retention desiderata senza ricorrere al campionamento?
Il sistema modella le relazioni tra infrastruttura, applicazioni, servizi e dati aziendali?
La maggior parte delle discussioni sugli strumenti di AI SRE comincia dal layer superiore, ma questo è il punto di partenza sbagliato. Un’analisi efficace basata sull’AI richiede l’azione combinata di tre layer, e il layer di AI è preciso solo quanto la struttura su cui si fonda.
Layer 1: storage di telemetria unificato ed economicamente efficiente: più dati il layer di AI ha a disposizione su cui operare, più i risultati saranno precisi. Questo richiede la combinazione di due elementi: uno storage unificato per log, metriche e trace, e uno storage abbastanza accessibile da conservare i dati su scala senza dover scendere a compromessi.
Layer 2: un grafo di contesto che modella le relazioni semantiche: la telemetria grezza può fornire alcuni insight su un incidente, ma un grafo di contesto spiega perché si è verificato e quali altre connessioni presenta. I grafi di contesto modellano le relazioni semantiche tra i vari oggetti dell’ambiente, così quando il layer di AI segue una traccia, ripercorre una mappa di come le diverse entità si collegano tra loro.
Layer 3: un AI SRE in grado di sfruttare i dati sottostanti e la struttura semantica: l’AI SRE si posiziona al di sopra dei Layer 1 e 2 ed è progettato per utilizzare interfacce ottimizzate per gli agenti con contesto e storage unificati. Un agente AI che interroga il sistema tramite interfacce ottimizzate per gli agenti restituisce risultati più precisi, con una latenza inferiore e meno overhead rispetto a un agente che invia query a una piattaforma non progettata per l’accesso all’AI.
Observe by Snowflake è progettato pensando agli agenti
Observe by Snowflake è realizzato combinando tutti e tre i layer. Il data lakehouse archivia log, metriche e trace con un’elevata fedeltà e costi contenuti. Il grafo di contesto struttura tali dati integrando il contesto proveniente da diverse fonti (aziendali, applicative, infrastrutturali e così via). L’AI SRE si posiziona al di sopra di entrambi, progettato fin dall’inizio per operare in sinergia con gli altri layer. Il risultato: diversi clienti di Observe hanno potuto risolvere i problemi fino a 10 volte più velocemente (con una media superiore a 4x).2 Ecco come si traduce tutto questo all’atto pratico.

Il ciclo di analisi continua ad avvalersi dell’AI, ma risulta fortemente accelerato. Ora questi task possono essere completati in una frazione del tempo originale e l’AI contribuisce a rendere questo processo accessibile a tutti gli utenti, non solo a pochi esperti.
Utilizzando una metodologia tratta dal framework di Anthropic per la misurazione della produttività dell’AI, abbiamo confrontato i tempi delle analisi manuali con quelli di completamento assistito dall’AI, riscontrando che il supporto dell’AI porta ai seguenti risultati:
- Aumenti di produttività costantemente concentrati nella fascia da 3x a 10x
- Il 30% delle interazioni ha mostrato un miglioramento superiore a 5x
- Il 5% delle interazioni ha superato un miglioramento di 10x
I guadagni maggiori sono stati riscontrati nelle analisi che richiedevano di sintetizzare rapidamente grandi volumi di dati da più fonti, ambiti in cui una telemetria unificata e un grafo di contesto possono contribuire a ridurre i tempi di indagine.

I miglioramenti non emergono solo dalle nostre ricerche: abbiamo raccolto anche i riscontri diretti dei clienti:
Un’azienda di location intelligence: l’AI SRE di Observe ha aiutato a migliorare la risposta agli incidenti in tutti i team di engineering dell’azienda. L’azienda ha dichiarato che l’AI SRE e l’MCP Server di Observe potrebbero trasformare la modalità di analisi degli incidenti. Queste funzionalità hanno inoltre contribuito a ridurre il tempo dedicato dagli engineer alla risoluzione dei problemi.
Un operatore del settore sport e intrattenimento: per questa azienda il valore è andato oltre la velocizzazione dell’analisi, traducendosi in un’affidabilità proattiva. L’operatore ha affermato che Observe ha aiutato i team ad abilitare l’individuazione dei problemi di sistema, garantendo una maggiore stabilità complessiva.
Un provider SaaS del settore automotive: il tempo di analisi degli incidenti si è ridotto da oltre tre ore a pochi minuti, migliorando direttamente la customer experience. Il provider ha registrato riscontri uniformi in tutti i team: meno escalation, risoluzione più rapida dei ticket di supporto e una generale riduzione dei tempi di revisione manuale.
In ciascun caso, la differenza è stata determinata dalla completezza di telemetria e contesto del layer di AI. Questi risultati mostrano le potenzialità espresse quando l’architettura sottostante supporta il layer di AI SRE.
L’architettura determina la capacità dell’AI SRE di produrre risultati
Quando valuti un’offerta di AI SRE, è importante porsi tre domande relative alla tua architettura sottostante:
L’AI SRE ha accesso unificato a tutti i dati di telemetria?
L’AI SRE comprende le relazioni tra servizi, deployment, utenti e contesto aziendale?
L’AI SRE è ottimizzato per sfruttare i layer sottostanti o si limita ad affiancarsi ad essi?
Le tue risposte determineranno se l’AI SRE contribuirà ad accelerare l’analisi o se fornirà semplicemente un’interfaccia di chat per la tua telemetria.
Scopri di più sull’osservabilità su scala registrandoti per guardare il video on-demand del webinar di agosto di Observe sull’osservabilità agent-first.
1 “What’s New: AI-Powered Observability at Scale with Observe by Snowflake”, Snowflake Summit 2026, Session WN201B.
2 In base all’analisi condotta da Observe su 3163 sessioni di conversazione AI SRE tra ottobre e novembre 2025.

