ہم نے ایک ٹریڈ کے دوران پیپر حکمتِ عملی ری اسٹارٹ کی، تو آرڈرز کی ترتیب اس سے مختلف تھی جو اس نے ری اسٹارٹ سے پہلے بنائی تھی۔ مارکیٹ کا ڈیٹا وہی، حکمتِ عملی کا ورژن وہی، اکاؤنٹ کا بیلنس وہی۔ سگنل کی گنتی یکساں تھی۔ لیکن حکمتِ عملی کو اپنی پوزیشن اور زیرِ التوا آرڈرز یاد نہیں تھے۔
ہم نے ایک دن ری پلے کر کے اس فرق کا سراغ لگایا۔ سبق سادہ تھا: آپ کے سافٹ ویئر کے لیے ری اسٹارٹ بھی مارکیٹ کا ایک واقعہ ہے۔ اگر آپ یہ نہیں آزماتے کہ حکمتِ عملی اپنی حالت کیسے بحال کرتی ہے، تو صاف ستھرا بیک ٹیسٹ یہ چھپا سکتا ہے کہ پیپر سسٹم بھول جاتا ہے کہ اس کے پاس کیا ہے۔
09:10 — ہم نے ایک سادہ سی پوزیشن چنی
ٹیسٹ حکمتِ عملی ایک زیادہ لیکویڈ پرپیچوئل میں ٹریڈ کرتی تھی: جب مختصر موونگ ایوریج طویل موونگ ایوریج سے اوپر جاتی تو لانگ میں داخل ہوتی، اور الٹا کراس ہونے پر نکل جاتی۔ ہم نے ری پلے ایک چھوٹی کھلی پوزیشن اور اسے کم کرنے کے لیے پہلے سے موجود reduce-only لمٹ آرڈر کے ساتھ شروع کیا۔ اس طرح بحالی کو 2 باتیں دوبارہ معلوم کرنا تھیں: ہمارے پاس کیا تھا، اور ہم وینیو سے پہلے ہی کیا کرنے کو کہہ چکے تھے۔
چیک پوائنٹ پر اکاؤنٹ میں 0.04 کنٹریکٹس تھے۔ 0.01 کا آرڈر کھلا تھا۔ حکمتِ عملی کے عمل نے دونوں قدریں میموری میں محفوظ کر رکھی تھیں، لیکن اسٹارٹ اپ پر صرف پوزیشن حاصل کی۔ اس نے سمجھا کہ محفوظ شدہ آرڈر اب موجود نہیں۔
09:25 — پہلا ڈپلیکیٹ آرڈر سامنے آیا
ری اسٹارٹ کے بعد حکمتِ عملی نے موجودہ لانگ پوزیشن دیکھی، سگنل لاجک چلائی اور اسے کم کرنے کے لیے مزید 0.01 کا آرڈر بھیج دیا۔ اب پیپر وینیو پر 2 آرڈرز کھلے تھے۔ ان میں سے کوئی بھی اکیلا غلط آرڈر نہیں تھا۔ لیکن اگر دونوں بھر جاتے تو وہ مطلوبہ مقدار سے دگنا بیچ سکتے تھے۔
شروع میں ہم نے سگنل لوپ کو قصوروار سمجھا۔ مسئلہ لوپ میں نہیں، نامکمل اسنیپ شاٹ میں تھا۔ حکمتِ عملی نے پوچھا، “میری پوزیشن کیا ہے؟” مگر کبھی یہ نہیں پوچھا، “کون سے آرڈرز ابھی بھی کام کر رہے ہیں؟”
| ری اسٹارٹ کے بعد حالت | عمل کا اندازہ | اکاؤنٹ میں موجود حالت |
|---|---|---|
| پوزیشن | لانگ 0.04 | لانگ 0.04 |
| کم کرنے کے کھلے آرڈرز | کوئی نہیں | 0.01 کے 2 آرڈرز |
| ایک آرڈر بھرنے کے بعد مطلوبہ ایکسپوژر | لانگ 0.03 | لانگ 0.02 تک ہو سکتا ہے |
10:00 — ہم نے بحالی درست کی، پھر وقت کا ایک مسئلہ ملا
ہم نے اسٹارٹ اپ بدل دیا تاکہ نئے فیصلے فعال ہونے سے پہلے اکاؤنٹ کی پوزیشنوں اور کھلے آرڈرز سے حالت دوبارہ بنائی جائے۔ اس سے ڈپلیکیٹ آرڈر ختم ہو گیا۔ پھر ہم نے کنکشن منقطع ہونے کی صورت کو پیچیدہ کیا: حکمتِ عملی آف لائن تھی تو ایک آرڈر بھر گیا، اور بھرنے کی اطلاع دوبارہ کنکشن کے بعد پہنچی۔
اکاؤنٹ اسنیپ شاٹ میں بھراؤ پہلے ہی شامل تھا۔ پھر تاخیر سے آنے والی اطلاع نے مقامی پوزیشن کو دوسری بار کم کر دیا۔ چند سیکنڈ تک حکمتِ عملی سمجھتی رہی کہ اس کے پاس 0.02 کنٹریکٹس ہیں، جبکہ اکاؤنٹ میں 0.03 تھے۔ اس کا اگلا ری بیلنس ایک فرضی کمی کی بنیاد پر تھا۔
ہم نے مطابقت کے اصول شامل کیے: اکاؤنٹ اسنیپ شاٹ کو نقطۂ آغاز سمجھیں، اس میں پہلے سے شامل بھراؤ نظر انداز کرنے کے لیے ایونٹ شناخت کار استعمال کریں، اور ابتدائی مطابقت مکمل ہونے تک آرڈرز نہ بھیجیں۔ اطلاع دیر سے یا 2 بار آ سکتی ہے۔ بحالی کو دونوں صورتیں سنبھالنی چاہییں۔
13:40 — ری پلے نے ایک باریک فرق پکڑا
ہم نے قیمتوں کی ایک ہی ترتیب کو اصل اور ری اسٹارٹ کے بعد والے رن میں دوبارہ چلایا۔ صرف آخری P&L کا موازنہ کرنے سے مسئلہ نظر نہ آتا: مارکیٹ پلٹنے کے بعد دونوں ورژن ایک ہی پوزیشن پر ختم ہوئے۔ آرڈر ایونٹس کا موازنہ کرنے سے فرق سامنے آیا۔
ہم نے ہر فیصلے کے ساتھ وہ حالت لاگ کی جسے اس نے پڑھا تھا: پوزیشن، کھلے آرڈرز، آخری پروسیس شدہ بھراؤ کا شناخت کار، سگنل کی قدر اور حکمتِ عملی کا ورژن۔ پھر پہلے مختلف ایونٹ کی وجہ واضح ہو گئی۔ ایک رن میں کام کرتا ہوا آرڈر موجود تھا؛ دوسرے میں فہرست خالی تھی۔ بعد میں ایک رن نے بھراؤ 2 بار لاگو کیا۔
اختتامی بیلنس یکساں ہونے سے یہ ثابت نہیں ہوتا کہ رویہ بھی یکساں تھا۔ فیصلوں اور آرڈرز کی ترتیب کا موازنہ کریں، خاص طور پر بحالی کے دوران۔
16:20 — اگلی بار ہم کیا مختلف کریں گے
اکاؤنٹ کی حالت میں تبدیلیاں دیکھنے سے پہلے ہم نے قیمتوں کا ڈیٹا ری پلے کرنے میں بہت وقت لگا دیا تھا۔ اگلی بار ہم پہلے خرابی کی صورتیں پیدا کریں گے اور مارکیٹ کی قیمتوں کو تقریباً ہموار رکھیں گے۔ یوں سافٹ ویئر کی خرابی آسانی سے دکھائی دے گی اور قیمت میں تیز حرکت تشخیص کو الجھائے گی نہیں۔
- پوزیشن اور جزوی طور پر بھرے آرڈر کے ساتھ ری اسٹارٹ کریں۔
- آرڈر بھیجنے کے بعد کنکشن منقطع کریں، پھر بھراؤ کی اطلاع آنے سے پہلے دوبارہ کنیکٹ کریں۔
- ایک ہی بھراؤ کا ایونٹ 2 بار بھیجیں اور تصدیق کریں کہ حالت صرف ایک بار بدلتی ہے۔
- پوزیشنوں اور کھلے آرڈرز دونوں کی مطابقت مکمل ہونے تک نئے آرڈرز روکیں۔
- بغیر رکاوٹ اور ری اسٹارٹ کے بعد والے رنز کے فیصلوں اور آرڈرز کے لاگز کا موازنہ کریں۔
ہم نے یہ بھی سیکھا کہ بحالی کا اسنیپ شاٹ، حکمتِ عملی کے ورژن اور ایونٹ لاگ کے ساتھ محفوظ کرنا چاہیے۔ اس سے کسی کو کنکشن دوبارہ قائم کرنے کی عین ترتیب یاد رکھنے پر انحصار کرنے کے بجائے، چند منٹ میں خرابی دوبارہ پیدا کی جا سکتی تھی۔
جو پیپر حکمتِ عملی صرف اس وقت درست چلتی ہے جب اس کا عمل بند نہ ہو، اس کی مکمل مشق نہیں ہوئی۔ اسے پوزیشن کے بیچ ری اسٹارٹ کریں، بھراؤ کی اطلاعات دیر سے پہنچائیں، پھر اس کے بھیجے گئے ہر آرڈر کا معائنہ کریں۔ مقصد یہ ثابت کرنا نہیں کہ اس میں کبھی خرابی نہیں آئے گی۔ مقصد یہ ہے کہ پیپر اکاؤنٹ آپ کو اچانک وہی سبق سکھانے پر مجبور کرے، اس سے پہلے ہی اس کی بحالی کا عمل واضح ہو۔
← تمام پوسٹس
