Come Databricks utilizza l'AI per accelerare l'analisi degli incidenti

Nel nostro post precedente del blog, abbiamo condiviso come Databricks utilizza l'AI per eseguire il debugging di migliaia di database. Qui continuiamo questa storia esplorando come i nostri ingegneri utilizzano l'AI per gestire centinaia di microservizi su oltre 1500 cluster Kubernetes, distribuiti in più di 70 regioni e tre cloud.

Quando qualcosa si rompe alle 2 del mattino, l'ingegnere reperibile deve rispondere rapidamente a una sola domanda: cosa è cambiato?

AI SRE è un agente di debugging basato sull'AI che avvia l'indagine non appena si verifica un incidente. Correla i segnali provenienti da tutto il nostro stack e guida gli ingegneri nell'analisi delle cause principali.

In questo post descriviamo il percorso di debugging che ha plasmato AI SRE, l'architettura alla sua base e i principi di ingegneria che abbiamo seguito per rendere affidabile un sistema basato su LLM durante gli incidenti.

Prima di AI SRE: l'esperienza delle 2 del mattino

Immagina una tipica chiamata di reperibilità. Un picco di latenza colpisce un'API rivolta ai clienti. L'ingegnere si sveglia e inizia la solita routine:

• Ispezionare le metriche del servizio tra dashboard e regioni.
• Cercare nei log gli errori che siano al contempo rilevanti e insoliti.
• Esaminare i deployment, le modifiche alle dipendenze e gli aggiornamenti dei feature flag.
• Verificare lo stato di salute del cloud, della rete e della piattaforma condivisa.
• Trovare ed eseguire il runbook appropriato.

Ognuno di questi flussi di lavoro funziona bene singolarmente, ma il flusso di debugging, ovvero l'atto di collegare i segnali tra di essi, avviene interamente nella mente dell'ingegnere. Gli ingegneri più esperti potrebbero farlo in pochi minuti perché hanno già visto questo pattern. I nuovi ingegneri potrebbero impiegare ore o dover passare il problema a qualcun altro.

Gli strumenti non erano il problema principale. L'onere di collegare i segnali ricadeva sull'ingegnere reperibile, che doveva lavorare rispettando un SLA.

Partire dal cliente, non dalla tecnologia

Non abbiamo iniziato creando un agente. Abbiamo iniziato osservando le persone fare debugging.

Nel corso di diverse settimane, abbiamo intervistato gli ingegneri reperibili di decine di team per mappare i loro percorsi di debugging end-to-end. Abbiamo letto i post-mortem e i documenti di indagine. Abbiamo posto una domanda semplice: dove trascorri il tuo tempo e dove ti blocchi?

Sono emersi costantemente tre pattern:

• L'assemblaggio del contesto richiedeva la maggior parte del tempo. Il vero momento di svolta, ovvero l'identificazione della causa principale, era spesso rapido una volta che l'ingegnere aveva davanti a sé i segnali corretti. Ma raccogliere quei segnali (la metrica giusta, la finestra temporale corretta, il deployment pertinente, la dipendenza a monte che era cambiata) consumava il 60-80% del tempo di indagine.
• La conoscenza era distribuita in modo non uniforme. Ogni team aveva un paio di esperti che "sapevano e basta" come si guastava il loro sistema. Quando questi esperti non erano disponibili, le indagini rallentavano drasticamente. I runbook esistevano, ma erano spesso obsoleti o incompleti e non potevano rispondere a nuove modalità di guasto.
• Lo stato di salute della piattaforma era invisibile finché non smetteva di esserlo. Molti incidenti erano riconducibili a un problema infrastrutturale su larga scala, come un'interruzione del cloud provider o della rete, o a un guasto critico del sistema come Auth. Ma gli ingegneri che eseguivano il debugging a livello applicativo non avevano un modo semplice per verificare questi segnali, quindi passavano il tempo a inseguire ipotesi a livello applicativo prima di scoprire che il problema risiedeva nei livelli infrastrutturali inferiori.

