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

“الوضع لوز”… ثم انهار كل شيء

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

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

لكننا كنا مخطئين… مخطئين جداً. هذا البطء الصغير في خدمة غير أساسية تسبب في تراكم الطلبات في طابور الرسائل (Message Queue). هذا التراكم استهلك كل الذاكرة المتاحة، مما أدى إلى انهيار خدمة الرسائل نفسها. وبما أن خدمة الرسائل كانت القلب النابض الذي يربط بين كل خدماتنا المصغرة (Microservices)، فقد بدأ النظام بأكمله ينهار كأحجار الدومينو. في غضون دقائق، تحول “الوضع اللوز” إلى كابوس حقيقي، والموقع توقف عن العمل بالكامل.

ذلك اليوم، أكلنا “كفّاً” تقنياً لن ننساه. تعلمنا بالطريقة الصعبة أن الاستقرار الذي نراه في بيئات الاختبار هو مجرد وهم جميل. الواقع في بيئة الإنتاج (Production) أكثر فوضوية وقسوة. ومن رحم هذه المعاناة، بدأت رحلتي الحقيقية مع مفهوم غيّر طريقة تفكيري في بناء الأنظمة: هندسة الفوضى (Chaos Engineering).

ما هي “هندسة الفوضى”؟ ليست فوضى عشوائية!

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

فكر فيها مثل اللقاح: أنت تحقن جسدك بنسخة ضعيفة أو ميتة من الفيروس (فشل مُحكم) لتدريب جهاز المناعة لديك (النظام) على التعرف عليه ومقاومته، حتى إذا واجهت الفيروس الحقيقي في المستقبل، تكون مستعداً.

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

من الوهم إلى الواقع: لماذا نحتاج هندسة الفوضى؟

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

كشف نقاط الضعف الخفية (Uncovering Hidden Weaknesses)

مثلما حدث معنا، غالباً ما تكون المشاكل الكبرى ناتجة عن تفاعلات غير متوقعة بين مكونات النظام. فشل صغير في مكان ما يمكن أن يؤدي إلى انهيار متسلسل (Cascading Failure). من خلال التجارب، يمكننا اكتشاف هذه التبعيات الخطيرة ونقاط الفشل المنفردة (Single Points of Failure) قبل أن تسبب كارثة.

بناء الثقة في النظام (Building Confidence in the System)

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

تحسين الاستجابة للحوادث (Improving Incident Response)

عندما تحدث مشكلة حقيقية، هل سيكون فريقك مستعداً؟ هندسة الفوضى تعمل كـ “تدريب على الحرائق” للمهندسين. من خلال محاكاة الحوادث في بيئة مسيطر عليها، يصبح الفريق أسرع وأكثر كفاءة في التشخيص والحل عندما يحدث الأمر بالفعل. تقل حالة الذعر ويزداد التركيز على الحل.

كيف نبدأ رحلتنا مع هندسة الفوضى؟ (خطوات عملية)

البدء ليس معقداً كما يبدو. السر هو في التدرج والتحكم. إليك الخطوات التي أتبعها دائماً:

1. الخطوة الأولى: ابدأ صغيراً وفي بيئة آمنة (Start Small)
   لا تقفز مباشرة إلى بيئة الإنتاج. ابدأ ببيئة الاختبار (Staging). اختر خدمة غير حرجة، ربما خدمة داخلية لا تؤثر على المستخدمين. الهدف هو أن يتعلم الفريق العملية بأمان.
2. الخطوة الثانية: تحديد الفرضية (Define the Hypothesis)
   هذا هو الجزء العلمي. قبل أن تفعل أي شيء، اكتب فرضية واضحة. يجب أن تكون على صيغة: “نحن نعتقد أنه إذا حدث [الفشل]، فإن النظام سيستجيب بـ [السلوك المتوقع]”.
   مثال: “نعتقد أنه إذا أوقفنا خادم الـ Cache (مثل Redis)، فإن التطبيق سيستمر في العمل ولكن مع زيادة طفيفة في زمن الاستجابة (latency) لأنه سيقرأ مباشرة من قاعدة البيانات.”
3. الخطوة الثالثة: تحديد نطاق التأثير (Blast Radius)
   هذه أهم خطوة لضمان الأمان. حدد بوضوح ما هو “نصف قطر الانفجار” لتجربتك. هل ستؤثر على خادم واحد؟ نسبة 1% من المستخدمين؟ مجموعة محددة من الحسابات التجريبية؟ ابدأ بأصغر نطاق ممكن.
4. الخطوة الرابعة: تنفيذ التجربة (Run the Experiment)
   استخدم الأدوات المتاحة (سنتحدث عنها لاحقاً) لحقن الفشل الذي حددته. على سبيل المثال، إيقاف حاوية (container)، زيادة استهلاك وحدة المعالجة المركزية (CPU) إلى 100%، أو إضافة تأخير (latency) على الشبكة.
