هندسة الفوضى والمرونة

أيام اللعب (Game Days)

18 دقيقة الدرس 7 من 27

أيام اللعب (Game Days)

يوم اللعب هو حدث منظم ومحدد بوقت، تقوم فيه فرقة هندسية بتعمد إدخال أعطال على نظام في بيئة خاضعة للسيطرة، بهدف اختبار ما إذا كانت الأنظمة والدلائل الإجرائية والأفراد يستجيبون على النحو المتوقع. المصطلح مستعار من كرة القدم الأمريكية — تنتهي أسبوع التدريب ثم تلعب في الظروف الحقيقية. في أمازون، كانت أيام اللعب (المعروفة بـ "fire drills") راسخة قبل وجود AWS. في جوجل، يقابلها تمرين DiRT (اختبار التعافي من الكوارث) الذي يُجرى سنويًا على مستوى البنية التحتية. في نتفليكس، تطور من أيام الفوضى ربع السنوية إلى خط أنابيب Chaos Monkey المستمر. في كل مؤسسة تنفذها جيدًا، تفعل أيام اللعب شيئًا لا تستطيع أدوات الفوضى الآلية وحدها فعله: اختبار النظام الاجتماعي-التقني بأكمله — وليس البرنامج وحده.

أيام اللعب تختبر الناس والعمليات، وليس البرنامج فقط. أدوات الفوضى الآلية (Chaos Monkey، Gremlin، Litmus) قادرة على حقن الأعطال على مدار الساعة. لكنها لا تستطيع الكشف عن أن المهندس المناوب لا يعرف أين يوجد الدليل الإجرائي، أو أن خط الحوادث يتطلب رقم سري لا أحد يملكه، أو أن افتراضات نطاق الضرر كانت خاطئة بسبب اعتماد غير موثق. تكشف أيام اللعب عن هذه الثغرات قبل أن تفعلها حوادث حقيقية.

المراحل الأربعة ليوم اللعب المُدار بشكل جيد

المرحلة الأولى: التخطيط (أسبوع إلى أسبوعين قبل)

ابدأ بفرضية وليس بسيناريو جاهز. تتبع الفرضية تنسيق هندسة الفوضى: "نؤمن بأنه إذا حدث الشرط X، فإن النظام Y سيستجيب بـ السلوك Z، وسيقتصر تأثير العملاء على الحد W." الهدف الغامض ("لنرَ ماذا يتعطل") ينتج تعلمًا غامضًا. الفرضية الحادة تنتج حكمًا بنجاح أو فشل وإجراء واضحًا.

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

حدد النطاق:

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

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

المرحلة الثانية: التجريب المبدئي

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

المرحلة الثالثة: التنفيذ

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

احقن الخطأ. يعلن مشغل الفوضى عن كل إجراء على قناة الحوادث في الوقت الفعلي: "حقن تأخر 500 ميلي ثانية على جميع الاستدعاءات من order-service إلى inventory-service — بدءًا الآن." يسجل المراقب هذا بطابع زمني في السجل الجاري.

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

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

المرحلة الرابعة: المراجعة اللاحقة (نفس اليوم أو اليوم التالي)

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

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

تنسيق يوم لعب متعدد الفرق

يوم لعب لخدمة واحدة أمر بسيط. أما يوم لعب متعدد الفرق — يحاكي انقطاع منطقة يؤثر على خمس خدمات تمتلكها أربع فرق — فيتطلب بنية تنسيق إضافية.

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

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

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

تصميم سيناريوهات يوم اللعب

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

  • تأخر اعتمادية واحدة — حقن تأخر p99 بمقدار 2 ثانية على استدعاء واحد وراقب ما إذا كانت قواطع الدارة تفصل والبدائل تعمل.
  • فقدان انتخاب القائد — اقتل الأساسي في نظام مكرر وقِس وقت التعافي الفعلي مقابل ميزانية SLO.
  • ضغط الذاكرة — حقن عملية نهمة للذاكرة على عقدة وراقب ما إذا كانت توقفات GC تسبب انهيارات مهلة انتظار.
  • محاكاة انتهاء صلاحية الشهادة — دوّر شهادة لشهادة منتهية في التجهيز وتحقق من أن mTLS يفشل بأمان.
  • اختبار دقة الدليل الإجرائي — أعطِ مهندسًا جديدًا الدليل الإجرائي لفئة إخفاق معروفة وراقبه يتبعه. إذا توقف، الدليل ناقص.
