Ogni sera un task programmato (un'automazione che parte da sola, senza che io la avvii) scandaglia i miei progetti e scrive un report: cosa ha funzionato, cosa si è fermato, cosa aspetta una decisione da troppi giorni. È il sistema che dovrebbe avvisarmi quando qualcos'altro si rompe in silenzio. Quest'estate ho scoperto che si era rotto lui.
Questi report li numero in sequenza: v93, v94, v95. Un giorno è uscito il v96. Il successivo, prodotto cinque giorni dopo, porta il numero v97.
Un numero soltanto più alto, per cinque giorni di distanza. Con una cadenza giornaliera quel report avrebbe dovuto essere il v101. Mancano quattro numeri: le versioni dei quattro giorni in mezzo non sono mai state scritte. Nessun errore registrato da nessuna parte, nessuna riga nel diario giornaliero che tengo in automatico, nessun avviso. Per quattro giorni di fila il task non ha prodotto niente, e niente l'ha segnalato.
Non l'ho scoperto perché qualcosa mi ha avvisato. L'ho scoperto contando. Se non numerassi questi report in sequenza, il buco sarebbe ancora lì, invisibile, e l'ultimo report arrivato sembrerebbe perfettamente normale.
Questo sistema esiste con uno scopo preciso: cogliere in fallo le altre automazioni quando si fermano senza dirlo. Un flusso di lavoro (workflow, nel gergo dell'automazione) che smette di girare senza generare un errore è il rischio più difficile da vedere, perché dal di fuori tutto sembra tranquillo. Il report di fine giornata è la mia contromisura.
Quello che non avevo previsto è che la contromisura potesse avere lo stesso identico problema che è nata per risolvere. Nessuno controllava se il controllore era vivo. L'unico motivo per cui me ne sono accorto è un effetto collaterale, la numerazione progressiva, non un controllo pensato apposta.
Quasi duemila anni fa Giovenale lo scriveva a proposito di un marito geloso che voleva far sorvegliare la moglie: chi sorveglia le guardie? ("Quis custodiet ipsos custodes?", Satire, libro III, satira VI, versi 347-348). Il problema non è cambiato: qualunque livello di controllo aggiungi, quel livello stesso può smettere di funzionare, e a quel punto serve un altro controllo, più semplice, dedicato solo a verificare che il primo sia ancora vivo.
Va detto con chiarezza: in quei giorni stavo chiudendo il salone per le ferie e partendo per un viaggio programmato da prima. Anche con un allarme in tempo reale non avrei agito diversamente. Ma la prossima volta che serve davvero, un buco così lungo non dovrebbe dipendere dal fatto che qualcuno, per caso, si mette a contare i numeri di versione.
Il report di fine giornata resta il pezzo complesso, quello che legge tutto e racconta tutto. Il controllo sulla sua vita doveva essere l'opposto: piccolo, stupido, separato. Qualche settimana dopo l'ho costruito, su due strati.
Il primo è un dispositivo a uomo morto, il meccanismo dei treni: se il macchinista smette di dare segni di vita, il sistema frena da solo. Ogni mattina il primo task della giornata manda un segno di vita a un server che sta fuori dal Mac dove girano i report. Due volte al giorno una guardia su quel server legge l'ultimo battito e, se il silenzio supera le ventisei ore, mi scrive su Telegram. Non c'è più niente da contare: è il silenzio stesso a fare rumore. L'ho collaudato invecchiando un battito a mano, per vedere l'allarme partire davvero.
Il secondo strato risponde alla domanda di Giovenale applicata alla guardia stessa: la sonda che ogni cinque minuti chiede allo stesso Mac se risponde manda, a ogni giro, un segnale a un servizio esterno che sta fuori perfino da n8n, la piattaforma dove girano le mie automazioni. Se i segnali smettono di arrivare, quel servizio manda una mail. Per assenza, non per errore: nessun livello si controlla da solo.
Un limite lo dichiaro: questi allarmi dicono "il sistema non ha lavorato", non "il task X è fallito". La seconda domanda ha ancora bisogno dei miei occhi. Ma un buco come quello oggi farebbe rumore entro ventiquattro ore, non dopo quattro giorni di conteggi fatti per caso.
Parti da qui: qualunque report automatico usi per sapere se il tuo business sta bene, in un foglio, in una dashboard, in una mail che ti aspetti ogni mattina, chiediti oggi stesso una cosa sola. Se domani smettesse di arrivare, te ne accorgeresti prima di sera, o lo scopriresti fra una settimana per caso?
Vuoi il prossimo articolo? Iscriviti alla newsletter — un articolo a settimana.
AI e automazione per chi non programma. Ogni lunedì un articolo dai miei sistemi reali: cosa ho costruito, i numeri veri, gli errori compresi.
Il 6 maggio ho promesso questo articolo con una data stampata: 15 luglio. Scrivevo: quando i funnel WhatsApp del salone avranno sessanta giorni di dati alle spalle, esco con tutto. Messaggi inviati, tassi di conversione, ore risparmiate, errori fatti. Il 15 luglio non è uscito niente. Esce oggi, con ottantadue giorni di ritardo. In cambio posso offrirti una cosa sola: più dati di quelli promessi. Non sessanta giorni di salone automatizzato: ottantasei, senza contare le cinque settimane...
A metà agosto, nel file di stato di una delle mie automazioni, c'era una lista di quattro voci. Ognuna finiva con la stessa istruzione: non ri-segnalare. Due memorie, non una Il task programmato si chiama el-wa-reply-drafts e gira da solo tre volte al giorno. Legge le risposte WhatsApp arrivate ai contatti del salone, e per quelle azionabili prepara una bozza di risposta che io poi invio a mano. Il 17 agosto ha girato per la quarantottesima volta di fila. Per non rifare il lavoro già fatto...