Cloudflare Workflows بعد تقليص سجل التشغيل: كيف تضبط الاحتفاظ والتكلفة

ما الذي تغيّر في Cloudflare Workflows؟ الإعداد الافتراضي لا الحد الأقصى

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

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

للتغيير الذي جاء في سبتمبر ثلاثة حدود واضحة:

• أي Workflow على Workers Paid أُنشئت في 10 سبتمبر أو بعده تصبح مدة الاحتفاظ الافتراضية بحالة المثيلات المكتملة أو المنتهية بخطأ فيها 7 أيام.
• أما أي Workflow قائمة فتستمر وفق سياسة الاحتفاظ الحالية. لم تُقصّر Cloudflare مدة Workflows القديمة بأثر رجعي.
• تظل Workers Free عند 3 أيام، وهي مدة الاحتفاظ الافتراضية والحد الأقصى معًا.

لا تزال الخطة المدفوعة تتيح الاحتفاظ بالحالة حتى 30 يومًا. ما خفّضته Cloudflare إذن هو الإعداد الافتراضي، لا الحد الأقصى.

هذا الفرق يحسم تعارضًا محرجًا بين صفحات التوثيق. كان آخر تحديث لـصفحة التسعير في 21 يوليو، وما زالت تصف 30 يومًا بأنها المدة الافتراضية لخطة Paid. أما مرجع Workers API، الذي حُدّث في 12 أغسطس، فيقول إن حذف إعداد الاحتفاظ يجعل النظام يستخدم الحد الأقصى للحساب. كلتا الصفحتين سبقتا سجل تغييرات 10 سبتمبر.

اعتمد القاعدة الأحدث والأكثر تحديدًا: 7 أيام هي المدة الافتراضية لأي Workflow مدفوعة جديدة. لا تتغير Workflows المدفوعة القائمة، ويظل 30 يومًا هو الحد الأقصى للخطة المدفوعة.

مهلة التعامل مع الحوادث أصبحت 7 أيام

السؤال الحقيقي ليس ما إذا كانت 7 أيام تبدو قصيرة، بل ما إذا كان فريقك يكتشف الأعطال المهمة قبل اليوم السابع.

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

وهناك فخ ثانٍ أمام مهندس SRE. تُبقي Cloudflare مقاييس Workflow قابلة للاستعلام لمدة 31 يومًا، لكن نافذة التحليلات هذه ليست هي فترة الاحتفاظ بالحالة التفصيلية للمثيل. قد يبيّن أحد المقاييس وقوع عطل، إلا أنه لا يثبت بقاء معاملات المثيل القديم ومخرجاته ومحاولاته وأخطائه متاحة.

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

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

افصل سجل النجاحات الرخيص عن سجل الأخطاء القيّم

تمنحك Cloudflare عنصرَي تحكم لسبب وجيه:

• يحدد successRetention مدة بقاء الحالة بعد اكتمال العملية بنجاح.
• يحدد errorRetention مدة بقاء الحالة بعد انتهاء العملية بخطأ أو بإيقافها.

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

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

يوضح المثال الرسمي للتغيير هذا الفصل مباشرةً:

const instance = await env.MY_WORKFLOW.create({
	retention: {
		successRetention: "2 days",
		errorRetention: "30 days",
	},
});

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

لا تستقيم حسابات التخزين من دون فصل الحالة النشطة

تسعّر Cloudflare مساحة تخزين Workflows بوحدة GB-month. في Workers Paid، تشمل الخطة أول 1 GB-month، وتبلغ كلفة التخزين الإضافي $0.20 لكل GB-month. وتحسب Cloudflare هذا القياس بأخذ متوسط ذروة التخزين اليومية على امتداد دورة فوترة من 30 يومًا.

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

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

فيما يلي نموذج افتراضي صريح، وليس اختبار أداء من Cloudflare ولا وفرًا مضمونًا.

افترض أن عمليات التشغيل الناجحة تضيف 1 GB من الحالة الجديدة المحتفَظ بها يوميًا مع ثبات الحجم. وتسهم المثيلات النشطة وقيد التشغيل والنائمة بمقدار 0.5 GB-month إضافي في كلا السيناريوهين. ولعزل أثر مدة الاحتفاظ بالنجاحات، استبعد تخزين حالات الخطأ من المقارنة. إذا ظل errorRetention عند 30 يومًا، فقِس تلك الحالة وأضف بند سجل الأخطاء نفسه إلى الجانبين.

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

الحدود التي ينبغي قولها بوضوح

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

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

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

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

ما الذي ينبغي فعله الآن؟

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

أجّل تحسين التكلفة إذا كانت الـWorkflow لا تزال تجربة منخفضة الحجم وتقع حالتها المحتفَظ بها ضمن أول 1 GB-month المشمول. ومع ذلك، اجعل السياسة صريحة؛ فنافذة التحقيق مهمة حتى عندما تكون زيادة كلفة التخزين صفرًا.

لا يؤثر عليك تغيير الإعداد الافتراضي إذا كانت Workflow قائمة بالفعل قبل 10 سبتمبر. كما أن Workers Free لم تتغير، إذ يظل الإعداد الافتراضي والحد الأقصى فيها 3 أيام. وفي الحالتين، يظل السجل الخارجي ضروريًا عندما تحتاج الأعمال إلى التحقيق بعد انتهاء نافذة المنصة.

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

اشترك في النشرة لتصلك الخطوة العملية التالية لأي تغيير في المنصات.