في 17 أغسطس، تعرضت GitHub لانقطاع استمر 7 ساعات و47 دقيقة. وقد أثّر هذا الانقطاع في المطورين والمؤسسات حول العالم، إذ عطّل github.com والمصادقة وGitHub Actions وواجهات API وطلبات السحب والمشكلات وCopilot. إذا كنتم تحاولون نشر برمجيات في ذلك اليوم، فقد خذلناكم.
كان هذا ثاني حادث كبير لنا في أغسطس، بعد عطل Actions في 6 أغسطس. كنت قد شاركت في مارس وأبريل العمل الذي كنا نقوم به لتحسين موثوقية GitHub. لقد أحرزنا تقدمًا، لكن هذه الحوادث توضح بجلاء أننا بحاجة إلى تسريع هذا العمل.
ما الذي حدث
كشف فحصنا أن الانقطاع بدأ عندما بلغت حركة البيانات ذروة جديدة، ولم يتمكن مكوّن حيوي في البنية التحتية بمركز بياناتنا في وسط الولايات المتحدة من التوسع بما يكفي لمواكبتها. وانتقل ضغط السعة الناتج عن ذلك إلى أنظمتنا، ما أدى إلى أخطاء في المصادقة وتعطيل العديد من خدمات GitHub.
تطلّب التعافي اتخاذ عدة خطوات منسقة. أعادت الفرق توجيه حركة البيانات، وعزلت البنية التحتية المتأثرة، واستعادت الخدمات تدريجيًا. تعافت معظم خدمات GitHub في وقت أبكر من ذلك اليوم، لكن بعض خدمات Copilot استغرقت وقتًا أطول. وأدت الأخطاء في هذه الخدمات إلى تشغيل حلقة إعادة محاولة من جانب العميل زادت حركة البيانات أثناء التعافي. وكان علينا أولًا الحد من هذا السلوك حتى نتمكن من استعادة حركة البيانات بأمان. ويتضمن التحليل الشامل للسبب الجذري جدولًا زمنيًا تقنيًا مفصلًا.
لم يتسبب أي تغيير في التعليمات البرمجية أو التهيئة في أي من الانقطاعين. وكان نقص السعة هو السبب الجذري لكلا الحادثين. لم نتمكن من توسيع نطاق المكونات الحيوية قبل أن تتجاوز الطلبات السعة المتاحة. ومنذ أبريل، ارتفع عدد عمليات commit الشهرية من 1.4 مليار إلى 2.9 مليار. يفسر هذا النمو الضغط الواقع على أنظمتنا، لكنه لا يعفي من مسؤولية هذه الانقطاعات.
ما فعلناه وما هو قادم
في إطار التزاماتنا بالموثوقية التي قطعناها في بداية هذا العام، ركزنا على ثلاث أولويات: إضافة السعة، وزيادة الكفاءة، وإزالة الاختناقات المعمارية. ومنذ ذلك الحين، أضفنا أكثر من 3 ملايين نواة CPU، و120 بيتابايت من وحدات التخزين عالية السرعة، وقدرًا كبيرًا من سعة الشبكة. وفي مراكز البيانات الحالية، سارعنا أيضًا إلى انتقالنا إلى Azure، بالتوازي مع تركيب أكبر قدر ممكن من الأجهزة ضمن حدود سعة الطاقة الحالية.
تخدم Azure اليوم نحو 58% من حمل منصة GitHub ونصف جميع عمليات Git؛ وقد ارتفعت هذه النسبة من 12% من حمل المنصة في مايو. كما دعمت هذه البنية التحتية المتوسعة النمو في عمليات تشغيل مهام GitHub Actions الموضح أدناه.
وقد أدت البنية التحتية والسعة لدى Azure أيضًا إلى تسريع جهودنا لتوسيع نطاق أكبر مستودعات monorepo. وتتمثل محطتنا الرئيسية التالية في بنية معمارية توسّع سعة القراءة خطيًا مع عدد القرّاء، وتتيح عددًا غير محدود من عمليات القراءة.
سنطرح ذلك تدريجيًا، وسنبدأ بأكبر مستودعات monorepo.
لا يمثل الحجم التحدي الوحيد الذي واجهناه. فمع ازدياد سرعة التغيير وتعقيده، لم تتمكن ممارساتنا التشغيلية الحالية من مواكبة ذلك. وقد وجّهنا الفرق والموارد نحو التوافر، واستثمرنا في اختبارات أقوى، وعمليات طرح أكثر أمانًا، وقابلية أفضل للرصد، وآليات تنبيه أكثر فعالية. لقد أحرزنا تقدمًا، لكن هذا العمل لم يكتمل بعد.
بالإضافة إلى ذلك، نعزل الأنظمة الحيوية عن بعضها بعضًا ونلغي التبعيات المشتركة فيما بينها. وقد صُمم هذا العمل لتقليل احتمال حدوث انقطاع والحد من تأثيره عند وقوعه.
نتعلم من كل انقطاع ونضيف أعمالًا جديدة إلى قائمة أعمال التوافر لدينا. وقد أدت حادثتا 6 أغسطس و17 أغسطس إلى تغييرين عاجلين.
أولًا، نطبّق حدودًا متسقة لإعادة المحاولة، وميزانيات لإعادة المحاولة، ومهلات زمنية متغيرة في التفاعلات بين الخدمات، لمنع عواصف إعادة المحاولة والحمل المتسلسل. ثانيًا، نراجع تنبيهات CPU والذاكرة منخفضة الأولوية لتحديد المكونات التي قد تتعطل أثناء الارتفاعات المفاجئة في حركة المرور.
إن التزامنا بالتوافر العالي ليس مجرد وعد تقني.