خدمةٌ ما لا تجيب إلا عن عدد قليل من الطلبات، ومع ذلك تكلّف أكثر من المتوقع. وخدمة أخرى تعالج كثيرًا من الاستدعاءات القصيرة بتكلفة زهيدة. لذلك فإن من يقيّد عدد الطلبات فقط لا يقيس تلقائيًا ما سيظهر لاحقًا في فاتورة البنية التحتية. فالتحكم في التكاليف والتحكم في الحمل يعملان عند نقاط مختلفة.
في 12 أكتوبر 2026، أعلنت Google عن الإتاحة العامة لسقوف الإنفاق في الميزانيات (Budget spend caps) في Cloud Run. وبعد إعداد سقف الإنفاق، يمكنه إيقاف أحمال العمل المعنية مؤقتًا. هذا تغيير مهم في البنية التحتية. لكنه لا يصبح مفهومًا إلا عندما تميّز بين تنبيه الميزانية وسقف الإنفاق والحدّ المفروض على الطلبات الفردية.
ثلاثة أسئلة، ثلاثة حدود مختلفة
يجيب حدّ الطلبات عن أسئلة مثل: كم استدعاءً يجوز لعميل معيّن أن يرسل خلال فترة محددة؟ أما حدّ العمل المتزامن فيسأل: ما مقدار ما يجوز تشغيله بالتوازي؟ وفي المقابل، ينظر حدّ التكاليف إلى استهلاك الموارد المسعَّر ضمن نطاقه. هذه الكميات مترابطة، لكنها ليست قابلة للتبادل.
لخدمتنا الخيالية مهمتان. إحداهما تُعيد استجابة حالة قصيرة. والأخرى تعالج مستندًا طويلًا. كلتاهما تبدأ بطلب واحد بالضبط، لكنهما تتطلبان مقادير مختلفة من العمل. وحتى لو سُمح للمستخدمَين بالعدد نفسه من الاستدعاءات، فلا يترتب على ذلك أنهما يفرضان الحمل نفسه على البنية التحتية. فالعدّاد الواحد يُخفي اختلاف دلالة مدخلاته.
تنبيه الميزانية ليس إيقافًا بعدُ
تميّز وثائق الفوترة الرسمية بين الميزانيات التي تقتصر على التنبيه وسقوف الإنفاق. وتعتمد السقوف الموصوفة على التكاليف الإجمالية التقديرية؛ ولا تُحتسب فيها الوفورات والأرصدة. ويقتصر النطاق على مشروع واحد وخدمة مدعومة، والفترة شهرية. وينبغي للمشغّل أن يحرص على قراءة هذه الشروط قبل تهيئة أي شيء.
كما أن التطبيق ليس فوريًا. إذ تشير Google إلى أن التجاوزات الناتجة عن التأخيرات تظل محتسبة في الفاتورة. لذلك فإن المبلغ المُدخَل ليس وعدًا رياضيًا بأن الفاتورة النهائية ستتوقف عنده بالضبط. تقدّم الميزة الجديدة تدخلًا تقنيًا، لا بديلًا عن فهم طريقة الفوترة.
بالنسبة إلى Cloud Run، تصف وثائق المنتج آثارًا محددة: لا تعود الخدمات قادرة على تلبية الطلبات وتُعيد أخطاء في نطاق 5xx؛ ولأنواع الموارد الأخرى عواقبها الخاصة. لذلك فإن إيقاف التكاليف هو أيضًا قرار يتعلق بالتوافر. وهذه العاقبة مكانها التخطيط، لا تقرير الحادث فحسب.
تجربة ذهنية تُظهر أي قاعدة تنطبق ومتى
لست بحاجة إلى إيقاف خدمة قيد التشغيل لكي تفهم النموذج. ارسم ثلاثة عدّادات مستقلة: الاستدعاءات لكل عميل، والعمل الجاري في الوقت نفسه، والتكاليف التقديرية في الفترة قيد النظر. وخصّص لكل منها استجابة. القاعدة الأولى ترفض المزيد من الاستدعاءات من عميل ما، والثانية تحدّ من التوازي، والثالثة يمكنها إيقاف نطاق خدمة محدد بأكمله مؤقتًا.
Client limit: Who may send requests, and how often?
Concurrency limit: How much work runs at the same time?
Spend cap: When is the service in question paused?ثم جرّب حالتين مختلقتين: طلبات قصيرة كثيرة، وطلبات قليلة متطلبة. أدخِل فروقًا نوعية فقط، لا مبالغ مختلقة باليورو. يُظهر هذا التمرين أي قاعدة ترى كل حالة أصلًا. إنه نموذج ذهني، وليس اختبارًا مقيسًا للحمل أو التكاليف.
البنية التحتية للمشغّل ليست حصة العميل
تستخدم KENJTEC خدمة Cloud Run لخدمات المنصة؛ ويمكن تتبّع ذلك في مصادر البنية التحتية والنشر الخاصة بالمشروع. ولا يترتب على ذلك أن ميزة Google الجديدة قد فُعّلت تلقائيًا. كما أنه لا يمنح كل حساب عميل في KENJTEC سقفًا للبنية التحتية قابلًا للضبط بشكل فردي. فمشروع المشغّل واشتراك العميل حدّان مختلفان للفوترة.
عمليًا، يكون السؤال المهم إذن: ما الاستخدام الذي يُقصد بالحدّ حمايته، وما العمل الذي سيتوقف أيضًا عند تفعيله؟ والخطة المعقولة تصف التحذير والتدخل والاستئناف معًا. عندئذ فقط يمكنك تقدير مدى توافق سقف الإنفاق مع حدود الطلبات ومتطلبات التوافر الخاصة بك.
المصادر والحالة
البحث والتوثيق حتى 25 أكتوبر 2026. ملاحظات إصدار Cloud Run — أكتوبر 12، 2026 · إعدادات الفوترة للخدمات — سقوف الإنفاق في الميزانيات · إدارة ميزانيات سقوف الإنفاق.
