في سبتمبر، شهدت GitHub حادثتين أدت إلى تدهور الأداء عبر خدماتها. غطى التحديث السابق المحتوى حتى أغسطس، ولم يتم نشر تحديث آخر في سبتمبر بينما تناول محتوى عام آخر انقطاع خدمة 17 أغسطس. يغطي هذا الإصدار التقدم المحرز على مدار الشهرين الماضيين.
باختصار عن أغسطس وسبتمبر: تم تقليل الضغط على قواعد البيانات المشتركة، وإضافة ضوابط للحمل الزائد، وتوفير مساحة عمل لـ GitHub Actions، وتوسيع احتواء الأعطال لطلبات السحب (pull requests)، ونقل المزيد من أعباء عمل الإنتاج إلى Azure.
بحلول 7 أكتوبر، تم نشر 120 من أصل 160 خدمة إنتاج في منطقة وسط الولايات المتحدة، وتم نقل 13 من أصل 51 قاعدة بيانات MySQL أساسية. تعاملت Azure أيضًا مع 65.4% من حركة قراءة البيانات لتطبيق GitHub الأساسي، و48.3% من حركة قراءة Git، و80.2% من حركة معالجة التدفق. تقيس هذه النسب المئوية أعباء عمل مختلفة ولا ينبغي جمعها.
تم إيقاف عمليات النشر وزيادات حركة المرور في منطقة وسط الولايات المتحدة في 11 سبتمبر بسبب عدم تساوي القدرة عبر مناطق التوفر. استؤنفت الزيادات الدائمة في 18 سبتمبر بعد تخفيف مؤقت، لكن عمل القدرة الدائمة مستمر، بهدف إطلاق جميع القدرات المتاحة بحلول نهاية أكتوبر. لم يتم تحقيق هدف 30 سبتمبر الطموح لنشر كل خدمة إنتاج هناك. خلال عملية تجاوز فشل قاعدة بيانات مخططة، قامت عملية طوارئ آلية بفصل نسخ قاعدة بيانات وسط الولايات المتحدة وعطلت العملاء في تلك المنطقة. تم تعطيل هذه العملية أثناء عمليات التسليم المخطط لها مع تحسين الاسترداد.
خارج عملية الترحيل الإقليمية، تم نقل 24 جدولًا أساسيًا للمصادقة من أقدم قاعدة بيانات مشتركة لـ GitHub، مما أزال ما يقرب من مليون استعلام في الثانية من نسخها المتماثلة. أزال تجمع قواعد البيانات الذي يدعم المشكلات وطلبات السحب ما يقرب من 980 مليون صف تاريخ تحرير غير ضروري، مما أدى إلى إنشاء ما يقدر بـ 1.8 تيرابايت من مساحة التخزين القابلة للاسترداد. انخفضت حالات الجمود الأسبوعية بنسبة 77% تقريبًا عن ذروتها في يونيو، ويمنع التنظيف المستمر الآن عودة نفس النمو غير المحدود.
يمكن الآن لنصف حركة مرور طلبات السحب التي تم أخذ عينات منها الاستمرار بوظائف محدودة عند فشل تبعية مشتركة. أظهرت نتائج الإنتاج أن العديد من عمليات القراءة ظلت متاحة أثناء حادثة قاعدة بيانات مشتركة. يمكن لتوجيه حركة مرور قاعدة البيانات أيضًا إضافة سعة تلقائيًا أثناء الارتفاعات؛ توسعت مجموعة واحدة من 14 إلى 19 مثيلًا خلال زيادة في نشاط طلبات السحب في 23 سبتمبر. يسمح التحكم في الحمل الزائد للإنتاج الآن للمستجيبين بحماية تدفقات عمل واجهة برمجة التطبيقات والويب ذات الأولوية الأعلى عن طريق رفض الطلبات ذات الأولوية الأقل قبل التشبع الأوسع. تم الانتهاء من وثائق وتدريب المشغلين.
اكتسبت GitHub Actions أيضًا مساحة تشغيل. أدت التغييرات في الإنتاج إلى تقليل عمليات Redis المقاسة بنسبة 28% تقريبًا ووحدة المعالجة المركزية النسبية بنسبة 30% تقريبًا. قللت ذاكرة التخزين المؤقت للبنية التحتية المنفصلة من عرض النطاق الترددي لـ Redis بنسبة 84%، ومتوسط وقت الاستجابة بنسبة 66%، ومتوسط وقت الاستجابة لطلب المخزون الأساسي بنسبة 96%، والطلبات في قائمة الانتظار بنسبة 95%.
تعد حادثة انقطاع خدمة Actions في 6 أغسطس، وحادثة انقطاع github.com في 17 أغسطس، وتعطيل تجاوز الفشل في سبتمبر، والتوقف المتحكم فيه للقدرة، تذكيرًا بأن التحسينات المقاسة لا تهم إلا عندما تقلل من مخاطر العملاء في ظل ظروف حقيقية. يبقى المبدأ كما هو: التوفر، ثم القدرة، ثم الميزات.
ماذا حدث في حادثة 13 سبتمبر؟
في 13 سبتمبر 2026، في الساعة 09:16 بالتوقيت العالمي المنسق، واستمرت لمدة ساعة و28 دقيقة، حدثت حادثة أدت إلى تدهور الأداء.
ما الخطأ الذي حدث ولماذا؟
زادت مهمة تنظيف بيانات خلفية الحمل على قاعدة بيانات مشتركة. كانت المهمة تحتوي على حماية مصممة لإبطاء عمليات الكتابة الخاصة بها عندما تتأخر النسخ المتماثلة لقاعدة البيانات، لكن الحماية لم تأخذ في الاعتبار الحمل الوارد على خادم قاعدة البيانات الأساسي. ونتيجة لذلك، استمرت المهمة في العمل حتى وصل الخادم الأساسي إلى حد اتصالاته. عندما نفدت الاتصالات المتاحة من الخادم الأساسي، لم تتمكن الطلبات التي تعتمد عليه من الاكتمال بشكل موثوق.
زاد عاملان آخران من التأثير وأخرا الاسترداد. أولاً، لم يكن هناك مهلة سريعة على استدعاءات قاعدة البيانات هذه، لذلك انتظرت معالجات الطلبات قاعدة البيانات المتوقفة بدلاً من الفشل بسرعة. ثانيًا، استمرت حلقة إعادة المحاولة حول إنشاء الرمز المميز في إعادة إرسال عمليات الكتابة التي كانت تفشل بالفعل، مما أبقى قاعدة البيانات مشبعة بدلاً من السماح لها بالاسترداد.
كيف كانت الاستجابة؟
بدأت مهمة تنظيف بيانات خلفية في الكتابة إلى قاعدة بيانات مشتركة. راقبت حماية المهمة تأخر النسخ المتماثلة لكنها لم تأخذ في الاعتبار الحمل المتزايد على خادم قاعدة البيانات الأساسي. نفدت الاتصالات المتاحة من الخادم الأساسي، مما تسبب في فشل الطلبات عبر الخدمات التابعة أو عملها ببطء. اكتشفت المراقبة الآلية الحادثة، وتم تتبع الأعطال إلى الحمل على قاعدة البيانات المشتركة. تم تقليل الحمل الداخلي وإيقاف المهمة الخلفية مؤقتًا. استعادت قاعدة البيانات عافيتها، وعادت معدلات الأخطاء عبر الخدمات المتأثرة إلى طبيعتها.
كيف يتم تقليل احتمالية أو تأثير حوادث مماثلة؟
يتم تنفيذ ضمانات إضافية لتحسين مرونة قاعدة البيانات وتوفر الخدمة. ستتحكم هذه الإجراءات بشكل أفضل في المعالجة الخلفية بناءً على سعة قاعدة البيانات المتاحة، وتقلل من عمليات إعادة المحاولة غير الضرورية أثناء الأعطال، وتحد من تأثير طلبات قاعدة البيانات البطيئة. كما يتم تحسين سلوك بدء تشغيل الخدمة لضمان عدم تأثير مشكلات اتصال قاعدة البيانات المؤقتة على استرداد الخدمة بشكل غير ضروري.
ماذا حدث في حادثة 28 سبتمبر؟
في 28 سبتمبر 2026، في الساعة 21:16 بالتوقيت العالمي المنسق، واستمرت لمدة 52 دقيقة، حدثت حادثة أخرى.
ما الخطأ الذي حدث ولماذا؟
تستخدم مراجعة أكواد Copilot خدمة منفصلة لتشغيل المراجعات، ويتم إرجاع نسختين من النتائج: نسخة محدودة تستبعد تعليقات المراجعة ونسخة كاملة تتضمن المراجعة المكتملة. تنشر مراجعة أكواد Copilot المراجعات فقط من النسخة الكاملة. بدأ تغيير في تلك الخدمة في إرسال النسخة الكاملة لبعض العملاء فقط. بالنسبة للعملاء الآخرين، تم إرسال النسخة المحدودة فقط.
نتيجة لذلك، لم تتمكن مراجعة أكواد Copilot من إنشاء مراجعة، لكنها أبلغت أن المهمة قد اكتملت بنجاح. لم يتم اكتشاف نتائج المراجعة المفقودة بسبب نقص المراقبة. تم اكتشاف الحادثة عندما ظلت بعض المراجعات غير مكتملة لأكثر من 30 دقيقة، مما أدى إلى تنبيه المستجيبين الأوائل. تم تخفيف الحادثة عن طريق التراجع عن التغيير.
كيف كانت الاستجابة؟
بدأ طرح تغيير على الخدمة التي تشغل مراجعات أكواد Copilot، وتوقفت نتائج المراجعة عن الظهور في طلبات السحب. وصل التغيير إلى كل بيئة. بدأت المراجعات في تجاوز المهلة، مما أدى إلى تنبيه فريق مراجعة أكواد Copilot. تم إعلان الحادثة. تم تتبع الأعطال إلى التغيير وبدأ التراجع عنه. بينما أكمل التراجع الفحوصات المطلوبة، تم نشر الحادثة على صفحة حالة GitHub. ثم وصل التراجع إلى جميع المناطق المتأثرة. تم حل الحادثة ونصح العملاء بطلب المراجعات المتأثرة مرة أخرى.
كيف يتم تقليل احتمالية أو تأثير حوادث مماثلة؟
يتم تعزيز موثوقية مراجعات أكواد Copilot عن طريق إضافة ضمانات طوال عملية المراجعة والتسليم. ستساعد هذه التحسينات في ضمان تسليم المراجعات المكتملة بنجاح، وتسمح للمراجعات الفاشلة بالاسترداد تلقائيًا، وتوفر إشعارًا مبكرًا عند حدوث مشكلات. كما يتم تحسين عمليات المراقبة والنشر بحيث يمكن تحديد المشكلات ومعالجتها بسرعة أكبر.
