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

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

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

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

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

هندسة الفوضى هي التخصص الذي يعنى بإجراء تجارب على نظام موزع (Distributed System) بهدف بناء الثقة في قدرة النظام على تحمل الظروف المضطربة وغير المتوقعة في بيئة الإنتاج.

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

من “يا رب ما يخرب” إلى “احنا جاهزين”

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

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

مبادئ هندسة الفوضى الأساسية

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

1. بناء فرضية حول الحالة المستقرة (Define ‘Steady State’)

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

• معدل الأخطاء (Error Rate) أقل من 0.1%.
• زمن الاستجابة (Response Time) للصفحة الرئيسية أقل من 200ms.
• عدد الطلبات في الثانية (Throughput) ضمن نطاق معين.

هذه هي قاعدتنا التي سنقيس عليها تأثير تجربتنا.

2. طرح فرضيات (Hypothesize)

هنا يبدأ الجزء الممتع. نسأل أنفسنا “ماذا لو؟”. الفرضية يجب أن تكون واضحة وقابلة للقياس. على سبيل المثال:

“الفرضية: إذا قمنا بإيقاف إحدى نسخ (instances) خدمة الدفع، فإن موازن الأحمال (Load Balancer) سيعيد توجيه الزيارات تلقائياً إلى النسخ السليمة خلال 5 ثوانٍ، ولن تتأثر الحالة المستقرة (معدل نجاح عمليات الدفع) بشكل ملحوظ.”

الآن لدينا شيء واضح نريد إثباته أو دحضه.

3. إحداث أعطال حقيقية (Introduce Real-World Failures)

يجب أن تحاكي التجربة ظروفاً حقيقية قدر الإمكان. لا تكتفِ بمجرد محاكاة نظرية. بعض الأمثلة على الأعطال التي يمكنك إحداثها:

• فشل الخوادم: إيقاف مفاجئ لسيرفر أو حاوية (Container).
• مشاكل الشبكة: إضافة تأخير (latency)، فقدان حزم البيانات (packet loss)، أو قطع الاتصال بين الخدمات.
• استهلاك الموارد: رفع استهلاك المعالج (CPU) أو الذاكرة (RAM) إلى 100%.
• فشل الخدمات الخارجية: محاكاة أن خدمة طرف ثالث (Third-party API) أصبحت لا تستجيب.

4. محاولة دحض الفرضية (Try to Disprove the Hypothesis)

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

5. تقليل نصف قطر الانفجار (Minimize the ‘Blast Radius’)

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

• استهداف نسبة صغيرة جداً من الزيارات (e.g., 1% of traffic).
• التجربة على خادم واحد فقط من بين العشرات.
• التجربة على خدمات غير حرجة (non-critical).
• وجود “زر إيقاف” كبير وواضح لإلغاء التجربة فوراً إذا خرجت الأمور عن السيطرة.

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

حسناً يا أبو عمر، كلام جميل، بس من وين نبدأ؟ الموضوع أبسط مما تتخيل.

الخطوة الأولى: ابدأ صغيراً وفي بيئة الاختبار

لا تقفز مباشرة إلى بيئة الإنتاج. ابدأ ببيئة الاختبارات (Staging) التي تشبه بيئة الإنتاج قدر الإمكان. قم بأول تجاربك هناك لتتعلم وتفهم سلوك النظام بدون أي مخاطرة.

الخطوة الثانية: حددوا أول تجربة (GameDay)

اجمع الفريق في جلسة تسمى “GameDay”. الهدف هو إجراء تجربة فوضى واحدة ومحددة. على سبيل المثال:

1. الهدف: اختبار آلية التعافي التلقائي لخدمة “توصيات المنتجات”.
2. الفرضية: إذا أوقفنا حاوية خدمة التوصيات، ستعرض الواجهة الأمامية قسماً بديلاً ثابتاً بدون أن تنهار الصفحة.
3. التنفيذ: يقوم أحد أعضاء الفريق بتنفيذ أمر docker stop [container_id] أو kubectl delete pod [pod_name].
4. المراقبة: يراقب باقي الفريق لوحات المراقبة (Dashboards) وسجلات الأخطاء (Logs) وسلوك الواجهة الأمامية.
5. النتيجة: هل تحققت الفرضية؟ وثّقوا النتائج، سواء كانت ناجحة أم فاشلة، وخططوا للتحسينات.

الخطوة الثالثة: اختاروا أدواتكم يا جماعة

يمكنك أن تبدأ بأدوات بسيطة جداً، حتى لو كانت مجرد سكربتات. مع الوقت، يمكنك الانتقال إلى أدوات أكثر تخصصاً.

• أدوات مفتوحة المصدر: Chaos Toolkit, Litmus, Chaos Mesh هي خيارات ممتازة.
• الخدمات السحابية: معظم مزودي الخدمات السحابية الكبار يقدمون الآن خدمات خاصة بهندسة الفوضى، مثل AWS Fault Injection Simulator (FIS) و Azure Chaos Studio.
• أمثلة بسيطة: يمكنك محاكاة حمل عالٍ على المعالج باستخدام سكربت بسيط.

# تحذير: هذا السكريبت سيستهلك كل موارد المعالج على جهازك
# لا تشغله على بيئة الإنتاج إلا ضمن تجربة محكومة جداً
# الهدف منه هو رؤية كيف يتصرف نظام المراقبة والتنبيهات لديك

echo "محاكاة حمل عالٍ على المعالج... اضغط Ctrl+C للإيقاف"

# احصل على عدد أنوية المعالج
cores=$(nproc)

# أنشئ عملية تستهلك المعالج لكل نواة
for i in $(seq 1 $cores); do
  while : ; do : ; done &
done

# احتفظ بمعرفات العمليات لإيقافها لاحقاً
pids=$(jobs -p)
trap "kill $pids" SIGINT SIGTERM

echo "العمليات بدأت بالمعرفات: $pids"
echo "انتظر حتى ترى التنبيهات، ثم اضغط Ctrl+C لإنهاء التجربة."

# انتظر حتى يتم إيقاف السكريبت
wait

هذا السكريبت البسيط يمكن أن يكون أول “تجربة فوضى” لك. هل تلقيت تنبيهاً بأن استهلاك المعالج 100%؟ هل آليات التوسع التلقائي (Auto-scaling) اشتغلت؟ هذه هي الأسئلة التي تبدأ بها رحلتك.

نصائح أبو عمر الذهبية 💡

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

الخلاصة: من الفوضى إلى الثقة بالنفس 🚀

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

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