Riepilogo Tecnico: OpsCortex – Memoria Operativa per Sistemi di Microservizi Auto-Diagnostici

Problema

Le moderne architetture a microservizi affrontano un'asimmetria critica: il rilevamento dei guasti è maturo e automatizzato, ma la localizzazione della causa radice (root-cause) e la relativa spiegazione rimangono manuali, lenti e soggetti a perdita di contesto. Quando i guasti si propagano attraverso le dipendenze dei servizi, innescano "inondazioni di avvisi" (alert floods) che sopraffanno gli ingegneri. Le sfide principali identificate sono:

1. Affaticamento da Avvisi (Alert Fatigue): I sistemi basati su soglie sono privi di memoria; non possono distinguere tra eventi ricorrenti benigni (es. job batch notturni) e crisi reali.
2. Perdita di Contesto: I dati diagnostici critici — come il grafo delle chiamate live, i baseline relativi all'ora del giorno e i recenti cambiamenti di configurazione — sono spesso transitori o dispersi, costringendo la diagnosi a diventare un'attività di "archeologia".
3. Il Probleamento della Cascata: I segnali di guasto sono topologici e temporali (chi si è rotto per primo e come si è diffuso il danno), ma i flussi di avvisi piatti scartano questa struttura, rendendo difficile distinguere la causa radice dalle vittime a valle.

L'articolo sostiene che l'ingrediente mancante nelle operazioni autonome non sia un migliore rilevamento di anomalie o modelli linguistici di grandi dimensioni (LLM) più grandi, ma la memoria operativa: una rappresentazione persistente e strutturata del comportamento del sistema, delle dipendenze e dei guasti storici.

Metodologia

OpsCortex è un prototipo multi-agente che organizza la memoria operativa in un'architettura a quattro livelli e separa la derivazione della causa radice dalla spiegazione.

1. Architettura della Memoria Operativa a Quattro Livelli

Il sistema stratifica la memoria per durata di vita e scopo per garantire che il sistema non sia mai "cieco" al riavvio:

• Livello 1 (Hot Working Memory - Redis): Memorizza i valori correnti delle metriche, le finestre scorrevoli e gli stream di avvisi con un tempo di sopravvivenza (TTL) breve. Rappresenta il "tempo presente" del sistema.
• Livello 2 (Live Dependency Graph - NetworkX): Un grafo diretto a tre livelli (Servizio → Categoria → Metrica) in-process con archi CALLS. Lo stato si propaga verso l'alto (la peggiore metrica determina lo stato della categoria, ecc.) per una rapida percorrenza.
• Livello 3 (Snapshot History - Neo4j): Serializza l'intero grafo ogni 60 secondi. Ciò consente al sistema di analizzare come lo stato è cambiato nei minuti precedenti un incidente, distinguendo tra perdite lente (slow leaks) e crash improvvisi.
• Livello 4 (Permanent Brain - SQLite): Lo stato "appreso". Memorizza i baseline per (servizio, metrica, ora, giorno della settimana), gli archi di chiamata confermati con conteggi di confidenza, i registri del rumore strutturale e la cronologia completa degli incidenti. All'avvio a freddo (cold start), questo livello ricostruisce il grafo e i baseline prima che arrivi la nuova telemetria, garantendo che il sistema mantenga la conoscenza anche durante i riavvii.

2. La Pipeline "Deriva, Poi Spiega"

Il processo di diagnosi è deliberatamente diviso in due fasi distinte per sfruttare i punti di forza della logica deterministica e dell'IA generativa:

• Fase 1: Derivazione Deterministica:
  • Computazione della Causa Radice: Il sistema esegue una ricerca in ampiezza (BFS) sugli archi CALLS confermati per identificare tutti i servizi connessi a un guasto.
  • Ordinamento Temporale: La causa radice viene identificata come il servizio che ha superato la propria soglia di avviso per primo ($arg \min t_{amber}$). Questo separa la causa dalle sue vittime.
  • Gestione del Rumore (Suppress-Then-Detect): Il sistema impara il rumore strutturale (es. job notturni innocui) e sopprime gli avvisi per essi. Tuttavia, la soppressione è annullata da picchi improvvisi (z-score di auto-rilevamento), deriva graduale (z-score di trend) o anomalie correlate in servizi partner.
  • Baseline Consapevoli del Tempo: Il rilevamento utilizza baseline raggruppate per (servizio, metrica, ora, giorno della settimana) per tenere conto delle normali variazioni cicliche.
