Due tipi di guasto: quello che ti avvisa e quello che ti lascia credere che vada tutto bene
Quando qualcuno chiede come capire se un'automazione è fallita, quasi sempre sta pensando al guasto rumoroso: il flusso si ferma, lo strumento manda una mail, qualcuno lo sistema. Quello è il guasto buono. È visibile, è delimitato e il suo costo è proporzionale al tempo che qualcuno impiega a guardare il telefono.
Il problema è l'altro. Il guasto silenzioso non si ferma: finisce. Segna l'esecuzione in verde, non rompe niente e continua a girare domani, uguale, male. E non scatta nessun allarme perché, tecnicamente, non c'è niente da segnalare: ogni passo ha fatto il suo e non ha restituito errore. Lo strumento ti sta dicendo la verità —«tutti i passi sono stati eseguiti»— e tu stai leggendo un'altra cosa —«il lavoro è stato fatto»—. Non è la stessa cosa.
La differenza conta perché il costo non si somiglia. Il guasto rumoroso costa ore. Quello silenzioso costa settimane, e quando si scopre bisogna ricostruire all'indietro: quali ordini non sono entrati, quali clienti non hanno ricevuto risposta, quali fatture non si sono registrate. Questa guida si aggancia a quella sulla manutenzione delle automazioni con IA, che spiega perché si rompono. Qui andiamo all'altra metà: come te ne accorgi.
Le quattro facce del guasto silenzioso
In produzione se ne ripetono quattro, e nessuna fa scattare un errore. Riconoscerle è metà del lavoro.
1. Il successo vuoto
La chiamata restituisce un 200 e il corpo arriva vuoto, o con una lista di zero elementi. Per il flusso è un successo perfetto: ha chiesto dati, ha ricevuto risposta, è andato avanti. Il ciclo che veniva dopo non ha girato nemmeno una volta, quindi non ha creato niente, quindi non è fallito. È il pattern numero uno ed è il più difficile da vedere, perché nel pannello sembra identico a un giorno buono.
2. Il filtro che si mangia tutto
Qualcuno ha cambiato il nome di un campo nel CRM, o il formato di una data, e la condizione che lasciava passare i record ormai non la rispetta più nessuno. Il flusso gira, filtra, e dal filtro non esce niente. Esecuzione corretta, zero lavoro fatto. Si distingue dal precedente per un dettaglio: qui i dati sono entrati davvero, semplicemente nessuno ha superato la porta.
3. La risposta inservibile che nessuno valida
È il guasto tipico di automatizzare con l'IA. Chiedi al modello di restituire una categoria o un JSON, e lui restituisce una scusa, un testo che spiega perché non può, o il JSON avvolto in tre frasi di cortesia. Il passo successivo lo accetta perché è una stringa di testo e lui si aspettava una stringa di testo. Da lì in poi tutto il flusso lavora su spazzatura, con totale normalità. Ci si copre con una validazione di formato prima di proseguire: se non rispetta lo schema atteso, si ferma e scala. La guida sull'umano nel loop sviluppa dove mettere quella rete in base a quanto costa l'errore.
4. Il flusso che ha smesso di girare
Il più banale e il più frequente. Nessuno l'ha rotto: si è disattivato cambiando piano, è scaduta una credenziale OAuth, qualcuno l'ha messo in pausa per provare un giovedì e non l'ha più riattivato. Non c'è esecuzione, quindi non c'è errore, quindi non c'è niente da segnalare. Questo non si scopre guardando cosa succede. Si scopre notando cosa non succede.
Cosa allertare e cosa tacere: un allarme che suona sempre non lo ascolta nessuno
L'errore opposto a non avere alert è averli tutti. Un canale che riceve quaranta avvisi al giorno smette di essere un canale di alert alla seconda settimana: si silenzia, si archivia o si ignora, e il giorno in cui arriva l'avviso che contava è in mezzo ad altri trentanove. La fatica da alert non è un problema delle persone; è un problema di progettazione.
La regola che tiene in produzione sta in una riga: allerta solo ciò che farà mollare a qualcuno quello che sta facendo. Tutto il resto non sparisce, va su un pannello che si guarda una volta al giorno col caffè.
- Allerta una persona: il flusso critico è fallito davvero; il flusso critico è senza esecuzioni da più tempo del normale; la coda di eccezioni cresce due giorni di fila; la spesa del giorno esce dal suo intervallo.
- Al pannello giornaliero: errori puntuali risolti al primo ritentativo, casi scalati a revisione umana, esecuzioni più lente del solito, avvisi di limite di piano che ancora non stringono.
- Né all'uno né all'altro: tutto ciò che nessuno guarderà mai. Se un avviso non ha un responsabile e un'azione possibile, non è un alert: è un log. Lascialo nei log.
Comincia corto. Due alert per flusso critico —è fallito, e ha smesso di girare— e aggiungi un terzo solo quando un incidente reale dimostra che mancava. Gli alert si guadagnano il posto; non si distribuiscono per sicurezza.
Il battito: come scoprire il flusso che ha smesso di girare
Questo è il pezzo che quasi nessuno ha ed è quello che salva più volte. Un battito è un alert che suona quando NON succede qualcosa. Il flusso manda un segnale ogni volta che finisce bene; un servizio esterno lo aspetta; se non arriva entro la finestra prevista, avvisa.
Due dettagli decidono se funziona. Il primo: il battito deve vivere fuori dallo strumento che stai sorvegliando. Se il guardiano e il sorvegliato sono lo stesso sistema, il giorno in cui il sistema cade non ti avvisa nessuno —ed è proprio il giorno in cui ti serve—. Il secondo: la finestra si calibra sul ritmo reale del flusso, non su quello ideale. Un flusso che gira ogni quindici minuti può permettersi un'ora di margine; uno giornaliero non dovrebbe avvisare per essere arrivato venti minuti tardi. Finestre mal calibrate producono falsi allarmi, e i falsi allarmi producono alert silenziati.
Conferma di chiusura: che l'ultimo passo dimostri che il lavoro è arrivato
Il battito ti dice che il flusso è girato. Non ti dice che ha fatto qualcosa di utile. Per quello c'è la conferma di chiusura: l'ultimo passo di ogni flusso critico non è l'azione, è la verifica dell'azione.
- Conta cosa è entrato e cosa è uscito. Se sono entrati quattordici record e ne sono stati creati zero, non è un giorno tranquillo: è un guasto. Un flusso che elabora zero elementi per più giorni di fila merita uno sguardo, non un visto buono.
- Verifica nella destinazione, non nella risposta. Che l'API abbia detto di sì non prova che il record esista. Una lettura di ritorno —chiedere al sistema di destinazione il record appena creato— trasforma una supposizione in un fatto.
- Riconcilia con cadenza. Una volta al giorno, confronta l'origine con la destinazione e cerca ciò che manca. È l'unica cosa che scopre l'evento mai arrivato, perché un webhook perso non genera nessun errore: genera un'assenza.
- Lascia la traccia. Ogni esecuzione con il suo identificativo, cosa è entrato, cosa è uscito e con quale versione. Senza questo non puoi ricostruire un caso specifico quando qualcuno te lo chiede tre settimane dopo; qui entra la governance e controllo dell'automazione con IA.
Cosa succede quando scatta: gravità, responsabile e la regola del tre
Un alert senza destinatario è una notifica. Prima di accendere qualsiasi cosa, scrivi tre cose per ogni flusso critico: chi risponde (una persona, non un reparto), cosa si fa nel frattempo che si sistema (il piano manuale: continuare a fatturare a mano non è un fallimento, è il piano) e cosa giustifica chiamare qualcuno fuori orario. Quasi niente lo giustifica; conviene deciderlo a mente fredda, non alle 23:40.
E una regola che risparmia molti incidenti futuri: se lo stesso guasto scatta tre volte, smette di aggiustarsi e passa a essere riprogettato. Un errore che si ripete non è sfortuna, è una supposizione sbagliata nel progetto del flusso —un caso non contemplato, un'API meno affidabile di quanto si credeva, un formato che cambia più di quanto si era assunto—. Rattoppare la terza volta garantisce solo che ce ne sarà una quarta.
Niente di tutto questo è costoso. Un battito esterno, una conferma di chiusura e due alert scelti bene si montano in un pomeriggio per flusso, e sono la differenza tra scoprirlo tu o scoprirlo da un cliente. Quello che costa è sostenerlo quando hai venti flussi vivi e nessuno il cui lavoro sia guardarli: a quel punto non è più montare automazioni, è gestirle —ed è esattamente ciò che facciamo in automazione delle operazioni—. Se stai ancora decidendo cosa automatizzare e con cosa, torna alla guida per automatizzare con l'IA; se l'hai già montato, comincia dal flusso che farebbe più danno fallendo in silenzio.