Paleidome popierinės prekybos strategiją iš naujo sandorio viduryje ir gavome kitokią pavedimų seką nei prieš paleidimą iš naujo. Tie patys rinkos duomenys, ta pati strategijos versija, tas pats sąskaitos likutis. Signalo skaičiavimas sutapo. Strategijos atmintis apie poziciją ir laukiančius pavedimus – ne.
Neatitikimą tyrėme visą dieną atkurdami įvykių seką. Pamoka paprasta: programinei įrangai paleidimas iš naujo yra rinkos įvykis. Jei nepatikrinsite, kaip strategija atkuria savo būseną, tvarkingas atgalinis testas gali paslėpti popierinės prekybos sistemą, kuri pamiršta, ką turi.
09:10 — Pasirinkome nuobodžią poziciją
Bandomoji strategija prekiavo likvidžiu amžinuoju kontraktu: atidaryti ilgąją poziciją, kai trumpasis slankusis vidurkis kerta ilgesnįjį iš apačios į viršų, o uždaryti, kai įvyksta priešingas kirtimas. Atkūrimą pradėjome jau turėdami nedidelę atvirą poziciją ir biržoje laukiantį tik poziciją mažinantį limitinį pavedimą. Taip atkuriant reikėjo nustatyti du dalykus: ką turėjome ir kokį veiksmą jau buvome nurodę atlikti prekybos platformai.
Kontroliniu momentu sąskaitoje buvo 0.04 kontrakto. Buvo pateiktas 0.01 kontrakto pavedimas. Strategijos procesas abi reikšmes buvo išsaugojęs atmintyje, tačiau paleidimo procedūra gaudavo tik informaciją apie poziciją. Jis laikė, kad podėlyje buvęs pavedimas nebegalioja.
09:25 — Pasirodė pirmasis dubliuotas pavedimas
Po paleidimo iš naujo strategija aptiko esamą ilgąją poziciją, įvykdė signalo logiką ir pateikė dar vieną 0.01 kontrakto pozicijos mažinimo pavedimą. Dabar popierinės prekybos platformoje buvo du aktyvūs pavedimai. Atskirai nė vienas jų nebuvo klaidingas. Tačiau įvykdžius abu būtų parduotas dvigubai didesnis kiekis, nei ketinta.
Iš pradžių apkaltinome signalų ciklą. Kaltas buvo ne ciklas, o neišsamus būsenos momentinis vaizdas. Strategija klausė: „Kokią poziciją turiu?“, bet niekada neklausė: „Kurie pavedimai vis dar galioja?“
| Būsena po paleidimo iš naujo | Ką manė procesas | Kas buvo sąskaitoje |
|---|---|---|
| Pozicija | Ilgoji 0.04 | Ilgoji 0.04 |
| Atviri pozicijos mažinimo pavedimai | Nėra | Du po 0.01 |
| Numatyta pozicija įvykdžius vieną pavedimą | Ilgoji 0.03 | Gali sumažėti iki 0.02 |
10:00 — Sutvarkėme atkūrimą, tada aptikome laiko problemą
Pakeitėme paleidimo procedūrą, kad prieš leidžiant priimti naujus sprendimus būsena būtų atkurta iš sąskaitos pozicijų ir atvirų pavedimų. Dubliuotas pavedimas dingo. Tada apsunkinome atsijungimo scenarijų: vienas pavedimas buvo įvykdytas, kol strategija neveikė, o pranešimas apie įvykdymą atėjo jai vėl prisijungus.
Sąskaitos momentinis vaizdas jau rodė įvykdytą pavedimą. Pavėluotas pranešimas dar kartą sumažino vietinę poziciją. Kelias sekundes strategija manė turinti 0.02 kontrakto, nors sąskaitoje buvo 0.03. Kitas pozicijos balansavimas rėmėsi neegzistuojančiu trūkumu.
Įtraukėme būsenos suderinimo taisykles: pradine būsena laikyti sąskaitos momentinį vaizdą, pagal įvykių identifikatorius ignoruoti jame jau užfiksuotus įvykdymus ir nepateikti pavedimų, kol nebus baigtas pradinis sinchronizavimas. Pranešimas gali vėluoti arba būti gautas du kartus. Atkūrimas turi atlaikyti abu atvejus.
13:40 — Atkuriant įvykių seką išryškėjo nepastebimas neatitikimas
Tą pačią kainų eigą atkūrėme ir pradiniame, ir iš naujo paleistos strategijos vykdyme. Palyginę galutinį P&L problemos nebūtume pastebėję: rinkai apsisukus abi versijos baigė su ta pačia pozicija. Neatitikimą atskleidė pavedimų įvykių palyginimas.
Kiekvieną sprendimą užregistravome kartu su tuo metu nuskaityta būsena: pozicija, atviri pavedimai, paskutinio apdoroto įvykdymo identifikatorius, signalo reikšmė ir strategijos versija. Tuomet paaiškėjo pirmojo nukrypusio įvykio priežastis. Vienas vykdymas matė galiojantį pavedimą, kitas – tuščią sąrašą. Vėliau viename įvykdymas buvo pritaikytas dukart.
Vienodas galutinis sąskaitos likutis neįrodo, kad elgsena sutapo. Palyginkite sprendimų ir pavedimų sekas, ypač atkūrimo momentais.
16:20 — Ką kitą kartą darytume kitaip
Per ilgai atkūrėme kainų duomenis, prieš patikrindami sąskaitos būsenos pokyčius. Kitą kartą pirmiausia įterptume gedimų atvejus, o rinkos kainų eigą paliktume beveik nekintančią. Taip programinės įrangos klaidą lengva pastebėti ir diagnozės neužtemdo staigus kainų svyravimas.
- Paleisti iš naujo esant atvirai pozicijai ir iš dalies įvykdytam pavedimui.
- Atsijungti pateikus pavedimą, tada vėl prisijungti dar negavus pranešimo apie jo įvykdymą.
- Du kartus pateikti tą patį įvykdymo įvykį ir patikrinti, kad būsena pasikeistų tik vieną kartą.
- Blokuoti naujus pavedimus, kol nebus suderintos ir pozicijos, ir atviri pavedimai.
- Palyginti sprendimų ir pavedimų žurnalus nepertraukiamo ir iš naujo paleisto vykdymo atvejais.
Taip pat išmokome kartu su strategijos versija ir įvykių žurnalu išsaugoti atkūrimo momentinį vaizdą. Taip gedimą pavyko atkurti per kelias minutes, užuot pasikliovus kieno nors atmintimi apie tikslią pakartotinio prisijungimo seką.
Popierinės prekybos strategija, kuri veikia teisingai tik tol, kol jos procesas nenutrūksta, dar neišlaikė visos repeticijos. Paleiskite ją iš naujo pozicijos viduryje, pavėluokite įvykdymo pranešimus ir patikrinkite kiekvieną po to pateikiamą pavedimą. Tikslas – ne įrodyti, kad ji niekada nesuges. Tikslas – pamatyti, kaip ji atsigauna, kol popierinės prekybos sąskaita tos pačios pamokos neišmoko jūsų netikėtai.
← Visi įrašai
