Abbiamo riavviato una strategia paper a metà di un trade e abbiamo ottenuto una sequenza di ordini diversa da quella prodotta prima del riavvio. Stessi dati di mercato, stessa versione della strategia, stesso saldo del conto. Il calcolo del segnale coincideva. La memoria della strategia sulla posizione e sugli ordini in sospeso, invece, no.
Abbiamo ricostruito l'origine della discrepanza in una giornata di replay. La lezione utile è semplice: per il software, un riavvio è un evento di mercato. Se non verifichi come la strategia ricostruisce il proprio stato, un backtest pulito può nascondere un sistema paper che dimentica cosa possiede.
09:10 — Abbiamo scelto una posizione senza sorprese
La strategia di test operava su un perpetual liquido: entrava long quando una media mobile breve superava una più lunga e usciva al crossover inverso. Abbiamo avviato il replay con una piccola posizione già aperta e un ordine limit reduce-only in attesa per ridurla. Il ripristino doveva quindi ricostruire 2 informazioni: cosa possedevamo e cosa avevamo già chiesto alla piattaforma di fare.
Al checkpoint, il conto deteneva 0.04 contratti. L'ordine aperto era di 0.01. Il processo della strategia aveva memorizzato entrambi i valori in memoria, ma la procedura di avvio recuperava solo la posizione. Considerava scomparso l'ordine memorizzato.
09:25 — È comparso il primo ordine duplicato
Dopo il riavvio, la strategia ha rilevato il long già aperto, ha eseguito la logica del segnale e ha inviato un altro ordine di riduzione da 0.01. Ora sulla piattaforma paper c'erano 2 ordini attivi. Preso singolarmente, nessuno dei 2 era sbagliato. Insieme, se fossero stati eseguiti entrambi, avrebbero potuto vendere il doppio della quantità prevista.
All'inizio abbiamo dato la colpa al ciclo del segnale. Il problema, però, non era il ciclo: era lo snapshot incompleto. La strategia chiedeva: «Che posizione ho?» ma non chiedeva mai: «Quali ordini sono ancora attivi?»
| Stato dopo il riavvio | Cosa credeva il processo | Cosa deteneva il conto |
|---|---|---|
| Posizione | Long 0.04 | Long 0.04 |
| Ordini di riduzione aperti | Nessuno | 2 da 0.01 ciascuno |
| Esposizione prevista dopo un'esecuzione | Long 0.03 | Potenzialmente long 0.02 |
10:00 — Abbiamo corretto il ripristino, poi trovato un problema di tempistica
Abbiamo modificato l'avvio perché ricostruisse lo stato usando le posizioni del conto e gli ordini aperti prima di abilitare nuove decisioni. Così abbiamo eliminato il duplicato. Poi abbiamo reso la disconnessione meno lineare: un ordine è stato eseguito mentre la strategia era offline e la notifica dell'eseguito è arrivata dopo la riconnessione.
Lo snapshot del conto includeva già l'eseguito. La notifica in ritardo ha quindi ridotto una seconda volta la posizione locale. Per alcuni secondi, la strategia credeva di detenere 0.02 contratti mentre il conto ne deteneva 0.03. Il ribilanciamento successivo si è basato su una carenza inesistente.
Abbiamo aggiunto regole di riconciliazione: usare lo snapshot del conto come punto di partenza, ignorare tramite gli identificativi degli eventi gli eseguiti già inclusi nello snapshot e non inviare ordini finché la sincronizzazione iniziale non è terminata. Una notifica può arrivare in ritardo o due volte. Il ripristino deve gestire entrambi i casi.
13:40 — Il replay ha rilevato una discrepanza difficile da notare
Abbiamo riprodotto lo stesso percorso dei prezzi nell'esecuzione originale e in quella riavviata. Confrontare il P&L finale non sarebbe bastato: dopo l'inversione del mercato, entrambe le versioni erano arrivate alla stessa posizione. La discrepanza è emersa confrontando gli eventi degli ordini.
Abbiamo registrato ogni decisione insieme allo stato consultato: posizione, ordini aperti, ultimo identificativo di eseguito elaborato, valore del segnale e versione della strategia. A quel punto, il primo evento divergente aveva una spiegazione. Un'esecuzione vedeva un ordine attivo; l'altra vedeva un elenco vuoto. Più tardi, una delle due aveva applicato un eseguito 2 volte.
Un saldo finale uguale non dimostra che il comportamento sia stato uguale. Confronta la sequenza di decisioni e ordini, soprattutto intorno ai momenti di ripristino.
16:20 — Cosa faremmo diversamente la prossima volta
Avevamo passato troppo tempo a rieseguire i dati dei prezzi prima di controllare i cambiamenti di stato del conto. La prossima volta inietteremmo prima i casi di errore e manterremmo il percorso del mercato quasi piatto. Così l'errore software sarebbe facile da individuare, senza che un movimento volatile confonda la diagnosi.
- Riavvia con una posizione e un ordine eseguito solo in parte.
- Disconnetti dopo l'invio dell'ordine, poi riconnettiti prima che arrivi la notifica dell'eseguito.
- Invia 2 volte lo stesso evento di eseguito e verifica che modifichi lo stato una sola volta.
- Blocca i nuovi ordini finché non sono state riconciliate sia le posizioni sia gli ordini aperti.
- Confronta i log delle decisioni e degli ordini tra le esecuzioni senza interruzioni e quelle riavviate.
Abbiamo anche imparato a salvare uno snapshot di ripristino insieme alla versione della strategia e al log degli eventi. Così abbiamo potuto riprodurre l'errore in pochi minuti, senza affidarci alla memoria di qualcuno per ricostruire l'esatta sequenza di riconnessione.
Una strategia paper che si comporta correttamente solo finché il processo resta attivo non ha superato una prova completa. Riavviala mentre sei in posizione, fai arrivare gli eseguiti in ritardo e controlla ogni ordine che invia dopo il riavvio. L'obiettivo non è dimostrare che non fallirà mai. È rendere visibile il ripristino prima che il conto paper ti insegni la stessa lezione all'improvviso.
← Tutti gli articoli
