كشفت GitHub عن تفاصيل خمسة حوادث أثرت في توافر خدماتها خلال أغسطس 2026، بينها أعطال في GitHub Actions وتأخر في نتائج Copilot Cloud Agent وفشل في طلبات نموذج Kimi K3. وتربط الشركة الحوادث بنمو المنصة وضيق هوامش السعة، إضافة إلى عيوب في التوسع التلقائي وسياسات إعادة المحاولة وآليات التعافي.
وتقول GitHub إنها تستثمر في تحسين البنية المعمارية ونقل مزيد من الخدمات إلى Azure، مع إعطاء الأولوية للتوافر ثم السعة ثم الميزات. كما أعلنت تحسينات في مراقبة السعة وإدارة الطوابير وسياسات إعادة المحاولة ومرونة الخدمات الأساسية.
خمسة حوادث بأسباب مختلفة
- 6 أغسطس: استمر الحادث 10 ساعات و42 دقيقة، بعدما أدى نشر روتيني لخدمة داخلية في Actions إلى خفض مؤقت للسعة في أحد المواقع. تسبب ذلك في تشبع الخدمات وانتشار أخطاء إلى التخزين المؤقت وDNS وواجهات API، ثم أبطأ عيب في مسار إسناد المهام عملية التعافي. فشلت أو تأخرت نسبة كبيرة من عمليات سير العمل، واضطرت بعض الأحداث إلى إعادة التشغيل يدوياً.
- 17 أغسطس: استمر التدهور 7 ساعات و35 دقيقة نتيجة بلوغ موازنات التحميل في مركز بيانات ذروة سعتها، مع عدم توسع مكوّن جانبي في شبكة الخدمات رغم بلوغه حد التزامن. أدى ذلك إلى تأخير وفشل في مسار المصادقة المشترك، وامتد الأثر إلى Issues وPull Requests وواجهات API وActions وCopilot. كما ضاعف عيب في إعادة المحاولة حركة الطلبات إلى نقطة مصادقة داخلية.
- 20 أغسطس: استمر الحادث 9 ساعات و54 دقيقة وأثر في حالة ونتائج مهام Copilot Cloud Agent لدى 54 مؤسسة على الأقل. تعطلت منطقة لدى مزود قاعدة البيانات السحابية التي تخزن حالات المهام، وفشل التحويل الإقليمي سريعاً بسبب إعداد تخزين، فتراكمت تحديثات الحالة. لم تُفقد المهام نفسها، لكن ظهور النتائج تأخر حتى استعادة المعالجة وتفريغ الطابور.
- 26 أغسطس: استمر التدهور ساعتين و50 دقيقة عندما دفعت دفعة من الأحداث قاعدة بيانات مشتركة كانت تعمل قرب حدها إلى التشبع. أدى ذلك إلى تأخر بدء عمليات Actions، وتأثرت خدمات تعتمد عليها مثل Copilot Code Review وبعض عمليات GitHub Pages. احتاجت GitHub إلى خنق الحمل الوارد تدريجياً، إذ لم يكن هناك قاطع دائرة تلقائي يفعّل الحماية عند ظهور مؤشرات الإجهاد.
- 27 أغسطس: استمر الحادث ساعتين و8 دقائق، وأثر فقط في الطلبات الموجهة إلى نموذج Kimi K3 داخل Copilot بسبب تدهور لدى مزود النموذج الخارجي. تجاوز معدل فشل هذه الطلبات النصف في ذروة الحادث، بينما ظلت النماذج الأخرى وإعداد Auto متاحة.
ما الذي تغير عملياً؟
توضح الإجراءات المعلنة أن GitHub تتعامل مع الحوادث بوصفها مشكلات سعة وعزل واستعادة، لا مجرد أخطاء نشر منفردة. فقد نقلت 33% من وظائف Actions من عنقود إنتاج مقيد إلى سعة احتياطية، ما خفض استخدام معالج التخزين المؤقت عند الذروة من 98% إلى 80% وأضاف، وفق تقديرها، نحو ثلاثة أشهر من الهامش. كما بلغت القراءات من الخدمات المهاجرة إلى Azure ذروة 60.4%، وقراءات النظام الأحادي 64.3%، وقراءات Git نسبة 54%.
وعلى مستوى قواعد البيانات، شُغّل أول MySQL primary إنتاجي من Azure في 11 أغسطس من دون أثر ملحوظ على عمليات الكتابة المرصودة من العملاء، ثم تكرر النمط مع قاعدتين أساسيتين في 27 أغسطس. كذلك أزالت GitHub نحو مليون استعلام في الثانية من نسخ قاعدة بيانات قديمة، وخفضت تغييرات أخرى 120 ألف استعلام في الثانية ونحو 59 ألف ثانية من العمل المهدور كل ساعة.
لماذا يهم هذا التقرير؟
تكشف الحوادث أن الاعتماد على التوسع الأفقي وحده لا يكفي عندما تتشارك الخدمات قواعد بيانات أو مسارات مصادقة أو بنية Actions واحدة. كما أن إعادة المحاولة غير المنضبطة قد تحول تدهوراً جزئياً إلى حمل أوسع، في حين يمكن أن يؤدي تأخر التحويل بين المناطق إلى تراكم حالات حتى عندما لا تضيع المهام الأصلية. وتبقى خطة Azure وإجراءات العزل وقواطع الحمل قيد التنفيذ، لذلك لا يثبت التقرير أن المخاطر أزيلت؛ بل يوضح أين تركز GitHub أعمالها المقبلة: نقل قواعد أساسية إضافية، أتمتة إدارة السعة، وتوسيع التعامل مع فشل التبعيات.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.