Michael Johnsonهل يمكن تقييد الإنفاق على الحوسبة السحابية من دون المخاطرة بإيقاف تطبيق قيد التشغيل؟ تتيح Cloudflare الآن الخيارين، لكن الحد الصارم يعمل كمفتاح إيقاف للمنتج على مستوى الحساب: فعند بلوغ العتبة، يمنع عمليات جديدة مشمولة. ومع ذلك، لا تضمن العتبة نفسها حدًا أقصى للفاتورة.
في 13 نوفمبر 2026، أعلنت Cloudflare إطلاق Spend Management لعملاء الدفع حسب الاستخدام (Pay-as-you-go). عند الإطلاق، أصبحت الحدود والتنبيهات متاحة لخدمتي Workers وDurable Objects. وهي آلية حماية تلقائية من الارتفاع المفاجئ في الاستهلاك، شريطة أن يفهم الفريق الخدمات التي سيشملها إيقاف موحّد، كما توضح Cloudflare.
ما الجديد مقارنةً بتنبيه الإنفاق؟
ينبهك الإشعار إلى بلوغ الإنفاق مستوى تختاره، فيما يواصل المنتج عمله. أما الحد الصارم فيمنع العمليات المشمولة. وفي Spend Management، تُضبط سياسة مستقلة لكل منتج، تشمل مبلغ الحد وعتبات الإشعار، وعنوان بريد إلكتروني عند ضبطه. وحدود Workers وDurable Objects مستقلة بعضها عن بعض، ويشمل كل منها المنتج المعني في الحساب كله. ولا يمكن ضبط عتبة لعامل Worker واحد أو لمساحة أسماء منفردة في Durable Objects أو لمقياس واحد، وفقًا لوثائق Cloudflare.
الخيار العملي واضح: يناسب الإشعار الحالات التي تكون فيها إتاحة الخدمة أهم، بينما يناسب الحد الذي يمنع العمليات فريقًا مستعدًا لإيقاف العمليات المشمولة للمنتج كي يحد من الاستهلاك اللاحق.
لماذا لا يُفعّل الحدّ عند المبلغ المحدد بالضبط؟
لا يجري احتساب الإنفاق وتعميم الحظر فورًا. وتصف Cloudflare لوحة التحكم بأنها تعرض الإنفاق شبه آني، في أقل من 10 دقائق؛ لكن محرك احتساب التكلفة لا يتدخل في مسار كل طلب. وتُعمّم السياسة على عقد الشبكة بصورة غير متزامنة، ثم تطبق بيئة التشغيل السياسة عند تحديث حالتها المحلية دوريًا. هكذا تشرح Cloudflare آلية عمل Spend Management.
لذلك، فالعتبة المحددة نقطة يُفترض أن يبدأ الحظر بعدها، وليست سقفًا صارمًا للفاتورة النهائية. وقد تستمر العمليات أثناء احتساب الإنفاق وتعميم القاعدة. كما أن بعض الرسوم لا تدخل في الحد: فمثلًا، تُستثنى رسوم اشتراك Workers Paid، وقد تواصل البيانات المخزنة في Durable Objects توليد تكاليف بعد الإيقاف المؤقت. وتحذر Cloudflare من أن الفاتورة هي التي تعرض المبلغ النهائي.
ما أجزاء التطبيق التي سيوقفها حدّ Workers؟
يجمع حدّ Workers تكاليف الطلبات ووقت وحدة المعالجة المركزية (CPU) لجميع Workers في الحساب، بعد خصم الحصة المشمولة. وعند سريان الحظر، ترفض Cloudflare استدعاءات الشيفرة الجديدة التي تنشئ تكاليف. أما الموارد الثابتة التي تُقدّم من دون تشغيل شيفرة Worker فتستمر في العمل. وهذا هو نطاق التطبيق الموصوف في وثائق Workers.
لنتصور حسابًا يضم تطبيقًا إنتاجيًا وWorker للاختبار. إذا أوصل حمل الاختبار إجمالي إنفاق Workers إلى العتبة، فقد يؤثر الحظر أيضًا في شيفرة الإنتاج ضمن الحساب نفسه. لا يمكن تخصيص حد لكل تطبيق على حدة؛ ولعزل الآثار، يمكن للفريق توزيع الأحمال المعنية على حسابات مختلفة أو اختيار الإشعارات إذا كان إيقاف Workers غير مقبول.
يحتسب الحد المنفصل لـDurable Objects الطلبات ومدة التنفيذ وعمليات قراءة صفوف SQLite وكتابتها، فضلًا عن عمليات القراءة والكتابة والحذف في مخزن key-value. ولا يشمل Workers أو Workers AI أو KV أو R2 أو غيرها من المنتجات. وإذا كان التطبيق يعتمد على خدمات متعددة، فلن يحمي حد واحد سوى الجزء الموافق من النفقات، وقد يؤدي إيقاف إحدى حلقات الخدمة إلى تعطيل التطبيق.
ما الذي ينبغي التحقق منه قبل تفعيل الحظر؟
ارسم خريطة تبعيات الحساب: ما التطبيقات التي تستخدم Workers، وما المهام الخلفية التي تشغّلها الجداول الزمنية أو قوائم الانتظار، وما الخدمات التي تستدعي Durable Objects. ثم قرر المنتجات التي يمكن قبول إيقافها تلقائيًا. إذا كان الانقطاع أسوأ من تجاوز الميزانية، فاضبط عتبة إشعار من دون حظر. وإذا كان الحظر مقبولًا، فاختر مبلغًا يراعي تأخير المعالجة والحصص المشمولة والنفقات المستثناة من الحد.
تشرح Cloudflare إمكانية الإعداد عبر لوحة التحكم وcf CLI وREST API. فعلى سبيل المثال، عند إنشاء سياسة باستخدام API، يُستخدم الحقل threshold_cents لتحديد المبلغ بالسنتات، وproduct_id للمنتج، وaction للإجراء، وnotification_email للإشعارات؛ ويظهر المثال في إعلان الشركة. ولا يغيّر الإعداد الآلي نطاق التطبيق: يظل الحد مشتركًا بين المنتج في الحساب.
حدّد مسبقًا أيضًا إجراء استعادة الخدمة. ولرفع الإيقاف قبل دورة الفوترة التالية، تقترح Cloudflare زيادة الحد فوق الإنفاق المتراكم أو تعطيله أو حذف السياسة. وقد يستغرق سريان التغييرات بضع دقائق؛ كما أن إعادة تفعيل الحد نفسه لا تصفّر إنفاق دورة الفوترة الحالية.
متى تكون هذه الآلية مفيدة؟
تضيف Spend Management استجابة آلية لزيادة الاستهلاك: فبدل الاكتفاء برسالة بريد إلكتروني، يمكن للنظام إيقاف العمليات الجديدة المشمولة للمنتج المحدد. وقد تكون هذه الآلية وسيلة حماية من حمل غير مضبوط لحساب يضم مهام اختبارية. أما في الحسابات التي تتضمن خدمات حيوية متعددة، فيربط الحد المشترك بين الميزانية وإتاحة جميع Workers أو جميع Durable Objects في الحساب.
يعتمد القرار على مدى تقبّل كلفة الإيقاف. إذا كانت استمرارية العمل أهم، فابدأ بالإشعارات ومراقبة الإنفاق. وإذا كان الحد من الاستخدام اللاحق أهم، ففعّل الحظر بعد التحقق من التبعيات والاستعداد للاستعادة. وينبغي التخطيط للعتبة بوصفها سياسة لإيقاف المنتج، لا وعدًا بمبلغ دقيق للفاتورة.