Una volta riconosciuto il debugging come una sequenza di passaggi investigativi ripetibili seguiti dal giudizio di un esperto, è diventato chiaro che gli agenti AI avrebbero potuto accelerare il lavoro. Ma nessun singolo team poteva creare un agente in grado di comprendere ogni servizio, segnale e modalità di guasto. Avevamo bisogno di una piattaforma condivisa che gestisse i blocchi fondamentali comuni, come la raccolta del contesto, l'esecuzione di strumenti e runbook e la correlazione delle prove, consentendo al contempo ai team di estenderla con le proprie conoscenze operative. La domanda si è spostata da Possiamo automatizzare il debugging? a Come possiamo offrire a ogni team una piattaforma basata sull'AI per una diagnosi e una risoluzione più rapide e informate?

Presentazione di AI SRE

AI SRE supporta due esperienze complementari: il triage automatico, che inizia quando si verifica un incidente, e l'indagine interattiva, che consente agli ingegneri reperibili di esplorare ipotesi e richiedere prove aggiuntive.

Triage automatico quando si verifica un incidente

Quando si verifica un incidente, AI SRE si attiva immediatamente, prima ancora che l'ingegnere abbia aperto il portatile. Avvia tre percorsi di indagine in parallelo, raccogliendo prove complementari per produrre una valutazione iniziale:

I controlli dello stato della piattaforma valutano l'ambiente in cui è in esecuzione il servizio.

• L'infrastruttura cloud sottostante funziona correttamente?
• Ci sono problemi di rete in corso nella regione interessata?
• Le dipendenze a monte (database, code di messaggi, servizi condivisi) stanno riscontrando un degrado?

Questo da solo elimina un'ampia classe di falsi indizi, evitando che un ingegnere passi 30 minuti a eseguire il debugging del codice applicativo solo per scoprire che la causa principale era un problema infrastrutturale su larga scala.

L'analisi a livello di servizio estrae i log, le metriche e le tracce pertinenti per il servizio interessato e le sue dipendenze immediate. Esamina i deployment recenti e le modifiche alla configurazione. Identifica le anomalie rispetto al comportamento di base del servizio, non solo "la CPU è alta", ma "la CPU ha registrato un picco di 3 volte alle 2:47 del mattino, in coincidenza con un deployment che ha modificato la dimensione del batch nella pipeline di elaborazione".

L'esecuzione del runbook è la fase in cui AI SRE assume un profilo specifico per il team. I team codificano le proprie procedure di debugging, come i controlli che un esperto di dominio eseguirebbe, le soglie da monitorare e le misure di mitigazione da adottare. I team possono convertire i runbook esistenti in runbook agentici utilizzando le competenze (skill). Queste competenze attingono alla codebase, ai dati di osservabilità e alla cronologia degli incidenti passati per rendere i runbook più accurati e consapevoli del contesto. Esegue quindi questi passaggi per conto dell'ingegnere reperibile, svolgendo la stessa indagine che farebbe un esperto di dominio, ma in pochi secondi anziché in minuti.

Nel momento in cui l'ingegnere legge per la prima volta i dettagli dell'incidente, AI SRE ha già assemblato un ricco riepilogo diagnostico: ecco cosa si è rotto, ecco cosa è cambiato e ecco cosa suggerisce di controllare il runbook del tuo team, con tutti i segnali, le correlazioni e i passaggi successivi in un'unica visualizzazione.

Debugging interattivo per indagini più approfondite

Non tutte le indagini si concludono con il triage automatico. A volte la causa principale è sottile o l'ingegnere desidera esplorare un'ipotesi. La UI di AI SRE fornisce un ambiente di debugging interattivo in cui gli ingegneri possono porre domande di approfondimento in linguaggio naturale, richiedere segnali aggiuntivi ed esaminare in dettaglio finestre temporali o componenti specifici.

È qui che la combinazione di controlli dello stato strutturati e AI conversazionale diventa potente. Un ingegnere potrebbe chiedere: "C'era qualcosa di insolito nel consumer lag di Kafka nei 10 minuti precedenti a questo avviso?" AI SRE recupera le metriche pertinenti, le sovrappone alla sequenza temporale dell'incidente e spiega cosa ha trovato.

