Un assistente basato sull'IA ha gestito i miei turni di reperibilità per sette giorni, elaborando 11 alert e riducendo il mio tempo medio di risoluzione di un problema da 45 minuti a 20 minuti. L'esperimento è importante perché un modello linguistico di dimensioni moderate può ridurre di mezz'ora i tempi di risposta agli incidenti, pur richiedendo una rigorosa supervisione umana.

Perché ho messo un'IA in reperibilità

I team cloud trascorrono la maggior parte del loro turno a scavare nei log, controllare i recenti deployment e confermare che una richiesta di scaling sia sicura. Quei compiti "noiosi" sono ripetitivi, ricchi di dati e soggetti alla fatica umana. I recenti progressi nei grandi modelli linguistici hanno promesso di automatizzare proprio quel lavoro di pattern matching, ma la maggior parte delle demo pubbliche viene eseguita in ambienti sandbox. Volevo vedere se l'entusiasmo sopravviveva in un cluster di livello produzione che serve effettivamente clienti paganti.

Configurazione del test

  • Accesso – L'agente poteva leggere ogni metrica, log e definizione di deployment. Poteva scrivere solo in una ristretta whitelist: riavviare un pod, aumentare il numero di repliche o scalare un deployment. Qualsiasi azione oltre queste richiedeva la mia approvazione esplicita.
  • Ruolo – Ho trattato il modello come un ingegnere junior al suo primo turno di reperibilità. Riceveva l'alert, eseguiva l'analisi e pubblicava una raccomandazione nel canale dell'incidente.
  • Reti di sicurezza – Tutte le azioni di scrittura erano protette da un prompt manuale "sì/no". Ho anche limitato l'uso di token del modello per mantenere i costi prevedibili.

Dove l'IA ha eccelso

La velocità dell'agente è stato il vantaggio più evidente. Non appena scattava un alert, recuperava i log pertinenti, tracciava le metriche recenti ed elencava gli ultimi tre deployment. Nel momento in cui ho aperto il laptop, il lavoro investigativo iniziale era già stato completato. Degli 11 alert:

  • 8 erano problemi di routine (picchi di memoria, riavvii di container, semplici errori di configurazione). L'IA ha identificato correttamente la causa principale ogni volta.
  • Ha segnalato un aumento graduale della memoria in un microservizio prima che il problema degenerasse in un outage alle 2 del mattino, dando al team la possibilità di intervenire precocemente.
  • Il consumo di token per l'intera settimana è rimasto intorno ai 30$, ben entro un tipico budget di reperibilità quando limitato.

Questi risultati si traducono in una riduzione misurabile del tempo medio di risoluzione (MTTR) da 45 minuti a 20 minuti, liberando gli ingegneri per concentrarsi su attività ad alto impatto.

Dove ha vacillato

La fiducia non equivale alla correttezza. L'IA si è sbagliata con sicurezza su 3 degli 11 alert:

  1. Ha dato la colpa a un recente deployment del codice per un fallimento della connettività del database, ma tale spiegazione era errata.
  2. Di fronte a un'anomalia di rete sconosciuta, ha proposto correzioni generiche che non affrontavano il problema sottostante.
  3. Durante un alert relativo al carico, ha suggerito di scalare un servizio da 3 a 30 repliche. Il problema non era il carico, ma una cattiva configurazione.

Poiché le mie protezioni richiedevano l'approvazione manuale per qualsiasi operazione di scrittura, gli errori del modello sono stati intercettati prima che potessero causare danni. Tuttavia, l'episodio ha evidenziato un rischio fondamentale: il modello può produrre raccomandazioni plausibili ma imprecise, specialmente per problemi nuovi.

Gestione dei costi e dei rischi

La bolletta di 30$ per i token dimostra che eseguire un LLM in un loop di produzione può essere economico se l'utilizzo è monitorato. Tuttavia, il costo reale è il rischio operativo. Scalare erroneamente un deployment può portare a spese cloud incontrollate, e annullare un rilascio riuscito può erodere la fiducia dei clienti. L'esperimento ha rafforzato due salvaguardie:

  • Controllo delle azioni – Consentire al modello solo di suggerire, mai di eseguire, cambiamenti ad alto impatto senza un clic umano.
  • Limiti di budget – Impostare limiti rigidi al consumo di token e avvisare il team quando il modello si avvicina al tetto massimo.

Cosa monitorare in futuro

Fino ad allora, i team dovrebbero:

  • Monitorare la proporzione di suggerimenti generati dall'IA che richiedono un override manuale.
  • Misurare l'impatto sul MTTR attraverso diverse categorie di incidenti (di routine vs. nuovi).
  • Testare il modello in un ambiente di staging con alert sintetici prima di concedere qualsiasi diritto di scrittura in produzione.

Insegnamenti per i team ops

  • Automatizza l'80% delle attività noiose – Usa l'IA per l'aggregazione dei log, la correlazione delle metriche e la generazione iniziale di ipotesi.
  • Riserva il 20% più rischioso agli umani – Lo scaling oltre una soglia moderata, i rollback e le eliminazioni dovrebbero rimanere soggetti a un passaggio di approvazione manuale.
  • Considera il modello come un partner, non come un sostituto – Un ingegnere che conosce il sistema può convalidare l'output dell'IA più velocemente di un nuovo arrivato, trasformando l'assistente in un moltiplicatore di forza.

Un agente AI non può ancora gestire un'operazione cloud in totale autonomia, ma come partner per il triage offre già tangibili incrementi di velocità. La chiave è mantenere la fiducia sotto controllo, imporre rigorosi guardrail e lasciare che il modello si occupi del lavoro ripetitivo e pesante, mentre l'esperienza umana guida le decisioni critiche.