Sinabi mong nag-crash ang proseso mo para sa paper trading kagabi. Ni-restart mo ito bago ang susunod na desisyon, wala kang nakitang error, at inakalang nagpatuloy ito mula sa pinaghintuan. Pagkatapos, nagsumite ito ng buy para sa asset na pag-aari mo na. Gusto mong malaman kung may bug ang strategy.
Posible. Pero tingnan muna kung alam ng ni-restart na proseso ang mga bagay na alam ng paper account. Problema sa pagbawi ng state ang pag-restart: dapat magkatugma ang mga posisyon, cash, bukas na order, at anumang memorya ng strategy na nakaaapekto sa susunod na desisyon. Madaling bahagi lang ang muling pagpapagana sa code.
Ano ang paniniwala ng strategy bago ito nag-crash?
Isulat ang huling desisyong ginawa ng proseso bago ito tumigil. Para sa bawat instrumentong tina-trade, itala ang nilalayong posisyon, aktuwal na posisyon ng account, mga nakabinbing order, at ang state ng signal na makaaapekto sa susunod na aksyon. Kung wala ang mga rekord na iyon, hindi mo malalaman kung naibalik ng pag-restart ang state o nagsimula lang ito ng panibagong strategy.
Halimbawa, bumibili ng 1 unit ang hourly strategy mo kapag nagiging positibo ang trend signal nito, at saka nagho-hold hanggang maging negatibo ang signal. Isinumite ng proseso ang buy noong 14:00, pero nag-crash ito bago maitala na tinanggap ang order. Na-fill ito ng paper venue. Sa pag-restart, wala itong nakatalang posisyon at positibo pa rin ang signal, kaya nagsumite ito ng isa pang buy. Pare-pareho ang asal ng signal. Luma na ang natatandaan ng strategy tungkol sa pag-aari ng account.
Kaya kailangang itugma ang kasalukuyang posisyon ng account sa na-save na state ng strategy bago payagang maglagay ng mga bagong order. Makakatulong ang lokal na snapshot, pero ang account o venue ang awtoridad sa kung ano talaga ang na-fill.
Aling state ang kailangang manatili matapos mag-restart?
Unahin ang state na maaaring magbago sa susunod na order. Magtago ng matibay na rekord na may timestamp at bersyon sa bawat update; gumawa ng kopya bago baguhin ang logic sa pagbawi para maulit mo sa susunod ang pagkabigo.
| State | Bakit ito mahalaga | Pagsusuri sa pagbawi |
|---|---|---|
| Mga posisyon at cash | Tinutukoy ng mga ito ang exposure at magagamit na pambili | Ihambing ang mga na-save na value sa paper account |
| Mga bukas na order | Maaaring na-fill ang order habang nakahinto ang proseso | Kunin ang status ng order at itugma ang mga bahagyang fill |
| Memorya ng signal | Maaaring tumagal nang higit sa isang desisyon ang mga crossing, cooldown, at holding period | Ibalik ang mga input ng huling na-commit na desisyon |
| Huling naprosesong event | Tinutukoy nito kung saan magpapatuloy ang strategy sa pagkuha ng data | I-play muli ang mga event pagkatapos ng puntong iyon nang hindi inilalapat ang mga ito nang 2 beses |
Madaling makaligtaan ang memorya ng signal. Maaaring magtago ang strategy na nagta-trade batay sa crossover ng value ng indicator noong kahapon para matukoy ang bagong crossing. Kung magsisimula ito nang walang value, maaari nitong mapagkamalan ang umiiral nang kondisyon bilang bagong event. Ganoon din ang problema sa cooldown timer: hindi dapat basta-bastang i-reset ng pag-restart ang patakarang nilalayong manatili.
Paano mo gagawing nauulit ang proseso ng pagbawi?
Bigyan ang bawat order ng matatag na client ID na hinango sa run ng strategy at sa desisyong pinagmulan nito. Kung susubukan muli ng proseso pagkatapos ng timeout, maaari nitong tingnan kung nakagawa na ng order ang desisyong iyon sa halip na maglagay ng duplicate. Itala lang ang mga pagbabago sa state kapag nakumpirma na ang katumbas na event sa account, at itago ang mga order at fill ID na nagpapaliwanag sa pagbabago.
Pagkatapos, subukan ang bahaging naging sanhi ng insidente mo. Patakbuhin ang strategy hanggang sa isang desisyon, i-save ang state, ihinto ito, at ibalik gamit ang mga posisyon at kasaysayan ng order ng paper account. Ihambing ang susunod na desisyon at mga kalalabasang order sa tuloy-tuloy na run. Ulitin ito gamit ang bahagyang na-fill na order at sa sitwasyong nag-crash sa pagitan ng pagsusumite at pagkumpirma. Hindi dapat mag-imbento ng bagong posisyon o ulitin ang nakumpleto nang aksyon ang run na nagpatuloy.
Magtago ng log ng pagbawi: huling naprosesong event, oras ng snapshot ng account, mga status ng bukas na order, naibalik na bersyon ng strategy, at unang desisyon pagkatapos mag-restart. Nagbibigay ito ng paraan para ma-audit ang “muli itong umandar.”
Ano ang dapat mong pagkatiwalaan pagkatapos mag-restart?
Pagkatiwalaan lang ang proseso kapag nagtugma na ang state ng account at strategy, alam na ang mga status ng nakabinbing order, at tumutugma ang susunod na desisyon sa inaasahan mo mula sa tuloy-tuloy na run. Kung hindi mo maipaliwanag ang hindi pagtutugma, ihinto muna ang pagsusumite ng paper order at siyasatin ang talaan ng mga event. Hindi patunay ng pagbawi ng strategy ang umaandar na proseso.
Nakita mo na ang pakinabang ng pag-crash: inilantad nito ang isang palagay na hindi mo kailangang harapin sa karaniwang run. Gawing nauulit na sitwasyon ang pag-restart, at malalaman mo kung ano ang natatandaan ng strategy mo bago mo itong muling pag-tradehin.
← Lahat ng post