Game Day Execution Timeline Game Day Execution Timeline T-0 Steady-state baseline screenshot dashboards T+5 min Fault injected operator announces T+8 min Alert fires / pager MTTD measured here T+14 min Mitigation applied MTTM measured here T+25 min Fault removed steady-state restored SLO breach window: 20 min observed vs 15 min target — gap to fix Halt condition: error rate > 5% sustained 60 s — any participant triggers all-stop signal
الجدول الزمني لتنفيذ يوم اللعب: لقطة الحالة المستقرة، حقن الخطأ، فجوة اكتشاف التنبيه (MTTD)، تخفيف المستجيب (MTTM)، والتعافي. نافذة خرق SLO تكشف فجوة مقابل وقت الاسترداد المستهدف.

قياس فعالية يوم اللعب

تتبع هذه المقاييس عبر أيام اللعب لإظهار النضج مع مرور الوقت:

  • متوسط وقت الاكتشاف (MTTD) — كم من الوقت من حقن الخطأ حتى إطلاق أول تنبيه. نوافذ تنبيه SLO الخاصة بك تحدد الهدف.
  • متوسط وقت التخفيف (MTTM) — كم من الوقت من التنبيه حتى احتواء الخطأ. قارن مع معدل استهلاك ميزانية الخطأ.
  • دقة الفرضية — هل تصرف النظام كما تنبأت؟ إذا كانت فرضيتك صحيحة دائمًا، فسيناريوهاتك ليست جديدة بما يكفي. معدل دقة 70-80% صحي.
  • معدل إغلاق بنود الإجراءات — ما نسبة بنود الإجراءات من يوم اللعب الأخير التي أُنجزت قبل اليوم التالي؟ أقل من 80% يشير إلى إخفاق في العملية.
# فحوصات PromQL لأيام اللعب: قبل وبعد حقن الخطأ # 1. تأكيد الحالة المستقرة: الخط الأساسي لمعدل الخطأ (قبل الحقن) sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) # 2. مراقبة تأخر p99 في الوقت الفعلي خلال نافذة الخطأ histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[1m])) by (le, service) ) # 3. حالة قاطع الدارة (مقاييس resilience4j عبر Micrometer) resilience4j_circuitbreaker_state{state="open"} # 4. إرسال تعليق Grafana لتثبيت نافذة الخطأ على جميع لوحات التحكم curl -s -X POST http://grafana:3000/api/annotations \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $GRAFANA_SA_TOKEN" \ -d '{ "time": '"$(date +%s%3N)"', "text": "Game day fault injected: db-latency 2s on order-service", "tags": ["gameday", "chaos", "fault-inject"] }' # 5. بعد إزالة الخطأ: راقب معدل الخطأ يعود للخط الأساسي (كل 15 ث) watch -n15 'curl -sg "http://prometheus:9090/api/v1/query" \ --data-urlencode \ "query=sum(rate(http_requests_total{status=~\"5..\"}[2m]))/sum(rate(http_requests_total[2m]))" \ | jq .data.result'

التعلم دون كسر العملاء

التوتر المحوري في أيام اللعب الإنتاجية هو الدقة مقابل السلامة. إليك الأساليب التي تستخدمها الصناعة لتعظيم كليهما:

  • ابدأ في التجهيز ثم انتقل إلى الإنتاج. نفذ التكرارات الثلاث الأولى لأي نوع سيناريو جديد في التجهيز. انتقل إلى الإنتاج فقط بعد التأكد من أن التجربة تتصرف كما صُممت وأن إجراء التراجع يعمل بشكل موثوق.
  • استخدم أعلام الميزات للحد من نطاق الضرر. إذا كانت منصتك تدعم أعلام ميزات لكل مستخدم أو مجموعة، احقن الأخطاء فقط للمستخدمين الداخليين أولًا.
  • أتمت التراجع وليس فقط التقدم. يجب أن يكون لكل سكريبت حقن خطأ سكريبت تفكيك مرافق. مشغل الفوضى يُشغّل التفكيك إذا تحقق شرط الإيقاف.
  • تتبع استهلاك ميزانية الخطأ. قبل كل يوم لعب، احسب كم دقيقة من خرق SLO تبقت في ميزانيتك الشهرية. إذا كنت عند 80% مستهلك، أجّل يوم اللعب.
أيام اللعب الأكثر قيمة هي تلك التي تكون فيها الفرضية خاطئة. إذا كان قاطع الدارة الذي ظننت أنه سيفصل في 30 ثانية يستغرق في الواقع 4 دقائق، فقد اكتشفت للتو خطرًا إنتاجيًا حقيقيًا في ظروف خاضعة للسيطرة — وهذا بالضبط هو الهدف.