La maggior parte degli strumenti di observability entra davvero in azione quando qualcosa sta già andando storto: una latenza sale, un servizio non risponde, una metrica supera una soglia e gli ingegneri iniziano a ricostruire la causa. Empirik vuole spostare il momento della decisione più indietro. La startup, incubata da Sequoia Capital e fondata dagli ex leader IT Avon Puri e Sudheer Dhurjati, è uscita allo scoperto con 21 milioni di dollari raccolti per costruire una piattaforma che prova a prevedere gli outage osservando i cambiamenti prima che producano un guasto.
L’idea nasce dall’esperienza di Puri, che prima di entrare in Sequoia come chief digital and information officer aveva lavorato per anni su infrastrutture in aziende come VMware e Rubrik. Insieme a Dhurjati ha ipotizzato che i modelli moderni potessero comprendere relazioni tra configurazioni, dipendenze e modifiche meglio dei sistemi basati soltanto su regole statiche.
Quasi ogni incidente importante ha una storia precedente
Un outage raramente appare dal nulla. Può essere preceduto da un deploy, una modifica di configurazione, un aggiornamento di dipendenza, una variazione di traffico o un cambiamento nei permessi. Il problema è che in architetture distribuite queste modifiche avvengono continuamente e i loro effetti attraversano servizi che appartengono a team diversi.
Empirik costruisce una rappresentazione delle relazioni e prova a inferire quali cambiamenti possano produrre effetti a cascata. Se un componente dipende da un altro in modo non evidente, la piattaforma vuole segnalarlo prima che l’incidente si manifesti.
Dalla diagnosi alla prevenzione
Il settore AIOps promette da anni di usare machine learning per correlare log e alert. La differenza dichiarata da Empirik è concentrarsi sul futuro invece che soltanto sul passato. Non chiedere “perché il sistema è caduto?”, ma “questa modifica rischia di farlo cadere?”.
È una distinzione enorme perché il costo di fermare un deploy rischioso prima della produzione è molto inferiore al costo di recuperare un servizio dopo un blackout. Ma richiede un livello di accuratezza alto: troppi falsi positivi porterebbero i team a ignorare gli avvisi.
L’infrastruttura moderna è difficile da comprendere anche per chi l’ha costruita
Microservizi, API, code, database gestiti e cloud multi-region creano dipendenze che nessuna persona può tenere interamente in testa. La documentazione spesso resta indietro rispetto al codice. Questo rende gli incidenti un problema di conoscenza oltre che tecnico.
Un sistema capace di leggere configurazioni, cronologia dei cambiamenti e telemetria può costruire una mappa dinamica più aggiornata delle tradizionali diagrammi architetturali. Il vantaggio dell’AI, se reale, starebbe proprio nella capacità di ragionare su una quantità enorme di relazioni.
Sequoia ha incubato il progetto dall’interno
Empirik è insolita perché i fondatori lavoravano dentro Sequoia prima di creare la società. Il venture fund ha riconosciuto che il problema poteva diventare un’azienda autonoma. Questa origine offre accesso a capitale e rete di potenziali clienti, ma non garantisce il prodotto.
Il mercato dell’observability è affollato da Datadog, Dynatrace, New Relic, Splunk e numerose startup. Empirik deve dimostrare che la previsione non è semplicemente una funzione che i grandi vendor possono aggiungere rapidamente.
Il valore si misura nei minuti di downtime evitati
Per un servizio finanziario, un marketplace o una piattaforma cloud, pochi minuti di indisponibilità possono costare milioni e danneggiare reputazione. Questo rende relativamente facile giustificare un software che previene anche una piccola quota di incidenti importanti.
Il problema è dimostrarlo. Un incidente evitato è, per definizione, qualcosa che non accade. Empirik dovrà costruire metriche credibili per mostrare che un alert ha davvero impedito un guasto e non era soltanto una previsione prudenziale.
L’AI può creare anche nuovi outage
La stessa tecnologia che Empirik usa per prevenire problemi sta entrando nei workflow di sviluppo e operations. Agenti di coding producono più modifiche e agenti operativi possono cambiare configurazioni automaticamente. Il volume delle variazioni potrebbe quindi aumentare.
Questo rende più urgente avere controlli che comprendano l’effetto delle modifiche. Se un agente può distribuire codice molto più rapidamente di un team umano, il sistema di verifica deve essere altrettanto veloce.
La fiducia richiede spiegazioni
Un avviso del tipo “non distribuire questo cambiamento” non basta se l’ingegnere non capisce il motivo. Per essere utile, la piattaforma deve mostrare la catena di dipendenze e gli elementi che hanno prodotto la previsione. La spiegabilità qui non è un requisito accademico: serve a decidere se bloccare una release.
La capacità di indicare “questo servizio dipende da quest’altro database, che ha già mostrato questo pattern” può trasformare una previsione probabilistica in un’indicazione operativa.
Prevenire diventa il prossimo obiettivo dell’observability
Per anni il settore ha migliorato la velocità con cui le aziende scoprono e risolvono incidenti. Empirik scommette che il prossimo vantaggio sarà evitare che una parte di essi inizi. Non tutti gli outage sono prevedibili e gli eventi esterni resteranno inevitabili, ma una quota significativa nasce da cambiamenti interni.
Se la startup riuscirà a individuare quella quota con pochi falsi allarmi, i 21 milioni raccolti potrebbero finanziare una nuova categoria. In caso contrario, il prodotto rischierà di diventare un’altra sorgente di alert in sistemi già rumorosi. La differenza tra le due possibilità si misura in una cosa molto concreta: quante notti gli ingegneri smetteranno davvero di essere svegliati da un pager.
