Oltre la risposta agli incidenti: come trasformare OpenTelemetry in un data asset aziendale

Uno dei cambiamenti più interessanti che ho osservato lavorando con i clienti Snowflake è l’evoluzione delle nostre conversazioni sull’osservabilità dei dati.

Qualche anno fa, i leader dell’ingegneria erano concentrati sulla strumentazione e sulla visibilità: Come possiamo raccogliere più telemetria? Come possiamo ridurre il tempo medio di risoluzione? Come possiamo ottenere una migliore visibilità su sistemi sempre più complessi?

Oggi, OpenTelemetry e le moderne piattaforme di observability come Snowflake rendono più semplice rispondere a molte di queste domande. Le conversazioni sull’observability possono ora partire da metriche di business e risultati, non da log, metriche e trace. L’obiettivo non è più solo capire cosa sta succedendo nei sistemi distribuiti, ma collegare i dati tecnici a ciò che significano per il business.

Questo cambiamento solleva una serie di domande pratiche per i team di ingegneria:

• Per quanto tempo dovremmo conservare la telemetria?
• Come colleghiamo i dati operativi con i dati dei clienti e di business?
• Come può la telemetria supportare l’analisi dei dati e l’AI?
• Come garantiamo che i dati di observability restino aperti e sotto il nostro controllo?

Queste domande non sono teoriche. Emergono non appena l’impatto tecnico di un incidente diventa una questione di abbandono dei clienti, ricavi e impatto sul business.

Prendiamo in considerazione una grande azienda ipotetica di servizi finanziari che serve milioni di clienti. Come molte aziende digitali, anche pochi minuti di performance degradate possono influire sull’esperienza del cliente, aumentare il volume delle richieste di supporto e mettere a rischio i ricavi.

Durante un incidente in produzione, il team di ingegneria ha notato una latenza elevata in un servizio di pagamento rivolto ai clienti. Inizialmente non era chiaro dove avesse origine il problema: nell’applicazione, in una dipendenza upstream o nell’infrastruttura sottostante. Il team non aveva un modo immediato per determinare quali clienti o transazioni fossero interessati.

Grazie all’Observability Context Graph di Observe e all'AI site reliability engineering (AI SRE), gli ingegneri hanno unificato stream di telemetria eterogenei per isolare il componente malfunzionante, hanno mappato i suoi effetti a cascata attraverso dipendenze complesse e hanno riportato l’ambiente a uno stato di salute.

Dal punto di vista operativo, l’incidente era concluso. Ma dal punto di vista strategico, era appena iniziato.

Il team di ingegneria aveva risposto alla domanda “Cosa si è rotto?” Il team esecutivo, però, ha subito iniziato a porre domande di approfondimento:

• Qual è stato l’impatto sui clienti?
• Quanti ricavi erano a rischio?
• Alcuni fornitori di servizi di pagamento sono stati colpiti più di altri?

Si tratta di un incidente isolato o dell’inizio di una tendenza più ampia in termini di affidabilità?

Per ottenere le risposte era necessario combinare la telemetria operativa con gli account dei clienti, le transazioni di pagamento, la cronologia dei deployment e l’utilizzo del prodotto. A questo punto, l’osservabilità ha smesso di essere solo un problema operativo ed è diventata anche un problema di dati.

Arricchire la telemetria operativa con il contesto relativo a clienti, prodotto e finanza ha dato ai leader di ingegneria e di business dell’organizzazione finanziaria una visione condivisa dell’impatto dell’incidente. Invece di fermarsi all’analisi della causa principale, il team ha potuto quantificare l’impatto sui propri clienti, stimare i ricavi a rischio e assegnare priorità agli interventi di correzione in base ai risultati di business.

Questa è l’applicazione più ampia dell’observability: I medesimi dati che aiutano gli ingegneri a ripristinare la produzione possono anche aiutare i leader a comprendere l’impatto sui clienti, identificare tendenze di affidabilità a lungo termine, migliorare le decisioni di ingegneria e alimentare l’AI.

Invece di chiedersi solo cosa si è rotto, le organizzazioni possono capire qual è l’impatto. Una volta che la telemetria è collegata al contesto di business, la gestione degli incidenti diventa il punto di partenza dell’analisi, non il punto di arrivo. La domanda successiva è come conservare, governare e riutilizzare i dati di observability nei flussi di lavoro di analisi, AI e operazioni.

Man mano che le organizzazioni di ingegneria maturano le proprie pratiche di observability, scoprono che la telemetria ha un valore che va ben oltre la finestra dell’incidente. Log, metriche e trace stanno diventando asset aziendali di lunga durata: dati che dovrebbero essere conservati, governati e arricchiti insieme ai dati di clienti, prodotto e business.

