كود لا يصل إلى المستودع، طلبات دمج تتعطل، اختبارات آلية تتوقف، وأداة ذكاء اصطناعي يراهن عليها ملايين المطورين تختفي في اللحظة نفسها، هكذا تحولت مشكلة داخل GitHub إلى عطل واسع امتد تأثيره إلى جزء مهم من خطوط تطوير البرمجيات حول العالم، قبل أن تبدأ الخدمات في العودة تدريجيًا ويظل «Copilot» من آخر المتأثرين.
موضوعات مقترحة
وبحسب موقع «Android Central»، بدأ العطل الواسع يوم 17 أغسطس بعدما واجه GitHub ارتفاعًا حادًا في معدلات الأخطاء شمل الموقع وواجهات البرمجة وأدوات مراجعة ودمج الأكواد وخدمة Actions، إلى جانب «GitHub Copilot»، ووصلت نسبة الأخطاء في حركة الويب وواجهات API إلى نحو 20%، بينما فشلت عمليات تنزيل محتوى المستودعات والملفات الخام في قرابة نصف المحاولات خلال ذروة الأزمة.
عندما يتوقف GitHub لا يتعطل موقع فقط
أهمية GitHub لا تأتي من كونه مكانًا لحفظ الأكواد فحسب، فآلاف الشركات وفرق التطوير تربط به عمليات الاختبار وبناء التطبيقات ونشر التحديثات بصورة آلية، لذلك يمكن لعطل واسع داخل المنصة أن يتحول سريعًا إلى مشكلة تمتد إلى خدمات ومواقع وتطبيقات لا تحمل اسم GitHub أصلًا.
وشملت الأزمة «Pull Requests» المستخدمة لمراجعة ودمج التعديلات، و«Issues» لمتابعة المشكلات، و«Webhooks» التي تربط GitHub بخدمات أخرى، إلى جانب «Actions» التي تعتمد عليها الفرق في تشغيل الاختبارات وعمليات البناء والنشر تلقائيًا، وهو ما يفسر لماذا وصف العطل بأنه قادر على إرباك خطوط تطوير برمجيات كاملة وليس مجرد منع المستخدمين من فتح الموقع.
الخطأ وصل إلى واحد من كل خمسة طلبات
خلال أسوأ مراحل العطل سجل GitHub معدل أخطاء يقترب من 20% في الموقع وواجهات البرمجة، لكن التأثير كان أشد في تنزيل الملفات الخام وأرشيفات المستودعات، حيث وصلت نسبة الفشل إلى نحو 50%.
وامتدت المشكلة كذلك إلى بعض خدمات تسجيل الدخول وإدارة الهويات المستخدمة داخل المؤسسات، بما في ذلك SAML وOIDC وخدمات مزامنة الفرق، ما أضاف طبقة أخرى من التعطيل للشركات التي تعتمد على GitHub داخل بيئات العمل المؤسسية.
الخدمات عادت.. وCopilot تأخر
بدأت معظم خدمات GitHub الأساسية في التعافي بعد تحديد المكون المسبب للمشكلة واتخاذ إجراءات تصحيحية، لكن «Copilot» واصل مواجهة مشكلات في المصادقة داخل بعض التطبيقات بعد استقرار أجزاء كبيرة من المنصة.
وأظهرت تحديثات الحالة أن الخدمات الأساسية تعافت أولًا، بينما استمرت أعطال متفرقة في الحصول على رموز الدخول الخاصة بـ«Copilot»، الأمر الذي جعل بعض المستخدمين يرون رسائل تفيد بعدم توافر نموذج الذكاء الاصطناعي أو فشل الاتصال بالخدمة حتى بعد عودة GitHub نفسه للعمل بصورة طبيعية.
لماذا تأخر الذكاء الاصطناعي عن باقي GitHub؟
تكشف التفاصيل الفنية التي نشرها GitHub لاحقًا أن المشكلة ارتبطت بتعطل شبكي في مركز بيانات بمنطقة وسط الولايات المتحدة، واضطرت الشركة إلى تحويل جزء من الحركة إلى مركز بيانات آخر أثناء التعامل مع الخلل.
لكن أزمة «Copilot» أخذت مسارًا إضافيًا، إذ أدى تأخر الرد من إحدى النقاط الداخلية إلى تشغيل خطأ قديم في آلية إعادة المحاولة داخل Visual Studio Code، ما ضاعف حجم حركة الطلبات بنحو 10 مرات وأبطأ تعافي خدمة الرموز الخاصة بـ«Copilot»، لتصبح أداة الذكاء الاصطناعي واحدة من آخر الخدمات التي استعادت استقرارها الكامل.
قرابة 8 ساعات قبل إغلاق الأزمة
استمر الحادث بصورة إجمالية من الساعة 13:28 وحتى 21:15 بالتوقيت العالمي يوم 17 أغسطس، أي قرابة 7 ساعات و47 دقيقة، بينما عادت أغلب الخدمات الأساسية للعمل قبل ذلك، واستمر «Actions» متأثرًا حتى نحو 18:03، قبل أن تستعيد خدمة «Copilot Token Service» عملها بالكامل عند 21:02.
وبذلك لم يعد «Copilot» متوقفًا حاليًا كما كان وقت نشر التقارير الأولى عن العطل، فقد أعلنت GitHub إغلاق الحادث رسميًا مساء 17 أغسطس وعودة الخدمات إلى العمل، لكن الأزمة قدمت مثالًا واضحًا على حجم الاعتماد الذي أصبح يربط عمليات تطوير البرمجيات العالمية بمنصة واحدة، وعلى أن تعطل خدمة للمطورين قد يمتد تأثيره في دقائق إلى منتجات رقمية يستخدمها ملايين الأشخاص من دون أن يعرفوا أن GitHub يقف في الخلفية.