أعلنت الشركة لاحقًا أنها حددت مكوّنًا مرتبطًا بالمشكلة وبدأت إجراءات تصحيحية. وفي تحديث نُشر عند 12:36 ظهرًا بتوقيت الساحل الشرقي، قالت GitHub إن المنصة تُظهر مؤشرات قوية على التعافي، مع استمرار العمل للوصول إلى الاستقرار الكامل.

لكن عودة الخدمات لم تحدث دفعة واحدة. فقد عادت خدمات رئيسية إلى الحالة التشغيلية، بينما استمرت مشكلات المصادقة في GitHub Copilot داخل بعض التطبيقات. وتشير تقارير تتبّع الحادثة إلى أن الانقطاع الكلي استمر حتى نحو 21:15 بالتوقيت العالمي، أي قرابة سبع ساعات ونصف.

ما حجم التأثير؟

أوضح مؤشرات التأثير التي أعلنتها GitHub كانت كالتالي:

• تجارب الويب وحركة واجهات API: أخطاء بنحو 20%.
• تنزيلات الأرشيف والمحتوى الخام للمستودعات: أخطاء بنحو 50%.
• أدوات المطورين: تراجع أداء أو انقطاع متقطع في Pull Requests وIssues وActions وWebhooks وعمليات Git وPages.
• المساعدة البرمجية بالذكاء الاصطناعي: تأثر GitHub Copilot، واستمرت مشكلات المصادقة فيه بعد بدء تعافي عدد من الخدمات الأساسية.
• هوية المؤسسات: أفادت التقارير بتأثر مصادقة SAML وOIDC، وتوفير المستخدمين عبر SCIM، وميزة Team Sync؛ ما قد يمنع بعض المؤسسات من تسجيل المستخدمين أو إدارة الصلاحيات بصورة موثوقة.

ولا تعني نسبة أخطاء قدرها 20% أن 20% من عملاء GitHub كانوا خارج الخدمة. فهي تقيس الطلبات التي فشلت أو واجهت أخطاء، كما أن نسبة 50% تخص طلبات التنزيل المتأثرة، لا حركة جميع المستودعات.

لماذا زاد توقيت الانقطاع من صعوبته؟

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

وبما أن Actions وPull Requests وواجهات API وWebhooks كانت من بين الخدمات المتأثرة، واجهت الفرق احتمال تعطل عدة حلقات مترابطة في سير العمل في الوقت نفسه، بدل توقف ميزة واحدة معزولة.

كما اختلفت أرقام بلاغات الأعطال باختلاف وقت الرصد والمنصة المستخدمة. فقد أشير إلى تسجيل أكثر من 10 آلاف بلاغ على Downdetector بحلول الساعة 8:12 صباحًا بتوقيت المحيط الهادئ، بينما تحدث تقرير آخر عن ذروة قاربت 3 آلاف بلاغ. ولا تمثل هذه الأرقام عدد المستخدمين المتضررين بدقة؛ إذ تقيس منصات التتبع البلاغات التي يرسلها المستخدمون، وتتغير النتائج بحسب الموقع الجغرافي والتوقيت وطريقة جمع البيانات.

ماذا فعلت GitHub؟ وما الذي لم توضحه؟

تثبت التحديثات العلنية للشركة ثلاث نقاط أساسية:

1. بدأ المهندسون التحقيق في ارتفاع معدلات الأخطاء وتراجع الأداء عبر عدة خدمات.
2. حددت GitHub مكوّنًا مرتبطًا بالمشكلة واتخذت إجراءً تصحيحيًا.
3. واصلت الشركة تطبيق إجراءات تخفيفية بعد بدء تعافي الخدمات الرئيسية، بما في ذلك معالجة مشكلات المصادقة المتقطعة في Copilot.

لكن المعلومات المتاحة لا تحدد اسم المكوّن، ولا تشرح الإجراء التقني الدقيق الذي اتُخذ. كما لا تثبت أن ضغط السعة أو تزايد أحمال الذكاء الاصطناعي كان السبب المباشر لهذا الانقطاع تحديدًا.

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

