كشفت GitHub في تقرير التوافر لشهر سبتمبر 2026 عن حادثتين أثرتا في أداء خدماتها، بالتوازي مع تقدم في إعادة توزيع البنية التحتية وتحسين قدرة قواعد البيانات على تحمل الضغط. وتشير الشركة إلى أن أعمال المعالجة لم تكتمل بعد، رغم تنفيذ تغييرات تهدف إلى تقليل مخاطر الأعطال عند ارتفاع الحمل أو فشل أحد المكونات المشتركة.
حتى 7 أكتوبر، كانت 120 خدمة من أصل 160 خدمة إنتاجية منشورة في منطقة Central US، فيما نُقلت 13 قاعدة بيانات MySQL أساسية من أصل 51. تعاملت Azure مع 65.4% من حركة القراءة لتطبيق GitHub الأساسي، و48.3% من حركة قراءة Git، و80.2% من حركة معالجة التدفقات. وتؤكد الشركة أن هذه النسب تخص أحمالاً مختلفة ولا ينبغي جمعها.
تقدم في نقل البنية التحتية مع تأخر عن الموعد
أوقفت GitHub عمليات النشر وزيادة حركة المرور في Central US يوم 11 سبتمبر بسبب تفاوت السعة بين مناطق التوافر. واستؤنفت الزيادات الدائمة في 18 سبتمبر بعد توفير سعة مؤقتة، لكن أعمال السعة طويلة الأجل ما زالت مستمرة، مع هدف إتاحة كامل السعة المتوفرة بحلول نهاية أكتوبر. ولم تحقق الشركة هدفها الطموح المتمثل في نشر جميع خدمات الإنتاج هناك بحلول 30 سبتمبر.
وخلال عملية تحويل مخطط لقاعدة بيانات، أدى إجراء طوارئ آلي إلى فصل نسخ قواعد البيانات في Central US، ما تسبب في اضطراب للعملاء في المنطقة. عطلت GitHub هذا الإجراء أثناء عمليات التسليم المخططة إلى حين تحسين آليات التعافي.
تقليل ضغط قواعد البيانات واحتواء الأعطال
نقلت GitHub 24 جدولاً من جداول نظام المصادقة الأساسي بعيداً عن أقدم قاعدة بيانات مشتركة لديها، ما أزال نحو مليون استعلام في الثانية من النسخ التابعة. كما حُذفت نحو 980 مليون سجل غير ضروري من تاريخ التعديلات في الكتلة التي تدعم Issues وPull Requests، وهو ما وفر نحو 1.8 تيرابايت من التخزين القابل للاستعادة. وانخفضت حالات التعارض بين المعاملات أسبوعياً بنحو 77% مقارنة بذروة يونيو.
وأصبحت نصف حركة Pull Requests التي شملتها العينة قادرة على الاستمرار بوظائف محدودة عند تعطل اعتماد مشترك. كما يمكن لتوجيه حركة قواعد البيانات إضافة سعة تلقائياً أثناء الارتفاعات؛ إذ توسعت إحدى المجموعات من 14 إلى 19 نسخة خلال زيادة في نشاط Pull Requests يوم 23 سبتمبر. وأضافت GitHub آلية للتحكم في التحميل تتيح رفض الطلبات الأقل أولوية قبل وصول الخدمات إلى تشبع أوسع.
حادثتا سبتمبر
في 13 سبتمبر، تسبب عمل تنظيف بيانات في الخلفية في زيادة الحمل على قاعدة بيانات مشتركة. كانت آلية الحماية تراقب تأخر النسخ التابعة، لكنها لم تراقب الحمل المتراكم على الخادم الأساسي، الذي بلغ حد الاتصالات المتاحة. أدى غياب مهلة قصيرة للاستعلامات إلى بقاء معالجات الطلبات منتظرة، كما واصلت حلقة لإعادة المحاولة إرسال عمليات كتابة فاشلة. استمر الحادث ساعة و28 دقيقة، وانتهى بعد خفض الحمل الداخلي وإيقاف المهمة.
في 28 سبتمبر، أدى تغيير في الخدمة التي تشغل مراجعات Copilot البرمجية إلى إرسال نسخة محدودة من نتائج المراجعة لبعض العملاء بدلاً من النسخة الكاملة التي تتضمن التعليقات. لذلك بدت المهام مكتملة رغم عدم ظهور المراجعات في طلبات السحب. استمر الحادث 52 دقيقة، وعالجته GitHub بالتراجع عن التغيير، مع مطالبة العملاء بإعادة طلب المراجعات المتأثرة.
ما الذي يتغير عملياً؟
توضح الحادثتان أن تحسينات السعة لا تكفي وحدها؛ فالموثوقية تعتمد أيضاً على اكتشاف الفشل مبكراً، وإيقاف عمليات إعادة المحاولة غير المفيدة، وضمان عدم إعلان نجاح مهمة قبل تسليم مخرجاتها فعلياً. وتعمل GitHub على إضافة ضوابط لمعالجة الخلفية، وتحسين سلوك بدء الخدمات، وتعزيز مراقبة وتسليم نتائج Copilot code review.
كما سجلت GitHub تحسناً في البنية الخاصة بـGitHub Actions؛ إذ انخفضت عمليات Redis المقاسة بنحو 28% واستخدام المعالج النسبي بنحو 30%. وخفّضت طبقة تخزين مؤقت منفصلة عرض النطاق المستخدم من Redis بنسبة 84%، وزمن الاستجابة المتوسط بنسبة 66%، وزمن الاستجابة الوسيط لطلب المخزون الأساسي بنسبة 96%، والطلبات المنتظرة بنسبة 95%. وتبقى الأسئلة المفتوحة مرتبطة بقدرة الشركة على إكمال أعمال السعة ومنع تكرار أعطال الاعتماديات المشتركة تحت ظروف الإنتاج الفعلية.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.