كان نظامنا بيتاً من ورق: كيف أنقذتنا ‘هندسة الفوضى’ من جحيم الانهيارات المتتالية؟

بتذكرها زي كأنها مبارح. كانت ليلة إطلاق الميزة الجديدة اللي اشتغلنا عليها شهور. الفريق كله سهران، القهوة ما وقفت، والعيون حمرة من التعب والحماس. الساعة دقت 12 بالليل، ضغطنا زر الإطلاق واحنا بنحكي “يا رب”. أول خمس دقايق، كل شيء تمام والاحتفالات بدأت. فجأة، بدأت التنبيهات توصل زي المطر على قنوات السلاك (Slack)… “High CPU Usage”, “5xx Server Error”, “Database Connection Timeout”.

في لحظات، تحول الحلم لكابوس. الموقع صار بطيء، بعدين صار يرمي أخطاء، وبعدين… مات تماماً. قعدنا يومين وليلتين، والشباب مش عارفين راسهم من رجليهم، بنحاول نلاقي “الإبرة في كومة القش”. كل ما نصلح إشي، إشي ثاني يخرب. كان نظامنا، اللي افتخرنا فيه، مجرد بيت من ورق انهار مع أول نسمة هوا قوية. هاي الليلة المشؤومة كانت قاسية، لكنها كانت الدرس الأهم في مسيرتي المهنية، الدرس اللي عرفنا على عالم “هندسة الفوضى”.

ما هي “هندسة الفوضى” (Chaos Engineering)؟ وليش مش مجرد “تخريب”؟

لما سمعت المصطلح أول مرة، فكرت زي ما كتير منكم بفكر هسا: “شو هالحكي الفاضي؟ يعني إحنا ناقصنا مشاكل عشان نروح نخرب النظام بإيدينا؟”. بس الفكرة أعمق من هيك بكثير.

هندسة الفوضى، ببساطة، هي “التخصص اللي بجرّب على نظامك عن قصد، عشان يبني ثقتك في قدرة النظام على تحمل الظروف الصعبة وغير المتوقعة في بيئة الإنتاج الحقيقية”.

فكّر فيها زي “التطعيم” أو “اللقاح” لنظامك. إنت بتحقن جرعة صغيرة ومُسيطَر عليها من الفشل (زي فيروس ضعيف)، عشان جهاز المناعة تبع النظام (اللي هو فريقك وأدواتك) يتعلم كيف يتعامل معها ويصير أقوى ضد الهجمات الحقيقية في المستقبل. هي مش اختبار عادي للكود، هي اختبار للنظام بأكمله: الكود، الشبكة، قواعد البيانات، الخدمات الأخرى، وحتى… البشر وقدرتهم على الاستجابة.

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

الفرق الجوهري بين الاختبار التقليدي وهندسة الفوضى

• الاختبار التقليدي (Testing): يسأل “هل هذا الكود يعمل كما هو مكتوب في المواصفات؟”. هو يتحقق من صحة مسار معين ومعروف.
• هندسة الفوضى (Chaos Engineering): تسأل “ماذا سيحدث لو فشل هذا الجزء من النظام فجأة؟ هل سيبقى النظام كله صامداً؟”. هي تتحقق من مرونة النظام في وجه المجهول.

لماذا أصبحنا بحاجة ماسة لهندسة الفوضى؟ قصة “البيت من ورق”

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

نظامنا كان عبارة عن شبكة معقدة من عشرات الخدمات الصغيرة اللي بتحكي مع بعضها. خدمة للمستخدمين، خدمة للمنتجات، خدمة للدفع، خدمة للتوصيات… إلخ. الجمال في هاي البنية إنها مرنة وسهلة التطوير، لكنها خلقت كابوس جديد اسمه “الانهيار المتتالي” (Cascading Failure).

اللي صار معنا ليلة الإطلاق هو بالضبط هذا الكابوس. خدمة صغيرة وغير مهمة نسبياً (كانت خدمة بتجيب صور مصغرة للمنتجات) صار عليها ضغط عالي وبدأت تبطئ. خدمة تانية بتعتمد عليها (خدمة عرض المنتجات) صارت تنتظرها لوقت طويل، وهذا خلّاها تستهلك كل الـ connections المتاحة. ولأن خدمة عرض المنتجات أساسية، كل طلبات الموقع صارت معلقة، وهذا أدى لضغط هائل على الـ Load Balancer والسيرفرات الرئيسية، اللي بدورها ضغطت على قاعدة البيانات… وفي النهاية، انهار كل شيء. خدمة صغيرة وغير حرجة، زي حجر دومينو صغير، وقعت كل الأحجار الكبيرة وراها.