حلقة جديدة في مشكلات موثوقية GitHub خلال 2026

جاء انقطاع أغسطس بعد فترة صعبة نسبيًا. فقد وثّق تقرير توافر GitHub لشهر يوليو ثماني حوادث خلال الشهر، من بينها حادثة في 8 يوليو استمرت أكثر من سبع ساعات وأثرت في واجهة الويب وواجهات REST وGraphQL وActions وPackages وCopilot وعمليات Git ضمن بعض بيئات Enterprise Cloud.

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

وتبرز الأرقام حجم التحدي: فقد كان الهدف الأصلي زيادة السعة 10 أضعاف، قبل أن يتضح بحلول فبراير 2026 أن التصميم ينبغي أن يستوعب ما يصل إلى 30 ضعف الحجم السابق. كما تناولت تقارير أخرى خططًا للاستفادة من سعات متعددة السحابة، بينها Azure وAWS، لكن هذه الخطط لا تفسر وحدها سبب انقطاع أغسطس.

المغزى العملي للمؤسسات هو أن GitHub لم تعد مجرد مساحة لتخزين مستودعات Git؛ فهي أيضًا طبقة للتعاون، ومنصة للأتمتة، ونظام لإدارة الهوية، وخدمة للمساعدة البرمجية بالذكاء الاصطناعي. وعندما تتعطل تبعيات مشتركة، قد يتوقف الوصول إلى الشيفرة ومراجعات التغييرات وعمليات البناء والنشر وWebhooks وCopilot في وقت واحد.

ما الذي ينبغي أن تراجعه فرق التطوير؟

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

ومن الإجراءات العملية المفيدة:

• الاحتفاظ بنسخ احتياطية أو مرايا للمستودعات.
• جعل إعدادات CI/CD قابلة للنقل قدر الإمكان.
• توثيق إجراءات الإصدار الطارئ.
• التأكد من معرفة الفرق بكيفية العمل عند تعطل SSO أو Webhooks أو المشغّلات المستضافة.
• إعداد مسارات بديلة للمراجعة والبناء والنشر عند الحاجة.

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

أعلنت الشركة لاحقًا أنها حددت مكوّنًا مرتبطًا بالمشكلة وبدأت إجراءات تصحيحية. وفي تحديث نُشر عند 12:36 ظهرًا بتوقيت الساحل الشرقي، قالت GitHub إن المنصة تُظهر مؤشرات قوية على التعافي، مع استمرار العمل للوصول إلى الاستقرار الكامل.

لكن عودة الخدمات لم تحدث دفعة واحدة. فقد عادت خدمات رئيسية إلى الحالة التشغيلية، بينما استمرت مشكلات المصادقة في GitHub Copilot داخل بعض التطبيقات. وتشير تقارير تتبّع الحادثة إلى أن الانقطاع الكلي استمر حتى نحو 21:15 بالتوقيت العالمي، أي قرابة سبع ساعات ونصف.

ما حجم التأثير؟

أوضح مؤشرات التأثير التي أعلنتها GitHub كانت كالتالي:

• تجارب الويب وحركة واجهات API: أخطاء بنحو 20%.
• تنزيلات الأرشيف والمحتوى الخام للمستودعات: أخطاء بنحو 50%.
• أدوات المطورين: تراجع أداء أو انقطاع متقطع في Pull Requests وIssues وActions وWebhooks وعمليات Git وPages.
• المساعدة البرمجية بالذكاء الاصطناعي: تأثر GitHub Copilot، واستمرت مشكلات المصادقة فيه بعد بدء تعافي عدد من الخدمات الأساسية.
• هوية المؤسسات: أفادت التقارير بتأثر مصادقة SAML وOIDC، وتوفير المستخدمين عبر SCIM، وميزة Team Sync؛ ما قد يمنع بعض المؤسسات من تسجيل المستخدمين أو إدارة الصلاحيات بصورة موثوقة.

ولا تعني نسبة أخطاء قدرها 20% أن 20% من عملاء GitHub كانوا خارج الخدمة. فهي تقيس الطلبات التي فشلت أو واجهت أخطاء، كما أن نسبة 50% تخص طلبات التنزيل المتأثرة، لا حركة جميع المستودعات.

