تعطل GitHub الناتج عن زيادة حركة المرور المدعومة بالذكاء الاصطناعي وخطأ في التكوين

في 9 فبراير من هذا العام، في منتصف الليل بتوقيت بكين، فتح ملايين المطورين حول العالم GitHub ورأوا نفس الصفحة.

ليس 404، بل شيء أكثر إثارة للقلق من 404 — شريط التحذير الأصفر الذي يُشعر جميع المهندسين بالبرود في ظهورهم، بالإضافة إلى صفوف من مؤشرات الحالة التي تتحول من الخضراء إلى الحمراء على صفحة الحالة.

github.com معطل.

الواجهة البرمجية متوقفة.

GitHub Actions تعطلت.

عملية Git تعطلت — حتى Copilot لم ينجو.

في تلك الليلة، توقفت خطوط CI/CD لبعض الأشخاص عند أبرز نقطة، وعلقت عمليات النشر التلقائية في الهواء، بينما كان آخرون ينتظرون دمج PR لم يُدمج بعد—خلف كل ذلك ميزة تنتظر الإطلاق، ومستخدمين حقيقيين ينتظرونها.

نشر GitHub تقرير الحادث لاحقًا. السبب الجذري، باستخدام المصطلحات الفنية، هو "تجاوز حمولة مجموعة قاعدة البيانات الأساسية المسؤولة عن المصادقة وإدارة المستخدمين". لكن هذه الكلمات القليلة تخفي سلسلة تحفيزية مروعة خلفها—

قبل يومين، قام فريق الهندسة بتعديل وقت تحديث "ذاكرة التخزين المؤقت لإعدادات المستخدم" من 12 ساعة إلى ساعتين للسماح بنشر نموذج جديد للمستخدمين في أسرع وقت ممكن. كان هذا التعديل يقتصر على رقم التكوين هذا فقط.

نتيجة لذلك، تم ضغط عملية إعادة كتابة التخزين المؤقت التي كانت موزعة على 12 ساعة داخل ساعتين فقط، مما أدى إلى عاصفة كثيفة من إعادة كتابة التخزين المؤقت، وانهيار صفوف المهام غير المتزامنة فجأة، وتعطل مكونات البنية التحتية المشتركة، وامتداد التأثير المتسلسل إلى الخدمة المسؤولة عن عمليات HTTPS Git الوسيطة، مما أدى في النهاية إلى استنفاد جميع الاتصالات على المنصة.

رقم واحد، تم تغييره من 12 إلى 2.

GitHub، تم اختراقه بسبب تكوين قمت بتعديله.

لكن إذا رأيت فقط هذا التغيير في التكوين، فربما فاتك الجزء الأهم من القصة.

حادثة 9 فبراير ليست حدثًا معزولًا.

في الواقع، شهدت GitHub في الأشهر الثلاثة الأولى من عام 2026 ما لا يقل عن 8 حوادث كبيرة. وسجلت فقط في فبراير 37 حادثًا صغيرًا وكبيرًا. وقد اعترف لاحقًا فلاد فيدوروف، الرئيس التنفيذي للتقنية في GitHub، في مدونته أن GitHub لم يتمكن خلال هذين الشهرين من الحفاظ على "ثلاثة تسعات" — 99.9% من التوفر — التي وعدت بها العملاء المؤسسيين.

عند مراجعة سجلات الأعطال للشهرين الماضيين، ستجد نمطًا غريبًا: كل حادثة تبدو وكأنها سبب مختلف.

2 فبراير: حدوث مشكلة لدى مزود الحوسبة Azure، توقف GitHub Actions لما يقرب من 4 ساعات، وتأثرت جميع خدمات Copilot Coding Agent وCodeQL وDependabot.

February 9: Cache rewrite storm, authentication database overload.

5 مارس: عطل في تجمع Redis، حيث لم يتمكن 95% من سير العمل في GitHub Actions من البدء خلال 5 دقائق، بمتوسط تأخير قدره 30 دقيقة.

March 18: ارتفع تأخير Webhook إلى 32 ضعف المستوى الطبيعي.

يبدو كل حادث وكأنه "حادث عرضي"، وكل سبب مباشر مختلف. لكن تفسير فيدوروف يربطها جميعًا في قصة واحدة. يقول إن هناك ثلاثة أسباب هيكلية مشتركة وراء هذه الحوادث: "النمو السريع في الحمل، والترابط الوثيق بين الخدمات الذي يؤدي إلى انتشار الأعطال الجزئية، ونقص قدرة النظام على حماية حركة المرور من العملاء غير الطبيعية."

بعبارة المهندس، بدأت أساسات GitHub في التصدع تحت ضغط الأحمال الجديدة.

واسم هذا "الحمل الجديد" محدد.

البيانات الرئيسية

إجمالي عدد الالتزامات لعام 2025: حوالي 1 مليار مرة

عدد الـ commits في أسبوع واحد لعام 2026: 275 مليون

بهذا المعدل، التوقعات السنوية لعام 2026: 14 مليار (نمو قدره 14 ضعفًا مقارنة بالعام السابق)

كمية حسابات GitHub Actions: 500 مليون دقيقة أسبوعيًا في عام 2023 → 1 مليار في عام 2025 → 2.1 مليار دقيقة في أسبوع ما في بداية عام 2026

إذا كنت مهندسًا في البنية التحتية لـ GitHub، فستكون مقارنة لوحات المراقبة لعامي 2025 و2026 مفاجئة تمامًا.

خلال عام 2025، عالج GitHub حوالي مليار عملية إرسال كود. هذا الرقم وحده كبير بالفعل، وهو نتيجة تراكمية على مدى سنوات من عمل منصة GitHub. لكن في عام 2026، وصل عدد عمليات الإرسال في أسبوع واحد إلى 275 مليون عملية. إذا حسبنا هذا المعدل على مدار العام الكامل، فسيصل إجمالي عمليات الإرسال في عام 2026 إلى ما يقارب 14 مليار عملية، أي ما يعادل 14 ضعف إجمالي عمليات الإرسال في عام 2025.

هذه ليست منحنى نمو سلس، بل منحدر حاد. إن تغير حسابات GitHub Actions يوضح الأمر بشكل أفضل: في عام 2023، استهلكت 500 مليون دقيقة أسبوعيًا، وازدادت إلى مليار دقيقة في عام 2025، ثم ارتفعت مباشرة إلى 2.1 مليار دقيقة في أحد أسابيع بداية عام 2026.

ما الذي يُقدّم كودًا بجنون؟

ليس مطورًا بشريًا.

تُظهر بيانات GitHub أن عوامل الذكاء الاصطناعي أصبحت أكثر "مستخدمين" نشاطًا على هذه المنصة. يساهم أداة Claude Code وحدها الآن بنسبة 4.5% من إجمالي عمليات الإرسال في جميع المستودعات العامة على GitHub. حيث بلغ عدد عمليات الإرسال الأسبوعية 2.6 مليون، بينما كان هذا العدد لا يتجاوز 100 ألف في نهاية سبتمبر 2025 — بزيادة قدرها 25 ضعفًا خلال ثلاثة أشهر.

عدد PRs التي فتحها وكيل الذكاء الاصطناعي يشهد أيضًا انفجارًا. في سبتمبر 2025، كان عدد PRs المولدة بواسطة الذكاء الاصطناعي حوالي 4 ملايين شهريًا، وفي مارس 2026، ارتفع هذا الرقم إلى 17 مليونًا — أكثر من أربعة أضعاف خلال ستة أشهر.

هناك صورة يمكنها مساعدتك على فهم ما يعنيه ذلك.

في الماضي، كان "المستخدمون" على GitHub في الغالب مبرمجين بشريين. كانوا يعملون نهارًا، وينامون ليلًا، ويأخذون إجازة في عطلات نهاية الأسبوع، وكل عملية دفع كانت تتطلب تفكيرًا وترددًا، وكان هناك حد أقصى لسرعة الأيدي. كان عبء النظام يتبع جدول البشر، مع فترات ذروة وانخفاض، ويمكن التنبؤ به.

الآن، يزداد عدد "المستخدمين" الذين هم وكلاء ذكاء اصطناعي. فهي لا تنام ولا تستريح ولا تتردد، ويمكن تشغيل عدة وكلاء متوازية في وقت واحد لمهمة واحدة، وكل وكيل يمكنه تقديم كمية تتجاوز بسهولة ما ينجزه مهندس حقيقي خلال أسبوع. والأهم من ذلك، أنها لا تقدم فقط الكود، بل تنشئ أيضًا مستودعات جديدة باستمرار — حيث تُعتبر المستودعات ناتجًا لسير العمل، وليس مساحة عمل للإنسان.

مهندسوا البنية التحتية في GitHub يواجهون مشكلة مختلفة تمامًا، وليست مجرد مشكلة ذات حركة مرور أكبر.

التعطلات المتكررة هي جانب واحد فقط من المشكلة، كما أن GitHub يواجه مشكلة أخرى أكثر إزعاجًا — عند مراجعة الحسابات، اتضح أنك خسرت.

المنطق الأساسي لتحديد أسعار Copilot كان مبنيًا على افتراض معقول: أن المستخدمين يستخدمونه بشكل رئيسي لـ "إكمال المساعدة"، حيث تكون كل تفاعل قصيرة وكمية الحسابات قابلة للتنبؤ بها. كان النموذج يعتمد على 10 دولارات شهريًا للنسخة الشخصية و19 دولارًا شهريًا للنسخة التجارية، مع التسعير حسب عدد المقاعد، وقد عمل هذا النموذج بشكل جيد على مدار السنوات القليلة الماضية.

ثم جاء الذكاء الاصطناعي الوكيل.

إن تدفقات Agentic وتكملة الكود التقليدية هما نوعان مختلفان. إن تكملة الكود القياسية تتطلب طلبات خطية وقابلة للتنبؤ، مع دورات حسابية قصيرة. أما جلسة ترميز Agentic، فقد تستغرق عدة ساعات، وتُطلق في نفس الوقت عدة خيوط متوازية، وتُجري استدلالات متعددة الخطوات، وتصحيحًا ذاتيًا، وإعادة هيكلة عبر المستودعات — حيث يتجاوز استهلاك الجلسة من الرموز بسهولة تكلفة اشتراك مستخدم عادي لشهر كامل.

تواجه GitHub موقفًا حيث يستخدم عدد قليل من المستخدمين المكثفين للنماذج الوكيلة موارد حسابية تكافئ مئات الدولارات برسوم شهرية تبلغ بضعة دولارات فقط.

في مواجهة هذا الموقف، كان رد فعل GitHub مباشرًا — أولاً تقييد التدفق، ثم تعديل السعر.

منذ بداية هذا العام، طبّق GitHub آلية تقييد متوازية مزدوجة لـ Copilot: حد أقصى لطول الجلسة وحد أقصى للاستخدام الأسبوعي، ويُحسب كلا البعدين بناءً على استهلاك الرموز مضروبًا في وزن حساب النموذج. في الوقت نفسه، تم تعليق تسجيل المستخدمين الجدد لبعض خطط Copilot الفردية.

في 1 يونيو، أكمل GitHub إصلاحًا أساسيًا في التسعير: انتقال Copilot بالكامل إلى نموذج التسعير حسب الاستخدام، واستبدال خطط الاشتراك السابقة بـ "رصيد الذكاء الاصطناعي"، حيث يعادل رصيد الذكاء الاصطناعي واحدًا سنتًا أمريكيًا، ويتم حساب الاستخدام فعليًا وفقًا لاستهلاك الرموز.

عصر الدفع حسب المقعد وصل إلى نهايته أمام الذكاء الاصطناعي المُوجَّه.

هذا التحول ليس مجرد مشكلة لـ GitHub. إنه أزمة تسعير جماعية تمر بها صناعة أدوات الذكاء الاصطناعي بأكملها في عام 2026 — عندما يبدأ الذكاء الاصطناعي في استبدال البشر لتنفيذ سير عمل كاملة، وليس فقط "دعم" عمل البشر، فستصبح جميع منطق الاشتراكات القائمة على "كل شخص شهريًا" غير فعالة.

العودة إلى مشكلة البنية التحتية. كيف يخطط GitHub للتعامل مع هذا "النمو بنسبة 14 ضعفًا"؟

هناك تفصيل واحد يوضح مدى خطورة المشكلة:

في أواخر ديسمبر 2025، بدأت سير عمل Agentic بالتسارع المفاجئ. أدرك مهندسو GitHub أن العامل 10 غير كافٍ. بحلول فبراير 2026، أي بعد تعطل كبير، أعلنت GitHub الحاجة إلى إعادة تصميم البنية التحتية بحجم 30 ضعف الحجم الحالي.

ليس توسعة، بل إعادة تصميم.

الفرق بين هذين المفهومين كبير جدًا. التوسع يعني زيادة عدد الخوادم الحالية أو إضافة ذاكرة إلى قاعدة البيانات الحالية — الاتجاه لا يتغير، فقط يزداد الحجم. أما إعادة التصميم فتعني أن الافتراضات الحالية في البنية التحتية ستتعطل بشكل منهجي عند حجم 30 ضعفًا، ويجب إعادة التفكير من الأسفل في تقسيم الخدمات وتدفق البيانات وعزل الأعطال.

تشمل التفاصيل المعلنة من GitHub تفكيك الخدمات الأساسية لمنع الفشل المتسلسل، وتقديم آليات الضغط العكسي وقدرات خفض التدفق، ونشر خوادم مستقلة للخدمات ذات الازدحام العالي، وإزالة نقاط الفشل الواحدة، بالإضافة إلى إدارة تغييرات أكثر شمولًا — تجنب تنفيذ عمليات مثل "تغيير TTL للذاكرة المؤقتة من 12 ساعة إلى ساعتين" دون اختبار ضغط كافٍ.

تجدر الإشارة إلى أن GitHub ليس وحيدًا.

واجهت Stripe مشكلة إنشاء حسابات جماعية بواسطة وكلاء الذكاء الاصطناعي، وتعمل AWS على بناء نظام هوية مخصص للوكلاء، ونظام سجلات، وآليات تحكم إنتاجية. هذه الإجراءات ليست تدابير وقائية، بل هي استجابة لإشارات ظهرت بالفعل على لوحات المراقبة واجبرتها على التصرف.

جيت هب كان مجرد أول من تم اختراقه – لأنه في قلب سلسلة أدوات الذكاء الاصطناعي.

توقف وفكّر في طبيعة هذا الأمر بأكمله.

ما هو GitHub؟ الإجابة الأكثر وضوحًا هي أنه المكان الذي يخزن فيه المبرمجون أكوادهم. لكن على مستوى أعمق، إنه البنية التحتية للتعاون البشري في البرمجيات — السجلات المقدمة هي مسارات التعاون، وطلبات السحب هي حاويات المناقشة، والمشكلات هي بقايا النوايا، والأعمال هي قنوات التنفيذ. إن النظام الكامل مصمم لينسجم مع إيقاع العمل البشري، وطريقة التفكير، وأنماط التعاون.

غيّر وكيل الذكاء الاصطناعي كل شيء.

عندما يمكن لوكيل ذكاء اصطناعي تقديم مئات المرات من الكود في يوم واحد، وكل "تقديم" يخلفه لا تفكير أو مراجعة بشرية، بل فقط خطوة تقدم في دورة مهمة — هل ما زال مستودع الكود "وعاءً تعاونيًا"؟

عندما تقوم أدوات الذكاء الاصطناعي تلقائيًا بإنشاء المستودعات، وفتح طلبات السحب، وتشغيل اختبارات التكامل المستمر، ودمج التغييرات تلقائيًا — هل لا يزال المطورون هم المحور الأساسي في هذه العملية، أم أنهم تراجعوا إلى دور "المراجعين" أو حتى "المراقبين"?

عند وصف هذه الأزمة، استخدم مسؤول تقنية GitHub مصطلح "نمو سريع في الحمل". لكن هذا المصطلح قد يقلل من جوهر المشكلة — فهذا ليس مجرد نمو في الكمية، بل تحوّل نوعي في طريقة الاستخدام. في النموذج القديم، كان GitHub "أداة للمطورين"؛ أما في النموذج الجديد، فيتحول GitHub إلى "أنبوب عادم للذكاء الاصطناعي"، وهو أنبوب لإخراج سير العمل التلقائي.

هذا لا يزال بلا إجابة فيما يتعلق بـ GitHub. يمكن للتوسع 30 ضعفًا حل مشكلة حركة المرور، لكنه لا يمكنه حل إعادة تعريف نموذج العمل، ولا حل مشكلة الهوية "من هو مستخدمي الحقيقي؟".

لقد ظهرت مؤخرًا ظاهرة ذات دلالة عميقة: بعد تعطل GitHub، نشر عددًا كبيرًا من مدونات الهندسة، وصفت بتفصيل شديد الأسباب الجذرية لكل حادث،达到了 مستوى شفافية يكاد يكون مفاجئًا. يرى البعض أن هذا تصرف متعمد من GitHub لبناء الثقة، بينما يرى آخرون أنه تبادل للشفافية مقابل صبر مجتمع المطورين — لأن فترة إعادة الهيكلة القادمة ستجلب المزيد من عدم الاستقرار.

منصة، بعد أن ثقبها نجاحها، تحتاج إلى فك نفسها وإعادة بنائها — وهذه العملية نفسها هي أيضًا اختبار لقدرتها على التحمل.

في ليلة 9 فبراير، ربما انتظر المهندس الذي كان ينتظر دمج الـ PR في النهاية الإشارة الخضراء. لكنه ربما لم يدرك أن التعطيل الذي انتظره لم يكن حادثًا عابرًا في GitHub، بل كان صوتًا يُعلن عن دخول صناعة تطوير البرمجيات عصرًا جديدًا.

هذا المقال من حساب ويشات الرسمي "جيكي بارك" (ID: geekpark)، الكاتب: يوهانغ يوان