هنا أدركنا أننا لم نكن نختبر “النظام” كنظام، بل كنا نختبر أجزاءه بشكل منفصل. لم نكن مستعدين لواقع أن “كل شيء يمكن أن يفشل في أي وقت”.

مبادئ هندسة الفوضى وكيف طبقناها عملياً

بعد ما لملمنا جراحنا، قررنا نتبنى الموضوع بشكل علمي. هندسة الفوضى لها 4 مبادئ أساسية، وهي كانت دليلنا في الرحلة:

1. ابدأ بفرضية عن “الحالة المستقرة” (Steady State)

أول خطوة هي إنك تعرف شو يعني “نظامي شغال تمام”. ما بنفع تحكي “الموقع شغال”. لازم تحدد مؤشرات أداء رئيسية (KPIs) قابلة للقياس. مثلاً:

• 99.9% من الطلبات على الصفحة الرئيسية يجب أن تنجح.
• متوسط زمن الاستجابة (Latency) يجب أن يكون أقل من 200ms.
• عدد عمليات الشراء في الدقيقة يجب ألا يقل عن 100.

هاي الأرقام بتصير هي “خط الأساس” اللي بنقيس عليه نجاح أو فشل التجربة.

2. أدخِل متغيرات من العالم الحقيقي (Vary Real-World Events)

هنا يبدأ المرح (أو الرعب!). لازم تفكر زي “الشرير” وتسأل حالك: شو أسوأ إشي ممكن يصير؟

• فشل السيرفرات: ماذا لو انطفأ سيرفر فجأة؟
• فشل الشبكة: ماذا لو زاد الـ Latency بين خدمتين، أو انقطعت الاتصالية تماماً؟
• فشل الموارد: ماذا لو امتلأ الـ CPU أو الـ Disk أو الـ Memory؟
• فشل الخدمات الخارجية (Dependencies): ماذا لو API الدفع أو خدمة البريد الإلكتروني توقفت عن الاستجابة؟

3. قم بإجراء التجارب في بيئة الإنتاج (Run Experiments in Production)

هاي هي الجملة اللي بتخوف المدراء. “شو؟! بدكم تلعبوا في البرودكشن؟!”. نعم، ولكن بحذر شديد. ليش في البرودكشن؟ لأنه مهما كانت بيئة الاختبار (Staging) قوية، مستحيل تحاكي تعقيد وفوضى بيئة الإنتاج الحقيقية وسلوك المستخدمين الفعلي. لكن طبعاً، هناك شرط أساسي…

4. قلّل من “نطاق الانفجار” (Minimize the Blast Radius)

هذا أهم مبدأ للسلامة. لا تبدأ بتفجير قاعدة البيانات الرئيسية! ابدأ بأصغر شكل ممكن:

• ابدأ على بيئة الاختبار: نعم، قلنا البرودكشن هو الهدف، لكن ابدأ على الـ Staging لتتأكد إن أدواتك وشغلك صح.
• استهدف نسبة صغيرة من المستخدمين: مثلاً، قم بتوجيه 1% فقط من الترافيك للتجربة.
• استهدف خدمات غير حرجة: ابدأ بخدمة لو تعطلت، التأثير بكون بسيط (زي خدمة التوصيات في مثالنا).
• حدد وقت للتجربة: لا تترك التجربة شغالة للأبد. شغلها لمدة 10 دقائق، راقب النتائج، ثم أوقفها.

أول تجربة فوضى لنا: “اقتلوا خدمة التوصيات!”

بعد ما فهمنا المبادئ، قررنا نعمل أول تجربة. قلنا “يا الله” وبدأنا.

1. الهدف: خدمة التوصيات (Recommendation Service).
2. الحالة المستقرة: الصفحة الرئيسية تفتح بأقل من 500ms، وتظهر فيها قائمة المنتجات الأساسية.
3. الفرضية (Hypothesis): “إذا توقفت خدمة التوصيات عن الاستجابة، يجب على الصفحة الرئيسية أن تفتح بشكل طبيعي (مع إخفاء قسم التوصيات) بدون أي زيادة ملحوظة في زمن التحميل.”
4. التجربة (The Experiment): قررنا محاكاة “فشل الشبكة” بين السيرفر الرئيسي وخدمة التوصيات. في عالم Kubernetes، هذا الأمر سهل جداً باستخدام أدوات مثل Chaos Mesh.

استخدمنا أداة Chaos Mesh لإنشاء “تجربة فوضى” بسيطة. هاي عينة من ملف الـ YAML اللي استخدمناه (طبعاً مع تبسيط للأسماء):

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: block-recommendation-service
  namespace: production
