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

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

وفجأة، حوالي الساعة 11 مساءً، في ذروة الزحمة، بدأت التنبيهات تصرخ على شاشاتنا زي المجنونة. “Gateway Timeout”، “Service Unavailable”… الموقع كله صار “يشرّش مي” من كل مكان. شو اللي صار؟ يا جماعة الخير شو القصة؟ بعد ساعات من التوتر والضغط والبحث المحموم، اكتشفنا المصيبة: خدمة صغيرة ومهمشة، مسؤولة عن توليد التوصيات الشخصية للمستخدمين، دخلت في حلقة لا نهائية بسبب حمل غير متوقع، وسحبت معها قاعدة البيانات الرئيسية، وبالتالي أسقطت الموقع بأكمله.

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

هذا السؤال كان بداية رحلتنا مع مفهوم غيّر كل شيء: هندسة الفوضى (Chaos Engineering).

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

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

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

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

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

طبعًا الاستقرار هو الهدف. لكن في عالم الأنظمة الموزعة (Distributed Systems)، والخدمات المصغرة (Microservices)، والبنية التحتية السحابية (Cloud Infrastructure)، فكرة “الاستقرار الكامل” هي وهم. الأنظمة الحديثة معقدة لدرجة أنه من المستحيل التنبؤ بكل الطرق التي يمكن أن تفشل بها.

الفشل ليس “احتمالاً”، بل هو “حتمية”. الشبكات تتقطع، الخوادم تتعطل، الخدمات تتأخر في الاستجابة. السؤال ليس “هل سيفشل النظام؟” بل “عندما يفشل جزء من النظام، هل سينهار النظام بأكمله؟”.

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

الفوائد الحقيقية لممارسة الفوضى المنظمة

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

مبادئ هندسة الفوضى: كيف نمارس الفوضى بمسؤولية؟

هندسة الفوضى تتبع منهجًا علميًا دقيقًا. لا ترمِ حجرًا في الماء وتأمل الأفضل. اتبع هذه الخطوات لتكون فوضويًا محترفًا.

الخطوة الأولى: تحديد “الحالة المستقرة” (Steady State)

قبل أن تُحدث أي فوضى، يجب أن تعرف كيف يبدو “الوضع الطبيعي”. ما هي المقاييس التي تدل على أن نظامك يعمل بشكل جيد؟ قد تكون هذه المقاييس تقنية (مثل زمن استجابة الـ API، نسبة الأخطاء) أو تجارية (مثل عدد الطلبات في الدقيقة، عدد المستخدمين النشطين).

نصيحة من أبو عمر: ركز على المقاييس التي تهم المستخدم النهائي. إذا كان زمن الاستجابة 50ms أو 100ms والنظام يعمل، فهذا جيد. لكن إذا ارتفع إلى 5 ثوانٍ، فهنا المشكلة. الحالة المستقرة هي “تجربة المستخدم لم تتأثر سلبًا”.

الخطوة الثانية: صياغة الفرضية (Hypothesis)

الآن، ضع فرضية واضحة حول ما تتوقع حدوثه. يجب أن تكون الفرضية على هذا النحو: “نحن نعتقد أنه حتى لو حدث [حدث فوضوي]، فإن [المقياس المحدد للحالة المستقرة] سيبقى ضمن الحدود الطبيعية”.

مثال: “نعتقد أنه في حال تعطل الخادم الرئيسي لقاعدة البيانات (Primary DB)، فإن النظام سيقوم تلقائيًا بالتحويل إلى الخادم الاحتياطي (Replica) في غضون 10 ثوانٍ، ولن تتأثر عمليات الشراء الجديدة.”

الخطوة الثالثة: تصميم وإجراء التجربة (The Experiment)

هنا يبدأ المرح. في هذه الخطوة، تقوم بإدخال المتغير الفوضوي الذي خططت له. من المهم جدًا تقليل “نصف قطر الانفجار” (Blast Radius) في البداية.

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

الخطوة الرابعة: التحقق من الفرضية (Verification)

أثناء وبعد التجربة، راقب مقاييس الحالة المستقرة التي حددتها. هل حدث ما توقعته؟

