عطل عالمي في GitHub يرفع نسبة الأخطاء إلى 20% لأكثر من 3 ساعات

تعرضت منصة GitHub في 17 أغسطس 2026 لعطل عالمي بدأ الساعة 13:40 بتوقيت UTC. وبلغت نسبة الأخطاء على الموقع والـ API نحو 20%، أي أن طلبًا من كل خمسة طلبات تقريبًا كان يفشل. وارتفعت النسبة إلى نحو 50% عند تحميل الأرشيفات (archives) والملفات الخام من المستودعات.

وشمل العطل Pull Requests وIssues وActions وWebhooks وCopilot وPages. وأعلنت GitHub تعافي 7 من 8 خدمات الساعة 16:59 بتوقيت UTC، أي بعد 3 ساعات و19 دقيقة من البداية.

والفرق بين الرقمين هو ما يفسر أثر العطل. فلو توقفت المنصة تمامًا، لفشلت أنظمة CI بسرعة، ولأدرك الفريق أن المشكلة خارجية فانتظر. أما نسبة فشل 20% فتعني أن أغلب الطلبات ينجح، فتعيد الأنظمة المحاولة تلقائيًا (retries)، وتزيد إعادة المحاولة الضغط على المنصة، وقد يستغرق الـ build أربعين دقيقة ثم يفشل في خطوة مختلفة كل مرة. ويصعب في هذه الحالة تمييز العطل الخارجي من خطأ في الكود نفسه.

وكانت نسبة الـ 50% على الأرشيفات أشد أثرًا، لأن كثيرًا من عمليات docker build وتثبيت الاعتماديات (dependencies) تمر عبر هذا المسار.

ويكشف العطل حقيقة تخص كل فريق يبيع خدمة لعملائه: نسبة التوفر (uptime) التي يتعهد بها المنتج لا يحددها الخادم الذي يملكه الفريق وحده، بل أضعف حلقة في سلسلة الأدوات التي يُبنى بها ويُنشر عبرها. وكثير من هذه الحلقات خدمات لا يدفع لها الفريق شيئًا، ولا يربطه بها أي تعهد.

ولم تنشر GitHub السبب الجذري للعطل بعد. وعادة ما تنشره في تقرير التوفر الشهري الذي تصدره على مدونتها.