Mi hai detto che il tuo processo di paper trading si è arrestato durante la notte. Lo hai riavviato prima della decisione successiva, non hai visto errori e hai dato per scontato che avesse ripreso da dove si era fermato. Poi ha inviato un ordine di acquisto per un asset che possedevi già. Vuoi sapere se c’è un bug nella strategia.
È possibile. Ma prima verifica che il processo riavviato conosca le stesse informazioni del conto paper. Un riavvio è un problema di ripristino dello stato: posizioni, liquidità, ordini aperti e ogni informazione che la strategia conserva e che influisce sulla decisione successiva devono essere coerenti. Rimettere in esecuzione il codice è la parte facile.
Che cosa riteneva la strategia prima dell’arresto?
Annota l’ultima decisione presa dal processo prima di fermarsi. Per ogni strumento negoziato, registra la posizione prevista, quella effettiva sul conto, gli ordini in sospeso e lo stato del segnale che influirà sull’azione successiva. Se non hai queste informazioni, non puoi sapere se il riavvio ha ripristinato lo stato o si è limitato a inizializzare una strategia nuova.
Immagina che la tua strategia oraria acquisti 1 unità quando il segnale di trend diventa positivo, per poi mantenerla finché il segnale non diventa negativo. Il processo invia l’ordine di acquisto alle 14:00, ma si arresta prima di registrare che l’ordine è stato accettato. La piattaforma paper lo esegue. Al riavvio, la strategia non trova alcuna posizione registrata e il segnale è ancora positivo, quindi invia un altro ordine di acquisto. Il segnale si sta comportando in modo coerente. È la sua memoria di ciò che il conto possiede a essere obsoleta.
Ecco perché la posizione attuale del conto va riconciliata con lo stato persistito della strategia prima di consentire nuovi ordini. Una copia locale dello stato può essere utile, ma il conto o la piattaforma sono la fonte autorevole su ciò che è stato effettivamente eseguito.
Quale stato deve sopravvivere a un riavvio?
Parti dallo stato che può modificare l’ordine successivo. Conserva un registro persistente, con timestamp e versione per ogni aggiornamento; prima di modificare la logica di ripristino, fanne una copia così da poter riprodurre in seguito il problema.
| Stato | Perché è importante | Verifica del ripristino |
|---|---|---|
| Posizioni e liquidità | Determinano l’esposizione e il potere d’acquisto disponibile | Confronta i valori persistiti con quelli del conto paper |
| Ordini aperti | Un ordine potrebbe essere stato eseguito mentre il processo era fermo | Interroga lo stato degli ordini e riconcilia le esecuzioni parziali |
| Memoria dei segnali | Incroci, periodi di attesa e durate di mantenimento possono estendersi su più decisioni | Ripristina gli ultimi input della decisione registrata |
| Ultimo evento elaborato | Determina da dove la strategia riprende a leggere i dati | Riproduci gli eventi successivi senza applicarli due volte |
È facile trascurare la memoria dei segnali. Una strategia che opera su un incrocio può conservare il valore dell’indicatore del giorno precedente per rilevare un nuovo incrocio. Se parte senza alcun valore, può scambiare una condizione già presente per un nuovo evento. Lo stesso vale per un timer di attesa: il riavvio non deve azzerare di nascosto una regola che dovrebbe rimanere attiva.
Come rendere ripetibile il ripristino?
Assegna a ogni ordine un ID cliente stabile, ricavato dall’esecuzione della strategia e dalla decisione che lo ha generato. Se il processo riprova dopo un timeout, può verificare se quella decisione ha già creato un ordine, invece di inviarne uno duplicato. Registra le modifiche di stato solo dopo aver confermato il corrispondente evento sul conto e conserva gli ID degli ordini e delle esecuzioni che spiegano la modifica.
Poi verifica la condizione che ha causato l’incidente. Fai eseguire alla strategia una decisione, salva lo stato, arrestala e ripristinala usando le posizioni e lo storico ordini del conto paper. Confronta la decisione successiva e gli ordini risultanti con quelli di un’esecuzione senza interruzioni. Ripeti la prova con un ordine eseguito parzialmente e con un arresto tra l’invio e la conferma. L’esecuzione ripresa non deve inventare una nuova posizione né ripetere un’azione già completata.
Tieni un registro del ripristino: ultimo evento elaborato, ora dello snapshot del conto, stati degli ordini aperti, versione della strategia ripristinata e prima decisione dopo il riavvio. Così “si è riavviato” diventa qualcosa che puoi verificare.
Di cosa puoi fidarti dopo il riavvio?
Puoi fidarti del processo solo quando lo stato del conto e quello della strategia sono riconciliati, gli ordini in sospeso hanno uno stato noto e la decisione successiva coincide con quella che ti aspetteresti da un’esecuzione continua. Se non sai spiegare una discrepanza, sospendi l’invio di ordini paper ed esamina la sequenza degli eventi. Un processo in esecuzione non dimostra che la strategia abbia recuperato il proprio stato.
Hai già ricavato qualcosa di utile dall’arresto: ha fatto emergere un’ipotesi con cui la normale esecuzione non ti aveva mai costretto a confrontarti. Rendi il riavvio uno scenario ripetibile e saprai che cosa ricorda la strategia prima di chiederle di operare di nuovo.
← Tutti gli articoli
