يا جماعة الخير، اسمحوا لي أن أروي لكم قصة حدثت معي قبل بضع سنوات. كانت ليلة إطلاق عرض الجمعة البيضاء الكبير، والله وكيلكم، كنا قد قضينا شهورًا نستعد لها. القهوة كانت صديقنا الوفي، والبيت أصبح مجرد مكان نمر به لنبدل ملابسنا. كنا على ثقة تامة أن كل شيء “تمام التمام” وأن أنظمتنا ستصمد كالجبال.
بدأ العد التنازلي، وانطلقت العروض. في الدقائق الأولى، كانت الأرقام ترتفع بشكل جنوني، والفرحة تعم المكتب. وفجأة، ودون سابق إنذار، بدأت التنبيهات الحمراء تملأ الشاشات كالمطر. توقفت الطلبات، والموقع أصبح بطيئًا كسلحفاة مصابة بالزكام، ثم… انهار كل شيء. شعرنا وكأن الأرض انشقت وابتلعتنا. قضينا الساعات الـ 18 التالية في جحيم لا يوصف، نحاول يائسين تحديد سبب العطل وإصلاحه، بينما كانت الخسائر تتراكم.
في تلك الليلة، أدركت حقيقة مُرّة: أنظمتنا كانت هشة كالزجاج. كنا نختبر الحالات المثالية، لكننا لم نكن مستعدين أبدًا لـ “فوضى” العالم الحقيقي. كانت تلك الليلة هي نقطة التحول التي دفعتنا لاستكشاف عالم جديد، عالم يُعرف باسم هندسة الفوضى (Chaos Engineering).
ما هي هندسة الفوضى؟ ليست كما تظن!
عندما يسمع الكثيرون مصطلح “هندسة الفوضى”، يتخيلون مبرمجين يرتدون معاطف المختبر ويضغطون على أزرار حمراء كبيرة عشوائيًا لتعطيل الأنظمة. الحقيقة مختلفة تمامًا. هندسة الفوضى ليست إحداث الفوضى، بل هي الكشف عن الفوضى الكامنة في نظامك.
ببساطة، هي تخصص علمي يعتمد على إجراء تجارب مدروسة على نظامك للكشف عن نقاط الضعف فيه قبل أن يفعل المستخدمون ذلك. فكر فيها كأنها “تدريب على الحرائق” لتطبيقاتك. أنت لا تنتظر نشوب حريق حقيقي لتكتشف أن رشاشات المياه لا تعمل أو أن باب الطوارئ مغلق!
“هندسة الفوضى هي الوسيلة التي نكتسب بها الثقة في قدرة نظامنا على تحمل الظروف المضطربة وغير المتوقعة في بيئة التشغيل الحقيقية.”
المبدأ الأساسي: من رد الفعل إلى الفعل الاستباقي
النهج التقليدي في اختبار الجودة يركز على التأكد من أن النظام يعمل بشكل صحيح في الظروف “الطبيعية”. لكن في عالم اليوم، المكون من خدمات مصغرة (Microservices) وسحابة وبيئات معقدة، “الطبيعي” هو حالة نادرة. الفشل ليس احتمالًا، بل هو حقيقة حتمية.
- النهج التقليدي (السلبي): انتظر حتى ينهار النظام، ثم ابدأ في البحث عن السبب وإصلاحه (ما فعلناه في ليلتنا المشؤومة).
- هندسة الفوضى (الاستباقي): قم بإحداث أعطال صغيرة ومُتحكّم بها عمدًا، وراقب كيف يستجيب النظام، ثم أصلح نقاط الضعف التي تظهر.
كيف نبدأ رحلة “الفوضى المنظمة”؟
قد يبدو الأمر مخيفًا في البداية، فكرة “كسر” الأشياء عمدًا تتعارض مع كل ما تعلمناه كمطورين. لكن مع اتباع منهجية علمية، يصبح الأمر آمنًا ومفيدًا للغاية. إليكم الخطوات التي اتبعناها:
الخطوة الأولى: تحديد “الحالة المستقرة” (Steady State)
قبل أن تبدأ في إحداث أي فوضى، يجب أن تعرف كيف يبدو نظامك في حالته الطبيعية والصحية. هذا هو خط الأساس الذي ستقيس عليه كل شيء. يمكن أن تكون هذه المقاييس:
- معدل الأخطاء (Error Rate) أقل من 0.1%.
- زمن استجابة واجهة برمجة التطبيقات (API Latency) أقل من 200 مللي ثانية.
- معدل إتمام الطلبات (Order Throughput) يبلغ 100 طلب في الدقيقة.
بدون فهم واضح للحالة المستقرة، لن تتمكن من معرفة ما إذا كانت تجربتك قد أحدثت تأثيرًا سلبيًا أم لا.
الخطوة الثانية: صياغة الفرضية (Hypothesis)
هنا يبدأ الجزء الممتع. بناءً على فهمك للنظام، ضع فرضية حول ما سيحدث عند إدخال عطل معين. يجب أن تكون الفرضية واضحة وقابلة للقياس.
مثال على فرضية: “إذا قمنا بزيادة استهلاك وحدة المعالجة المركزية (CPU) بنسبة 90% على خوادم خدمة التوصيات (Recommendation Service)، فإن الصفحة الرئيسية للموقع ستستمر في العمل بشكل طبيعي، ولكن قسم ‘المنتجات الموصى بها’ سيختفي أو يعرض رسالة بديلة، دون التأثير على أداء بقية الصفحة.”
الخطوة الثالثة: إجراء التجربة (Injecting Failure)
هذه هي لحظة الحقيقة. حان الوقت لإدخال العطل المُتحكم فيه. من المهم جدًا أن تبدأ صغيرًا وفي بيئة آمنة (مثل بيئة الاختبار أو الـ Staging) وأن يكون تأثير التجربة محدودًا قدر الإمكان (Blast Radius).
هناك أنواع عديدة من الأعطال التي يمكنك محاكاتها:
- فشل الموارد: استهلاك عالٍ للـ CPU أو الذاكرة، امتلاء القرص الصلب.
- فشل الشبكة: زيادة زمن الاستجابة (Latency)، فقدان الحزم (Packet Loss)، أو قطع الاتصال بين خدمتين.
- فشل الخدمات: إيقاف حاوية (Container)، أو جهاز افتراضي (VM)، أو عملية (Process) بشكل مفاجئ.
نصيحة أبو عمر: ابدأ دائمًا بأقل التجارب تدميرًا وأكثرها قابلية للعكس. على سبيل المثال، زيادة زمن الاستجابة أسهل في التحكم والتراجع عنها من حذف قاعدة بيانات! ودائماً جهّز “زر إيقاف” طارئ للتجربة.
مثال عملي بسيط: محاكاة استهلاك CPU
لو كان لديك خدمة تعمل داخل حاوية Docker، يمكنك بسهولة محاكاة ضغط على الـ CPU باستخدام أداة مثل `stress-ng`.
# قم بتثبيت الأداة داخل الحاوية (مثال على Debian/Ubuntu)
# apt-get update && apt-get install -y stress-ng
# قم بتشغيل التجربة لزيادة استهلاك نواة واحدة من الـ CPU بنسبة 100% لمدة 60 ثانية
stress-ng --cpu 1 --cpu-load 100 --timeout 60s
أثناء تشغيل هذا الأمر، راقب لوحات المراقبة (Dashboards) الخاصة بك. هل ارتفعت أزمنة الاستجابة؟ هل ظهرت أخطاء جديدة؟ هل تصرف النظام كما توقعت في فرضيتك؟
الخطوة الرابعة: القياس والتحقق
بمجرد انتهاء التجربة، قارن حالة النظام أثناء التجربة وبعدها مع “الحالة المستقرة” التي حددتها في البداية. هل فرضيتك كانت صحيحة؟
- إذا كانت صحيحة: ممتاز! لقد أثبتت أن نظامك مرن (Resilient) تجاه هذا النوع من الفشل. وثّق النتيجة وانتقل إلى فرضية أخرى.
- إذا كانت خاطئة: هذا أفضل! لقد كشفت عن نقطة ضعف حقيقية في نظامك. هذا ليس فشلاً، بل هو انتصار. الآن لديك فرصة لإصلاح هذه المشكلة قبل أن تؤثر على عملائك.
الخطوة الخامسة: الإصلاح والتكرار
بعد اكتشاف نقطة ضعف، يأتي دور فريق التطوير لإصلاحها. قد يكون الإصلاح بسيطًا مثل زيادة مهلة (timeout)، أو معقدًا مثل إضافة آلية “قاطع الدائرة” (Circuit Breaker). بعد الإصلاح، أعد تشغيل نفس التجربة لتتأكد من أن المشكلة قد حُلّت بالفعل. ثم انتقل إلى التجربة التالية. إنها دورة مستمرة من التحسين.
أدوات ستساعدك في رحلتك
لست بحاجة لإعادة اختراع العجلة. هناك العديد من الأدوات الرائعة، مفتوحة المصدر وتجارية، التي يمكن أن تساعدك في تطبيق هندسة الفوضى:
- Chaos Monkey: الأداة الكلاسيكية من Netflix التي بدأت كل هذا. تقوم بإنهاء الأجهزة الافتراضية بشكل عشوائي.
- Gremlin: منصة تجارية قوية وسهلة الاستخدام توفر مجموعة واسعة من الهجمات “الفوضوية” مع واجهة رسومية.
- LitmusChaos: مشروع مفتوح المصدر من CNCF، مصمم خصيصًا لبيئات Kubernetes.
- AWS Fault Injection Simulator (FIS): خدمة مدمجة في AWS تسمح لك بإجراء تجارب الفوضى على مواردك السحابية.
نصيحة أبو عمر: لا تركز على الأداة بقدر تركيزك على المنهجية. يمكنك أن تبدأ بأبسط الأدوات، حتى لو كانت مجرد سكربتات بسيطة تكتبها بنفسك. المهم هو بناء ثقافة التجريب والتعلم من الفشل.
الخلاصة: الزبدة من كل هالحكي 💡
بعد تلك الليلة الكارثية، لم نعد نخاف من الأعطال. على العكس، أصبحنا نبحث عنها بأنفسنا، ولكن بشروطنا نحن. هندسة الفوضى حولت علاقتنا بالفشل من الخوف والذعر إلى الفضول والتعلم. أنظمتنا لم تعد هشة كالزجاج، بل أصبحت مرنة كالعجين الذي كلما ضغطت عليه، عاد أقوى.
نصيحتي الأخيرة لك: لا تخف من كسر الأشياء، طالما أنك تفعل ذلك بهدف التعلم والتحسين. ابدأ صغيرًا، كن منهجيًا، واحتفل بكل نقطة ضعف تكتشفها، لأن كل اكتشاف هو خطوة نحو بناء نظام لا يقهر. صدقني، ستنام بشكل أفضل في الليل. 😉