È qui che entra in gioco l’osservabilità aperta. Lo standard OpenTelemetry offre un modo coerente e indipendente dal fornitore per strumentare le applicazioni. Tecnologie aperte come Apache Iceberg™ stanno cambiando il modo in cui le organizzazioni archiviano e gestiscono i dati aziendali, separando l’archiviazione dal calcolo e consentendo l’interoperabilità tra più motori. Scopri di più su Observe su Apache Iceberg (attualmente in anteprima privata.

Insieme, queste tecnologie creano una base in cui la telemetria non deve necessariamente vivere esclusivamente all’interno di una piattaforma operativa. Le organizzazioni possono conservarla come un set di dati aperto sotto il proprio controllo: un set di dati che può essere governato in modo coerente, analizzato insieme ai dati aziendali e utilizzato nei flussi di lavoro di analisi, AI e operazioni.

La domanda che sento più spesso dai leader di ingegneria è come la loro piattaforma di observability e la piattaforma dati dovrebbero lavorare insieme. La risposta diventa chiara quando osserviamo da vicino il ciclo di vita di un incidente.

Un’idea sbagliata comune è che portare la telemetria in Snowflake sostituisca una piattaforma di observability. Ciò che ho osservato sul campo è che i clienti generalmente le considerano complementari, non reciprocamente esclusive.

Quando gli ingegneri rispondono a un incidente, hanno bisogno di flussi di lavoro operativi che uniscano dati e contesto per comprendere e risolvere rapidamente i problemi. Snowflake fornisce la base dati, mentre Observe aggiunge flussi di lavoro di observability progettati appositamente, l’AI SRE e l’Observability Context Graph per collegare log, metriche, trace e relazioni infrastrutturali, aiutando i team a passare dai dati a un contesto utilizzabile e a ripristinare il servizio più rapidamente.

L’analisi post-incidente è una sfida diversa. I team devono collegare la telemetria con i dati dei clienti e finanziari per identificare tendenze a lungo termine. Una volta che i dati di telemetria si trovano nell’AI Data Cloud Snowflake, possono essere arricchiti e analizzati come asset aziendale strategico.

Man mano che l’AI diventa centrale nei flussi di lavoro di ingegneria, avere la telemetria insieme ai dati aziendali consente ai team di identificare pattern e anomalie che sarebbero difficili da individuare in sistemi disconnessi.

Quando la produzione è degradata, gli ingegneri hanno bisogno di risposte immediate. Le piattaforme di observability progettate appositamente, come Observe, sono pensate per questo flusso di lavoro operativo. L’AI SRE aiuta i team a investigare gli incidenti, individuare anomalie e sintetizzare insight, mentre il context graph collega applicazioni, infrastruttura, log, metriche e trace in una vista unificata del sistema.

Insieme, queste funzionalità offrono agli ingegneri il contesto necessario per capire cosa è successo e ripristinare il servizio il più rapidamente possibile.

Una volta ripristinato il servizio, la stessa telemetria può essere collegata ai dati di clienti, transazioni, finanza, prodotto e deployment. I team possono usare questo contesto più ampio per quantificare l’impatto sul business, identificare pattern ricorrenti e assegnare priorità agli investimenti in affidabilità.

È qui che Snowflake estende il valore dell’observability. La telemetria può essere conservata e analizzata insieme al resto dei dati aziendali, supportando l’analisi dei dati governata e l’AI senza separare i dati tecnici dal contesto di business necessario per interpretarli.

Observe fornisce intelligence operativa per la risoluzione degli incidenti in tempo reale. Snowflake estende il valore della telemetria come asset aperto e governato per l’analisi a lungo termine e l’AI. Insieme, sono progettati per supportare l’intero ciclo di vita dell’observability:

• Strumentare e raccogliere segnali con standard aperti
• Investigare gli incidenti con flussi di lavoro operativi rapidi e contestuali
• Collegare la telemetria ai dati di business per quantificare l’impatto
• Conservare e governare i dati risultanti per l’analisi, l’ingegneria dell’affidabilità e l’AI

L’obiettivo non è scegliere tra una piattaforma di observability e una piattaforma dati. È collegare la piattaforma che gli ingegneri usano durante un incidente con i dati che l’azienda utilizza in seguito.

La telemetria non è più solo dati operativi: è dati aziendali. Quando le organizzazioni la trattano come tale, vanno oltre la gestione degli incidenti e possono iniziare ad apprendere continuamente dai propri sistemi.

Come sta affrontando la tua organizzazione questa evoluzione? Come stai collegando la telemetria operativa con il resto dei tuoi dati aziendali? E come potrebbe un approccio più aperto e governato aiutare i tuoi team a trasformare i segnali di affidabilità in insight di business?

Scopri di più su Observe by Snowflake o contattaci all’indirizzo snowflake.com/en/product/observe/contact/.

Note legali

Questo articolo contiene delle affermazioni riferite al futuro, tra cui offerte future di prodotti, che però non rappresentano un impegno a fornire alcuna offerta di prodotti. Le offerte e i risultati effettivi potrebbero essere diversi ed essere soggetti a incertezze e rischi noti e non noti. Fai riferimento al nostro più recente modulo 10‑Q per ulteriori informazioni.