Recuperare i dati persi di un'automazione: come rilavorare ciò che è caduto senza duplicare niente

Cosa si perde davvero quando un'automazione si rompe (e perché non è «niente»)

La prima domanda dopo un blocco è quasi sempre «adesso funziona?». La seconda, quella che non fa quasi nessuno, è «e cosa ne è stato di quello che è arrivato mentre non funzionava?». La risposta dipende da una cosa decisa il giorno in cui è stato costruito il flusso: se ciò che entra ha una fonte interrogabile o se è esistito solo come un evento di passaggio.

I due casi si comportano in modo opposto. Se il tuo flusso legge da un posto che conserva —gli ordini del negozio, i ticket del CRM, le mail di una casella—, non hai perso niente: il dato è ancora lì, in attesa che qualcuno lo elabori. Se il tuo flusso dipende dal fatto che qualcuno ti spinga il dato —un webhook, una notifica— e chi lo invia non ritenta né conserva storico, quell'evento è evaporato. Nessuna traccia, nessun errore, nessuna schermata dove cercarlo.

• Ciò che è interrogabile si recupera. Ordini, record, documenti: tutto quello che resta nell'origine si può richiedere di nuovo per intervallo di date e rielaborare.
• Ciò che viene spinto dipende da chi lo invia. Stripe, GitHub o Shopify ritentano i loro webhook per ore o giorni; uno script interno o un'integrazione fatta in casa quasi mai. Prima di fidarti di un webhook, verifica se chi lo invia ritenta e per quanto tempo.
• Quello che è stato elaborato a metà è il caso peggiore. Un flusso che ha creato il record ma è caduto prima di segnarlo come inviato lascia il sistema in uno stato che non è né fatto né in attesa. È quello che produce duplicati quando rielabori.
• Quello che è stato elaborato male in silenzio non è una perdita, è una corruzione. Non lo risolve questo piano; lo intercetta la sorveglianza di cui parla rilevare i guasti nelle automazioni.

Questa distinzione non è teorica: decide cosa puoi promettere. Quando qualcuno chiede «abbiamo perso qualcosa?», la risposta onesta è «di quello che entra dal negozio no; di quello che entra dal webhook del fornitore X, dipende se ritenta». E se non l'hai mai verificato, quello è il primo compito, prima di qualsiasi rielaborazione.

Prima l'idempotenza: la riparazione che duplica le fatture

Il giorno del guasto c'è una tentazione fortissima: prendere il lotto delle ore brutte e ripassarlo tutto intero. È rapido, dà la sensazione di risolvere ed è il modo più comune di trasformare un incidente piccolo in uno caro. Perché una parte di quel lotto è stata elaborata davvero —i primi minuti, quello che è entrato nelle finestre in cui il servizio rispondeva— e quel pezzo verrà eseguito una seconda volta.

Il pezzo che lo impedisce si chiama idempotenza e significa esattamente questo: eseguire due volte la stessa operazione lascia lo stesso risultato di eseguirla una volta sola. Non è un'impostazione da attivare; è una proprietà da progettare, e sta in piedi su due decisioni concrete.

• Una chiave stabile per unità di lavoro. Il numero d'ordine, l'id del messaggio, l'hash del documento. Mai il timestamp, mai un contatore dell'esecuzione, mai «il record più recente»: cambiano da un tentativo all'altro e rompono il confronto.
• Un passo di scrittura che controlla prima di creare. Cercare con quella chiave e, se esiste, aggiornare o uscire senza fare nulla. Molte API lo risolvono già con un header di idempotency key o con un «crea o aggiorna» nativo; quando non c'è, si costruisce a mano con una tabella propria di chiavi già elaborate.

Regola pratica che evita discussioni: se un flusso non è idempotente, non ha un piano di ripristino, ha un piano di rischio. E l'ordine conta —renderlo idempotente viene prima di rielaborare qualunque cosa, anche con il capo che guarda l'orologio—. Rielaborare un flusso non idempotente per guadagnare venti minuti e generare quaranta fatture duplicate è un pessimo affare che per giunta va spiegato.

Ritentativi con attesa crescente: cosa si ritenta e cosa non va ritentato mai

La maggior parte dei guasti non ha bisogno che nessuno li recuperi: si sistemano da soli se il sistema aspetta un po' e riprova. Un timeout, un limite di richieste, un 503 di un fornitore che sta rilasciando. La condizione è che il ritentativo sia fatto bene, e «fatto bene» ha una forma precisa.

Attesa crescente: non ritentare ogni secondo, ma distanziare i tentativi sempre di più —qualche secondo, poi il doppio, poi ancora il doppio—, con un piccolo scarto casuale perché mille esecuzioni fallite insieme non tornino tutte insieme. Ritentare in loop immediato contro un fornitore giù non lo aiuta a rialzarsi: lo tiene a terra, e intanto ti brucia la quota.

E una distinzione che separa i ritentativi utili da quelli dannosi: si ritenta quello che è fallito per l'ambiente, non quello che è fallito per il dato. Un 500 o un timeout sono candidati legittimi. Un 400 perché manca un campo obbligatorio, un 401 per credenziale scaduta o un 422 perché l'importo è negativo non migliorano ripetendosi: quelli vanno dritti nella coda dei falliti, perché ogni ritentativo è solo rumore e costo. Un flusso che ritenta cinque volte un errore di validazione spende cinque volte e impara zero.

Quanti tentativi: fra tre e cinque coprono praticamente tutto ciò che è transitorio. Da lì in poi la causa non è più un singhiozzo dell'ambiente, e insistere ritarda soltanto il momento in cui una persona se ne accorge. Quel momento —il passaggio dal ritentare all'arrendersi— è ciò che dà senso al pezzo successivo.

