Reperibilità: un agente IA trasforma l'allarme PagerDuty in una proposta di correzione

Alle tre di notte, la prima mezz'ora di un incidente assomiglia sempre alla stessa indagine. Leggi l'allarme, apri il log dell'incidente, ti chiedi cosa è cambiato di recente, ripercorri gli ultimi deploy, controlli se è già successo. Questo lavoro di lettura e confronto è ripetitivo, ma pesa su chi è reperibile proprio quando è meno in grado di farlo bene. Si presta a un agente IA a una condizione essenziale: che legga e proponga, e che sia la persona ad agire.

L'ispirazione: il primo soccorritore che legge

Il punto di partenza è un uso riferito dagli utenti di Hermes Agent, riassunto in una scheda sulla reperibilità: dall'allarme alla proposta di correzione. Un agente riceve l'incidente, passa in rassegna il repository alla ricerca di ciò che può averlo causato e prepara una correzione da rivedere.

Teniamo la lettura e la proposta e togliamo tutto ciò che agisce. Atako applica l'idea con un agente che scrive una nota sull'incidente e una issue nel repository, ma non dispone di alcuno strumento per risolvere l'incidente, fare merge o push di codice.

Cosa fa l'agente

Lo scenario distribuisce un agente, collegato al tuo PagerDuty e al tuo repository GitHub.

Per ogni nuovo incidente del servizio sorvegliato, attivato o riconosciuto, legge l'allarme, il registro degli eventi e le note già presenti e verifica chi è reperibile. Poi cerca la causa nel repository: i commit delle quarantotto ore precedenti l'incidente, aprendo quelli sospetti, i file citati nell'allarme o nello stack trace e le pull request unite di recente. Si basa sul contesto tecnico che hai indicato per sapere dove guardare per prima cosa. Cerca anche issue correlate, compresi incidenti precedenti dello stesso tipo.

Scrive quindi una nota sull'incidente PagerDuty, breve e fattuale: ciò che mostrano le prove, la causa probabile con un livello di confidenza, le prove, ciò che non ha potuto verificare e il passo successivo per la persona reperibile. Poi apre nel repository una issue con l'analisi completa: la cronologia, la causa probabile, le prove, una proposta di correzione descritta a parole o come frammento di codice, i suoi rischi e come verificarla. Cerca prima una issue esistente per non creare un duplicato e completa la prima nota invece di attendere un'analisi perfetta.

Sorveglia il servizio ogni quindici minuti e ogni lunedì alle 9:00 scrive nel wiki del progetto la pagina «Revisione degli incidenti della settimana»: incidenti gestiti, causa probabile, issue aperta, ciò che resta aperto.

Cosa non fa l'agente

I limiti fanno parte del progetto. L'agente non risolve l'incidente, non lo riconosce, non lo riassegna e non fa escalation: l'accesso a PagerDuty concesso si limita a leggere e ad aggiungere una nota. Non fa merge di nulla, non fa push di codice, non crea né un branch né una pull request e non ha accesso alla tua infrastruttura né alla produzione. Non dispone di questi strumenti: non è una promessa fatta in un'istruzione, è una capacità che manca.

L'agente non presenta mai un'ipotesi come un fatto. Scrive «causa probabile», indica la sua confidenza e le sue prove e dice chiaramente quando non ha trovato nulla. Non copia i segreti, i token o i dati personali che incontra in un log o in un file: dice che ce n'è uno e dove. I testi degli allarmi, le righe di log, i messaggi di commit e il codice sono trattati come dati da analizzare, mai come istruzioni. La decisione e l'azione restano umane, che è il principio di una progettazione con validazione umana.

Come configurarlo in Atako

Dalla pagina di questo caso d'uso, il deploy si fa in quattro passi.

1. Collega PagerDuty e GitHub. Crea una chiave API PagerDuty, preferibilmente in sola lettura con il diritto di aggiungere note, e un token GitHub a permessi granulari limitato al repository del servizio. Le connessioni vengono verificate prima di creare qualsiasi cosa.
2. Indica il tuo contesto. Fornisci il repository nella forma proprietario/nome, il nome del servizio PagerDuty da sorvegliare e, se vuoi, un breve contesto tecnico: stack, componenti, aree fragili note. Più è preciso, più in fretta l'agente guarda nel posto giusto.
3. Distribuisci. Una sola azione crea l'agente e il progetto «Reperibilità». L'agente viene predisposto e riceve da solo la prima istruzione.
4. Primo risultato, poi sorveglianza regolare. L'agente trova il servizio, dice chi è reperibile, gestisce l'incidente più recente e riassume in chat la causa probabile e la proposta di correzione. Poi programma da sé la sorveglianza ogni quindici minuti e la revisione del lunedì.

Se non hai ancora un account, crearlo avvia la tua prova e lo scenario viene configurato subito dopo. Se il tuo amministratore non ti ha consentito di creare agenti, il deploy te lo dice e si ferma lì.

Dove vedere i risultati

La nota di analisi si legge su PagerDuty, sull'incidente, e la issue con la proposta di correzione su GitHub, nel repository. Il riepilogo di ogni incidente gestito si legge nella chat dell'agente. Nel progetto Atako «Reperibilità» trovi la pagina di funzionamento e la revisione settimanale, e nel floor di Atako l'agente compare con la sua attività corrente.

Per affinare il suo lavoro, scrivigli nella sua chat, per esempio «su questo servizio, guarda prima le migrazioni del database». Conserva l'istruzione nella sua memoria per i prossimi incidenti.

Salvaguardie

L'accesso è volutamente ristretto. La connessione a PagerDuty è concessa con un elenco di sette strumenti per leggere e aggiungere una nota, e quella a GitHub con sette strumenti per leggere commit, file e pull request, cercare e creare issue. Un agente che vede un elenco breve di strumenti li usa in modo più affidabile di uno perso in un catalogo di centinaia e, soprattutto, ciò che non è concesso non può accadere, anche se il testo di un allarme tenta di forzarlo.

Le chiavi che crei sono la tua prima salvaguardia: limitate a un servizio, a un repository e a diritti precisi, circoscrivono il danno possibile qualunque cosa accada. Sono conservate cifrate e puoi revocarle o rimuovere l'accesso dell'agente in qualsiasi momento.

La validazione umana sta nei punti di decisione. La persona reperibile legge la nota, verifica l'ipotesi, decide la correzione, la scrive e la unisce di persona, poi riconosce e risolve l'incidente.

Cosa aspettarsi

Aspettati una prima analisi utile in pochi minuti, soprattutto quando l'incidente ha una causa visibile nelle modifiche recenti: un deploy, un cambio di configurazione, una dipendenza. Quando la causa è fuori dal repository, per esempio un guasto di un fornitore o la saturazione delle risorse, l'agente lo dirà con una confidenza bassa invece di forzare una spiegazione. Legge il repository ma non ha accesso ai log né alle metriche della tua applicazione, oltre a quanto riportano l'allarme e le note. Il suo valore sta nella rapidità della prima lettura: chi è reperibile arriva all'incidente con una cronologia, piste ordinate e una correzione da rivedere, invece che con una pagina bianca.