• إذا صحت الفرضية: رائع! لقد زادت ثقتك في هذا الجزء من النظام. يمكنك الآن توسيع التجربة (زيادة نصف قطر الانفجار) لبناء المزيد من الثقة.
• إذا لم تصح الفرضية: هذا أفضل! لقد وجدت نقطة ضعف حقيقية في بيئة آمنة ومتحكم بها. الآن لديك فرصة لإصلاحها قبل أن تسبب كارثة.

الخطوة الخامسة: التعلم والتحسين

سواء نجحت التجربة أم فشلت، فإن الهدف هو التعلم. وثّق النتائج، وشاركها مع الفريق، وقم بإنشاء تذاكر عمل (Tickets) لإصلاح المشاكل المكتشفة. ثم كرر الدورة مرة أخرى.

أدوات في جعبتنا: كيف نبدأ عمليًا؟

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

• أدوات مفتوحة المصدر: مثل LitmusChaos (مشروع ضمن CNCF) و Chaos Mesh. كانت أداة Chaos Monkey من Netflix هي الرائدة في هذا المجال.
• منصات سحابية: معظم مزودي الخدمات السحابية الكبار يقدمون خدمات لهذا الغرض، مثل AWS Fault Injection Simulator (FIS) و Azure Chaos Studio.

مثال عملي مبسط: محاكاة زيادة حمل المعالج (CPU) على Kubernetes

لنفترض أن لديك تطبيقًا يعمل على Kubernetes وتريد أن ترى كيف سيتصرف إذا ارتفع استخدام المعالج في إحدى الحاويات (Pods) إلى 100%. هل سيقوم Kubernetes بإعادة تشغيل الحاوية؟ هل ستتعامل موازنات التحميل (Load Balancers) مع الموقف بشكل صحيح؟

يمكننا استخدام أداة مثل LitmusChaos لتعريف هذه التجربة بسهولة عبر ملف YAML.

# هذا مجرد مثال توضيحي لملف تعريف تجربة في LitmusChaos
# The actual implementation might have more details.

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-chaos
  namespace: default
spec:
  # ... (engine configuration details)
  appinfo:
    applabel: 'app=nginx'
    appkind: 'deployment'
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-cpu-hog
      spec:
        components:
          env:
            # النسبة المئوية لاستخدام المعالج
            - name: CPU_LOAD
              value: '100'
            
            # عدد الأنوية التي سيتم استهدافها
            - name: CPU_CORES
              value: '1'

            # مدة التجربة بالثواني
            - name: TOTAL_CHAOS_DURATION
              value: '60'

ما يفعله هذا الكود المفاهيمي هو أنه يطلب من Litmus استهداف أي Pod يحمل الوسم app=nginx، ثم يقوم برفع استخدام المعالج (CPU) فيه إلى 100% لمدة 60 ثانية. خلال هذه الدقيقة، وظيفتك هي مراقبة لوحات المعلومات (Dashboards) والتنبيهات لترى ما إذا كان النظام قد تصرف وفقًا لفرضيتك.

نصائح من قلب الميدان (من أبو عمر)

• ابدأ صغيرًا جدًا (Start Small): لا تحاول “غلي المحيط”. ابدأ بأبسط تجربة ممكنة على خدمة غير حرجة في بيئة التطوير. نجاح صغير واحد يفتح شهيتك للمزيد.
• التواصل هو المفتاح: قبل وأثناء وبعد التجربة، تواصل مع فريقك. “يا جماعة الخير، كمان ربع ساعة رح نعمل تجربة فوضى على خدمة الـ X، ما حدا يرتبك إذا شاف تنبيهات”. الشفافية تمنع الذعر وتبني ثقافة مشتركة.
• أتمِتْ ما تستطيع (Automate): الهدف النهائي هو دمج هذه التجارب في مسار الـ CI/CD الخاص بك، أو تشغيلها بشكل دوري (ما يسمى بـ GameDays) للتأكد من أن النظام يظل مرنًا مع كل تغيير جديد.
• ركز على التأثير البشري: لا تنسَ أن الهدف من كل هذا هو حماية المستخدم النهائي وتقليل الضغط على فريقك. كل مشكلة تكتشفها اليوم هي أزمة تتجنبها غدًا.

الخلاصة: من إطفاء الحرائق إلى بناء القلاع 🏰

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

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