الخلاصة

  • يقرب GitHub زمن كل مهمة إلى أعلى دقيقة كاملة. جمع أزمنة المهام أولًا ثم تقريب المجموع مرة واحدة يخفي أثرًا ماليًا لحدود التقسيم.
  • في مثال افتراضي، ست مهام مكتملة مدة كل منها عشر ثوانٍ تعادل ست دقائق محسوبة، مقابل دقيقة لمهمة واحدة مدتها دقيقة كاملة. بسعر Linux القياسي المحدد، 0.006 دولار للدقيقة، يصبح الاستهلاك 0.036 دولار مقابل 0.006 دولار.

من يصمم سير العمل يستطيع إصدار أمر شراء من دون أن يفتح شاشة المشتريات. يكفي أن يقسم العمل إلى مهام مستقلة في GitHub Actions. لكل مهمة ساعة صغيرة، ولكل ساعة حد أدنى كامل عند احتساب الدقائق.

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

ستة مؤقتات بدل مؤقت واحد

نثبت المقارنة على مستودع خاص ومشغل Linux قياسي بمعمارية x64 ونواتين. السعر الحالي لهذه الفئة 0.006 دولار للدقيقة. نفترض ست مهام، تستغرق كل واحدة منها عشر ثوانٍ من زمن المهمة الكامل المقاس. يبلغ مجموع وقت المشغلات ستين ثانية، لكن كل مهمة تُقرب إلى دقيقة: ست دقائق، بقيمة 0.036 دولار.

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

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

الثانية التي تعبر الدرجة أغلى

مهمة مدتها 61 ثانية تُقرب إلى دقيقتين. مهمة مدتها دقيقة كاملة تبقى دقيقة. هنا يخفض اختصار ثانية واحدة الكمية المحسوبة إلى النصف. وفي المقابل، تقليل إحدى عشرة ثانية إلى عشر يترك الكمية دقيقة واحدة في الحالتين.

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

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

الرصيد المشمول يدفع قبل البطاقة

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

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

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

ما الذي نشتريه حين نفصل المهام؟

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

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

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