في GitLab، استقلال المشروع لا يعني استقلال رصيد التشغيل

الخلاصة

• ينسب GitLab.com استهلاك الوظائف الخاضعة لحصة التشغيل إلى نطاق الأسماء الأعلى للمشروع. لذلك قد تستخدم مشاريع ومجموعات فرعية منفصلة الرصيد نفسه.
• يبدأ استهلاك الدقائق الإضافية بعد الحصة الشهرية المشمولة، ويُرحّل غير المستخدم منها، لكن شراءها لا يتجدد كل شهر ولا يمكن نقلها بين المجموعات.
• وجود رصيد، وتوافر بيئة تشغيل مناسبة، والسماح الآمن بتنفيذ الشيفرة شروط مختلفة. شراء المزيد من الدقائق يعالج أحدها فقط، ولا يلغي مسؤوليات التشغيل عند استخدام بيئة يديرها العميل.

من يقرر التشغيل، ومن يدفع لاستمراره؟

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

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

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

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

الحدود التي يراها العداد

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

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

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

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

الدقيقة المحسوبة ليست دقيقة انتظار

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

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

قد يكون الحصول على نتيجة أسرع جديرا باستهلاك أعلى. وقد يأتي التحسن من حذف عمل مكرر فعلا بدلا من إضافة توازٍ أكبر. تناقش إرشادات كفاءة سلاسل التنفيذ المسار الحرج، واعتماد الوظائف بعضها على بعض، وموارد الأجهزة، وتجهيز البيئة. لا تعني معالجة أحد هذه الجوانب أن بقية الجوانب تحسنت تلقائيا.

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

كيف يُطبّق نفاد الحصة؟

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

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

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

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

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

رصيد له مكان وعمر

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

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

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

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

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

التنفيذ يحتاج أكثر من حق الدفع

المشغّل، أو runner، هو البيئة التي تنفذ الوظائف. تفصل وثائق المشغلات بين من يدير البيئة وبين نطاق استخدامها. كما تتوقف مطابقة الوظيفة على الوسوم والحالة والقدرة والتجهيزات المتاحة. لا يلغي الرصيد هذه الشروط، ولا يجعل كل آلة مناسبة لكل عمل.

تمنح البيئات المستضافة العميل فائدة تشغيلية ملموسة. في الاستخدام العادي لـ GitLab.com تحصل الوظيفة على آلة افتراضية جديدة، تُزال بعد التنفيذ. وتختلف بعض ترتيبات المساهمات المجتمعية، فلا يصح تعميم هذه الصورة على كل حالة. وتعلن الوثائق هدفا لبدء 90% من الوظائف خلال 120 ثانية. إنه هدف مستوى خدمة، وليس أداء قاستْه هذه المقالة أو حجزا مضمونا للوظيفة التالية.

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

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

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

المصادر ونطاق الاستنتاج

تستند الوقائع إلى وثائق GitLab التي روجعت في 3 سبتمبر 2026 بشأن دقائق الحوسبة، وتطبيق الحصة، والشراء الإضافي، ونطاقات الأسماء، والكفاءة.

وتأتي الفروق التشغيلية من وثائق المشغلات، والاستضافة، وطلبات الدمج، والأمن، والتحليلات. لم تُفحص فواتير عملاء أو بيانات تشغيل خاصة أو عقود تفاوضية. تتعلق قراءة الحصة بـ GitLab.com، ولا تفترض خضوع كل أنظمة Self-Managed أو Dedicated للترتيب التجاري نفسه.