Da Uptime a Experience: Il passaggio guidato dall’IA nell’Osservabilità moderna

Nel 2001, IBM redasse un manifesto per l’IT autonomo. La Visione del Computing Autonomico suddivise l’auto-gestione in quattro pilastri: auto-ottimizzazione, auto-guarigione, auto-configurazione e auto-protezione. Ero in Microsoft quando IBM presentò questa visione IT. Reagimmo proponendo idee tecnologiche come il data center autonomo, ma in definitiva era un sogno molto avanti rispetto al suo tempo. Non esisteva un modo pratico per trasformare quella visione in realtà.

Durante i miei anni in Microsoft, facevo parte del team dietro Clippy. Anche se l’assistente a forma di graffetta animata era famosamente invadente, l’idea alla base era valida: i computer dovrebbero aiutare attivamente gli esseri umani a svolgere il loro lavoro. Non disponevamo semplicemente della potenza computazionale e dell’IA necessarie per renderlo possibile. 25 anni dopo, finalmente ci riusciamo.

Dal Livello di Servizio al Livello di Esperienza

Il concetto di osservabilità non nasce nell’IT. Nel 1960, l’ingegnere e matematico ungherese-americano Rudolf E. Kálmán coniò il termine “observability” per descrivere quanto bene un sistema possa essere misurato tramite le sue uscite. Poi, nel 2013, Twitter adottò il termine in una serie di post sul blog, affermando di fatto che il monitoraggio tradizionale, attraverso tutti gli strumenti commerciali disponibili, era progettato per un’epoca tecnologica diversa e non funzionava nelle architetture a scala microservizi.

Pensateci come a un medico che visita un paziente. Può controllare il suo battito, misurare la pressione sanguigna e osservare altre caratteristiche esterne per valutare indirettamente la salute interna del paziente. Nell’IT, dobbiamo fare lo stesso. Quando c’è un’irregolarità nel battito del paziente, dobbiamo capire se ciò indica problemi al rene o al fegato. Alla scala e alla complessità delle operazioni che Twitter gestiva già 20 anni fa (l’azienda serviva solo 100 milioni di utenti con tweet e feed in tempo reale), l’osservabilità richiedeva strumenti e approcci di monitoraggio diversi.

I sistemi odierni sono diventati ancora più grandi e complessi, con dipendenze da reti di distribuzione dei contenuti, caching e distribuzione di bitmap, font, file JavaScript e così via in tutto il mondo. Comprendere davvero le prestazioni delle applicazioni reali non è un’impresa facile.

Quando l’IT riceve una chiamata di allerta alle 4 del mattino, qualcuno deve alzarsi dal letto e capire se il problema è dovuto a un settore difettoso su un disco rigido o a un attore maligno che tenta di penetrare e creare scompiglio nell’infrastruttura. In realtà non importa quale dei due sia: alla fine, il loro compito è mantenere tutti i sistemi in funzione. Fortunatamente, per valutare oggi la salute delle applicazioni, possiamo raccogliere tutta la telemetria disponibile: ogni dispositivo di rete, ogni applicazione, migliaia di integrazioni pronte all’uso, il flusso dei ticket attraverso JIRA o Atlassian e molti altri segnali.

È qui che entrano in gioco gli Experience Level Objectives (XLO). Probabilmente avete sentito parlare di Service Level Agreements (SLA) e Service Level Objectives (SLO), ma gli XLO fanno il passo successivo misurando se i vostri clienti e dipendenti stanno ottenendo il livello di esperienza che desiderano. Si tratta di qualità, non solo di uptime. Da un punto di vista tecnico, l’unico modo per raggiungere gli XLO è avere visibilità dal NIC al dispositivo dell’utente finale.

Lo scorso ottobre, AWS US‑EAST‑1 è andato offline. Catchpoint ha rilevato il problema 16 minuti prima che Amazon lo riconoscesse pubblicamente. I clienti con quella visibilità hanno potuto reagire prima che i loro utenti percepissero le conseguenze dell’interruzione.

La promessa dell’osservabilità è come Smokey Bear: rilevare dove c’è fumo prima che ci sia un incendio. Se implementata correttamente, l’osservabilità consente di spegnere un incendio di prateria prima che diventi una conflagration che distrugge le Palisades in California. Smokey è il sistema di allarme precoce che può rilevare quei piccoli sentori di fumo indipendentemente dalla loro origine: un problema AWS, un problema Oracle, un problema GCP, un problema Microsoft Azure o qualcosa di anomalo nella vostra infrastruttura.

L’IA scala i sistemi di sicurezza

Nessun operatore umano può tenere sotto controllo i sistemi infrastrutturali odierni. L’unico modo per monitorare i sistemi su larga scala, ingerendo petabyte di dati di log e trilioni di metriche al giorno, è utilizzare l’IA.

Ad esempio, supponiamo di voler monitorare le prestazioni di lettura/scrittura di un disco o gli overflow di I/O o di buffer di pacchetti nell’ambiente di rete. È possibile utilizzare una soglia dinamica per definire cosa sia normale, oppure un metodo deterministico per analizzare i dati delle serie temporali dell’ultima settimana, mese, anno o di qualsiasi intervallo desideriate, e stabilire soglie di prestazione normali. Una volta ottenuta questa analisi statistica, potete impostare livelli a due deviazioni standard dalla media, così che quando qualcosa si verifica al di fuori di quel range, si genera un avviso che le prestazioni potrebbero essere anomale.

Tuttavia, i sistemi altamente complessi possono ricevere migliaia di avvisi al giorno. I cruscotti iniziano a lampeggiare e le persone cominciano a ricevere chiamate di allerta. Setacciare tutti questi avvisi non è un uso efficace del tempo umano. Infatti, Vectra stima che le organizzazioni ricevano in media 2.992 avvisi di sicurezza al giorno, il 63 % dei quali rimane non affrontato.

Gli strumenti di IA possono ridurre queste migliaia di avvisi al giorno a poche decine. Ricordo un caso in cui un unico problema su una singola NIC di una singola macchina ha generato 2.000 avvisi a valle. Grazie all’IA, il cliente è riuscito a correlare gli avvisi e a ottenere un’analisi della causa radice molto più rapida, che ha concluso che un unico problema in quel preciso momento stava facendo diventare rosso l’intero cruscotto dell’azienda.

L’IA rende di nuovo entusiasmante l’IT

Mi sono preso una pausa dopo che Cisco ha acquisito Splunk nel 2023. Nei due anni successivi ho osservato amici e ex colleghi fondare aziende per utilizzare l’IA in modi che non erano possibili nemmeno cinque anni fa. (Ricordate che, se ChatGPT fosse un bambino umano, sarebbe un treenne).

I team IT hanno bisogno di aiuto per rilevare il fumo prima che scatti l’allarme, non di più cruscotti da fissare. In un certo senso, questo è lo stesso problema che IBM, Twitter e persino Microsoft con Clippy hanno cercato di risolvere.

Questo è il motivo per cui ho deciso di tornare in gioco. La tecnologia ha finalmente raggiunto un punto in cui possiamo mantenere la promessa originale di osservabilità e IT autonomo.