• Fase 2: Spiegazione Generativa:
  • Un LLM viene invocato solo dopo che lo strato deterministico ha identificato una causa radice e assemblato le prove (percorso del guasto, z-score, punteggi di Isolation Forest, progressione dello stato).
  • Il compito dell'LLM è ristretto a spiegare, confermare e raccomandare correzioni basandosi sulle prove fornite, piuttosto che inferire la causalità dalla telemetria grezza.
  • Pattern Matching: Se un nuovo incidente corrisponde a una firma nota nel "cervello permanente", il sistema ricostruisce la diagnosi precedente e bypassa l'LLM, riducendo costi e varianza.

Contributi Chiave

1. Architettura della Memoria a Quattro Livelli: Un design che separa lo stato presente, la topologia live, la cronologia dei cambiamenti e la conoscenza permanente, prevenendo la perdita di contesto durante i riavvii.
2. Metodo di Root-Cause a Due Stadi: Un approccio deterministico (BFS + ordinamento temporale) che computa la causa, con l'LLM strettamente limitato al ruolo di spiegatore utilizzando le prove pre-assemblate.
3. Ciclo di Vita "Suppress-Then-Detect" Appreso: Un meccanismo che silenzia il rumore strutturale pur rilevando dinamicamente quando la degradazione (picchi o deriva) annulla la soppressione.
4. Mappatura Esplicita dei Modi di Guasto: Una mappatura architettonica diretta dove ogni scelta di design affronta specifici modi di guasto osservati in documentati incidenti di produzione (outage Slack 2021 e 2022).

Risultati e Validazione

Il prototipo è stato validato su un benchmark e-commerce strumentato con otto scenari di guasto iniettabili, inclusi picchi di richieste, ritardi nelle code, guasti a cascata e esaurimento delle risorse.

• Comportamenti di Apprendimento: Il sistema ha dimostrato con successo la capacità di apprendere e sopprimere pattern ricorrenti benigni (job batch) pur rilevando immediatamente e annullando la soppressione quando questi degradavano.
• Bypass dei Pattern: Il sistema ha identificato con successo pattern noti per bypassare l'LLM, dimostrando guadagni di efficienza nei costi man mano che il sistema "impara".
• Ambito di Validazione: Gli autori dichiarano esplicitamente che si tratta di una validazione del meccanismo end-to-end, non di una valutazione comparativa dell'accuratezza rispetto a dati di produzione o altri strumenti come MicroRCA.

Significato e Rivendicazioni

Il documento sostiene che il collo di bottiglia nelle operazioni autonome sia la memoria, non la percezione. Mentre i sistemi di rilevamento sono abbondanti, i sistemi che "comprendono" la normalità, le dipendenze e la storia non lo sono.

OpsCortex rivendica importanza come argomento architettonico concreto per:

• Riformulare l'Obiettivo: Passare dall'inferire le cause radici da zero ad ogni avviso al mantenimento di un "modello vivente" dove la risposta è spesso già nota.
• Divisione del Lavoro: Assegnare compiti deterministici (localizzazione, ordinamento) a sistemi basati su regole e compiti generativi (spiegazione, raccomandazione) agli LLM, riducendo così il rischio di allucinazioni della causa radice.
• Riduzione dei Costi: Rendere il sistema "più economico" nel tempo imparando a sopprimere il rumore e a bypassare le chiamate LLM costose per i pattern noti.

Gli autori rimangono modesti riguardo allo stato attuale del prototipo, riconoscendo limitazioni come l'uso del "primo attraversamento" (first-crossing) come proxy per la causalità (che può fallire in sistemi con accoppiamento di feedback) e la mancanza di valutazione su corpora di incidenti reali etichettati. Il lavoro futuro è identificato nel passaggio dagli euristiche temporali all'inferenza causale e nella validazione del sistema su dati reali di post-mortem.