الكريبتو لا ينام أبدًا: ليه الأسواق اللي تشتغل 24/7 تحتاج بنية تحتية 24/7

الكريبتو لا ينام أبدًا: ليه الأسواق اللي تشتغل 24/7 تحتاج بنية تحتية 24/7

أذكر بالضبط اللحظة اللي أدركت فيها إن التداول المستمر هشّ أكثر مما نتخيل. كانت الساعة 2:47 فجرًا، يوم ثلاثاء. كنت أراقب بوت مراجحة لعميل، وفجأة صار صمت تام من WebSocket الخاص بالمنصة. لا رسالة انهيار، لا تحذير rate-limit. صمت فقط. البوت استمر يرسل أوامر بناءً على أسعار قديمة لمدة 11 دقيقة قبل ما أنتبه. وبحلول ذلك الوقت، كان الضرر حصل.

هذا هو الفرق مع الأسواق اللي ما تقفل أبدًا: ما في جرس إغلاق يخفي الأعطال. لما تنغلق الأسواق التقليدية، المشاكل تتأجل. في الكريبتو، كل ثانية تعطّل هي ثانية فيها شخص آخر يتداول — ضدك، بدونك، أو فوق أوامرك.

جرس الإغلاق هو مستشفى للأنظمة المكسورة

الأسواق المالية التقليدية عندها شيء الكريبتو ما عنده: وقت إغلاق. بورصة ناسداك ما توقف التداول الساعة 4:00 مساءً بتوقيت شرق أمريكا من غير سبب. جرس الإغلاق يعطي الجميع لحظة لتسوية الحسابات، إصلاح الأخطاء، تسكير الثغرات، وإعادة الضبط. إنها نافذة صيانة ليلية ظلت تدعم استقرار أسواق الأسهم لعقود.

الكريبتو ما يوقف أبدًا. البيتكوين ما يأخذ استراحة غداء. الإيثيريوم ما يعرف التوقيت الصيفي. لما بنيت شركتي السابقة بوت ماركت ميكينج، أول سؤال ما كان "ما هي استراتيجيتنا؟" كان: "ماذا يحدث لو AWS us-east-1 طاحت الساعة 3 الفجر؟"

ومعظم الفرق ما عندها جواب مقنع.

اللي يصير فعليًا لما تفشل البنية التحتية

خلني أعطيك ثلاثة سيناريوهات واقعية. ولا واحد منها افتراضي.

السيناريو الأول: تاجرة في طوكيو ومنصة في فرانكفورت

يوكي تشتغل موظفة، عندها محفظة كريبتو صغيرة في طوكيو. تداولها الفعلي يكون بين 1 و4 الفجر بتوقيت اليابان — وقت ما يكون السوق الأمريكي نشيطًا والتقلبات تظهر. في ليلة من الليالي، المنصة المفضلة عندها تطلع "503 Service Unavailable" قرابة أربعين دقيقة أثناء موجة تصفية كبيرة.

يوكي ما تقدر تقفل مركز يخسر. تتفرج وهوامشها تتعفن من تمويل المراكز بينما صفحة حالة المنصة تقول "جميع الأنظمة تعمل" — صفحة واضح إنه ما يفحصها إلا بشر في أوقات الدوام الرسمي.

النتيجة؟ يوكي ما تخسر فلوس فقط. تخسر الثقة. تنقل أصولها لمكان ثاني وتحكي لأربع أصدقاء في مجموعة التداول. فشل البنية التحتية للمنصة ما كلّفها عميلة واحدة، كلّفها شبكة كاملة.

السيناريو الثاني: الانهيار الخاطف والأوراكل البطيء

بروتوكول إقراض لامركزي عنده محرك تصفية يعتمد على أوراكل أسعار تتحدث كل 15 دقيقة. في أثناء انهيار مفاجئ، الأصل الأساسي يهبط 23% خلال أربع دقائق. الأوراكل — الشغال على بنية تحتية بدون تكرار كافٍ — يتأخر سبع دقائق.

لما يلحق الأوراكل أخيرًا، يكون عدد كبير من المراكز غير المضمونة انزلق. لوحة مخاطر البروتوكول شكلها صحي لأنها تقرأ بيانات قديمة. البروتوكول يتحمل 3 ملايين دولار ديون معدومة لأن بنيته "اللحظية" ما كانت لحظية فعلًا.

الأسوأ؟ تغيير معماري بسيط — تشغيل عقد أوراكل مكررة في مناطق متعددة وحساب السعر بالوسيط — كان ممكن يمنع الكارثة كلها.

السيناريو الثالث: حد Rate Limit قتل البوت

