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

ليلة لا تُنسى: عندما انهار كل شيء بسبب خدمة “تافهة”

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

وفجأة، حوالي الساعة 11 بالليل، بدأت التنبيهات تنهال علينا زي المطر. “Checkout service is down!”، “Payment gateway timeout!”. الموقع شبه توقف عن العمل. الكارثة إنه كل الخدمات الأساسية كانت تبدو سليمة على لوحات المراقبة (Dashboards). شو القصة؟ حالة من الهلع سادت الفريق، والكل صار يركض في كل اتجاه يدور على سبب المشكلة.

بعد ساعة من البحث المحموم في السجلات (Logs) والـ Traces، اكتشفنا المصيبة. خدمة صغيرة، كنا نعتبرها “غير مهمة”، مسؤولة عن عرض “المنتجات الموصى بها” في صفحة الدفع، دخلت في حلقة لا نهائية (infinite loop) بسبب بيانات فاسدة. هذه الخدمة الصغيرة، اللي المفروض لو تعطلت ما تأثر على شيء، سببت تزايد في استهلاك الموارد على الشبكة الداخلية، مما أدى إلى اختناق (bottleneck) منع خدمة الدفع الأساسية من الوصول لقاعدة البيانات. ببساطة، عطل تافه في مكان غير متوقع تسبب في انهيار متسلسل (cascading failure) شلّ النظام بأكمله.

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

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

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

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

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

المبادئ الأساسية اللي بنمشي عليها

هندسة الفوضى مش فوضوية، بل بتتبع منهجية علمية واضحة:

• بناء فرضية حول الحالة المستقرة (Steady State): أولاً، لازم نعرّف شو يعني “النظام شغال تمام”. هل هو عدد الطلبات في الثانية؟ هل هو زمن الاستجابة أقل من 200ms؟ هل نسبة الأخطاء أقل من 0.1%؟ هذا هو مقياسنا للنجاح.
• افتراض ما سيحدث (Hypothesize): بنحط فرضية. مثلاً: “نعتقد أنه إذا توقفت خدمة التخزين المؤقت (Caching Service)، فإن زمن تحميل الصفحة سيزداد بنسبة 30%، لكن الموقع سيبقى يعمل بشكل كامل لأن النظام سيلجأ إلى قاعدة البيانات مباشرة”.
• إدخال متغيرات من العالم الحقيقي (Introduce Real-World Variables): هنا تبدأ المتعة. نقوم بمحاكاة أعطال حقيقية:
  • فشل خادم (Server Failure).
  • ارتفاع مفاجئ في استهلاك المعالج (CPU Spike).
  • تأخير في الشبكة (Network Latency).
  • فشل إحدى قواعد البيانات التابعة (Database Replica Failure).
• محاولة دحض الفرضية (Try to Disprove the Hypothesis): نقوم بتشغيل التجربة ونراقب. هل حدث ما توقعناه؟ في كثير من الأحيان، الجواب هو “لا”. قد نكتشف أن النظام انهار بالكامل، أو أن خدمة أخرى غير متوقعة تأثرت. وهذا هو الكنز الحقيقي! اكتشاف هذه المشاكل هو الهدف.
• تقليل نصف قطر الانفجار (Minimize the Blast Radius): هذه أهم نصيحة. لا تبدأ تجربتك على كل المستخدمين! ابدأ بأصغر نطاق ممكن: خادم واحد، نسبة قليلة من المستخدمين، أو حتى على بيئة الاختبارات (Staging) التي تشبه بيئة الإنتاج قدر الإمكان. ثم توسع تدريجياً.

كيف نبدأ؟ خارطة طريق عملية من مطبخ أبو عمر

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

الخطوة الأولى: ابدأ صغيراً جداً وفي بيئة آمنة

لا تقفز مباشرة إلى بيئة الإنتاج. ابدأ بتنظيم ما يسمى بـ “يوم اللعب” (GameDay). اجمع الفريق، واختر بيئة الاختبارات (Staging)، وابدأوا بطرح الأسئلة: “ماذا لو…؟”

• ماذا لو أوقفنا هذا السيرفر يدوياً؟
• ماذا لو قمنا بحظر الاتصال بقاعدة البيانات من إحدى الخدمات؟

هذه التمارين اليدوية تبني ثقافة الوعي بالمرونة (Resilience) وتجعل الفريق يفكر بطريقة مختلفة.

الخطوة الثانية: حدد خدماتك الحرجة وابدأ بها

مش كل الخدمات بنفس الأهمية. ركز على العمليات الأساسية في نظامك: نظام المصادقة (Authentication)، بوابات الدفع (Payment Gateways)، سلة المشتريات (Shopping Cart). هذه هي الأماكن التي إذا فشلت، يعني فشل البزنس كله. ابدأ تجاربك هنا (طبعاً مع تقليل نصف قطر الانفجار لأقصى درجة).

الخطوة الثالثة: اختر أدواتك (أسلحتك في المعركة)

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

• Chaos Monkey: الأداة الكلاسيكية من نتفليكس التي تقوم بإيقاف السيرفرات بشكل عشوائي.
• Gremlin: منصة تجارية قوية توفر واجهة سهلة لتصميم وتنفيذ هجمات فوضوية متنوعة.
• LitmusChaos: مشروع مفتوح المصدر قوي ومخصص لبيئات Kubernetes.

لكن مش دايماً بتحتاج أداة معقدة. أحياناً، سكربت بسيط يمكن أن يؤدي الغرض في البداية.

مثال عملي: سكربت بسيط لمحاكاة ضغط على المعالج (CPU)

لنفترض أنك تريد أن ترى كيف يتصرف نظامك عندما يكون أحد السيرفرات تحت ضغط معالج عالٍ. يمكنك استخدام سكربت `bash` بسيط على سيرفر لينكس (في بيئة الاختبار طبعاً!).

# هذا السكربت سيقوم بتشغيل عملية تستهلك 100% من نواة معالج واحدة
# تحذير: لا تشغل هذا على بيئة إنتاج حقيقية دون تخطيط مسبق!

echo "Starting CPU stress test for 60 seconds..."

# استخدم أداة 'stress' أو حلقة لا نهائية بسيطة
# إذا لم تكن أداة stress مثبتة، يمكنك استخدام: sudo apt-get install stress

stress --cpu 1 --timeout 60s

# أو بطريقة يدوية أكثر
# end=$((SECONDS+60))
# while [ $SECONDS -lt $end ]; do
#   :
# done &

echo "CPU stress test finished."

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

الخطوة الرابعة: الأتمتة والدمج في الـ CI/CD

هذه هي المرحلة المتقدمة. بعد أن تصبح مرتاحاً مع التجارب اليدوية، يمكنك دمج تجارب الفوضى كجزء من مسار النشر والتكامل المستمر (CI/CD Pipeline). على سبيل المثال، بعد كل عملية نشر ناجحة على بيئة الـ Staging، يمكن تشغيل سكربت فوضى تلقائي للتأكد من أن التغيير الجديد لم يُدخل نقطة ضعف جديدة.

النتيجة: من إطفاء الحرائق إلى الوقاية منها

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

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

خلاصة أبو عمر ونصيحة من القلب 💡

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

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