Cosa separa un prototipo in Make da un sistema in produzione
Lo scenario funziona. Montato in un pomeriggio, provato con cinque record, tutti e cinque sono passati. Sembra finito, ed è esattamente lì che comincia il problema: un prototipo dimostra che il processo è possibile; un sistema in produzione dimostra che lo è ancora il martedì alle tre di notte, con un dato strano e l'API dall'altra parte a terra. In mezzo c'è del lavoro, e non è lavoro da trascinare moduli.
Quando un'automazione in Make non scala, quasi mai è la logica di business a cedere. Cedono quattro cose che il prototipo non aveva perché non gli servivano: un tetto di esecuzione che si vede solo col volume, un comportamento in caso di errore da decidere a mano, l'assenza totale di versioning e una fattura che cresce proprio quando fai le cose per bene.
| Dimensione | Prototipo che funziona | Sistema in produzione |
|---|---|---|
| Volume | Cinque record di prova | Il picco di fine mese, senza preavviso |
| Errori | Non ce n'è stato nessuno | Si dà per scontato che ci saranno e si decide che fine fa il dato |
| Proprietario | Chi l'ha montato, se se lo ricorda | Qualcuno reperibile, con allerta e procedura |
| Modifiche | Si edita a caldo | Si versiona, si prova a parte e si promuove |
| Costo | Ci sta comodo nel piano | Proiettato a dodici mesi con i passaggi irrobustiti |
Nessuna di queste cinque righe è un difetto di Make. Make è uno strumento eccellente per scoprire se un processo si può automatizzare, e quella fase conta. L'errore non è partire da lì: è restarci e chiamarla produzione.
Il tetto di tempo: 40 minuti e cosa succede quando lo tocchi
Make interrompe qualsiasi esecuzione che superi il tempo massimo. Sui piani a pagamento il tetto è di 40 minuti; su quello gratuito, 10. Quando lo tocchi non ricevi un avviso gentile: la corsa si ferma con un errore del tipo «MAXIMUM EXECUTION TIMEOUT [40 minutes] had elapsed», e quel che era a metà resta a metà.
Un prototipo non lo tocca mai. Elabora cinque righe e finisce in dodici secondi. Lo schema che fa saltare tutto è sempre lo stesso e sempre a sorpresa: un iteratore su una lista che cresce. Sincronizzi 200 ordini e va bene; sei mesi dopo sono 4.000 e lo scenario muore a metà strada, dopo aver bruciato le operazioni dei primi 2.700. Il processo non è cambiato. È cambiato il business, che era l'obiettivo.
La via d'uscita giusta non è quasi mai un piano superiore, perché il tetto di tempo non si compra: si riprogetta. Lo schema che funziona è spezzare il lavoro in due scenari — uno che raccoglie e mette in coda, uno che svuota la coda a piccoli lotti con una sua pianificazione — così che nessuna corsa si avvicini al limite. È più lavoro che trascinare un modulo in più, ed è la differenza tra un flusso che regge la crescita e uno che si spezza proprio quando gli affari vanno bene.
Cosa fa Make quando qualcosa si rompe (e cosa non fa al posto tuo)
Make porta una rete di sicurezza che in molti nemmeno attivano: le esecuzioni incomplete. Quando uno scenario esplode a metà, invece di perdere il dato la piattaforma conserva la corsa non finita così puoi riprenderla o ripararla. È una buona rete e va usata. Ha anche dei bordi, e i bordi sono la clausola in piccolo che decide se il tuo sistema perde informazione.
Quel magazzino non è infinito: c'è un limite per scenario non risolto — dell'ordine di 10 MB — e un tetto complessivo per team — dell'ordine di 500 MB — e quelle che risolvi vengono cancellate automaticamente dopo 30 giorni. La parte scomoda arriva quando il magazzino si riempie, perché allora il comportamento dipende da una casella che qualcuno ha spuntato mesi fa senza pensarci: se la perdita di dati è disattivata, Make disattiva lo scenario; se è attivata, Make continua a schedulare le corse e scarta l'esecuzione incompleta che non ci sta. Nessuna delle due è una buona opzione. Una ti ferma il business, l'altra te lo svuota in silenzio.
| Cosa si rompe | Cosa fa Make di default | Cosa devi decidere tu |
|---|---|---|
| 429 dall'API di destinazione (rate limit) | L'esecuzione muore; se le incomplete sono attive, il dato finisce lì | Quanti ritentativi, con quale attesa e cosa succede quando finiscono |
| 503 transitorio dall'altra parte | Uguale: si ferma dov'era | Se ritenti o se il record va in una coda di revisione umana |
| Dato inatteso (campo vuoto, formato strano) | Niente di speciale: salta il modulo che lo tocca | Validare in ingresso e mandare il caso strano a una persona |
| Magazzino delle incomplete pieno | Disattiva lo scenario, o scarta l'esecuzione, a seconda di una casella | Quale dei due mali preferisci — e come vieni a saperlo |
C'è un secondo errore classico, e te lo fai da solo: il ritentativo senza tetto. Un gestore di errori che ritenta all'infinito contro un'API che risponde 429 non ripara nulla; brucia operazioni a ritmo d'incendio e blocca lo scenario. Ogni ritentativo ha bisogno di tre cose — un numero massimo, un'attesa crescente tra i tentativi e una destinazione finale per il record quando si esauriscono — e quella destinazione finale di solito è una persona. Progettare quell'uscita senza trasformarla in un collo di bottiglia è esattamente il problema dell'umano nel ciclo.
Versioning: lo scenario che nessuno sa chi ha toccato
Make non porta un controllo di versione alla maniera di un repository di codice. La pratica diffusa, e quella che quasi tutti raccomandano, è clonare lo scenario prima di toccarlo e provare su dati di sviluppo. Funziona finché sei uno. Appena siete in tre, la cartella si riempie di copie chiamate «Ordini v2 FINAL (quello buono)» e nessuno sa quale sia vivo.
Il costo vero del non versionare non è il disordine, è che perdi la capacità di rispondere a tre domande il giorno in cui qualcosa si rompe: cosa è cambiato, chi l'ha cambiato e come si torna indietro. Senza quelle tre risposte ogni incidente diventa archeologia. E l'archeologia, in produzione, si paga in ore di gente cara mentre il processo è fermo.
- Un blueprint esportato per ogni modifica. Make permette di esportare lo scenario in JSON: mettilo nel repository aziendale. È il diff che la piattaforma non ti dà.
- Nomenclatura noiosa e rigida. Un nome per scenario, un suffisso per la copia di lavoro, zero aggettivi. «FINAL» non è uno stato.
- Un ambiente di test vero, con credenziali proprie e dati finti. Provare in produzione su un record reale è esattamente quello che sembra.
- Una persona che promuove. Chiunque può proporre una modifica; una sola la porta in produzione. Non è burocrazia: è sapere chi chiamare alle tre di notte.
- Un registro modifiche di due righe. Data, cosa è stato toccato, perché. Nessuno lo legge fino al giorno in cui serve, e quel giorno ripaga tutti gli altri.
Non è una fissazione da ingegnere: è la parte minima di governance e controllo dell'automazione senza la quale non si può dire che un processo sia in produzione. Un flusso che muove denaro o dati dei clienti e che chiunque può editare a caldo senza lasciare traccia non è un sistema: è un rischio con una bella interfaccia.
La fattura sale proprio quando fai le cose bene
Ecco la trappola che convince in silenzio molti a lasciare lo scenario fragile apposta. Make fattura a operazione: ogni modulo che elabora dati passa in cassa. E tutto quello che abbiamo appena descritto — validare l'ingresso, gestire gli errori, ritentare con attesa, registrare cosa è successo, avvisare un umano quando il caso è ambiguo — sono moduli. Irrobustire il flusso moltiplica il consumo dello stesso processo senza automatizzare un solo caso nuovo.
Il risultato è un incentivo perverso perfettamente misurabile: la piattaforma ti fa pagare di più perché hai reso il sistema più solido. Non è cattiveria di Make, è la conseguenza aritmetica del fatturare a passo, e capita a qualunque strumento con quel modello. Il confronto completo delle tre unità di fatturazione — passo, operazione ed esecuzione — sta in il prezzo degli strumenti di automazione, ed è la lettura che trasforma questa guida in una decisione con i numeri.
Conseguenza pratica: quando proietti il costo di portare il prototipo in produzione, non proiettare lo scenario di oggi. Proietta quello irrobustito, che avrà il triplo dei moduli, al volume che ti aspetti fra dodici mesi. Se quel conto viene male, il problema non è più di configurazione; è di strumento, e tocca la conversazione Make contro n8n.
Tre uscite: irrobustire, spezzare o spostare il motore
Non tutti gli scenari che si inceppano hanno bisogno della stessa cosa, e sbagliare diagnosi costa caro in entrambe le direzioni: migrare per gusto costa settimane, restare per inerzia costa fermi. Queste sono le tre uscite reali e il segnale che le distingue.
| La tua situazione | Cosa fare | Segnale che è il tuo caso |
|---|---|---|
| Lo scenario è corretto ma fragile | Irrobustirlo dov'è: validazione, gestione errori, allerte, log | Si rompe di rado, ma quando succede nessuno se ne accorge finché non chiede un cliente |
| Lo scenario soffoca per dimensione | Spezzarlo: uno che accoda, uno che consuma a lotti | Tocchi il tetto di tempo, o l'iteratore cresce ogni mese |
| Il modello di prezzo ti sta punendo | Spostare il motore su uno strumento che fattura a esecuzione | La fattura sale e non hai aggiunto un solo processo nuovo |
Tutte e tre esigono la stessa decisione preliminare, ed è organizzativa, non tecnologica: qualcuno deve essere proprietario del flusso. Un processo automatizzato senza proprietario si degrada da solo, perché le API cambiano, i formati si spostano e i casi strani aumentano col volume. Quella disciplina — chi guarda cosa, ogni quanto, con quali allerte — è ciò che descrive la manutenzione delle automazioni, ed è la differenza tra un sistema che invecchia bene e uno che un giorno ha semplicemente smesso di girare senza che nessuno se ne accorgesse.