صوفيا تدير شركة تداول خاص صغيرة. فريقها عندهم نشر بوتات رائع على Kubernetes يتوسع تلقائيًا بشكل مثالي في الظروف العادية. أثناء موجة تقلبات عنيفة الساعة 2 الفجر، الطلب على API العام للمنصة يتضاعف ثلاث مرات. بنية المنصة التحتية — المخصصة للحمولة المتوسطة، مو للذروة — تبدأ تفرض rate limits بقسوة.

بوت صوفيا ينخنق في نص الاستراتيجية. ما يقدر يلغي أوامر، ما يقدر يعدل العطاءات، ما يسوي شي غير ينتظر. لما يختفي الـ rate limit، السوق يكون تحرك ضد مراكزها، وكود "الأمان" في البوت ينفذ بيع هلع بأسوأ سعر ممكن.

طيب، ماذا يعني "بنية تحتية 24/7" فعليًا؟

لما أتكلم مع مؤسسين ومهندسين يشتغلون في الكريبتو، عادة عندهم حس سليم بس المقياس غلط. يظنون إن شوية سيرفرات مكررة ولوحة مراقبة تكفي. لا، ما تكفي.

التكرار الجغرافي مو خيار، إلزامي

إذا كانت بنيتك التحتية كلها في منطقة سحابية واحدة، إذًا أنت ما تشغّل بنية تحتية 24/7. أنت تشغّل بنية "أحيانًا" مع إحصائيات Availability حلوة.

مجموعات Kubernetes لازم تكون موزعة على منطقتين على الأقل، ويفضل ثلاث مناطق جغرافية. موفرو السحابة سهّلوا هذا — AWS Global Accelerator و GCP multi-region load balancing يساعدون — بس المسؤولية تبقى عليك في تصميم النظام لتحمل انهيار منطقة كاملة. أغلب الفرق تصمم لتحمل فشل خدمة، مو فشل منطقة. والفرق كبير جدًا.

"فحص الصحة" المفروض يختبر أسوأ يوم في حياتك

معظم أنظمة المراقبة فعاليتها مثل كاشف دخان بدون بطارية. تنبهك بعد ما يصير العطل أصلًا، وبحلولها السوق يكون تحرك بعيد.

اللي أنصح فيه شيء شوي جنوني: أنظمة failover معدّة مسبقًا ومختبرة كل أسبوع. لا تكتفي بوجود نسخة احتياطية — بدّل إليها فعليًا. ارم لها زبالة. اقتل الـ primary الأساسي في الإنتاج وشوف اللي يصير. هذا مخيف، لكنه أرخص بكثير من تعلّم نقاط ضعف بنيتك أثناء حدث سوقي.

هندسة الفوضى صديقتك، مو مجرد buzzword

نتفليكس كانت أول من ابتكر هندسة الفوضى مع Chaos Monkey. لكن بالنسبة لأنظمة التداول، المكافئ أقسى بكثير. نظامك المفروض يتحمل، بدون تدخل بشري:
- منطقة سحابية كاملة تنطفئ
- نسخ قاعدة البيانات تتأخر لدرجة الدقائق
- المنصة اللي تعتمد عليها تبدأ تفرض rate limits على كل مفاتيحك
- نظام إدارة أسرارك يتم اختراقه

سوّوا game days. اكسروا الأشياء عمدًا. إذا فريقكم ما يقدر يتحمل فشلًا معمولًا له ظهر الخميس، أكيد ما راح يتحمل فشلًا حقيقيًا الساعة 2 الفجر.

الوعي بـ Rate Limits ميزة تنافسية

لما تبني لسوق 24/7، المنصة مو شريكك — هي خصم محتمل. أغلب المنصات تفرض rate limits على طلبات API لما تكون بنيتها التحتية تحت ضغط. إذا نظامك ما فيه backoff مدمج، وطوابير انتظار، وتدهور سلس، راح تكون أول واحد ينفصل بالسكاكين وقت الضرورة.

ابنِ نظامك وكأن المنصة على بعد حادثة واحدة من خنقك. لأنها فعلًا كذلك.

الجانب الإنساني: ما تقدر تشغّل 24/7 بفريق 9 إلى 5

لنتكلم عن الجزء اللي أحد ما يبي يذكره. حتى مع أتمتة مثالية، لازم في شخص صاحي ومسؤول. أسلوب "فيشوا المؤسسين" ينكسر بعد ثالث حادثة الساعة 3 الفجر.

رأيي قوي: إذا كنت تشغّل بنية تداول، لازم يكون عندك نظام on-call رسمي بمسارات تصعيد. مو "كلنا بنشوف سلاك" — لأ، on-call حقيقي ومنظم. استخدم أدوات مثل PagerDuty أو Opsgenie. اكتب runbooks لكل حادثة متوقعة. وسجّلوا حوادثكم، بحق الجرأة — ثقافة postmortem مو بيروقراطية، هذي طريقة تتجنبون بها تكرار الدروس المؤلمة.

