GitHub Actions وPages: ساعات من تراجع التوافر

عمل GitHub Actions بتوافر منخفض خلال معظم يوم 6 أغسطس 2026، إذ فشلت عمليات سير العمل أو بقيت في الانتظار طويلًا في الطوابير، وامتد الأثر إلى GitHub Pages وميزات Copilot وأدوات الترحيل المؤسسية. وثّق صفحة الحالة في GitHub الحادثة من الساعة 15:05 بتوقيت UTC في 6 أغسطس حتى 00:14 UTC من اليوم التالي.

ما الذي تعطّل

بحسب تقرير ما بعد الحادثة، كان السبب نشرًا روتينيًا في خدمة داخلية ضمن Actions مسؤولة عن معالجة الأحداث وإنشاء المهام. كشف النشر ضعفًا قائمًا في السعة والتزامن: فمع استبدال الحاويات (pods) بلغت السعة المتبقية حد التشبع، وانهارت الخدمات، وانتشر العطل بشكل متسلسل على عدة عناقيد وخدمات تابعة. في الذروة، واجه 71 بالمئة من عمليات سير العمل أعطالًا في البنية التحتية، وتأخر 75 بالمئة من العمليات المتبقية أكثر من خمس دقائق. تضرر العملاء الذين يستخدمون مشغّلات GitHub المستضافة وكذلك المشغّلات ذاتية الاستضافة.

علة ثانية وساعات من التقييد

وسّع المهندسون السعة، وقيّدوا العمل الذي تنشئه خطافات الويب كي تتعافى المنظومة، وأضافوا قدرة معالجة للتراكم؛ وعادت الخدمات الأساسية نحو الساعة 17:00 UTC. لكن ظهرت مشكلة ثانية بحلول ذلك الحين: علة كامنة في خدمة إسناد المهام إلى المشغّلات جعلت المشغّلات تتلقى مهامًا لم تعد صالحة وتعلق في إعادة المحاولة. في أدنى نقطة، كانت نحو 30 إلى 40 بالمئة من المهام في الطابور تنجح؛ وبعد نشر الإصلاحات ارتفعت نسبة نجاح سير العمل المبتدئ إلى 97 ثم 99 بالمئة، واستُنزفت الطوابير المتراكمة خلال الليل.

ما بعد الحادثة

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