Papirno strategijo smo znova zagnali sredi posla in dobili drugačno zaporedje naročil kot pred ponovnim zagonom. Isti tržni podatki, ista različica strategije, isto stanje na računu. Izračun signala se je ujemal. Strategija pa se ni več spominjala svoje pozicije in čakajočih naročil.
Neskladje smo raziskovali ves dan s predvajanjem dogodkov. Koristen nauk je bil preprost: ponovni zagon je za vašo programsko opremo tržni dogodek. Če ne preverite, kako strategija znova vzpostavi svoje stanje, lahko čist rezultat testiranja za nazaj prikrije papirni sistem, ki pozabi, kaj ima v lasti.
09:10 — Izbrali smo dolgočasno pozicijo
Preskusna strategija je trgovala z likvidno trajno pogodbo: vstopila je v dolgo pozicijo, ko je kratko drseče povprečje prečkalo daljše navzgor, in izstopila ob nasprotnem prehodu. Predvajanje smo začeli z že odprto majhno pozicijo in čakajočim omejenim naročilom reduce-only za njeno zmanjšanje. Sistem je moral ob obnovitvi rekonstruirati 2 podatka: kaj imamo v lasti in kaj smo borzi že naročili.
Ob kontrolni točki je bilo na računu 0.04 pogodbe. Odprto je bilo naročilo za 0.01. Proces strategije je imel obe vrednosti predpomnjeni v pomnilniku, vendar je ob zagonu pridobil samo podatke o poziciji. Predpostavil je, da čakajočega naročila ni več.
09:25 — Pojavilo se je prvo podvojeno naročilo
Po ponovnem zagonu je strategija zaznala obstoječo dolgo pozicijo, izvedla signalno logiko in oddala še eno naročilo za zmanjšanje za 0.01. Na papirni borzi sta bila zdaj aktivna 2 naročili. Vsako zase je bilo ustrezno. Skupaj pa bi lahko prodali dvakrat več od načrtovane količine, če bi se obe izvršili.
Sprva smo krivili zanko signalov. Težava ni bila v zanki, temveč v nepopolnem posnetku stanja. Strategija je vprašala: »Kakšno pozicijo imam?« Nikoli pa ni vprašala: »Katera naročila so še aktivna?«
| Stanje po ponovnem zagonu | Kaj je menil proces | Kaj je bilo na računu |
|---|---|---|
| Pozicija | Dolga 0.04 | Dolga 0.04 |
| Odprta naročila za zmanjšanje | Nobenega | 2, vsako za 0.01 |
| Načrtovana izpostavljenost po 1 izvršitvi | Dolga 0.03 | Lahko bi postala dolga 0.02 |
10:00 — Odpravili smo težavo pri obnovitvi, nato našli težavo s časovno uskladitvijo
Ob zagonu smo spremenili postopek tako, da pred omogočanjem novih odločitev znova vzpostavi stanje na podlagi pozicij in odprtih naročil na računu. Podvojeno naročilo je izginilo. Nato smo prekinitev povezave naredili manj urejeno: eno naročilo se je izvršilo, ko strategija ni delovala, obvestilo o izvršitvi pa je prispelo šele po ponovni vzpostavitvi povezave.
Posnetek računa je izvršitev že upošteval. Zaradi zakasnelega obvestila se je lokalna pozicija nato zmanjšala še enkrat. Nekaj sekund je strategija verjela, da ima 0.02 pogodbe, čeprav jih je bilo na računu 0.03. Njeno naslednje prilagajanje pozicije je temeljilo na namišljenem primanjkljaju.
Dodali smo pravila za usklajevanje: posnetek računa uporabimo kot izhodišče, z identifikatorji dogodkov prezremo izvršitve, ki so v njem že upoštevane, naročil pa ne oddajamo, dokler se začetna sinhronizacija ne konča. Obvestilo lahko prispe z zamudo ali dvakrat. Postopek obnovitve mora prenesti oboje.
13:40 — Predvajanje je razkrilo tiho neskladje
Isto gibanje cen smo predvajali pri prvotnem zagonu in zagonu po ponovnem zagonu. Če bi primerjali samo končni P&L, bi težavo spregledali: po obratu trga sta se oba zagona končala z isto pozicijo. Razkrila se je šele pri primerjavi dogodkov naročil.
Vsako odločitev smo zabeležili skupaj s stanjem, ki ga je strategija prebrala: pozicijo, odprta naročila, zadnji obdelani identifikator izvršitve, vrednost signala in različico strategije. Prvi razhajajoči se dogodek je tako dobil pojasnilo. En zagon je zaznal aktivno naročilo, drugi pa prazen seznam. Pozneje je eden izvršitev upošteval dvakrat.
Ujemanje končnega stanja na računu ne dokazuje, da se je strategija obnašala enako. Primerjajte zaporedje odločitev in naročil, zlasti ob ponovni vzpostavitvi stanja.
16:20 — Kaj bi naslednjič naredili drugače
Preveč časa smo porabili za ponovno predvajanje cenovnih podatkov, preden smo preverili prehode stanja na računu. Naslednjič bi najprej vnesli primere napak in ohranili gibanje trga skoraj nespremenjeno. Tako bi programsko napako lažje opazili, ne da bi diagnozo zameglilo nestanovitno gibanje cen.
- Znova zaženite strategijo, ko ima odprto pozicijo in delno izvršeno naročilo.
- Po oddaji naročila prekinite povezavo, nato jo znova vzpostavite, še preden prispe obvestilo o izvršitvi.
- Isti dogodek izvršitve pošljite dvakrat in preverite, ali spremeni stanje samo enkrat.
- Blokirajte nova naročila, dokler niso usklajene tako pozicije kot odprta naročila.
- Primerjajte dnevnike odločitev in naročil pri neprekinjenem zagonu ter zagonu po ponovnem zagonu.
Naučili smo se tudi, da je treba shraniti posnetek za obnovitev skupaj z različico strategije in dnevnikom dogodkov. Tako smo lahko napako poustvarili v nekaj minutah, ne da bi se morali zanašati na to, da se nekdo spomni natančnega zaporedja ponovne vzpostavitve povezave.
Papirna strategija, ki deluje pravilno samo, dokler njen proces teče, še ni opravila celovite vaje. Znova jo zaženite sredi pozicije, poskrbite, da bodo izvršitve prispele z zamudo, in preglejte vsako naročilo, ki ga nato odda. Namen ni dokazati, da nikoli ne odpove. Pomembno je, da je njena obnovitev vidna, še preden vas papirni račun na enak nauk opozori nepričakovano.
← Vse objave
