في الشهر الماضي، أضفنا قسمًا جديدًا إلى تقاريرنا الشهرية يتضمن تحديثات حول أعمال توفر GitHub واستثمارات البنية التحتية التي تقف وراءها. لقد أوضحت الاستجابة والأسئلة التي سمعناها شيئًا واحدًا: العملاء يريدون المزيد من هذا، وليس أقل – بما في ذلك عندما تكون الأخبار مختلطة.
النسخة المختصرة لشهر يونيو: لقد حققنا تقدمًا هيكليًا حقيقيًا، وتوقفنا مؤقتًا بشكل متعمد عندما انحرف المنحدر جانبًا، وأخطأنا الهدف الذي قمنا الآن بإعادة تحديد خط الأساس له.
بلغت حركة المرور المتجانسة في Azure ذروتها عند 45% في الولايات المتحدة الوسطى هذا الشهر. هذا الرقم أقل مما كنا نأمل، لأننا أوقفنا المنحدر مؤقتًا لمدة شهر تقريبًا بعد أن أوضح حادث الاستقرار الذي وقع في 21 مايو أن البيئة لم تكن جاهزة لمزيد من حركة المرور. لقد قمنا بإعادة تشغيل الطريق المنحدر في 17 يونيو باستخدام بوابة استقرار جديدة لكل مرة تتطلب أن تكون البيئة صحية بشكل يمكن التحقق منه قبل كل خطوة للأعلى. إن التحرك بشكل أبطأ وبثقة أكبر هو التداول الصحيح – يفضل التوقف المؤقت المتحكم فيه عن إعادة تعلم نفس الدروس عند تحميل أعلى.
نما Git في Azure من 30% إلى الذروة 43% (HTTP وSSH مدمجان) خلال الشهر، وفشلنا في الوصول إلى هدفنا البالغ 50% في شهر يونيو. نتوقع أن يصل Git إلى ما يقرب من 45% في الوقت الحالي بسبب قرارين متعمدين لتجنب زمن استجابة المستخدم الإضافي: نحن ننتظر حركة مرور vPoP إضافية للتوجيه إلى وسط الولايات المتحدة بدلاً من إعادة توصيل حركة مرور IAD HUB Git، ونحن نقوم بتوجيه HTTP فقط في الوقت الحالي لأن SSH ليس لديه تقسيم للقراءة/الكتابة على الحافة. نحن مستمرون في إعطاء الأولوية لهذا الأمر، ولكن ليس لدينا هدف جديد لنشاركه. سنواصل العمل بأسرع ما يمكن وبأمان قدر الإمكان وسنبلغ عن الأرقام المحددة في التحديث القادم.
وتحت هذه الأرقام الرئيسية، أحرزنا تقدمًا نحن متحمسون له بشكل خاص. خدمة طلبات السحب المستخرجة الجديدة الخاصة بنا، pullsd، قيد المعالجة الآن يقرأ 100% من طلبات السحب المجهولة في الإنتاج لم تعد الوحدة المتراصة تخدم حركة المرور هذه. أصبحت Reposd، خدمة المستودع المستخرجة الجديدة لدينا، أول خدمة مستخرجة تخدم حركة مرور REST للإنتاج من Azure، حيث زادت إلى 50% من حركة مرور القراءة قبل أن نقوم برفضها بشكل استباقي لقيود سعة Redis. لم يكن هناك أي حادث ولم يكن هناك تراجع تحت الإكراه. سيتم إعادة رفعه بمجرد اكتمال عمل السعة. يتم الآن تفريغ خدمة المستخدمين الجدد تقريبًا 500000 استفسار في الثانية في الذروة من قاعدة بياناتنا الأساسية، مع الترحيل الفعلي لجداول المصادقة والترخيص في أوائل شهر يوليو. أصبح الحد الأقصى لمعدل واجهة برمجة التطبيقات لدينا الآن تقريبًا تم التعامل مع 97% عند البوابة، لذلك لم تعد قرارات تحديد المعدل تتعارض مع العاملين الذين يخدمون الطلب داخل الكتلة المتراصة. يتم تشغيل فصل أحمال قاعدة البيانات من جانب العميل مقابل 5% من حركة الإنتاج الحقيقية، مما يعني أن لدينا الآن دليلًا حيًا على أنه يمكننا التخلص من الاستعلامات ذات الأولوية المنخفضة تحت الضغط قبل أن تتحول إلى حالات فشل يواجهها المستخدم. ويلزم الآن التأكيد من شخصين بشكل شامل للوصول التفاعلي إلى الإنتاج وتغييرات ChatOps، مع وجود مسار تدقيق موحد خلفه.
إن الأحداث التي تلي ذلك هي النصف الآخر من الصورة: ما الذي قام به النظام بشكل جيد وما الذي لم يفعله، وما الذي قمنا بتغييره بالفعل نتيجة لذلك، وما الذي لا نزال نغيره. ويستمر نفس المبدأ في توجيهنا: التوفر، ثم القدرة، ثم الميزات.
في شهر يونيو، واجهنا ستة حوادث أدت إلى انخفاض الأداء عبر خدمات GitHub.
04 يونيو، الساعة 17:30 بالتوقيت العالمي (لمدة ساعة و25 دقيقة)
في 4 يونيو 2026، من الساعة 17:30 إلى الساعة 18:55 بالتوقيت العالمي المنسق، واجهت مراجعة كود Copilot حالات فشل مرتفعة لطلبات المراجعة على github.com. رأى المستخدمون المتأثرون رسالة “حدث خطأ في برنامج Copilot” في طلبات السحب عند طلب مراجعة التعليمات البرمجية.
أثناء فترة الحادث، فشل ما متوسطه 81.6% من طلبات مراجعة التعليمات البرمجية لبرنامج Copilot، مع معدل فشل الذروة بنسبة 93.9%، وإجمالي ما يقرب من 36,800 طلب مراجعة التعليمات البرمجية الفاشلة. لم تتأثر GitHub Enterprise Cloud مع موقع البيانات.
كان سبب المشكلة هو التبعية التي تم إصدارها حديثًا والمستخدمة في سير عمل معالجة مراجعة كود Copilot. قدم الإصدار عدم توافق مع بيئة وقت التشغيل. نظرًا لأن سير العمل يستهلك أحدث إصدار تلقائيًا، فقد تم التقاط الإصدار غير المتوافق دون التحقق من التوافق بشكل كافٍ وتسبب في فشل معالجة المراجعة. لم تفشل مهام المراجعة المتأثرة بسرعة؛ استمر الكثير في الجري حتى انتهت المهلة.
لقد خففنا من حدة الحادث عن طريق إزالة إصدار التبعية الذي به مشكلات وإعادة نشر خدمة المعالجة المتأثرة. بدأت مراجعات التعليمات البرمجية الجديدة في التعافي في الساعة 18:44 بالتوقيت العالمي، وعاد معدل الفشل إلى خط الأساس بحلول الساعة 18:55 بالتوقيت العالمي. تم استنفاد العمل المنتهي في الساعة 19:59 بالتوقيت العالمي المنسق.
لتقليل مخاطر التكرار، نقوم بتثبيت إصدار التبعية بدلاً من استهلاك أحدث إصدار تلقائيًا، وإضافة فحوصات التوافق للإصدارات المستقبلية، وتحسين سلوك الفشل السريع عندما لا يتمكن معالج المراجعة من البدء، وإضافة عناصر تحكم مهلة أقصر لسير عمل المراجعة، وتحسين مراقبة حالات فشل إكمال المراجعة.
08 يونيو، الساعة 06:30 بالتوقيت العالمي (يستمر لمدة ساعتين و06 دقيقة)
في 8 يونيو 2026، بين الساعة 06:30 و08:36 تقريبًا بالتوقيت العالمي المنسق، واجه المستخدمون الذين قاموا بتسجيل الخروج أخطاء HTTP 504 مرتفعة ومستمرة عند الوصول إلى طلبات السحب والمشكلات والإصدارات واختلافات التصحيح وصفحات github.com الأخرى ذات الصلة. أثناء الحادث، أدى ما يقرب من 17% من الطلبات غير المصادق عليها إلى نقاط نهاية github.com المتأثرة إلى إرجاع أخطاء مهلة البوابة، وبلغت ذروتها عند 34% تقريبًا من الطلبات في حوالي الساعة 06:50 بالتوقيت العالمي المنسق. تأثرت أيضًا بعض مسارات عمل GitHub Actions عندما كانت تعتمد على تنزيلات الإصدار أو نقاط نهاية github.com ذات الصلة. واستمر الاصطدام حوالي ساعتين وتم عزله عن حركة المرور غير الموثقة. ولم يتأثر المستخدمون الذين قاموا بتسجيل الدخول.
نتجت المشكلة عن الزيادة الكبيرة في حركة المرور المجهولة المسيئة والآلية إلى نقاط نهاية github.com محددة. نظرًا لأن الطلبات التي لم تتم مصادقتها يتم تقديمها من خلال مجموعة مخصصة من خوادم تطبيقات الويب، فقد أدى ذلك إلى تدهور قدرتنا على الاستجابة للطلبات التي لم تتم مصادقتها، مما تسبب في انتظار الطلبات بما يتجاوز حدود المهلة وإرجاع أخطاء مهلة البوابة.
لقد خففنا من حدة الحادث من خلال تحديد نمط حركة المرور الشاذ وتطبيق الكتل المستهدفة في موازن التحميل وطبقات التطبيق. بمجرد أن تصبح الكتل سارية المفعول بالكامل، تعود معدلات الخطأ إلى وضعها الطبيعي وتتم استعادة الخدمات المتأثرة بالكامل بحلول الساعة 08:36 بالتوقيت العالمي.
لتقليل احتمالية حدوث حوادث مماثلة وتأثيرها في المستقبل، نعمل على تحسين الكشف الآلي عن أنماط حركة المرور هذه وحظرها، وتحسين مسار نشر حظر حركة المرور في حالات الطوارئ، وتقييم تغييرات التوجيه لنقاط النهاية التي يستخدمها كل من المستخدمين المسجلين الخروج وسير العمل الآلي.
10 يونيو، الساعة 15:05 بالتوقيت العالمي (لمدة ساعة و20 دقيقة)
في 10 يونيو 2026، بين الساعة 15:05 و16:25 بالتوقيت العالمي المنسق، واجهت خدمات GitHub API انخفاضًا في التوفر بسبب فشل المصادقة المتقطع الذي أثر على حوالي 9٪ من الطلبات. تأثرت طلبات REST وGraphQL API. واجه العملاء سلوك “تسجيل الخروج” المتقطع حيث تسببت الاستجابات الخاطئة 401 (غير المصرح بها) في عمليات تكامل تطبيقات الطرف الأول والثالث لتحفيز تدفقات المصادقة المتكررة. نظرًا لأن الطلبات التي تم توجيهها عبر البنية التحتية المتأثرة فقط هي التي فشلت، فقد ينجح العميل نفسه في طلب واحد ويفشل في الطلب التالي، مما ينتج عنه السلوك المتقطع. واجهت الطلبات المتأثرة أيضًا زمن وصول إضافي يبلغ حوالي 800 مللي ثانية، حيث أعادت البوابة محاولة المصادقة قبل إرجاع خطأ.
تسببت خدمة وكيل memcached، التي تم طرحها في البنية الأساسية لواجهة برمجة التطبيقات (API) الداخلية لدينا، في قيام خدمة المصادقة الخاصة بنا بالتقاط تكوين مضيف غير صحيح، مما أدى إلى فشل متقطع في البحث عن المصادقة. لقد خففنا من حدة الحادث من خلال نشر تغيير التكوين في خدمة memcached لاستخدام المضيف الصحيح.
لمنع حدوث مشكلات مماثلة في المستقبل، نخطط لترحيل نظام المصادقة الخاص بنا إلى البنية الأساسية الجديدة للتخزين المؤقت لتحسين المرونة وتعزيز وضع الموثوقية العام. نعمل أيضًا على تحسين كيفية تمييز البوابة لأخطاء نظام المصادقة العابرة وبيانات الاعتماد غير الصالحة فعليًا، بحيث لا تظهر حالات فشل البحث المؤقت للمستخدمين على أنها مسجلة الخروج.
16 يونيو، الساعة 17:20 بالتوقيت العالمي (لمدة 55 دقيقة)
في 16 يونيو 2026، بين الساعة 17:20 و18:15 بالتوقيت العالمي، شهد نموذج Opus 4.8 انخفاضًا في التوفر في GitHub Copilot. خلال هذه النافذة، فشلت بعض طلبات Opus 4.8 أو حدث بها خطأ. لم تتأثر نماذج مساعد الطيار الأخرى وظلت متاحة كبدائل. حدث هذا بسبب مشكلة مع موفر النموذج الأولي.
أثناء استمرار المشكلة، قمنا بتمكين المراسلة ذات الوضع المنخفض لإبلاغ المستخدمين المتأثرين. قام موفر الخدمة الأولية بحل المشكلة، وقمنا بمراقبة Opus 4.8 حتى عادت معدلات النجاح إلى وضعها الطبيعي. تم حل الحادث بالكامل.
نحن نعمل على تقليل اعتمادنا على أي مزود استدلال واحد لنموذج معين ونوازن بين السعة عبر مقدمي الخدمة، بحيث يمكن أن تفشل حركة المرور في الوصول إلى السعة السليمة أثناء انقطاع المنبع. وبشكل منفصل، قمنا بتعزيز أدوات صفحة الحالة العامة لدينا لضمان نشر تحديثات الأحداث بشكل موثوق، مما يؤدي إلى تحسين كيفية إبقاء العملاء على اطلاع أثناء عملية التخفيف.
17 يونيو، الساعة 03:50 بالتوقيت العالمي (يستمر لمدة 54 دقيقة)
في 17 يونيو 2026، بين الساعة 03:50 و04:44 تقريبًا بالتوقيت العالمي المنسق، تدهور أداء GitHub Copilot وأصبحت معظم نماذج الدردشة الحدودية غير متاحة مؤقتًا في جميع المناطق. خلال هذه النافذة، اختفت النماذج المتأثرة من منتقي النماذج في تجارب الويب والمحرر وCLI، أو عرضت خطأ “النموذج غير متوفر” عند تحديده. يمكن للعملاء الاستمرار في استخدام GitHub Copilot عن طريق اختيار أحد النماذج التي ظلت متاحة. ووقع الحادث خارج ساعات الذروة، مما أدى إلى الحد من عدد العملاء المتأثرين.
كان هذا بسبب تغيير في التكوين اعتبره نظام الإنتاج لدينا غير صالح. لقد خففنا من حدة الحادث من خلال التراجع عن تغيير التكوين، وبعد ذلك عادت النماذج المتأثرة تلقائيًا حيث قامت الخدمة بإعادة تحميل التكوين السابق.
نحن نعمل على طرح تغييرات التكوين تدريجيًا من خلال عمليات تحقق أقوى، وتنبيهات عند الانخفاض المفاجئ في عدد النماذج المتاحة، والتراجع تلقائيًا عن تغييرات التكوين التي تؤدي إلى ظهور هذه التنبيهات.
25 يونيو، الساعة 17:33 بالتوقيت العالمي (لمدة 23 دقيقة)
في 25 يونيو 2026، بين الساعة 17:33 و17:55 بالتوقيت العالمي المنسق، واجهت خدمة المهام الخلفية لدينا تدهورًا أدى إلى زيادة التأخير في سحب الطلبات، ودفعات المستودع، وسير عمل الإجراءات، وخطافات الويب، مع وصول التأخير إلى ذروته عند 7 دقائق. كان سبب المشكلة هو مشكلات برنامج Hypervisor الأساسية وارتفاع حركة المرور الواردة، مما تسبب في انتهاء مهلات الخدمة مما أدى إلى عاصفة الاتصال وعمليات إعادة التوازن المستمرة.
تم التخفيف من المشكلة عن طريق استبدال العقدة المتأثرة في الساعة 17:49، وبعد ذلك شهدت جميع الخدمات التعافي بحلول الساعة 18:07.
لتقليل احتمالية وقوع حوادث مماثلة وتأثيرها في المستقبل، جعلنا معالجة الوظائف في الخلفية أكثر مرونة في مواجهة الارتفاع المفاجئ في حركة المرور، وقللنا من احتمالية انقطاع الاتصال في الحالات المتدهورة، وأزلنا الموقع المشترك للعقد المهمة بحيث لا يمكن لعقدة واحدة غير صحية أن تؤثر على العقد الأخرى، وأضفنا تنبيهًا مبكرًا بشأن الظروف التي أدت إلى هذا التدهور.
اتبع صفحة الحالة الخاصة بنا للحصول على تحديثات في الوقت الفعلي حول تغييرات الحالة وملخصات ما بعد الحادث. لمعرفة المزيد حول ما نعمل عليه، راجع القسم الهندسي في مدونة GitHub.
كتب بواسطة