5. الخطوة الخامسة: المراقبة والتحليل (Monitor and Analyze)
   أثناء التجربة وبعدها مباشرة، راقب لوحات المراقبة (Dashboards) عن كثب. هل تطابقت النتائج مع فرضيتك؟
   • إذا كانت الفرضية صحيحة: ممتاز! لقد أثبتت مرونة نظامك في هذا السيناريو.
   • إذا كانت الفرضية خاطئة (وهو ما يحدث غالباً في البداية): رائع! لقد اكتشفت نقطة ضعف حقيقية. الآن يمكنك العمل على إصلاحها.
6. الخطوة السادسة: التحسين والمشاركة (Improve and Share)
   قم بإصلاح المشكلة التي وجدتها. ربما تحتاج إلى إضافة آلية احتياطية (fallback)، أو زيادة مهلة الانتظار (timeout)، أو عزل الخدمة بشكل أفضل. الأهم من ذلك، قم بتوثيق التجربة ونتائجها وشاركها مع الفريق بأكمله. هذا يبني ثقافة جماعية تركز على المرونة.

أدوات في جعبتي: أشهر أدوات هندسة الفوضى

لست بحاجة إلى بناء كل شيء من الصفر. هناك العديد من الأدوات الرائعة التي يمكن أن تساعدك:

Chaos Monkey (الأصل من نتفليكس)

الأداة التي بدأت كل شيء. وظيفتها بسيطة: تقوم بإيقاف الخوادم الافتراضية (Virtual Machines) بشكل عشوائي في بيئة الإنتاج. الفكرة هي إجبار المهندسين على بناء خدمات يمكنها تحمل فشل الخوادم دون التأثير على المستخدم.

Gremlin (المنصة التجارية الشاملة)

منصة “الفوضى كخدمة” (Chaos-as-a-Service) سهلة الاستخدام. توفر واجهة رسومية لإجراء أنواع مختلفة من “الهجمات” مثل استهلاك الموارد (CPU, Memory)، أو إحداث مشاكل في الشبكة (latency, packet loss)، أو إيقاف العمليات. إنها خيار ممتاز للشركات التي تريد البدء بسرعة.

LitmusChaos (المشروع المفتوح المصدر لـ Kubernetes)

إذا كنت تعمل في عالم Kubernetes والحاويات، فإن Litmus هو صديقك المفضل. إنه مشروع مفتوح المصدر تابع لـ CNCF (Cloud Native Computing Foundation) ومصمم خصيصاً لبيئات Kubernetes. يتيح لك تعريف تجارب الفوضى كملفات YAML، تماماً مثل أي مورد آخر في Kubernetes.

مثال عملي: تجربة حذف Pod باستخدام LitmusChaos

لنفترض أنك تريد اختبار ما إذا كان تطبيقك (الذي يعمل بعدة نسخ Replicas) سيظل متاحاً إذا تم حذف إحدى حاوياته (Pods) فجأة. يمكنك تعريف التجربة كالتالي:

# chaosengine.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-chaos
  namespace: default
spec:
  # استهدف تطبيق nginx
  appinfo:
    appns: 'default'
    applabel: 'app=nginx'
    appkind: 'deployment'
  # جدولة التجربة لتعمل مرة واحدة
  chaosServiceAccount: litmus-admin
  engineState: 'active'
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            # احذف حاوية واحدة فقط
            - name: TOTAL_CHAOS_DURATION
              value: '30' # مدة التجربة بالثواني
            - name: PODS_AFFECTED_PERC
              value: '50' # النسبة المئوية للحاويات المتأثرة (لو كان لديك اكثر من حاويتين)

بتطبيق هذا الملف، سيقوم Litmus باختيار إحدى حاويات nginx وحذفها، مما يسمح لك بمراقبة ما إذا كان Kubernetes سيقوم بإعادة تشغيلها بسرعة وما إذا كان المستخدمون قد لاحظوا أي انقطاع في الخدمة.

نصائح من “أبو عمر”

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

– الأتمتة صديقك: مع نضج ممارستك، حاول أتمتة تجارب الفوضى كجزء من مسار التكامل والنشر المستمر (CI/CD). هذا يضمن أن المرونة يتم اختبارها باستمرار مع كل تغيير جديد.

• ابدأ دائماً بالسؤال “ماذا لو؟”: قبل كتابة أي سطر برمجي، اسأل نفسك: “ماذا لو فشلت هذه الاستدعاء للـ API؟”، “ماذا لو كانت قاعدة البيانات بطيئة؟”، “ماذا لو امتلأ القرص الصلب؟”. هذه العقلية هي جوهر بناء الأنظمة المرنة.

الخلاصة: من بناء القلاع الرملية إلى بناء الحصون المنيعة 🏰

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

توقف عن بناء القلاع الرملية التي تنهار مع أول موجة، وابدأ في بناء الحصون المنيعة التي تصمد في وجه العواصف. ابدأ اليوم، ابدأ صغيراً، ولكن الأهم من ذلك، ابدأ. 🚀