في أكتوبر، شهدنا ثماني حوادث أدت إلى تدهور الأداء عبر خدمات GitHub. نواصل مشاركة التحديثات الشهرية حول العمل وراء توفر وموثوقية GitHub. النسخة المختصرة لشهر أكتوبر: أضفنا سعة Azure كبيرة قابلة للتطوير بشكل مستقل وأزلنا عدة طرق يمكن أن تتصاعد بها الأعطال. ومع ذلك، فإن انقطاع عمليات الكتابة، وفجوات المراقبة أثناء ترحيل البيانات، واضطراب الشبكة الإقليمي، عززت الحاجة إلى أن يقترن نمو السعة بعمليات أكثر أمانًا، وعزل أقوى، واستعادة إقليمية مُتحقق منها. اعتبارًا من 9 نوفمبر، كانت 140 من أصل 151 خدمة إنتاج و32 من أصل 50 قاعدة بيانات MySQL رئيسية تعمل في Azure Central US. خدمت Azure 63% من قراءات الخدمات المُرحّلة، و66% من قراءات المونوليث، و52% من قراءات Git. أكملنا أيضًا توسيع الحوسبة عبر جميع مجموعات Kubernetes التسع في Central US، مما ضاعف السعة. هذه السعة تحمل بالفعل نموًا حقيقيًا. زادت حركة مرور الخدمات المُرحّلة بنسبة 82% منذ مارس، حيث استوعبت Central US النمو الذي تجاوز أعلى حمل أسبوعي متوسط تم تقديمه سابقًا من مركز البيانات الحالي لدينا. وهذا يمنح GitHub مساحة أكبر للنمو دون دفع البيئة الأصلية إلى ما يتجاوز نطاق تشغيلها السابق. أجرينا أيضًا العديد من التحسينات المستهدفة على الموثوقية. زادت تغييرات Actions من سعة طلبات مستوى التحكم الحرجة في Azure. قلل تخفيف منفصل لبوابة NAT الاستخدام بنسبة 85%؛ فشلت أربع وظائف إنتاج أثناء التغيير، مقارنة بحوالي 800 وظيفة متوقعة بدون التخفيف. كما أن حدود الاتصال وتحسينات العميل الأخرى تقلل الآن من فرصة تحول انقطاع التبعية إلى عاصفة إعادة اتصال أوسع. أزلنا مصادر مركزة لحمل قاعدة البيانات أيضًا. تم نقل نقطة نهاية GitHub Actions عالية الحركة التي تتعامل مع أكثر من 250 مليون طلب يوميًا إلى مسار خدمة أكثر كفاءة، مما قلل قراءات قاعدة البيانات في الذروة بنسبة 85%. أدى طلب ثلاثة أحرف على الأقل قبل البحث في مواضيع المستودعات إلى تقليل الاستعلامات البطيئة أو المنهية لهذا النمط بنسبة 98% تقريبًا. لم تكن الموثوقية لا تزال عند المستوى المطلوب. كشفت انقطاعات الكتابة في 7 أكتوبر عن تفاعل غير آمن بين تنسيق قاعدة البيانات وتوجيه الإنتاج. أثر اضطراب شبكة Azure في 29 أكتوبر على جميع مناطق التوفر الثلاث في Central US وما لا يقل عن 34,128 مستخدمًا مسجلاً الدخول. تتبع تفاصيل هذه الحوادث وغيرها.
تأخر بناء East US 3 بحوالي أسبوع واحد عن الخطة. تبدأ المرحلة التالية بأول زيادة حركة مرور مُتحقق منها في الأسبوع الأول من ديسمبر، بينما نواصل تعزيز سلامة الترحيل، وعزل التبعيات، والاستعادة الإقليمية. المبدأ يبقى كما هو: التوفر، ثم السعة، ثم الميزات.
5 أكتوبر 19:11 بالتوقيت العالمي المنسق (استمر 3 ساعات و38 دقيقة) المدة: حوالي 3 ساعات و45 دقيقة. ربما رأى العملاء وظائف GitHub Actions على المُشغّلات المستضافة من GitHub تبقى في قائمة الانتظار لفترة أطول بكثير من المعتاد، وفشلت بعض عمليات تشغيل سير العمل في البدء. خلال أسوأ فترة، التي استمرت حوالي 90 دقيقة، لم تبدأ معظم الوظائف على المُشغّلات المستضافة من GitHub في غضون خمس دقائق. خف التأثير مع تحويلنا إلى مناطق صحية وإضافة سعة. لم تتأثر المُشغّلات المستضافة ذاتيًا. كانت مواقع GitHub Pages التي تُبنى باستخدام Actions بطيئة في التحديث، على الرغم من أن المواقع الموجودة استمرت في الخدمة بشكل طبيعي. رأى بعض العملاء أيضًا أخطاء في قوائم المستودعات، وصفحات الترخيص والفوترة، وبعض ميزات Copilot.
ما الذي حدث بشكل خاطئ ولماذا؟
بقيت وظائف Actions في قائمة الانتظار أو فشلت في البدء لأن الخدمة التي تُعيّن الوظائف للمُشغّلات المستضافة من GitHub توقفت عن العمل بشكل موثوق. أدى فشل جزئي في الشبكة من جانب مزود الخدمة السحابية لدينا إلى تعطيل بعض الاتصالات بين إحدى مناطق مركز البيانات لدينا وقواعد البيانات المستضافة على السحابة التي تعتمد عليها هذه الخدمة. بدلاً من الفشل السريع، انتظرت الخدمة حتى تنتهي مهلة هذه المكالمات. تراكمت المكالمات المنتظرة حتى نفدت ذاكرة الخدمة وأعادت التشغيل. ثم تحولت الوظائف إلى نفس الخدمة في منطقة صحية، والتي لم تكن لديها سعة كافية للطلب الإضافي وبدأت في الفشل أيضًا. في الوقت نفسه، توقفت المُشغّلات التي مرت عليها عدة دقائق دون تلقي وظيفة عن العمل وكانت بطيئة في الاستبدال، لذلك كان عدد أقل من المُشغّلات متاحًا لالتقاط الوظائف.
كيف استجبنا؟
- بدأ فشل جزئي في الشبكة، وبدأت وظائف Actions في التراكم.
- كشفت التنبيهات عن الأخطاء وبطء تعيين الوظائف، وأعلنا عن حادث.
- أعدنا نشر الخدمة التي تُعيّن الوظائف للمُشغّلات المستضافة من GitHub، لكنها لم تتعافَ. تتبعنا الأعطال إلى مشكلة الشبكة.
- قمنا بتحويل قواعد البيانات والتخزين المتأثرة إلى مناطق صحية، خدمة تلو الأخرى، وأضفنا سعة. تعافت Actions، لكن بعض الخدمات المتأثرة الأخرى استمرت في الفشل حتى بعد التحويل.
- عملنا مع مزود الخدمة السحابية لدينا لحل فشل الشبكة. تعافت الخدمات المتبقية، وحللنا الحادث.
كيف نجعل حوادث كهذه أقل احتمالاً أو أقل تأثيرًا؟
- نجعل الخدمة التي تُعيّن الوظائف للمُشغّلات المستضافة من GitHub أفضل قدرة على التعامل مع الزيادات المفاجئة في الحمل، بحيث تستمر في العمل عندما تحول منطقة أخرى وظائف إضافية إليها.
- لدينا الآن أولوية موسعة لتعيين المُشغّلات بناءً على ملف تعريف العميل عندما تكون سعة المُشغّلات المتاحة متدهورة.
- نغير سلوك المُشغّلات المستضافة من GitHub لتقليل وقت الاستعادة عندما تتدهور خدمات تعيين الوظائف لفترة من الوقت.
- نحسن سرعة اكتشافنا وتحديدنا لأعطال الشبكة الجزئية بين مراكز البيانات لدينا والخدمات المستضافة على السحابة التي تعتمد عليها.
6 أكتوبر 19:57 بالتوقيت العالمي المنسق (استمر 3 ساعات و43 دقيقة) المدة: حوالي 6 دقائق من الطلبات الفاشلة أو البطيئة عبر github.com، تليها حوالي 3 ساعات و30 دقيقة تم خلالها إيقاف ترحيل المؤسسات مؤقتًا. ربما رأى العملاء أخطاء في الخادم أو استجابات بطيئة عند تسجيل الدخول، أو العمل مع المستودعات وطلبات السحب، أو استدعاء واجهة برمجة التطبيقات (API)، أو استخدام GitHub Codespaces. كانت إعادة المحاولة بعد فترة قصيرة ستنجح، ولحقت عمليات تسليم الويب هوك المتأخرة بعد ذلك بوقت قصير. في الذروة، فشل أو انتهت مهلة حوالي 1.3% من جميع الطلبات، وشهدت حوالي 6.4 ألف مؤسسة طلبًا واحدًا على الأقل فاشلاً أو بطيئًا. تم إيقاف عمليات الترحيل مؤقتًا للعملاء الذين يستخدمون GitHub Enterprise Importer، واستؤنفت بمجرد نشر الإصلاح.
ما الذي حدث بشكل خاطئ ولماذا؟
تسبب ارتفاع في نشاط الترحيل في إرسال GitHub Enterprise Importer دفعة من الاستعلامات الكبيرة جدًا إلى قاعدة بيانات مشتركة. استغرقت هذه الاستعلامات وقتًا أطول بكثير من المعتاد، وبالتزامن مع حركة المرور العادية، استخدمت جميع اتصالات قاعدة البيانات المتاحة، مما منع ميزات github.com الأخرى التي تعتمد على نفس قاعدة البيانات من إكمال طلباتها. لم يقلل المُستورد حمولته عندما أصبحت قاعدة البيانات محملة بشكل زائد. انتهى التأثير في غضون دقائق، بمجرد أن أنهى المُستورد استعلاماته في قائمة الانتظار وتم تحرير اتصالات قاعدة البيانات. لمنع تكرار ذلك، أوقفنا عمليات الترحيل مؤقتًا حتى نشرنا تخفيفًا يقوم بتشغيل هذه الاستعلامات على دفعات أصغر.
كيف استجبنا؟
- تسبب ارتفاع في أعمال الترحيل في تحميل زائد على قاعدة بيانات مشتركة، مما أدى إلى فشل أو تباطؤ الطلبات عبر github.com.
- اكتشفت المراقبة الآلية الأعطال وقامت بتنبيه مهندسينا المناوبين.
- توقفت الأخطاء من تلقاء نفسها في غضون دقائق.
- أعلنا عن حادث وأوقفنا عمليات ترحيل المؤسسات مؤقتًا لمنع تكرار ذلك أثناء تحقيقنا في السبب.
- بمجرد نشر التخفيف، استأنفنا عمليات الترحيل وحللنا الحادث.
كيف نجعل حوادث كهذه أقل احتمالاً أو أقل تأثيرًا؟
- قمنا بتحسين الاستعلام الذي يرسله GitHub Enterprise Importer إلى قاعدة البيانات بحيث يبقى كل واحد صغيرًا وثابت الحجم.
- نقوم بأتمتة تراجع المُستورد عندما تكون قاعدة البيانات تحت الضغط، مما يخفف الحمل قبل أن يؤثر على خدمات GitHub الأخرى.
- نضيف تنبيهات لقاعدة البيانات التي تشير إلى الاستعلامات التي تقوم بعمل أكثر بكثير من المعتاد وتحدد الاستعلام المسؤول، حتى نتمكن من العثور على مشاكل مثل هذه وإصلاحها بشكل أسرع.
7 أكتوبر 15:14 و 17:17 بالتوقيت العالمي المنسق (استمرت ساعة و11 دقيقة، و47 دقيقة على التوالي) المدة: استمر انقطاعان منفصلان لعمليات الكتابة حوالي 10 دقائق و9 دقائق، بإجمالي حوالي 19 دقيقة. كان الثاني تكرارًا للأول، بنفس السبب. ربما رأى العملاء أخطاء عند دفع التعليمات البرمجية، أو تسجيل الدخول، أو تحديث طلبات السحب أو المشكلات، أو إجراء تغييرات عبر واجهة برمجة التطبيقات (API). تأثرت أيضًا الويب هوكس، وتطبيقات GitHub و OAuth، و Actions، وفحص التعليمات البرمجية، و Codespaces، و Copilot. لم يتأثر عرض المحتوى إلى حد كبير. لم تُفقد البيانات التي تم حفظها بالفعل، ونجحت الإجراءات التي فشلت أثناء الانقطاعات عند إعادة المحاولة بعد الاستعادة. بلغت ذروة فشل طلبات الويب وواجهة برمجة التطبيقات 8.9% في الانقطاع الأول و9.3% في الثاني، مما أثر على أكثر من 12,000 وأكثر من 11,000 مؤسسة على التوالي. ربما تأثرت بعض المؤسسات بكلا الانقطاعين.
ما الذي حدث بشكل خاطئ ولماذا؟
أثناء الصيانة الدورية، استبدلنا الأجهزة التي تدير مكان إرسال عمليات الكتابة إلى قاعدة البيانات. بدأ جهاز جديد بسجلات قديمة لا تزال تُدرج خوادم قواعد بيانات متقاعدة. بمجرد انتخابه قائدًا تلقائيًا، نشر إعدادات توجيه أرسلت عمليات الكتابة لعدة قواعد بيانات أساسية إلى تلك الخوادم المتقاعدة. تجاوزت الإعدادات غير الصحيحة التحقق الحالي لدينا ودخلت حيز التنفيذ على الفور. لاحقًا، لم تحترم مهمة صيانة آلية توقف الصيانة وأطلقت انتخابًا آخر، ولأن الجهاز الجديد لم يكن قد أُزيل بعد، أصبح قائدًا مرة أخرى.
كيف استجبنا؟
- نبهتنا المراقبة الآلية إلى فشل عمليات الكتابة، وأعلنا عن حادث.
- تعافت عمليات الكتابة عندما أصبح جهاز راسخ بسجلات صحيحة قائدًا ونشر إعدادات صحيحة.
- تتبعنا السبب إلى الجهاز الجديد، وحللنا الحادث الأول، وأوقفنا الصيانة الآلية مؤقتًا لمنع التكرار.
- عندما لم تحترم مهمة صيانة التوقف وتكرر الانقطاع، أعلنا عن حادث ثانٍ.
- تعافت عمليات الكتابة عندما أصبح جهاز راسخ قائدًا مرة أخرى. أزلنا الجهاز الجديد وحللنا الحادث الثاني.
كيف نجعل حوادث كهذه أقل احتمالاً أو أقل تأثيرًا؟
- قمنا بتحسين كيفية إيقاف تشغيل خوادم قواعد البيانات، بحيث لا تُترك سجلات قديمة.
- شددنا الضوابط على إضافة أجهزة جديدة تدير توجيه قاعدة البيانات، والتأكد من أن الصيانة الآلية تحترم التوقف المؤقت.
- عززنا التحقق من إعدادات توجيه قاعدة البيانات، بحيث يتم اكتشاف الإعدادات غير الصحيحة قبل دخولها حيز التنفيذ.
19 أكتوبر 15:49 بالتوقيت العالمي المنسق (استمرت ساعة و7 دقائق) المدة: حوالي ساعة و28 دقيقة. ربما رأى العملاء تأخيرات في تحديثات حالة سير عمل GitHub Actions، والسجلات، والفحوصات. شهد حوالي 5% من الوظائف على المُشغّلات المستضافة من GitHub تأخيرات في البدء، وفشلت نسبة صغيرة جدًا من عمليات تشغيل سير العمل، وأعادت بعض الطلبات إلى واجهة برمجة تطبيقات REST لوظائف Actions أخطاء. تأخرت أيضًا عمليات نشر GitHub Pages وأحداث الويب هوك لسير العمل والفحص التي تم إنشاؤها بواسطة عمليات تشغيل Actions. لجزء من هذا الوقت، تدهورت التحديثات المباشرة على github.com وبحث التعليمات البرمجية.
ما الذي حدث بشكل خاطئ ولماذا؟
فقدت خدمة Actions داخلية تخزن سجلات سير العمل وحالة التشغيل اتصالاتها ببعض خوادم التخزين المؤقت في منطقة سحابية واحدة. ثم أعاد كل خادم يشغل تلك الخدمة محاولة تلك الاتصالات في نفس الوقت. معًا، أدت عمليات إعادة المحاولة هذه إلى تشبع اتصالات الشبكة بين مركز بيانات GitHub وتلك المنطقة، مما أدى إلى تعطيل الخدمات الأخرى التي تستخدم نفس الرابط.
كيف استجبنا؟
- اكتشفت التنبيهات الآلية الأعطال، وأعلنا عن حادث، وتتبعنا المشكلة إلى رابط الشبكة المشترك.
- وجهنا خدمة Actions بعيدًا عن بعض خوادم التخزين المؤقت الخاصة بها في تلك المنطقة، لكن الرابط كان لا يزال فوق السعة.
- وجهناها بعيدًا عن بقية خوادم التخزين المؤقت تلك، وتعافى الرابط.
- رفعنا حدود المعالجة لمسح تراكم Actions، وحللنا الحادث بمجرد تعافي جميع الخدمات المتأثرة.
كيف نجعل حوادث كهذه أقل احتمالاً أو أقل تأثيرًا؟
- لقد حددنا مدى سرعة هذه الخدمة Actions في فتح اتصالات جديدة بخوادم التخزين المؤقت الخاصة بها.
- نقوم بالتنبيه عند حدوث ارتفاعات في الاتصالات الجديدة من هذه الخدمة لتحديد ومعالجة المصدر بشكل أسرع.
21 أكتوبر 14:52 بالتوقيت العالمي المنسق (استمر 4 ساعات و30 دقيقة) المدة: حوالي 6 ساعات و46 دقيقة. ربما رأى العملاء تأخيرات في تحديثات طلبات السحب، وتحديثات حالة سير عمل GitHub Actions، وعمليات تسليم الويب هوك. بعد الدفع، كانت الالتزامات الجديدة بطيئة في الظهور على طلبات السحب. بدأت سير العمل التي تم تشغيلها بواسطة الدفع متأخرة. يمكن أن تبدو فحوصات الحالة من سير عمل Actions عالقة في طلبات السحب، مما أدى إلى تأخير عمليات الدمج التي تتطلب اجتياز هذه الفحوصات. تعافت هذه الميزات في غضون حوالي 2 إلى 3.5 ساعة. تأثرت أحداث سجل التدقيق لأطول فترة. استغرقت الأنشطة الأخيرة وقتًا أطول للظهور عندما بحث العملاء في سجلات التدقيق الخاصة بهم، مع تأخيرات تصل إلى ساعة و50 دقيقة. تم تحديث أحداث سجل التدقيق بالكامل بعد حوالي 6 ساعات و46 دقيقة. قد تكون بعض عمليات تسليم الويب هوك من هذه الفترة مفقودة من سجل تسليم الويب هوك، على الرغم من تسليم الويب هوكس نفسها.
ما الذي حدث بشكل خاطئ ولماذا؟
كانت بعض الخوادم في منصة تدفق الأحداث لدينا قريبة من حدود ذاكرتها، ويزداد استخدام الذاكرة على هذه الخوادم مع عدد اتصالات العميل. عندما فشلت الطلبات إلى هذه الخوادم، تم فتح اتصالات جديدة على الفور، مما زاد من عدد الاتصالات والذاكرة التي استخدمتها. أدت الزيادة في استخدام الذاكرة إلى تباطؤ الخوادم وتحميلها بشكل زائد. أخرجنا الخوادم المحملة بشكل زائد من الخدمة، وانتقلت حركة المرور الخاصة بها إلى خوادم أخرى. ثم أصبحت تلك الخوادم محملة بشكل زائد أيضًا، وانتشرت المشكلة إلى المزيد من الخوادم خلال الساعة التالية. بدأنا في إعادة موازنة الأقسام المحملة بشكل زائد على الوسطاء الذين لديهم سعة متاحة، وهذا خفف المشكلة. استغرقت سجلات التدقيق أطول وقت للتعافي. استمرت الخدمة التي تكتب أحداث سجل التدقيق في إعادة التشغيل بسبب أخطاء من المنصة لأكثر من ساعتين وتأخرت أكثر. بمجرد استقرارها، لم تتمكن من كتابة الأحداث إلا بمعدل محدود، لذلك استغرق مسح التراكم عدة ساعات أخرى.
كيف استجبنا؟
- أعلنا عن حادث ونقلنا بعض حركة المرور من خادم محمل بشكل زائد، لكن المزيد من الخوادم أصبحت محملة بشكل زائد بعد ذلك بوقت قصير.
- قسمنا حركة المرور الأكثر ازدحامًا إلى أقسام أكثر ونقلناها إلى خوادم أقل تحميلًا. تعافت جميع الميزات المتأثرة باستثناء سجلات التدقيق تدريجيًا.
- بمجرد توقف خدمة سجل التدقيق عن إعادة التشغيل، رفعنا المعدل الذي يمكنها به كتابة الأحداث حتى يتم مسح التراكم بشكل أسرع.
- حللنا الحادث بمجرد عودة تأخيرات سجل التدقيق إلى النطاق الصحي، وتم مسح التراكم المتبقي بعد ذلك.
كيف نجعل حوادث كهذه أقل احتمالاً أو أقل تأثيرًا؟
- أضفنا تأخيرات عشوائية لإعادة الاتصال بعد طلب فاشل، بحيث لا تتعرض الخوادم البطيئة بالفعل لدفعة من الاتصالات الجديدة.
- نقوم بالتنبيه مبكرًا بشأن استخدام ذاكرة الخادم، حتى نتمكن من نقل حركة المرور قبل أن يتباطأ الخادم.
- نضيف وجهة ثانية لبيانات تسليم الويب هوك يمكننا التبديل إليها، حتى نتمكن من الحفاظ على عمليات تسليم الويب هوك مستمرة إذا تباطأت منصة تدفق الأحداث لدينا.
- لقد قمنا بتحسين خطط العمل لدينا لنقل الأقسام الساخنة لمواقف مماثلة في المستقبل.
28 أكتوبر 14:12 بالتوقيت العالمي المنسق (استمرت ساعة و16 دقيقة) المدة: حوالي ساعة و32 دقيقة. ربما رأى العملاء أخطاء عند استخدام عدة نماذج من عائلة GPT في Copilot. أعادت الطلبات التي تستخدم هذه النماذج في Copilot Chat في بيئات التطوير المتكاملة (IDEs) وعلى github.com، و Copilot CLI، ومراجعة التعليمات البرمجية لـ Copilot، ووكيل ترميز Copilot أخطاء أو لم تكتمل. فشل حوالي واحد من كل 10 طلبات للنماذج المتأثرة. استمرت النماذج الأخرى في العمل، وتجنب اختيار نموذج آخر الأخطاء. قلل التحديد التلقائي للنموذج الأخطاء عن طريق إرسال بعض الطلبات إلى نموذج غير متأثر. تأثرت ميزات الإصلاح التلقائي وجودة التعليمات البرمجية في فحص التعليمات البرمجية، والتي تُبنى على نموذج محدد واحد بدون نموذج بديل للتبديل إليه، بشكل أكبر.
ما الذي حدث بشكل خاطئ ولماذا؟
يصل Copilot إلى هذه النماذج من خلال مزود نموذج خارجي ويستخدم بيانات اعتماد للمصادقة مع هذا المزود. أصبحت بيانات الاعتماد هذه غير صالحة، وبدأ المزود في رفض طلباتنا على أنها غير مصادق عليها، وأعادت خدمتنا هذه الرفوض إلى العملاء كأخطاء مصادقة. ترسل ميزات Copilot التي تستخدم هذه النماذج طلباتها عبر هذا المزود، لذلك بدأت في الفشل في نفس الوقت.
كيف استجبنا؟
- توقفت بيانات اعتماد نستخدمها مع مزود نموذج خارجي عن العمل، وبدأت الطلبات إلى النماذج المتأثرة في الفشل.
- نشرنا تحديثًا عامًا للحالة وأوصينا باختيار نموذج آخر في هذه الأثناء.
- تتبعنا الأخطاء إلى بيانات الاعتماد الخاصة بنا وأنشأنا بديلاً.
- بدأنا في نشر بيانات الاعتماد الجديدة، وبدأت الطلبات في التعافي بمجرد تحديث البيئة الأولى.
- أكملنا النشر في البيئات المتبقية، وتأكدنا من تعافي الطلبات إلى النماذج المتأثرة، وحللنا الحادث.
كيف نجعل حوادث كهذه أقل احتمالاً أو أقل تأثيرًا؟
- قمنا بتحسين كيفية تعامل خدمتنا مع فشل المصادقة من مزودي النماذج الخارجيين، بحيث يمكن إعادة محاولة الطلبات بدلاً من الفشل.
- نعزز كيفية إدارة بيانات الاعتماد لمزودي النماذج الخارجيين.
- نضيف تنبيهات لفشل المصادقة من مزودي النماذج الخارجيين، حتى نتمكن من تحديد ومعالجة هذا النوع من المشاكل بشكل أسرع.
30 أكتوبر 14:31 بالتوقيت العالمي المنسق (استمر 31 دقيقة) المدة: حوالي 9 دقائق. ربما رأى العملاء بعض الطلبات إلى github.com تتوقف لمدة تصل إلى حوالي 10 ثوانٍ ثم تفشل مع خطأ في الخادم. تأثرت عمليات دمج طلبات السحب وعمليات Git عبر SSH و Git LFS بشدة. في أسوأ نقطة، فشل حوالي 43% من محاولات الدمج، مقارنة بحوالي 3.5% من مكالمات واجهة برمجة التطبيقات (API). شهدت المشكلات، و GitHub Pages، والإشعارات، وتسجيل الدخول لتطبيقات GitHub وتطبيقات OAuth أيضًا أخطاء متقطعة.
ما الذي حدث بشكل خاطئ ولماذا؟
وصل تجمع اتصالات قاعدة البيانات الذي تستخدمه العديد من خدمات github.com إلى حده الأقصى، ولم تكن هناك اتصالات متاحة لعدة دقائق. انتظرت الطلبات الجديدة التي تحتاج إلى اتصال حتى انتهت مهلة الاتصال ثم فشلت. كان التجمع يعمل بالفعل بالقرب من سعته عندما بدأت بعض طلبات التحديث في الاحتفاظ باتصالاتها لفترة أطول بكثير من المتوقع. بدأ كل منها في كتابة تغيير، ثم أجرى بحثًا منفصلاً يمكن أن يستغرق عدة ثوانٍ، محتفظًا باتصاله محجوزًا ولكنه غير مستخدم طوال الوقت. مع مساحة صغيرة جدًا، ساعدت هذه الاتصالات المحتجزة في تجاوز التجمع.
كيف استجبنا؟
- استخدمت الطلبات كل اتصال في تجمع قاعدة البيانات المشترك، وبدأت الطلبات عبر github.com في الفشل.
- أعلنا عن حادث بعد رؤية الأعطال، وتم تنبيه مهندسينا المناوبين للخدمات المتأثرة.
- استنزف التجمع وعادت معدلات الخطأ إلى طبيعتها. بعد فترة وجيزة، أكدنا أن تجمع الاتصالات الكامل قد تسبب في الأخطاء ونشرنا تحديثًا عامًا للحالة.
- تحققنا من أن اتصالات قاعدة البيانات عادت إلى طبيعتها وحللنا الحادث بعد المراقبة للاستقرار.
كيف نجعل حوادث كهذه أقل احتمالاً أو أقل تأثيرًا؟
- نقوم الآن بتشغيل البحث البطيء قبل أن تبدأ طلبات التحديث هذه في كتابة تغيير، لذلك لم تعد تحتفظ باتصال قاعدة بيانات أثناء انتظارها.
- نقوم بتقييم حدود المدة التي يمكن الاحتفاظ بها باتصال قاعدة بيانات مجمع، بحيث يكون نمط الطلب البطيء أقل احتمالاً لربط التجمع.
تابع صفحة الحالة الخاصة بنا للحصول على تحديثات في الوقت الفعلي حول تغييرات الحالة وملخصات ما بعد الحادث. لمعرفة المزيد حول ما نعمل عليه، تحقق من قسم الهندسة في مدونة GitHub. العلامات: كتب بواسطة مشاركات ذات صلة GitHub Universe 2026: تطوير كل طبقة من المكدس اليوم، وضعنا رؤيتنا لـ GitHub كنظام تسليم البرامج الأكثر شمولاً وشاملًا في العالم. Octoverse: الالتزامات، الدفعات، تصل إلى مستويات قياسية جديدة في 2026 بينما يبني المطورون بالوكلاء شاهد كيف وصل عام قياسي من النمو إلى كل صناعة، وكل مجال، وكل نوع من البناة في تقرير Octoverse لعام 2026. واجهة المطور التالية هي الذكاء المحيطي الذكاء الاصطناعي، والوكلاء، والصوت، وعناصر التحكم المادية تحول تطوير البرمجيات من تشغيل الأدوات إلى التعبير عن النية - ومساعدة المطورين على التركيز على البناء.
جرّب الأداة: منسق ومتحقق JSON
