أيام اللعب (Game Days)
أيام اللعب (Game Days)
يوم اللعب هو حدث منظم ومحدد بوقت، تقوم فيه فرقة هندسية بتعمد إدخال أعطال على نظام في بيئة خاضعة للسيطرة، بهدف اختبار ما إذا كانت الأنظمة والدلائل الإجرائية والأفراد يستجيبون على النحو المتوقع. المصطلح مستعار من كرة القدم الأمريكية — تنتهي أسبوع التدريب ثم تلعب في الظروف الحقيقية. في أمازون، كانت أيام اللعب (المعروفة بـ "fire drills") راسخة قبل وجود AWS. في جوجل، يقابلها تمرين DiRT (اختبار التعافي من الكوارث) الذي يُجرى سنويًا على مستوى البنية التحتية. في نتفليكس، تطور من أيام الفوضى ربع السنوية إلى خط أنابيب Chaos Monkey المستمر. في كل مؤسسة تنفذها جيدًا، تفعل أيام اللعب شيئًا لا تستطيع أدوات الفوضى الآلية وحدها فعله: اختبار النظام الاجتماعي-التقني بأكمله — وليس البرنامج وحده.
المراحل الأربعة ليوم اللعب المُدار بشكل جيد
المرحلة الأولى: التخطيط (أسبوع إلى أسبوعين قبل)
ابدأ بفرضية وليس بسيناريو جاهز. تتبع الفرضية تنسيق هندسة الفوضى: "نؤمن بأنه إذا حدث الشرط X، فإن النظام Y سيستجيب بـ السلوك Z، وسيقتصر تأثير العملاء على الحد W." الهدف الغامض ("لنرَ ماذا يتعطل") ينتج تعلمًا غامضًا. الفرضية الحادة تنتج حكمًا بنجاح أو فشل وإجراء واضحًا.
حدد نطاق الضرر قبل أن تلمس أي شيء. حدد الخدمات وقواعد البيانات وشرائح المستخدمين التي قد تتأثر. لكل منها، حدد إجراء التراجع وشرط الإيقاف — الإشارة الملاحظة التي تخبرك بإيقاف التجربة فورًا. بدون شرط الإيقاف مكتوبًا مسبقًا، ستتردد في الإيقاف حين يجب، وهذا التردد يكلف العملاء.
حدد النطاق:
- يوم لعب إنتاجي — أعلى دقة وأعلى خطورة. مناسب للفرق الناضجة التي تمتلك رقابة قوية وأتمتة تراجع. اختر نافذة زمنية منخفضة الحركة (مثل الثلاثاء الساعة 10 صباحًا).
- يوم لعب على بيئة التجهيز — آمن لكن دقته منخفضة. مناسب للفرق الجديدة أو أنماط الأعطال الجديدة.
- يوم لعب بحركة مرور ظلية — حقن الأعطال فقط على نسخة من الحركة المرورية. ممتاز للتحقق دون أي مخاطرة بالعملاء، لكنه يتطلب بنية تحتية ظلية.
خصص الأدوار صراحةً قبل اليوم: مشغل الفوضى (يحقن العطل)، قائد الحوادث (يقود الاستجابة، نفس دوره في الحوادث الحقيقية)، المراقب/الكاتب (يوثق الجدول الزمني والقرارات — شخص مختلف عن المستجيبين)، وربما محامي العميل الذي يراقب لوحات تحكم SLO الخارجية.
المرحلة الثانية: التجريب المبدئي
قبل أسبوع من يوم اللعب، نفذ حقن الخطأ في بيئة التجهيز مع نفس الفريق والجدول الزمني. هذا يكشف أخطاء التكوين (الكتلة المستهدفة الخاطئة، نوع الخطأ الخاطئ)، يتحقق من إطلاق مراقبتك للتنبيهات المتوقعة، ويؤكد أن إجراء التراجع يعمل فعلًا.
المرحلة الثالثة: التنفيذ
ابدأ بـ التحقق من الحالة المستقرة: تأكد أن جميع SLOs خضراء، ومعدلات الأخطاء في الخط الأساسي، ولوحات التحكم محملة بشكل صحيح قبل لمس أي شيء. هذا هو الخط الأساسي قبل الخطأ — التقط له صورة.
احقن الخطأ. يعلن مشغل الفوضى عن كل إجراء على قناة الحوادث في الوقت الفعلي: "حقن تأخر 500 ميلي ثانية على جميع الاستدعاءات من order-service إلى inventory-service — بدءًا الآن." يسجل المراقب هذا بطابع زمني في السجل الجاري.
دع الفريق يستجيب بالضبط كما يفعل في حادثة حقيقية. لا توجه، لا تلمح، لا تتدخل إلا إذا تحقق شرط الإيقاف. للمحاكاة قيمة صفرية إذا أنقذت المستجيبين — الهدف هو الكشف عن الثغرات بينما المخاطر اصطناعية.
المرحلة الرابعة: المراجعة اللاحقة (نفس اليوم أو اليوم التالي)
المراجعة اللاحقة هي مكان التعلم. استخدم نفس تنسيق تحليل الأسباب الجذرية غير الإلزامي المستخدم في الحوادث الحقيقية. اعمل من جدول المراقب الزمني. لكل نقطة قرار، اسأل: "ما المعلومات التي امتلكها المستجيب؟ ماذا قرر؟ ما الذي كان سيجعل هذا القرار أسرع أو أكثر دقة؟" هذا يكشف عن فجوات التوثيق ولوحات التحكم المفقودة وخطوات الدليل الإجرائي غير الواضحة.
أنتج تقريرًا مكتوبًا بثلاثة أقسام: ما توقعناه (الفرضية)، ما حدث فعلًا (الجدول الزمني)، وبنود الإجراءات مع الأصحاب وتواريخ الاستحقاق. بدون أصحاب وتواريخ، لن تنجز البنود. أدرجها كتذاكر هندسية في نفس دورة السبرينت.
تنسيق يوم لعب متعدد الفرق
يوم لعب لخدمة واحدة أمر بسيط. أما يوم لعب متعدد الفرق — يحاكي انقطاع منطقة يؤثر على خمس خدمات تمتلكها أربع فرق — فيتطلب بنية تنسيق إضافية.
استخدم قناة Slack مخصصة لهذا اليوم فقط، منفصلة عن قنوات الحوادث العادية، حتى يتمكن المراقبون من المشاهدة دون إلغاء تلوث محادثة المستجيبين في الوقت الفعلي. يرسل مشغل الفوضى جميع إجراءات حقن الخطأ والتراجع كرسائل مختومة بالوقت هناك.
اتفقوا على إشارة إيقاف كاملة يمكن لأي مشارك تفعيلها — رمز إيموجي محدد في Slack، أو كلمة مرور على خط الجسر. يجب أن يكون بمقدور أي شخص يرى ضررًا حقيقيًا على العملاء يتشكل أن يوقف التجربة دون تفاوض.
تصميم سيناريوهات يوم اللعب
يجب أن تُستخلص السيناريوهات من تاريخ حوادثك الفعلية بالإضافة إلى أنماط الإخفاق النظرية في رسم بيان الاعتماديات. محفظة بداية جيدة:
- تأخر اعتمادية واحدة — حقن تأخر p99 بمقدار 2 ثانية على استدعاء واحد وراقب ما إذا كانت قواطع الدارة تفصل والبدائل تعمل.
- فقدان انتخاب القائد — اقتل الأساسي في نظام مكرر وقِس وقت التعافي الفعلي مقابل ميزانية SLO.
- ضغط الذاكرة — حقن عملية نهمة للذاكرة على عقدة وراقب ما إذا كانت توقفات GC تسبب انهيارات مهلة انتظار.
- محاكاة انتهاء صلاحية الشهادة — دوّر شهادة لشهادة منتهية في التجهيز وتحقق من أن mTLS يفشل بأمان.
- اختبار دقة الدليل الإجرائي — أعطِ مهندسًا جديدًا الدليل الإجرائي لفئة إخفاق معروفة وراقبه يتبعه. إذا توقف، الدليل ناقص.
قياس فعالية يوم اللعب
تتبع هذه المقاييس عبر أيام اللعب لإظهار النضج مع مرور الوقت:
- متوسط وقت الاكتشاف (MTTD) — كم من الوقت من حقن الخطأ حتى إطلاق أول تنبيه. نوافذ تنبيه SLO الخاصة بك تحدد الهدف.
- متوسط وقت التخفيف (MTTM) — كم من الوقت من التنبيه حتى احتواء الخطأ. قارن مع معدل استهلاك ميزانية الخطأ.
- دقة الفرضية — هل تصرف النظام كما تنبأت؟ إذا كانت فرضيتك صحيحة دائمًا، فسيناريوهاتك ليست جديدة بما يكفي. معدل دقة 70-80% صحي.
- معدل إغلاق بنود الإجراءات — ما نسبة بنود الإجراءات من يوم اللعب الأخير التي أُنجزت قبل اليوم التالي؟ أقل من 80% يشير إلى إخفاق في العملية.
التعلم دون كسر العملاء
التوتر المحوري في أيام اللعب الإنتاجية هو الدقة مقابل السلامة. إليك الأساليب التي تستخدمها الصناعة لتعظيم كليهما:
- ابدأ في التجهيز ثم انتقل إلى الإنتاج. نفذ التكرارات الثلاث الأولى لأي نوع سيناريو جديد في التجهيز. انتقل إلى الإنتاج فقط بعد التأكد من أن التجربة تتصرف كما صُممت وأن إجراء التراجع يعمل بشكل موثوق.
- استخدم أعلام الميزات للحد من نطاق الضرر. إذا كانت منصتك تدعم أعلام ميزات لكل مستخدم أو مجموعة، احقن الأخطاء فقط للمستخدمين الداخليين أولًا.
- أتمت التراجع وليس فقط التقدم. يجب أن يكون لكل سكريبت حقن خطأ سكريبت تفكيك مرافق. مشغل الفوضى يُشغّل التفكيك إذا تحقق شرط الإيقاف.
- تتبع استهلاك ميزانية الخطأ. قبل كل يوم لعب، احسب كم دقيقة من خرق SLO تبقت في ميزانيتك الشهرية. إذا كنت عند 80% مستهلك، أجّل يوم اللعب.