الخلاصة

  • نُشر التحديث الجوهري للسجل qcvjkzcs7j74 في 11 أغسطس، بينما وقع التأثير التشغيلي من 15:05 بالتوقيت العالمي يوم 6 أغسطس إلى 00:14 يوم 7 أغسطس.
  • تقول GitHub إن 71% من عمليات workflow تعرضت في الذروة لأعطال بنية تحتية، وإن 75% من العمليات المتبقية تأخرت أكثر من خمس دقائق.
  • أدى استبدال وحدات pod أثناء نشر روتيني إلى كشف ضعف سابق في السعة والتزامن، ثم تشبعت الخدمات وامتد الأثر عبر عدة عناقيد وخدمات تابعة.
  • بدأت الاستعادة بإضافة سعة وتقليل العمل الداخل عبر webhook وزيادة قدرة معالجة التراكم.
  • كشف ذلك خللاً يجعل وحدات runner تعيد طلب مهام غير صالحة، فيما احتاج بعض ARC runner إلى استعادة يدوية وتعذر تشغيل بعض أحداث push وpull request تلقائياً.
  • التحسينات المعلنة في الحماية والمراقبة والطوابير والاستعادة التلقائية ما زالت التزامات مستقبلية وليست نتيجة مثبتة.

البداية كانت في هامش السعة لا في قفزة طلب استثنائية

الخدمة الداخلية المتأثرة تعالج الأحداث وتحولها إلى مهام Actions. عند استبدال وحدات pod خلال النشر، لم تستطع السعة الباقية حمل الطلب، فحدث تشبع وانهيار وانتقال للأثر إلى عناقيد وخدمات أخرى.

هذا يعني أن هامش الأمان يجب أن يغطي فترة التغيير نفسها، لا ذروة الاستخدام المعتادة فقط. السعة المؤقتة الخارجة من الخدمة والتراكم الجديد يستهلكان المورد نفسه.

النسبتان لا تستخدمان المقام نفسه

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

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

توسيع السعة لم يصلح حالة المهمة

رفعت GitHub السعة، وخفّضت مؤقتاً تدفق الأعمال المحفزة عبر webhook، وزادت معالجة التراكم. بعد ذلك ظهر خلل كامن في الإسناد: كانت وحدات runner تتلقى مهام لم تعد صالحة وتكرر محاولة الحصول عليها بدلاً من التقاط عمل صحيح.

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

بقيت آثار تتطلب تدخلاً من العميل

أثرت إحدى وسائل التخفيف في بعض وحدات Actions Runner Controller، فظلت عالقة إلى أن استعيدت يدوياً. كما لم تُعالج بعض محفزات push وpull request، ولم يكن من الممكن إعادة تشغيلها تلقائياً.

لذلك كان على الفرق مراجعة مستودعاتها وتحديد ما إذا كانت تحتاج إلى إعادة الحدث أو تشغيل workflow يدوياً أو إصلاح runner. عودة المنصة لا تنجز هذه المطابقة.

11 أغسطس تاريخ للتفسير لا للانقطاع

انتهى العطل في 7 أغسطس. أما 11 أغسطس فهو تاريخ نشر السبب والأرقام وإجراءات الاستعادة. التعامل معه كعطل جديد سيضخم المدة ويخلط بين ساعة التشغيل وساعة الشفافية.

الفصل بينهما يتيح قياس زمن الإصلاح وزمن تقديم التفسير العام بصورة مستقلة.

وعود المنع تحتاج إلى دليل تنفيذ

تقول GitHub إنها ستحسن حواجز النشر والسعة، ورصد الظروف السابقة للعطل، ومرونة الطوابير وإسناد runner، واحتواء الانتشار، والاستعادة التلقائية. هذه البنود تتبع سلسلة الفشل المنشورة.

لكن السجل لا يحدد ما نُشر فعلاً أو حد السعة أو مقياس النجاح. إصدار قادم من Runner وARC ونتائج اختباره سيكونان دليلاً أقوى.

سجل العميل هو خطوة الإغلاق الأخيرة

يمكن للمؤسسة الاحتفاظ بالمحفزات المتوقعة ومعرفات التشغيل والحالات النهائية والمخرجات. بهذه الطريقة تكشف العملية المفقودة وتتجنب تكرار عملية ربما اكتملت بعد تأخر.

حالة GitHub تثبت إمكانية بدء العمل الآن، بينما تثبت المطابقة المحلية أن كل عمل متوقع خلال نافذة العطل حصل على نهاية موثوقة.

المصادر