Formazione AI e sviluppo su misura · Bergamo, Italia
ITEN
Il sistema di misurazione che uso ogni domenica per 21 automazioni in produzione: 3 numeri, 5 minuti, nessuna sorpresa il lunedì.
Da febbraio 2026 ho 21 automazioni in produzione. Non un portfolio teorico: 21 task che girano ogni giorno, ogni notte, ogni settimana, senza che io le guardi.
Il problema non era costruirle. Era capire se funzionavano davvero, senza perdere un'ora ogni mattina a controllare i log.
La soluzione sono 3 numeri. Uno per dimensione. Un check domenicale da 5 minuti.
Ho provato con più metriche. Durata media, token usati, latenza, numero di run. Il risultato: passavo più tempo a guardare i numeri che a lavorare.
E ogni volta che trovavo un rosso minore, mi distraevo. Un timeout di 2 secondi in più su un'automazione non critica non è un problema. Ma lo trattavo come tale.
3 numeri mi forzano a decidere cosa conta davvero. Gli altri li tengo nei log se mi servono per debug, ma non li guardo ogni domenica.
Per ogni automazione ho un'etichetta che indica il task manuale equivalente. Quanto mi richiederebbe fare quella stessa cosa a mano, ogni settimana?
Non stimo. Misuro una volta, all'inizio, e aggiorno solo se il task cambia.
Esempio: il monitor GSC mi richiederebbe 2h a settimana a mano. La routine cloud gira in autonomia. Quel numero è 2h risparmiate.
Aggregato su 21 automazioni: questa settimana 41h. Non sono ore di risparmio pianificato: erano già libere prima che me ne accorgessi.
La soglia minima che mi tengo per mantenere un'automazione in produzione è 30 minuti a settimana. Se risparmia meno, probabilmente il task non valeva l'effort di automatizzarlo.
Errore bloccante = l'automazione si è fermata e ha richiesto il mio intervento per ripartire. Non un warning, non un timeout temporaneo. Un blocco che non si è auto-risolto.
L'obiettivo è 0.
Se trovo 1 errore bloccante, lo analizzo subito. Causa quasi sempre:
La cosa che ho imparato: la maggior parte degli errori bloccanti si previene con un circuit breaker e un retry con backoff esponenziale. Non con il monitoraggio. Il monitoraggio te li mostra dopo. Il circuit breaker li gestisce prima che diventino bloccanti.
Questo è il filtro. Risponde a una domanda sola: se stacco 3 giorni e non guardo nulla, questa automazione continua a girare e a produrre l'output giusto?
Se la risposta è no, non è in produzione. È in beta.
Può girare già ogni giorno. Può produrre output utile. Ma se richiede il mio occhio, la mia mano, o una mia decisione per funzionare, la classifico come beta.
Questo ha cambiato come costruisco. Non dichiaro finito qualcosa che non passa questo check. L'automazione non è pronta quando funziona una volta. È pronta quando funziona senza di me.
Ogni domenica mattina apro un file. Ha 21 righe e 4 colonne:
5 minuti. Compilo i numeri, guardo il quadro. Se tutto verde, chiudo il file e la settimana parte.
Se trovo un rosso, lo affronto prima del lunedì. Non voglio scoprire che qualcosa si è rotto giovedì mentre sono nel mezzo di altro.
Numero 1 scende sotto soglia: guardo se il task manuale equivalente è cambiato, o se l'automazione sta facendo lavoro che non serve più.
Numero 2 maggiore di 0: analisi causa entro 24h, fix o pausa.
Numero 3 uguale a no: l'automazione torna in beta. Non è un fallimento, è diagnosi. Torna in produzione quando il problema è risolto.
Non ho bisogno di guardare ogni automazione ogni giorno. Ho bisogno di sapere, una volta a settimana, se il sistema regge.
3 numeri. 5 minuti. 21 righe.
Se qualcosa si rompe tra una domenica e l'altra, il sistema me lo segnala in tempo reale via alert. Il check domenicale è per il quadro aggregato, non per l'emergenza.