GitHub يعيد تصميم تخزين Git: ‏5,000 وكيل في مستودع واحد و7,200 عملية دفع في الثانية

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

ما الذي أعلنته GitHub

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

ما المشكلة التي يحلها ذلك

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

الرقم الأهم هنا ليس 5,000 وكيل، بل الجمع بين شرطين: معدل كتابة مرتفع وزمن استجابة قراءة منخفض في الوقت نفسه. يمكن تحمل ذروات الكتابة على حساب تدهور كل شيء آخر. أما هنا، فالادعاء هو أن أداء القراءة لم يتراجع.

لماذا يهم ذلك الآن تحديدًا

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

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

ما الذي ينبغي فعله عمليًا

أولًا: قدروا عدد عمليات الدفع التي ينشئها نظام الوكلاء لديكم فعليًا في الدقيقة. لدى معظم الفرق، يكون العدد بضع عمليات أو عشرات، لا آلافًا؛ ولذلك لا يعنيكم رقم GitHub القياسي حتى الآن.

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

ثالثًا: قسموا عمل الوكلاء بين الفروع ومناطق الشيفرة. فإذا عدل 5,000 وكيل الملف نفسه، فسيغرقون في التعارضات مهما بلغت سرعة الخادم.

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

القيود

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

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