Un'architettura a livelli per il debugging

La nostra intuizione principale derivante dalle interviste ai clienti è stata che il debugging non è un singolo problema, ma uno stack di problemi, e risolverli richiede astrazioni deliberate. Abbiamo progettato AI SRE come una piattaforma a livelli, in cui ogni livello ha una responsabilità chiara e i livelli superiori possono concentrarsi su aspetti di livello sempre più elevato.

Le primitive costituiscono la base: i dati operativi grezzi da cui dipende in ultima analisi ogni indagine. Esistono già primitive per metriche, avvisi, log, informazioni di rilascio e codice, ma accedervi durante un incidente significava passare da uno strumento all'altro tra cinque tool diversi con tre o quattro linguaggi di query differenti. Il livello delle primitive non sostituisce questi sistemi; li riconosce come unica fonte di verità.

Il livello API utilizza le primitive e fornisce un accesso controllato e uniforme ai dati sottostanti. Invece di fare in modo che ogni strumento di debugging interroghi direttamente le origini dati, come l'archivio dei log o delle metriche, abbiamo creato API specifiche per ogni scopo: un'Observability API, una Deployment API e un'Alerts API che gestiscono l'autenticazione, il rate limiting e la normalizzazione dei dati. Questo è il livello che trasforma l'"infrastruttura grezza" in "infrastruttura di cui è possibile eseguire il debugging". Significa anche che quando sostituiamo un sistema sottostante, gli strumenti di debugging sovrastanti non smettono di funzionare.

Il Core Engine è dove risiede l'intelligenza. Un framework bot fornisce il livello di orchestrazione per la creazione di workflow di debugging, mentre l'engine gestisce i meccanismi di esecuzione parallela, correlazione dei risultati e sintesi basata su LLM. Questa è la piattaforma su cui vengono eseguiti i nostri bot proprietari ma, cosa fondamentale, è anche la stessa piattaforma a disposizione di ogni team che desideri creare i propri.

L'Application Layer è il luogo in cui avviene effettivamente il debugging. È qui che viene eseguito il nostro bot di triage degli incidenti a livello di piattaforma. È anche il punto in cui possono integrarsi strumenti di IA di terze parti, fornendo funzionalità complementari senza dover ricostruire tutto da zero.

Questa separazione ci consente di migliorare l'accesso ai dati e l'orchestrazione in modo indipendente, supportando al contempo sia i workflow gestiti centralmente sia i runbook di proprietà dei singoli team.

Progettare per l'affidabilità in un mondo non deterministico

Rendere un agente basato su LLM sufficientemente affidabile per la gestione degli incidenti, dove la fiducia è tutto, ha richiesto una progettazione mirata. Alcuni principi ci hanno guidato:

Controlli strutturati prima del ragionamento aperto. AI SRE esegue prima i controlli deterministici dello stato della piattaforma e i passaggi del runbook. Il livello LLM sintetizza e spiega i risultati, ma la raccolta dei dati non è lasciata al giudizio del modello.

Trasparenza rispetto a risposte da scatola nera. Ogni conclusione presentata da AI SRE rimanda alle prove sottostanti: la metrica specifica, la riga di log, il diff di deploy. Gli ingegneri possono verificarle, non solo fidarsi. Questo era un punto non negoziabile, perché gli ingegneri reperibili non agiscono in base a una raccomandazione che non possono verificare.

Degradazione graduale. Se AI SRE non riesce a determinare una causa radice con certezza, lo dichiara esplicitamente e presenta le prove raccolte, organizzate per rilevanza. Un'indagine parziale che sia onesta sui propri limiti è molto più utile di una diagnosi frutto di allucinazione.

Impatto

AI SRE ora supporta più di 150 team in Databricks, con oltre 250 utenti attivi settimanali che eseguono più di 2.000 indagini ogni giorno, risparmiando diverse ore di debugging. Dal lancio abbiamo ricevuto feedback positivi:

“Il team della piattaforma di storage si affida molto a AI SRE per il triage. Anticipa le mie indagini: prima ancora che io apra un alert, l'agente ha già correlato i segnali e prodotto un'analisi iniziale della causa radice. Complimenti al team per aver creato una piattaforma di debugging davvero generica che consente a più team di integrare workflow agentici nella loro quotidianità.”—Gaurav Garg, Sr. Staff Engineer

“Prima di AI SRE, la prima fase di un incidente consisteva nel raccogliere il contesto: dashboard, intervalli temporali, filtri sull'intera flotta. Ora il contesto rilevante arriva in un unico posto, già circoscritto all'alert o all'incidente. Non devo fidarmi sulla parola dell'agente. Le prove sono integrate nell'indagine e un solo clic apre lo strumento sottostante, già pre-filtrato, in modo che io possa verificarle di persona.”—Himanshu Mishra, Senior Engineer

“AI SRE ha trasformato la gestione degli incidenti unificando metriche, log e stato delle dipendenze, accelerando il triage degli incidenti, individuando prima le cause radice e riducendo così l'MTTR a livello aziendale.”—Adama Kone, Manager - NOC Team

Il risultato più importante non è stato quello di sostituire il giudizio degli ingegneri, ma di fornire loro un punto di partenza più rapido e supportato da prove per l'indagine.

Cosa abbiamo imparato

Tre insegnamenti tratti dalla creazione di AI SRE:

Lasciare che i team gestiscano le proprie competenze. Un agente centralizzato che cerca di codificare la conoscenza del dominio di ogni team sarà sempre obsoleto e fragile. Rendendo i runbook agentici una primitiva componibile di proprietà e manutenzione dei team, abbiamo trasformato AI SRE in una piattaforma che diventa più intelligente man mano che cresce, senza che la piattaforma stessa diventi il collo di bottiglia.

Costruire il livello di contesto prima di ottimizzare il modello. Abbiamo dedicato più tempo a mappare il modo in cui gli ingegneri analizzano effettivamente gli incidenti rispetto a quello dedicato al prompt engineering. Questo investimento iniziale nella comprensione del problema ci ha permesso di creare la cosa giusta, ovvero un agente che raccoglie il contesto ed esegue controlli noti, anziché la cosa più ovvia, che sarebbe stata un chatbot integrato a forza nel nostro sistema di osservabilità.

Guadagnare fiducia attraverso prove tracciabili. Gli ingegneri reperibili lavorano sotto pressione e non possono permettersi di seguire false piste. Ogni raccomandazione formulata da AI SRE è supportata da prove tracciabili. Questa trasparenza è ciò che ha trasformato i primi utenti scettici in utilizzatori quotidiani.

I guardrail sono più importanti per gli agenti che per le persone. Consentire agli agenti di accedere ai dati di osservabilità ha significato riprogettare il nostro livello API, non solo aprirlo. Gli agenti eseguono query in modo diverso rispetto agli esseri umani. Interrogano gli endpoint a raffica, eseguono controlli in parallelo e non si stancano né si fermano da soli. Abbiamo dovuto integrare dei guardrail in modo che gli agenti potessero lavorare rapidamente senza compromettere l'infrastruttura che supporta anche i sistemi di alerting e monitoraggio critici per il business.

Prossimi passi

Oggi AI SRE si concentra sulla fase di indagine della gestione degli incidenti: capire cosa è successo e perché. Il passo successivo naturale è l'estensione alla mitigazione guidata: non solo diagnosticare il problema, ma aiutare gli ingegneri a intraprendere l'azione correttiva corretta in tutta sicurezza.

Stiamo anche investendo nell'apprendimento tra incidenti diversi: utilizzare i pattern degli incidenti passati per migliorare le diagnosi future, far emergere problemi ricorrenti prima che generino un alert e aiutare i team a identificare lacune sistemiche di affidabilità.

Unisciti a noi

Guardando al futuro, siamo entusiasti di continuare a spingere i limiti di come l'IA può plasmare i sistemi di produzione e rendere semplice la gestione di infrastrutture complesse. Se hai la passione per la creazione di piattaforme interne di nuova generazione basate sull'IA, unisciti a noi!

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale