GitHub تسجل ثمانية حوادث أثرت على أداء خدماتها في أكتوبر 2026
تواصل GitHub تقديم تحديثات شهرية حول جهودها في مجال التوافر والموثوقية.
ملخص أكتوبر: أضافت الشركة سعة كبيرة في Azure قابلة للتوسع بشكل مستقل، وعالجت عدة مسارات لتصعيد الأعطال. لكن تحديات مثل انقطاعات الكتابة، وثغرات المراقبة أثناء ترحيل البيانات، واضطراب في الشبكة الإقليمية، أبرزت الحاجة إلى تحسين السلامة التشغيلية ونمو السعة.
حتى 9 نوفمبر، كانت 140 من أصل 151 خدمة إنتاجية و32 من أصل 50 من قواعد بيانات MySQL الأساسية تعمل في Azure Central US. وتعاملت Azure مع 63% من قراءات الخدمات المرحّلة، و66% من قراءات النظام الأحادي (monolith)، و52% من قراءات Git. كما ضاعف توسيع القدرة الحاسوبية عبر جميع مجموعات Kubernetes التسع في Central US السعة أكثر من مرتين.
تدعم هذه السعة المتزايدة بالفعل نمواً حقيقياً. فقد ارتفعت حركة المرور للخدمات المرحّلة بنسبة 82% منذ مارس، مع استيعاب Central US لأحمال تتجاوز المتوسطات الأسبوعية السابقة من مركز البيانات الأصلي، ما سمح لـ GitHub بالنمو دون إفراط في تحميل بيئتها الأولية.
كما نُفذت تحسينات موجهة للموثوقية. فقد أدت تغييرات في GitHub Actions إلى زيادة سعة طلبات مستوى التحكم الحرجة في Azure، بينما قلل تخفيف منفصل لبوابة NAT الاستخدام بنسبة 85%. وخلال هذا التغيير، فشلت أربع وظائف إنتاجية فقط، مقارنة بنحو 800 وظيفة كان متوقعاً فشلها دون هذا التخفيف.
إضافة إلى ذلك، عالجت GitHub مصادر مركزة لتحميل قاعدة البيانات. فقد انتقل أحد نقاط نهاية GitHub Actions عالية الحركة، والذي كان يتعامل مع أكثر من 250 مليون طلب يومياً، إلى مسار خدمة أكثر كفاءة، ما قلل ذروة قراءات قاعدة البيانات بنسبة 85%. كما أدى اشتراط ثلاثة أحرف على الأقل قبل البحث في موضوعات المستودعات إلى خفض الاستعلامات البطيئة أو المنتهية لهذا النمط بنحو 98%.
ورغم هذه الجهود، ظلت الموثوقية مصدر قلق. فقد كشفت انقطاعات الكتابة في 7 أكتوبر عن تفاعل غير آمن بين تنسيق قاعدة البيانات وتوجيه الإنتاج. كما أثر اضطراب شبكة Azure في 29 أكتوبر على جميع مناطق التوافر الثلاث في Central US، مما أثر على ما لا يقل عن 34,128 مستخدماً مسجلاً.
ويتأخر بناء East US 3 حالياً نحو أسبوع عن الجدول الزمني، ومن المقرر أن تبدأ المرحلة التالية أول زيادة تدريجية للحركة تم التحقق منها في الأسبوع الأول من ديسمبر. وتتواصل الجهود لتعزيز سلامة الترحيل وعزل التبعيات والتعافي الإقليمي.
ويبقى المبدأ التوجيهي: التوافر، ثم السعة، ثم الميزات.
5 أكتوبر 19:11 UTC (استمر 3 ساعات و38 دقيقة)
المدة: نحو 3 ساعات و45 دقيقة.
ربما لاحظ العملاء تأخيرات في وظائف GitHub Actions على runners المستضافة لدى GitHub، مع فشل بعض تشغيلات سير العمل في البدء. وخلال فترة الذروة، لم تبدأ معظم الوظائف خلال خمس دقائق. وتحسنت الحالة مع تحويل الشركة إلى مناطق سليمة وإضافة سعة.
ما الذي حدث خطأ ولماذا؟
ظلت وظائف Actions في قائمة الانتظار أو فشلت في البدء بسبب مشكلة موثوقية في الخدمة التي تعين الوظائف على runners المستضافة لدى GitHub. وقد أدى فشل شبكي جزئي من جانب مزود السحابة إلى تعطيل الاتصالات بين منطقة مركز بيانات واحدة وقواعد البيانات المستضافة سحابياً التي تعتمد عليها الخدمة.
كيف استجبنا؟
- أشارت التنبيهات إلى أخطاء وتعيينات وظائف بطيئة، ما استدعى إعلان حادث.
- أُعيد نشر الخدمة التي تعين الوظائف على runners المستضافة لدى GitHub، لكنها لم تتعاف.
- حوّلنا قواعد البيانات والتخزين المتأثرة إلى مناطق سليمة، خدمة تلو الأخرى، وأضفنا سعة.
- أدى التعاون مع مزود السحابة إلى حل الفشل الشبكي، ما سمح لبقية الخدمات بالتعافي.
كيف نجعل حوادث كهذه أقل احتمالاً أو أقل تأثيراً؟
- يجري تحسين الخدمة التي تعين الوظائف على runners المستضافة لدى GitHub للتعامل بشكل أفضل مع الزيادات المفاجئة في الحمل.
- وُسّع نطاق إعطاء الأولوية لتعيين runners بناءً على ملف تعريف العميل عند تدهور السعة المتاحة.
6 أكتوبر 19:57 UTC (استمر 3 ساعات و43 دقيقة)
المدة: نحو 6 دقائق من الطلبات الفاشلة أو البطيئة عبر github.com، تلتها نحو 3 ساعات و30 دقيقة توقفت خلالها عمليات ترحيل المؤسسات.
ما الذي حدث خطأ ولماذا؟
تسبب ارتفاع مفاجئ في نشاط الترحيل في إرسال GitHub Enterprise Importer استعلامات كبيرة إلى قاعدة بيانات مشتركة، استغرقت وقتاً أطول من المعتاد لمعالجتها، ما استنفد الاتصالات المتاحة لقاعدة البيانات.
كيف استجبنا؟
- اكتشفت المراقبة الآلية الأعطال ونبهت المهندسين المناوبين.
- أُعلن حادث، وأُوقفت عمليات ترحيل المؤسسات لمنع التكرار أثناء التحقيق.
كيف نجعل حوادث كهذه أقل احتمالاً أو أقل تأثيراً؟
- حُسّن الاستعلام الذي يرسله GitHub Enterprise Importer ليبقى صغيراً وثابت الحجم.
- يجري تنفيذ تراجع آلي (backoff) لأداة الاستيراد عندما تكون قاعدة البيانات تحت ضغط.
7 أكتوبر 15:14 و17:17 UTC (استمرا ساعة و11 دقيقة، و47 دقيقة على التوالي)
المدة: استمر انقطاعا الكتابة المنفصلان نحو 10 دقائق و9 دقائق، بإجمالي نحو 19 دقيقة.
ما الذي حدث خطأ ولماذا؟
أثناء صيانة روتينية، استُبدلت أجهزة تدير توجيه الكتابة في قاعدة البيانات. وبدأ أحد الأجهزة الجديدة بسجلات قديمة، ما أدى إلى إعدادات توجيه غير صحيحة.
كيف استجبنا؟
- نبهتنا المراقبة الآلية إلى فشل عمليات الكتابة، ما استدعى إعلان حادث.
- تعافت عمليات الكتابة عندما أصبح جهاز بسجلات صحيحة هو القائد.
كيف نجعل حوادث كهذه أقل احتمالاً أو أقل تأثيراً؟
- أُجريت تحسينات على طريقة إخراج خوادم قاعدة البيانات من الخدمة لمنع بقاء سجلات قديمة.
19 أكتوبر 15:49 UTC (استمر ساعة و7 دقائق)
المدة: نحو ساعة و7 دقائق.
ستُقدم تفاصيل هذا الحادث في تقارير مستقبلية.
المصدر: GitHub Blog