La coda dei falliti: dove finisce quello che non è passato e come si rilancia

Quando i ritentativi si esauriscono, il lavoro deve atterrare da qualche parte. Se quel posto non esiste, atterra nel log —cioè da nessuna parte—. La coda dei falliti è quel posto: una tabella, un foglio, un canale, quello che vuoi, purché conservi tre cose per ogni fallimento.

• Il dato originale integro, non un riassunto né il messaggio di errore. Senza il payload completo non puoi rilanciare: puoi solo indagare.
• Il motivo del fallimento e il momento, per poter raggruppare. Duecento fallimenti con lo stesso motivo sono un problema; duecento con motivi diversi sono duecento problemi.
• Lo stato: in attesa, rilanciato, risolto o scartato con una motivazione. Senza stato, la coda diventa un cimitero che nessuno osa svuotare.

Quello che cambia quando ce l'hai è la conversazione. Si passa da «abbiamo perso quelli di ieri» a «ce ne sono 214 in coda: 190 falliti per il fornitore giù e si rilanciano così come sono, 24 falliti per validazione e vanno guardati». Questo è un incidente gestibile. E aggiunge un segnale di salute che nessun alert dà altrettanto bene: una coda che cresce avvisa di un problema sistemico prima che lo faccia un cliente.

Il rilancio si fa a lotti piccoli e in ordine, mai tutto insieme. Prima una manciata, si controlla il risultato a destinazione, e solo allora il resto. Se il primo lotto fallisce uguale, la causa non era risolta e ti sei appena risparmiato di ripetere l'errore duecento volte. Tutto questo dà per scontato il punto precedente: senza idempotenza, rilanciare una coda è una scommessa.

Riconciliazione: come trovi quello che non è mai entrato

Ritentativi e coda coprono quello che è fallito. Resta il buco vero: quello che non è mai stato nemmeno tentato. Il webhook perso, il trigger disattivato, il record che il filtro ha scartato per un campo vuoto. Lì non c'è errore, non c'è fallimento in coda e non c'è niente da ritentare. Non c'è nemmeno traccia che sarebbe dovuto succedere qualcosa.

L'unico modo di trovarlo è smettere di guardare l'automazione e confrontare i due estremi. Riconciliare è questo: chiedere all'origine tutto ciò che è cambiato in una finestra di tempo, chiedere alla destinazione ciò che è stato creato nella stessa finestra, incrociare per la chiave stabile e tenersi la differenza. Quello che sta nell'origine e non nella destinazione è esattamente ciò che si è perso.

Tre dettagli decidono se la riconciliazione serve o produce falsi positivi: usa la stessa chiave stabile dell'idempotenza (se confronti per nome cliente o per importo, troverai differenze che non esistono); lascia un margine di tempo di qualche minuto ai bordi della finestra, perché il dato di origine e quello di destinazione non si scrivono nello stesso istante; e decidi cosa fare con la differenza: la scelta prudente è mandarla nella coda dei falliti per rilanciarla dalla strada normale, non scriverla direttamente per una via parallela che salta le validazioni del flusso.

La cadenza dipende dal danno, non dal volume. Giornaliera e automatica su ciò che muove soldi o impegni con il cliente; settimanale sull'interno a basso impatto. E soprattutto permanente, non solo dopo uno spavento: la riconciliazione vale proprio perché trova l'ordine perso un martedì qualunque senza che sia caduto niente, quello che oggi si scopre quando il cliente scrive per chiedere. È la stessa disciplina di cura continua che regge la manutenzione delle automazioni con IA.

Il piano di ripristino: chi lo esegue, in che ordine e con quale verifica finale

I quattro pezzi precedenti sono capacità. Ciò che li trasforma in ripristino è un piano scritto in anticipo, corto, che qualcuno possa eseguire nel giorno brutto senza improvvisare e senza dipendere dalla disponibilità di chi ha costruito il flusso. Sta in mezza pagina e ha sei passi.

• 1. Fermare l'ingresso. Prima di recuperare, chiudi il rubinetto: se il flusso continua a ingoiare mentre rielabori, non saprai mai quale lotto è quale.
• 2. Fissare la finestra. Da quando a quando è andata male. Con margine da entrambi i lati; meglio che avanzi piuttosto che manchi.
• 3. Confermare l'idempotenza del flusso. Se non ce l'ha, si sistema qui. Questo passo non si salta per fretta.
• 4. Riconciliare la finestra. Confrontare origine e destinazione, e mandare la differenza nella coda dei falliti.
• 5. Rilanciare a lotti piccoli, controllando la destinazione dopo il primo prima di proseguire con il resto.
• 6. Chiudere con una verifica di risultato, non di esecuzione: contare i record a destinazione e quadrarli con l'origine. Che la rielaborazione «sia finita senza errori» non dimostra niente.

E una cosa che non è tecnica ma decide il risultato: il piano ha bisogno di un proprietario con nome e cognome, non di un reparto. La stessa regola che governa tutto il resto in governance e controllo dell'automazione: senza un nome non c'è controllo, c'è solo un documento. Se devi montare l'insieme da zero, la mappa completa sta nella guida ad automatizzare con l'IA.

La conclusione scomoda è che il ripristino non si improvvisa: si installa. Ritentativi, idempotenza, coda e riconciliazione si costruiscono quando va tutto bene, perché il giorno in cui servono non c'è più tempo per costruirli. Se i tuoi flussi critici oggi non ce li hanno, è esattamente questo che facciamo quando mettiamo un processo in produzione in automazione delle operazioni: non solo che funzioni, ma che sappia recuperare quando non funziona.