spec:
  action: loss # يمكن أن تكون loss, delay, partition
  mode: all
  selector:
    namespaces:
      - production
    labelSelectors:
      app: web-server # استهدف الـ Pods تبعت السيرفر الرئيسي
  target:
    selector:
      namespaces:
        - production
      labelSelectors:
        app: recommendation-service # استهدف خدمة التوصيات
    mode: all
  loss:
    loss: "100" # اقطع 100% من الـ Packets
  duration: "5m" # لمدة 5 دقائق فقط
  direction: to # فقط في اتجاه خدمة التوصيات

هذا الكود، باختصار، يقول لـ Chaos Mesh: “لمدة 5 دقائق، أي محاولة اتصال من الـ ‘web-server’ إلى الـ ‘recommendation-service’، قم بإسقاطها (block)”.

النتيجة: الصدمة التي كنا نحتاجها

شغلنا التجربة واحنا بنراقب لوحات المراقبة (Dashboards). الفرضية كانت خاطئة تماماً! ما حدث كان كارثياً:

الصفحة الرئيسية لم تفتح أبداً. بقيت عالقة في التحميل لمدة 30 ثانية ثم أعطت خطأ Timeout. السبب؟ المبرمج الذي بنى الصفحة لم يضع Timeout مناسب عند استدعاء خدمة التوصيات. كان الـ web server ينتظر 30 ثانية كاملة قبل أن ييأس، وخلال هذه الفترة، كان يستهلك Thread كامل. مع 10 مستخدمين فقط، استهلكنا كل الـ Threads المتاحة وتوقف السيرفر عن خدمة أي شخص آخر.

وهون كانت الصدمة… أو زي ما بنحكي، هون الفرس مربوط. اكتشفنا نقطة ضعف خطيرة جداً، لم تكن لتظهر في أي اختبار عادي، وبسبب خدمة كنا نظنها “غير مهمة”. في ذلك اليوم، لم نصلح مجرد bug، بل أصلحنا “ثقافة” كاملة. أضفنا Timeouts و Fallbacks و Circuit Breakers في كل مكان. تعلمنا ألا نثق بالشبكة أبداً.

نصائح أبو عمر العملية لبدء رحلتك مع هندسة الفوضى

بعد سنوات من تطبيق هذه المنهجية، جمعت لكم شوية نصائح من القلب:

• الاستثمار في المراقبة أولاً (Observability): لا تفكر حتى في هندسة الفوضى إذا لم يكن لديك نظام مراقبة قوي (Metrics, Logs, Traces). إذا أحدثت فوضى ولم تتمكن من رؤية ما حدث، فأنت فقط تخرب بدون فائدة. أدوات مثل Prometheus, Grafana, Jaeger, و ELK Stack هي أفضل أصدقائك.
• ابدأ صغيراً جداً (Start Small): أول تجربة لك يجب أن تكون مملة وآمنة. مثلاً، زد استهلاك الـ CPU على سيرفر واحد بنسبة 10% لمدة دقيقة واحدة. الهدف هو بناء الثقة في أدواتك وعملياتك.
• اجعلها ثقافة فريق (Game Days): لا تجعلها مهمة شخص واحد. خصص يوماً في الشهر أو الربع، سمّه “Game Day”، يجتمع فيه الفريق كله (مطورين، عمليات، مدراء) لتصميم وتنفيذ تجربة فوضى. هذا يبني المعرفة الجماعية ويزيل الخوف.
• أتمِت ما يمكنك أتمتته (Automate): الهدف النهائي هو أن تصبح تجارب الفوضى جزءاً من الـ CI/CD pipeline. كل تغيير جديد في الكود يجب أن يمر عبر “اختبار فوضى” صغير ليثبت صموده.
• لا تعاقب، بل تعلم (Blameless Postmortems): عندما تكشف تجربة الفوضى عن مشكلة، لا تسأل “من الذي كتب هذا الكود السيء؟”. بل اسأل “كيف يمكننا تحسين نظامنا لمنع حدوث هذا مرة أخرى؟”. الهدف هو التعلم والتحسين، وليس إلقاء اللوم.

الخلاصة: احتضن الفوضى المنظمة

رحلتنا من “بيت من ورق” إلى “قلعة صامدة” لم تكن سهلة، لكنها كانت ضرورية. هندسة الفوضى غيرت طريقتنا في التفكير. لم نعد نخاف من الفشل، بل أصبحنا نبحث عنه بشكل استباقي في بيئة مسيطر عليها، لنتعلم منه ونقوي نظامنا.

إذا كان نظامك ينهار بشكل متكرر، إذا كنت تقضي لياليك في إطفاء الحرائق، فربما حان الوقت لتتوقف عن لعب دور رجل الإطفاء، وتبدأ في لعب دور “مهندس الفوضى” الذي يجري تدريبات على الحرائق. ابدأ اليوم، ابدأ صغيراً، واجعل نظامك أقوى من أي وقت مضى. 💪