الخلاصة

  • استمر الحادث المصنف major من 07:53:59.358 إلى 09:39:19.558 UTC، أي ساعة و45 دقيقة و20.200 ثانية.
  • شملت المكونات Actions وIssues وWebhooks وPull Requests.
  • كان بدء مهام Actions أبطأ، وكان بحث Issues يعرض نتائج قديمة.
  • عند 09:22:21 UTC قالت GitHub إنها حددت مصدر التأخير وطبقت إصلاحاً، فيما كانت قوائم المعالجة تتناقص.
  • وعدت الشركة بتحليل مفصل للسبب الجذري، ولم تنشر عدد المتأثرين أو الخسارة المالية.

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

قالت الشركة عند 09:22:21 إنها حددت مصدر التأخير في خدمات متعددة وطبقت إصلاحاً. لكنها لم تذكر قاعدة بيانات أو قائمة رسائل أو تغييراً برمجياً أو مزود بنية تحتية. كما لم تشرح لماذا انتقل الأثر بين أربع واجهات.

وبالتالي لا يجوز ملء الفراغ بتخمين. اشتراك المنتجات في حادث واحد يوحي باعتماد أو مسار انتشار، لكنه لا يحدد ماهيته.

الأعراض معروفة والتكلفة غير محسوبة

بدأ الحادث عند 07:53:59.358 UTC. شملت البلاغات الأولى Actions وIssues وWebhooks، ثم أضيف Pull Requests.

شرحت GitHub أن مهام Actions قد تستغرق وقتاً أطول قبل البدء، وأن بحث Issues قد يعرض نتائج قديمة. ويمكن أن تؤخر هذه الأعراض الاختبار والنشر، وتربك صورة العمل، وتبطئ الأحداث والمراجعات.

لم تنشر الشركة عدد المستخدمين أو المهام أو المستودعات أو الأحداث المتأثرة. لذلك لا يمكن حساب خسارة مالية أو ساعات عمل من مدة الحادث وحدها.

المدة الدقيقة هي حالة المزود: ساعة و45 دقيقة و20.200 ثانية. وقد يستمر عمل العميل بعد ذلك للتحقق من المهام والأحداث والمراجعات المتأخرة.

التعافي كان تدريجياً

أعلنت GitHub تخفيف أثر Issues عند 09:18:37 وActions عند 09:19:49. وبعد تطبيق الإصلاح، قالت إن الخدمات المتبقية تتحسن مع إفراغ قوائم المعالجة.

خُفف أثر Pull Requests عند 09:27:35، وعاد Webhooks طبيعياً عند 09:35:17، ثم أُغلق الحادث عند 09:39:19.558. وهذا يفصل بين إصلاح المصدر، وتعافي كل خدمة، وإنهاء الحادث.

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

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

هذا الحادث مستقل أيضاً عن تأخير runners المستضافة في 22 يوليو، لأن التوقيت ونطاق المنتجات والأعراض المنشورة مختلفة. التقارب الزمني ليس دليلاً على سبب واحد.

حتى يصدر التحليل، تظل الخلاصة محدودة: استعادت GitHub أربع خدمات خلال 105 دقائق، بينما تحمل العملاء كلفة الانتظار والتحقق. أما الآلية التقنية ومن يتحمل منع تكرارها فهما سؤالان مفتوحان.

المصادر