لماذا زاد توقيت الانقطاع من صعوبته؟

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

وبما أن Actions وPull Requests وواجهات API وWebhooks كانت من بين الخدمات المتأثرة، واجهت الفرق احتمال تعطل عدة حلقات مترابطة في سير العمل في الوقت نفسه، بدل توقف ميزة واحدة معزولة.

كما اختلفت أرقام بلاغات الأعطال باختلاف وقت الرصد والمنصة المستخدمة. فقد أشير إلى تسجيل أكثر من 10 آلاف بلاغ على Downdetector بحلول الساعة 8:12 صباحًا بتوقيت المحيط الهادئ، بينما تحدث تقرير آخر عن ذروة قاربت 3 آلاف بلاغ. ولا تمثل هذه الأرقام عدد المستخدمين المتضررين بدقة؛ إذ تقيس منصات التتبع البلاغات التي يرسلها المستخدمون، وتتغير النتائج بحسب الموقع الجغرافي والتوقيت وطريقة جمع البيانات.

ماذا فعلت GitHub؟ وما الذي لم توضحه؟

تثبت التحديثات العلنية للشركة ثلاث نقاط أساسية:

1. بدأ المهندسون التحقيق في ارتفاع معدلات الأخطاء وتراجع الأداء عبر عدة خدمات.
2. حددت GitHub مكوّنًا مرتبطًا بالمشكلة واتخذت إجراءً تصحيحيًا.
3. واصلت الشركة تطبيق إجراءات تخفيفية بعد بدء تعافي الخدمات الرئيسية، بما في ذلك معالجة مشكلات المصادقة المتقطعة في Copilot.

لكن المعلومات المتاحة لا تحدد اسم المكوّن، ولا تشرح الإجراء التقني الدقيق الذي اتُخذ. كما لا تثبت أن ضغط السعة أو تزايد أحمال الذكاء الاصطناعي كان السبب المباشر لهذا الانقطاع تحديدًا.

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

حلقة جديدة في مشكلات موثوقية GitHub خلال 2026

جاء انقطاع أغسطس بعد فترة صعبة نسبيًا. فقد وثّق تقرير توافر GitHub لشهر يوليو ثماني حوادث خلال الشهر، من بينها حادثة في 8 يوليو استمرت أكثر من سبع ساعات وأثرت في واجهة الويب وواجهات REST وGraphQL وActions وPackages وCopilot وعمليات Git ضمن بعض بيئات Enterprise Cloud.

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

وتبرز الأرقام حجم التحدي: فقد كان الهدف الأصلي زيادة السعة 10 أضعاف، قبل أن يتضح بحلول فبراير 2026 أن التصميم ينبغي أن يستوعب ما يصل إلى 30 ضعف الحجم السابق. كما تناولت تقارير أخرى خططًا للاستفادة من سعات متعددة السحابة، بينها Azure وAWS، لكن هذه الخطط لا تفسر وحدها سبب انقطاع أغسطس.

المغزى العملي للمؤسسات هو أن GitHub لم تعد مجرد مساحة لتخزين مستودعات Git؛ فهي أيضًا طبقة للتعاون، ومنصة للأتمتة، ونظام لإدارة الهوية، وخدمة للمساعدة البرمجية بالذكاء الاصطناعي. وعندما تتعطل تبعيات مشتركة، قد يتوقف الوصول إلى الشيفرة ومراجعات التغييرات وعمليات البناء والنشر وWebhooks وCopilot في وقت واحد.

ما الذي ينبغي أن تراجعه فرق التطوير؟

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

ومن الإجراءات العملية المفيدة:

• الاحتفاظ بنسخ احتياطية أو مرايا للمستودعات.
• جعل إعدادات CI/CD قابلة للنقل قدر الإمكان.
• توثيق إجراءات الإصدار الطارئ.
• التأكد من معرفة الفرق بكيفية العمل عند تعطل SSO أو Webhooks أو المشغّلات المستضافة.
• إعداد مسارات بديلة للمراجعة والبناء والنشر عند الحاجة.

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