علاقة الذكاء الاصطناعي

إحنا نشوف ثورة هادئة في طريقة تشغيل هذي البنية. عملاء الذكاء الاصطناعي صاروا خط الدفاع الأول لكثير من الفرق. الوضع التلقائي في Claude Code أصبح مفعّلًا افتراضيًا الآن، يعني راح نشوف عملاء مستقلين أكثر يتولون مهام تشغيل روتينية بإشراف بشري قليل.

لكن عندي تحذير: العملاء المستقلين ما هم أفضل من الحواجز اللي تبنيهم حولهم. صناديق Docker الرملية لعملاء الذكاء الاصطناعي (docker.com/products/docker-sandboxes/) توفر بيئة معزولة وقابلة للرمي — تقدر تخلّي الذكاء الاصطناعي يحقق في حادثة أو يختبر سكربت failover بدون ما تقلق إنه يلمس بيئة الإنتاج. استخدم هذا. دايم اعزل أدواتك المستقلة.

وكمان، لما تكتب سكربتات بنيتك التحتية، تذكر إن تشديد GitHub Actions مهم. حدد صلاحيات أقل مستوى على workflows — سكربت نشر يوصله أكثر من المطلوب هو قنبلة موقوتة تستنى تتفعل.

خطوات عملية

إذا كنت تقرأ هالحين وتفكر "محتاجين نصلح بنيتنا"، ابدأ من هنا:

1. **دقق نطاق الانفجار (blast radius).** اكتب كل مكوّن في نظامك. لكل واحد اسأل: "إذا فشل هذا الساعة 3 الفجر، ما هو الضرر المالي؟"
2. **اقتل سيرفرًا عمدًا هذا الأسبوع.** اختر خدمة غير حرجة، اقتل الـ primary، وشاهد استجابة فريقك. احسب كم استغرق التعافي.
3. **ارسم خارطة اعتمادياتك.** هل تعرف كل API خارجي نظامك يستهله؟ حدوده؟ تاريخ تعطّله؟ لازم تعرف.
4. **ابنِ هيكل runbook.** لأكثر خمسة أعطال محتملة، اكتب إجراءات الاسترداد الحين. مستقبلك الساعة 3 الفجر راح يشكرك بلا حدود.

الأسئلة الشائعة

هل البنية التحتية 24/7 غالية؟

نعم، لكنها أرخص من البديل. تشغيل بنية متعددة المناطق ممكن يكلّف 2-3 أضعاف الإعداد لمنطقة وحدة. لكن حادثة واحدة كبيرة في الوقت الغلط تقدر تمحي أرباح سنوات. اعتبرها تأمينًا — ما تشتريه لأنك تتوقع حريق، تشتريه لأن كلفة الحريق كارثية.

هل الفرق الصغيرة في الكريبتو تقدر فعلًا تحافظ على تشغيل 24/7؟

بصراحة؟ لحالها صعب. لكن مو لازم. استخدم خدمات مُدارة (AWS/GCP/Azure)، اعتمد على Kubernetes المُدار (EKS, GKE, AKS)، ولا تحاول تبرمج قاعدة بياناتك بنفسك. الفرق اللي تفشل هي اللي تحاول تسوي كل شيء بنفسها. استخدم بنية تحتية مُدارة جيدة، ووفّر وقت هندستك للشي اللي يميزك فعلًا.

ما هو أهم شيء لازم تضبطه؟

التكرار الجغرافي لخدمات الحالة (stateful services). الخدمات عديمة الحالة مثل خوادم API سهلة التوسع والتحرك. قواعد البيانات وطوابير الرسائل هي الجزء الصعب. إذا بياناتك مو مكررة عبر المناطق، ما يهم أي شيء ثاني.

كيف أتعامل مع توقف API في المنصات؟

افترض إنها بتصير، وابنِ نظامك لينهار بنعومة. خزّن بيانات دفتر الأوامر مؤقتًا لكن وسمّها بوضوح إنها قديمة. نفّذ exponential backoff. سوّي circuit breaker يوقف التداول — أو يحول لوضع دفاعي — لما يتعدى عمر بيانات الفيد عمرًا محددًا. الهدف إنك توقف خسارة المال ببطء بدل ما تخسره بسرعة.

الخلاصة

سوق الكريبتو ما يهمه عطلة نهاية أسبوعك. ما يهمه إجازات مهندسيك، ولا ظروف موفر السحابة، ولا اجتماع زوم اللي مفروض ما صار. السوق آلة تتحرك للأمام فقط.

كل ما أسرعت في معاملة بنيتك التحتية كأنها نظام يجب أن يعمل دائمًا، كل ما قلت آلام مكالمات الساعة 3 الفجر. لأني أضمن لك: إذا ما بنيت للعمل 24/7، السوق راح يلاقي الثغرة. دايم يلاقيها.