ملخص

  • فتحت GitHub حادثًا حرجًا في Actions في 19 يوليو الساعة 23:34 UTC. قد تتأخر سير العمل الجديدة أو لا تبدأ، بينما قد تفشل عمليات التنفيذ الجارية.
  • امتد العطل إلى طلبات API وPages وIssues. أشارت GitHub لاحقًا إلى أن وقت تعطل Actions الممتد تسبب في تأثيرات لاحقة، وأدخلت حادثًا منفصلاً لـ Git LFS/API في نفس التحقيق.
  • أبلغت CircleCI عن خطوط أنابيب لم تبدأ أو تعلقت، بينما أبلغت OpenAI عن أخطاء أو تأخيرات في سير عمل البرمجة المعتمدة على GitHub. يؤكد كلا السجلين بشكل مستقل أن الخطأ تجاوز حدود الشركة.
  • ذكرت GitHub أنها حددت السبب، واستعادت Actions بحلول الساعة 04:43 UTC، وأغلقت الحادث بعد دقيقة واحدة. وعدت بتحليل تفصيلي للسبب الجذري، لكنها لم تنشره بعد وقت إغلاق التحرير.

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

أبلغت GitHub عن تدهور أداء Actions في الساعة 23:34 UTC يوم 19 يوليو. في غضون دقائق، حذرت من أن سير العمل الجديدة قد تتأخر أو لا تبدأ، وأن عمليات التنفيذ الجارية قد تفشل. في الساعة 23:57، ذكرت الشركة أنها حددت السبب وتعمل على استعادة الخدمة، دون وصف هذا السبب.

ثم تجاوز الحادث حدود أسطول Runner. دخلت طلبات API في عطل جزئي في الساعة 00:07 UTC. تدهورت Pages وIssues. سجل ثانٍ أبلغ عن أخطاء في بعض عمليات Git LFS وعند تحميل الملفات عبر API. في الساعة 01:11، قدمت GitHub الرابط السببي: بدأ وقت تعطل Actions الممتد في إحداث تأثيرات لاحقة في الخدمات الأخرى، وكان حادث منفصل مرتبطًا.

هذا البيان يحول مجموعة من أضواء الحالة الحمراء إلى حدث تشغيلي واحد.

أصبحت طبقة التحكم هي نصف قطر الضرر

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

لهذا السبب يمكن أن تنتشر مشكلة Runner دون أن يصبح كل مستودع أو عملية Git غير متصلة. يمكن أن يكون الدفع موجودًا بينما لا تبدأ خطوط الأنابيب التي تم تشغيلها. يمكن تنفيذ وظيفة بينما تكون الحالة التي تستهلكها قاعدة دمج أو خدمة خارجية قديمة. يمكن أن يكون ملف كبير موجودًا في LFS بينما يفشل طلب API اللازم لتحميله. يمكن أن يظل موقع ثابت قابل للوصول بينما لا يمكن بناء Pages جديد.

يظهر الجدول الزمني لـ GitHub هذا الفصل. تم الإبلاغ عن Pages كمستعادة في الساعة 01:37. تبعت Issues في الساعة 02:20. ذكرت GitHub أن Issues وطلبات API وPages قد استعيدت في الساعة 02:43، لكنها استمرت في العمل على استعادة وظائف Actions التي تستخدم Runners ذاتية الاستضافة أو أكبر. تم إعلان طلبات API كطبيعية في الساعة 03:03. انتقلت Actions إلى المراقبة في الساعة 03:34 ووصفت بأنها مستعادة بالكامل في الساعة 04:43.

التسلسل أكثر أهمية من مدة إجمالية واحدة. دخل كل عميل الحادث من خلال مجموعة مختلفة من الأحداث وواجهات API وRunners والفحوصات اللاحقة. لم تنشر GitHub عدد عمليات التنفيذ الفاشلة أو المستودعات أو المؤسسات أو المناطق، لذلك لا يمكن تحويل الطوابع الزمنية العامة إلى فترات توقف عالمية للعملاء.

تظهر السجلات اللاحقة اختلاف الحالة

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

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

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

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

لم تلغ ملكية Runner اعتماد التنسيق

توثق GitHub أن Runner ذاتي الاستضافة هو جهاز يوفره العميل ويديره لتنفيذ وظائف Actions. يتحكم العميل في الأجهزة ونظام التشغيل والبرامج المثبتة، ويدفع مقابل صيانتها.

يمكن أن يكون هذا التحكم ذا قيمة للأمن والمحلية والسعة والأجهزة المتخصصة. إنه ليس مثل امتلاك طبقة التحكم الكاملة في سير العمل.

ذكرت GitHub صراحةً أنها استمرت في العمل على استعادة وظائف Actions باستخدام Runners ذاتية الاستضافة أو أكبر بعد أن تم بالفعل استعادة Issues وواجهات API وPages. البيان لا يثبت أن أجهزة العملاء كانت معيبة. إنه يظهر أن قدرة الحوسبة المتاحة للعملاء لا تزال تنتظر على مسار التنسيق الخاص بـ GitHub.

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

يتطلب التعافي المطابقة، وليس مجرد إعادة المحاولة

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

لذلك فإن السؤال الأول ليس "هل يمكن الضغط على الزر الأخضر مرة أخرى؟" بل "ماذا حدث في النظام الهدف؟" يجب على الفريق مطابقة حدث المستودع وسجل تنفيذ GitHub وسجلات Runner وحالة الحزمة أو القطعة الأثرية وهدف النشر قبل إعادة العمل. تعمل الوظائف المتكررة ومعرفات الإصدار القابلة للتحقق خارجيًا على تقليل هذا الخطر؛ لا تلغي الحاجة إلى التحقق.

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

الأدلة المفقودة هي الآلية

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

لا يوجد أساس عام هنا لادعاء خرق أمني أو فقدان كود مصدر أو فشل نشر العملاء أو فقدان بيانات أو منطقة جغرافية محددة أو رصيد SLA. تصنيف GitHub على أنه "حرج" يصف مستوى تأثير الحادث؛ إنه ليس قياسًا لخسارة كل عميل.

يجب أن يشرح الإفصاح المفيد التالي الاعتماد الذي سمح لحادث Runner في Actions بالتأثير على مسارات API وLFS وIssues وPages، ويجب أن يفصل الخطأ الأولي عن تأثيرات التراكم والتعافي. حتى ذلك الحين، الاستنتاج المعقول هو تشغيلي: استعاد GitHub سلسلة الخدمات، لكن يجب على العملاء اختبار ما إذا كانت سجلات الأحداث والوظائف والنشر الخاصة بهم متطابقة قبل اعتبار الحادث منتهيًا.

المصادر