اختبار Cloudflare للتحكم في الحافة: هل يمكن عكس كل قاعدة؟

الملخص

• أقوى ادعاءات منتجات Cloudflare هو التحكم القابل للبرمجة عالميًا. تقول صفحاتها الرسمية أن الشركة تخدم 102 مليون طلب HTTP في الثانية في المتوسط وتخدم البيانات من 335 مدينة في أكثر من 125 دولة، بينما تقول صفحة شبكتها إن حركة مرور العملاء تتم معالجتها في أقرب مركز بيانات وأن كل خدمة تعمل في كل مركز بيانات. هذه البنية جذابة تجاريًا لأنه يمكن لسياسة التخزين المؤقت أو قاعدة WAF أو إصدار Worker أو قاعدة Zero Trust أو إعداد حماية الشبكة تغيير السلوك بالقرب من المستخدمين دون انتظار إعادة بناء كل بيئة أصلية. نفس البنية تجعل انضباط التغيير هو سؤال الموثوقية المركزي.
• تدعم الأدلة وجهة نظر ضيقة ومهمة حول Cloudflare Inc: إنها ليست مجرد CDN، ولا مجرد WAF، ولا مجرد بيئة تشغيل خوادم بدون خادم. إنها سطح تشغيل حافة يجمع بين وكيل حركة المرور والقواعد وسلوك التخزين المؤقت وقرارات الروبوت وWAF و Workers وR2 وAccess وTunnel وLogpush وعمليات الحالة وآليات الاسترجاع. تمتلك Cloudflare خدمات الحافة التي تديرها وعناصر التحكم الموثقة. لا تملك أصول العملاء أو رمز Worker الخاص بالعميل أو تعبيرات قواعد العميل أو خيارات DNS الخاصة بالعميل أو السحب الخارجية أو موفري الهوية الخارجيين أو عملية الإصدار الداخلي لكل فريق يستخدم Cloudflare.
• أفضل الأدلة العامة مختلطة بطريقة مفيدة. توثق Cloudflare آليات أمان جادة: إصدارات Worker، والنشر التدريجي، والاسترجاع، والمقاييس، وLogpush، وإصدارات Ruleset Engine، وقواعد WAF، وخيارات مسح التخزين المؤقت، ومنطق سياسة Access، وواجهات برمجة التطبيقات العامة للحالة. كما نشرت تقريرين بعد الحوادث في عام 2025 يظهران لماذا آليات الأمان ليست هي نفسها الأمان. في 18 نوفمبر 2025، انتشر خطأ في ملف ميزة إدارة الروبوتات عبر الشبكة وتسبب في فشل واسع النطاق من نوع 5xx. في 5 ديسمبر 2025، أثر تغيير متعلق بـ WAF على حوالي 28% من حركة مرور HTTP التي تخدمها Cloudflare لمدة 25 دقيقة تقريبًا. هذه ليست أسبابًا لرفض Cloudflare؛ إنها الحالات الاختبارية العامة الأكثر وضوحًا للحكم على عبء التشغيل الحقيقي للمنتج.
• لذلك فإن السؤال التجاري ليس ما إذا كانت Cloudflare يمكنها إجراء تغييرات سريعة على الحافة، فهي تستطيع ذلك. سؤال المشتري هو ما إذا كانت هذه السرعة تقلل بدرجة كافية من حمل الأصل واحتكاك النشر والأدوات الأمنية والتعرض للشبكة والأعباء على المطورين لتبرير الاعتماد على البائع واختبار القواعد والسجلات وتخطيط تجاوز الفشل وحدود وقت التشغيل وأعمال الترحيل وتعقيد الدعم. أظهر تقرير Cloudflare 10-K لعام 2025 وجود 332,466 عميلًا يدفعون و 4,298 عميلًا بإيرادات سنوية تتجاوز 100,000 دولار، وأظهر إصدار الربع الأول من 2026 إيرادات ربع سنوية قدرها 639.8 مليون دولار. هذه الأرقام تثبت الطلب. لكنها لا تثبت أن أي مشتري واحد لديه نتائج إيجابية خاطئة محدودة أو انتشار ثابت أو سجلات كاملة أو خطة استرداد.

المنتج هو التحكم، وليس مجرد التسليم

بدأت Cloudflare في السوق كوسيلة لجعل مواقع الويب أسرع وأكثر أمانًا، لكن منتج Cloudflare الحديث يُفهم بشكل أفضل على أنه لوحة تحكم موزعة عالميًا. تصف الشركة منصة تجمع بين SASE وأمن التطبيقات وتسليم التطبيقات وخدمات الشبكة والتطوير الكامل السيرفر ليس على نفس البنية التحتية العالمية. في صفحةحول Cloudflare، تقول Cloudflare أن أي دفع كود يؤثر تلقائيًا على ملايين ممتلكات الإنترنت وأنها تخدم 102 مليون طلب HTTP في الثانية في المتوسط من 335 مدينة في أكثر من 125 دولة. في صفحةالشبكة العالمية، تقول أن كل خدمة تعمل في كل مركز بيانات وأن حركة مرور العملاء تتم معالجتها بالقرب من مصدرها، مع أكثر من 13,000 اتصال عبر مزودي الخدمة ومزودي السحابة وشبكات المؤسسات.

هذه هي أطروحة التشغيل. إذا كانت كل خدمة متاحة في كل مكان، يمكن لنفس البنية التحتية تخزين الأصول مؤقتًا وتصفية الهجمات وفرض سياسة الوصول وتوجيه حركة المرور وتشغيل كود Workers ودفع السجلات. يرى العميل لوحة تحكم واحدة وعائلة API واحدة بدلاً من سلسلة من الأجهزة الإقليمية. يمكن تغيير قاعدة مرة واحدة وتطبيقها في أماكن كثيرة. يمكن نشر Worker على الحافة دون أن يدير العميل المناطق. يمكن لتغيير CDN تقليل حركة مرور الأصل دون تحريك الأصل. يمكن لسياسة Zero Trust حماية تطبيق دون كشف IP عام إذا كانت البنية مبنية حول Cloudflare Tunnel.

لهذا السبب فإن عرض القيمة لـ Cloudflare يختلف عن مزود استضافة ضيق. يصبح المنتج طبقة من صنع القرار أمام التطبيقات. بعض القرارات بسيطة: تخزين هذا الكائن مؤقتًا، تمرير هذا الطلب، حظر نطاق IP هذا، طلب مجموعة هوية معينة. البعض الآخر احتمالي أو سياقي: تعيين درجة روبوت، تقييم قاعدة WAF مُدارة، تحدي طلب، إرسال حركة المرور عبر مسار وصول آمن. لا يزال البعض الآخر قرارات مطور: تشغيل إصدار Worker هذا، ربط مساحة اسم KV هذه، قراءة كائن R2 هذا، استدعاء هذه الخدمة النهائية.

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

ما تملكه Cloudflare Inc وما لا تملكه

الحدود حول Cloudflare Inc مهمة لأن Cloudflare تظهر في العديد من قصص الفشل حيث تكون جزءًا واحدًا فقط من المسار. يمكن لموقع استخدام DNS من Cloudflare مع استضافة تطبيقه في مكان آخر. يمكن للعميل كتابة Worker معيب. يمكن للأصل إرجاع ترويسات سيئة تجعل سلوك التخزين المؤقت مفاجئًا. يمكن لمزود هوية خارجي أن يجعل سياسة Access غير قابلة للاستخدام. يمكن لمزود سحابة أن يفشل خلف وكيل Cloudflare. يمكن أن يكون سجل المسجل مهيأ بشكل خاطئ. يمكن للعميل كتابة تعبير WAF يحظر المشترين الحقيقيين.

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

تعزز إيداعات Cloudflare الحدود التجارية. يقولنموذج 10-K لعام 2025أن الإيرادات تأتي بشكل أساسي من الاشتراكات للوصول إلى شبكتها ومنتجاتها، إلى جانب خدمات الدعم، وأن العملاء يحصلون على وصول مستمر إلى شبكة ومنتجات Cloudflare بدلاً من امتلاك البرمجيات التي تدير الشبكة. هذا عقد خدمة، وليس نقل ملكية البنية التحتية. يقول نفس الإيداع أن الاحتفاظ بالعملاء والتوسع يعتمدان على الرضا عن أمان وأداء وموثوقية منتجات Cloudflare وشبكتها العالمية.

هذا أيضًا سبب أهمية نمو عملاء Cloudflare الكبار على نحو ذي حدين. أبلغ إيداع 2025 عن 332,466 عميلًا يدفعون في نهاية العام و 4,298 عميلًا بإيرادات سنوية تتجاوز 100,000 دولار. العملاء الكبار هم تحقق للمنصة، لكن الإيداع يقول أيضًا أن العملاء الكبار قد يتطلبون تكوينات وتكاملات ونشرًا ومساعدة في الترحيل والتزامات دعم وإنفاق على البنية التحتية للشبكة أكثر تعقيدًا. بعبارة أخرى، كلما نجحت Cloudflare في بيع التحكم للمؤسسات، كلما تم الحكم على المنتج من خلال إدارة التغيير الفوضوية بدلاً من التسويق البسيط لسرعة الصفحة.

الربع الأول من 2026 يظهر نفس التوتر. أعلنتنتائج الربع الأول من 2026عن إيرادات قدرها 639.8 مليون دولار، بزيادة 34% على أساس سنوي، مع دخل تشغيلي غير GAAP قدره 73.1 مليون دولار وتدفق نقدي حر قدره 84.1 مليون دولار. هذا طلب قوي على الحزمة. لكنه لا يحدد ما إذا كان يجب على عميل معين وضع WAF وCDN وWorkers وR2 وAccess وحماية الشبكة خلف بائع واحد. إنه يظهر فقط أن العديد من العملاء على استعداد للدفع مقابل الإمكانية.

القواعد هي حيث تصبح السرعة خطرًا

آلية القواعد في Cloudflare مركزية للمنصة. يحددتوثيق Ruleset Engineruleset على أنه مجموعة مرتبة من القواعد المطبقة على حركة المرور على شبكة Cloudflare العالمية. تنتمي rulesets إلى مراحل، ولها إصدارات، وكل تعديل ينشئ إصدارًا جديدًا. تظهرقائمة المراحلأن تنفيذ القواعد ليس إجراءً عامًا واحدًا؛ مراحل طبقة الشبكة، ومراحل Magic Transit، ومراحل الطلب، والمراحل الخاصة بالمنتج تعمل بترتيب محدد. القيمة أنه يمكن وضع قرارات الأمان وحركة المرور المختلفة في الجزء الصحيح من مسار الطلب. التكلفة هي أن الترتيب والنطاق واختيار المرحلة Matters.

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

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

تقولصفحة منتج WAFأن WAF يفحص طلبات HTTP/S على الحافة باستخدام قواعد مُدارة ومخصصة، وتدعي أن القواعد المُدارة يمكن أن تحمي من الثغرات الجديدة بسرعة. هذه ميزة جادة عندما تصبح ثغرة في إطار عمل أو مكتبة عامة قبل أن تتمكن فرق التطبيق من التصحيح. لكن معيار الأدلة يجب أن يكون مختلفًا لادعاء البائع حول التصحيح الافتراضي السريع مقابل قرار المشتري بتطبيقه. السؤال ليس فقط "هل يمكن لـ Cloudflare كتابة ونشر قاعدة؟" بل "هل ستعمل هذه القاعدة بشكل صحيح مع حركة المرور الحقيقية لدينا، وتدفق تسجيل الدخول، ومسار الدفع، وعملاء API، وتطبيقات الجوال، وتكاملات الشركاء؟"

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

Workers تجعل تغيير الحافة إصدار برمجيات

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

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

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

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

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

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

صحة التخزين المؤقت هي قرار تجاري

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

الجزء الصعب هو الصحة. يقولتوثيق سلوك التخزين المؤقت الافتراضيأن Cloudflare لا تخزن المورد عندما يكونCache-Controlخاصًا أو no-store أو no-cache أو max-age=0، أو عندما يكون هناك ترويسة Set-Cookie، أو عندما لا تكون طريقة الطلب GET. كما يقول أن Cloudflare تخزن مؤقتًا بعض امتدادات الملفات افتراضيًا، ولا تخزن HTML أو JSON افتراضيًا، وتستخدم طي الطلب بحيث لا تؤدي حالات فقدان التخزين المؤقت المتزامنة لنفس الأصل في مركز بيانات واحد إلى جلب أصل مكرر. هذه افتراضيات معقولة، لكن الافتراضيات ليست سياسة كاملة.

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

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

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

المراقبة جزء من المنتج، وليس إضافة

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

توثق Cloudflare عدة طرق للمراقبة. يقولمقاييس وتحليلات Workersأن مقاييس Workers والتحليلات المستندة إلى المنطقة يمكنها إظهار حركة المرور ومقاييس نجاح الطلب وخطأه وحالة الاستدعاء. يمكنLogpushإرسال السجلات إلى التخزين وSIEMs وموفري إدارة السجلات. يمكنلوحات تحكم صحة Logpushمراقبة حالة المهمة وتشخيص الأخطاء، لكن نفس الصفحة تلاحظ حدًا حاسمًا: لا يمكن لـ Logpush استعادة السجلات المفقودة بعد إسقاط البيانات.

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

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

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

Cloudflare One يوسع نفس النمط إلى الوصول

يجلب Cloudflare One نموذج التحكم في الحافة إلى الوصول والشبكات للمؤسسات. يصفتوثيق Cloudflare Oneمنصة SASE تتضمن Access وTunnel وSecure Web Gateway وBrowser Isolation وCASB وDLP وEmail Security وDigital Experience Monitoring. Access يوثق المستخدمين ويسجل كل حدث وطلب. Tunnel يربط الموارد بـ Cloudflare دون كشف IP عام من خلال اتصالات صادرة من البنية التحتية للعميل.

الجاذبية التقنية هي نفسها مع CDN وWAF: نقل تطبيق السياسة إلى مزود موزع وتقليل الحاجة إلى الأجهزة القديمة. الخطر هو نفسه أيضًا: صحة السياسة تصبح انضباطًا تشغيليًا. يقولتوثيق سياسات Accessأن قواعد Include تعمل مثل OR، وExclude مثل NOT، وRequire مثل AND. جميع سياسات Access تحتاج إلى قاعدة Include واحدة على الأقل، وقواعد Require تضيق النطاق. هذا المنطق واضح، لكن المنظمات الحقيقية ليست واضحة. لديهم متعاقدون، حسابات خدمة، مسؤولون طوارئ، اندماجات، أجهزة منتهية الصلاحية، هويات خارجية، واستثناءات يصعب نمذجتها.

Access يعتمد أيضًا على تفاعلات المنتج. يشير نفس توثيق السياسة إلى عدم توافق سياسة التجاوز عندما تتضمن سياسات التجاوز فحوصات حالة الجهاز ويكون إما Zaraz ممكّنًا للمنطقة المحمية أو يعترض Worker الطلب. الحل الموصى به هو تغيير إجراء السياسة إلى Service Auth. هذا هو بالضبط نوع التفاصيل التي تحدد ما إذا كان طرح Zero Trust ناضجًا. المشكلة ليست في وجود عدم توافق. المشكلة هي ما إذا كان لدى العميل الحوكمة لمعرفة أي المنتجات تتفاعل، ومن يملك الاستثناء، وكيف يتم اختبار الاستثناء بعد تغييرات الحافة اللاحقة.

يمكن لـ Cloudflare One تقليل انتشار الأجهزة وجعل الوصول أكثر أصلاً على الإنترنت. يمكنه أيضًا إنشاء تبعية جديدة على تكاملات الهوية، وصحة العميل، وتوفر النفق، وترتيب السياسة، والسجلات، ولوحة القيادة/API الخاصة بـ Cloudflare. المشتري الذي يقارن Cloudflare One بأجهزة VPN لا يجب أن يقارن الميزات فقط. بل يجب أن يقارن أوضاع الفشل. إذا كان Access غير متاح، ما الذي لا يزال يعمل؟ إذا كان مزود الهوية متدهورًا، من يمكنه الوصول إلى مسار كسر الزجاج؟ إذا قام Worker بتعديل طلب قبل تقييم Access، هل تم مراجعة هذا التفاعل؟ هذه الأسئلة تحدد ما إذا كان الدمج يقلل المخاطر أم يجعلها أكثر أناقة.

Magic Transit يظهر النسخة الشبكية من نفس الرهان

يوسع Magic Transit دور Cloudflare من وكيل تطبيقات إلى حماية الشبكة. يصفتوثيق Magic Transitخدمة مؤسسات لحماية DDoS وتسريع حركة المرور عبر الشبكات المحلية والسحابية والهجينة. يستخدم شبكة Cloudflare العالمية لامتصاص وتخفيف الهجمات بالقرب من مصدرها، ويتضمن فحوصات الصحة وتوجيه حركة المرور وعناوين IP التي تملكها Cloudflare وترابط BGP في مرحلة تجريبية. يصفالهندسة المرجعيةMagic Transit كحماية قائمة على BGP للبنية التحتية للشبكة المواجهة للإنترنت وتقول أن Cloudflare لديها مئات Tbps في سعة التخفيف وتخفيف عالمي متوسط أقل من ثلاث ثوانٍ.

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

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

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

R2 يغير اقتصاديات التخزين، لكن ليس مسؤولية البيانات

R2 مثال آخر على استخدام Cloudflare لموقع الحافة لمهاجمة مشكلة التكلفة. تصفصفحة منتج R2تخزينًا كائنيًا متوافقًا مع S3 بدون رسوم خروج، وتكامل مع Workers، وهجرة تدريجية من تخزين الكائنات الحالي. يقولتوثيق تسعير R2أن R2 يفرض رسومًا على التخزين بالإضافة إلى عمليات الفئة A والفئة B، ولا توجد رسوم على عرض النطاق الترددي للخروج لأي فئة تخزين، ويطبق قواعد الاسترجاع والحد الأدنى للمدة على تخزين Infrequent Access.

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

الخطر هو أن "لا رسوم خروج" يمكن أن يبدو مثل "لا اقتصاديات تخزين". هذا غير صحيح. العمليات قابلة للفوترة. استرجاع Infrequent Access له تكاليف. أدوات الترحيل يمكن أن تخلق رسوم عمليات. حوكمة البيانات، سياسة دورة الحياة، النسخ الاحتياطي، التشفير، التحكم في الوصول، وتوقعات الاتساق تظل مسؤوليات العميل. إذا نقل تطبيق من خدمة تخزين hyperscaler إلى R2، قد يقلل الفريق تكلفة النقل ولكنه يزيد الاعتماد على منصة مطوري Cloudflare وسلوك API ومسار الدعم والمراقبة.

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

انقطاع نوفمبر 2025 هو الاختبار العام الأكثر فائدة

حادث 18 نوفمبر 2025 هو المثال العام الأكثر وضوحًا لخطر التحكم في الحافة. فيتقرير ما بعد الحادث، قالت Cloudflare أن الشبكة بدأت تعاني من فشل كبير في الساعة 11:20 UTC. لم تكن المشكلة هجومًا. كانت ناتجة عن تغيير في أذونات قاعدة البيانات تسبب في استعلام إرجاع صفوف ميزة مكررة لـ Bot Management. أصبح ملف الميزة أكبر من المتوقع، وانتشر عبر الأجهزة في الشبكة، وتجاوز حدًا في وحدة الوكيل وتسبب في فشل. عادت حركة المرور الأساسية إلى طبيعتها إلى حد كبير بحلول الساعة 14:30، وكانت جميع الأنظمة تعمل بشكل طبيعي في الساعة 17:06.

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

قصة الاسترداد ذات صلة أيضًا. أوقفت Cloudflare إنشاء ونشر ملف الميزة السيئ، وأدخلت ملفًا صحيحًا معروفًا في قائمة انتظار التوزيع، وأعادت تشغيل أجزاء من النظام، واستعادة الخدمات بمرور الوقت. يقول الجدول الزمني أن أول اختبار آلي اكتشف المشكلة في الساعة 11:31، وانعقاد فريق الحادث في الساعة 11:35، وركز العمل على استرجاع Bot Management في الساعة 13:37، وتوقف النشر التلقائي في الساعة 14:24، ونشر ملف مصحح عالميًا في الساعة 14:30، واستعادة جميع الخدمات النهائية في الساعة 17:06.

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

التحليل المستقلمن Cisco ThousandEyes يضيف المنظر الخارجي. لاحظ ThousandEyes فشل HTTP 500 في الخدمات المعتمدة على Cloudflare التي تم مراقبتها، وشخص غياب مكونات التحدي أثناء فشل إدارة الروبوتات، ورأى بعض المؤسسات تنفيذ تجاوز فشل DNS بعيدًا عن Cloudflare AS 13335. استعاد هذا التجاوز إمكانية الوصول لبعض الخدمات، لكنه يعني أيضًا فقدان خدمات Cloudflare مثل إدارة الروبوتات والتخزين المؤقت على الحافة. هذا هو المفاضلة للعميل في جملة واحدة: تجاوز Cloudflare يمكن أن يعيد توفر الأصل، ولكن فقط إذا كان الأصل مستعدًا للعمل بدون طبقة Cloudflare.

انقطاع ديسمبر 2025 يظهر لماذا نوع الطرح مهم

حادث 5 ديسمبر 2025 كان أقصر، لكنه زاد نفس النقطة حدة. قالتقرير ديسمبرأن جزءًا من الشبكة عانى من فشل كبير في الساعة 08:47 UTC وتم استعادته في الساعة 09:12 UTC. قالت Cloudflare أن حوالي 28% من جميع حركة مرور HTTP التي تخدمها تأثرت. كان المشغل عملًا على تحليل جسم طلب WAF المتعلق باكتشاف وتخفيف ثغرة أمان حرجة في مكونات خادم React.

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

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

بالنسبة للعملاء، هذا يعني أن تصنيف التغيير مهم. يمكن للفريق أن يختبر بأمان Worker الخاص به بينما يظل معرضًا لتغيير من جانب المزود في قاعدة مُدارة أو تكوين. يمكن للفريق اختبار قاعدة WAF المخصصة الخاصة به بينما يعتمد على القواعد المُدارة لوحدات الوكيل في Cloudflare. هذا ليس فريدًا لـ Cloudflare؛ كل خدمة سحابية لديها مخاطر تغيير من جانب المزود. لكن موضع Cloudflare أمام حركة مرور العملاء يعني أن مخاطر تغيير جانب المزود يمكن أن تكون مرئية للمستخدمين النهائيين بسرعة كبيرة.

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

التبعية هي ثمن الدمج

عرض Cloudflare يصبح أقوى عندما يحاول العملاء تقليل انتشار الأدوات. قد لا يرغب فريق الويب في وجود بائعين منفصلين لـ CDN وDNS وإدارة الروبوتات و DDoS وWAF والتخزين الكائني وبيئة التشغيل الخالية من الخوادم ووكيل الوصول ومصدر السجلات وتوجيه حركة المرور. قد يفضل فريق الأمان سطح سياسة واحدًا على أجهزة في كل منطقة. قد يفضل فريق منصة المطورين Workers وR2 وPages على تجميع حوسبة سحابية وCDN وتخزين كائني من الصفر.

يمكن أن يكون الدمج عقلانيًا. عدد العملاء الكبار في 10-K لعام 2025 ونمو إيرادات الربع الأول من 2026 يظهران أن السوق يدفع ثمن ذلك. تشير إشارات العملاء المستضافة على البائع على صفحات WAF وWorkers وR2 إلى نفس الطلب: Carrefour تستخدم WAF من Cloudflare وإدارة الروبوتات عبر العديد من مواقع التجارة الإلكترونية، و Intercom تثني على سرعة Workers من المفهوم إلى الإنتاج، و Character.AI تصف R2 كجزء من بنية بيانات متعددة السحابات. يجب معاملة هذه الأمثلة كإشارات عملاء مختارة، وليس كدليل عالمي، لكنها تظهر الوظائف التي يوظف العملاء Cloudflare للقيام بها.

الثمن هو التبعية. العميل الذي يضع العديد من عناصر التحكم خلف Cloudflare يقلل من عمل التكامل ولكنه يزيد من عواقب مشاكل حساب Cloudflare، ومشاكل لوحة القيادة/API، وحوادث المزود، وتغييرات الفوترة، وتأخيرات الدعم، والحدود الخاصة بالمنتج. كما يزيد من تكلفة الخروج. مغادرة CDN أساسي أسهل من مغادرة مجموعة من قواعد WAF، وقواعد التخزين المؤقت، ومسارات Worker، وحاويات R2، وسياسات Access، والأنفاق، وسجلات DNS، وسجلات توجيه Magic Transit.

لهذا السبب، يجب أن تكون مناقشة lock-in تشغيلية وليست أيديولوجية. تستخدم Cloudflare العديد من البروتوكولات المفتوحة والواجهات المألوفة. DNS قياسي. HTTP قياسي. R2 متوافق مع S3. تستخدم Workers JavaScript والمفاهيم ذات الصلة ببيئة تشغيل الويب. لكن lock-in التشغيلية تأتي من دفاتر التشغيل والتنبيهات ولوحات القيادة والاستثناءات وسياسات الوصول وعادات الإنتاج التي تنمو حول البائع. قد يكون الفريق قادرًا على نقل الكود أو الكائنات، لكنه لا يزال يحتاج إلى أشهر لإعادة بناء نفس سلوك الأمان وحركة المرور في مكان آخر.

المقارنة الصحيحة ليست Cloudflare مقابل لا تكلفة. المقارنة هي سطح التحكم المتكامل لـ Cloudflare مقابل تكلفة تجميع واختبار وتشغيل عناصر تحكم مماثلة عبر hyperscaler و CDN وبائع أمان ومكدس هوية وسلسلة مراقبة. للحصول على تطبيق صغير، قد تكون أدوات السحابة المحلية المنفصلة أبسط. لخدمة عامة عالمية أو مؤسسة بها فرق كثيرة، يمكن لـ Cloudflare تقليل العمل المتكرر. مسؤولية المشتري هو تسعير التبعية بأمانة.

اختبار المشتري الجاد ينظر إلى التغييرات العادية

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

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

بالنسبة لـ Workers، يجب على المشتري اختبار انضباط الإصدار. انشر خدمة حقيقية صغيرة مع تحميل إصدار يدوي، ونشر تدريجي، ومراجعة المقاييس، واسترجاع، وتغيير ارتباط متعمد. ثم اختبر الحالات الحدودية: مساحة اسم KV مفقودة، ترحيل Durable الكيان، حد الطلب الفرعي، خدمة نهائية فاشلة، وسلوك فتح/إغلاق المسار عند الفشل. الهدف ليس اكتشاف فشل Cloudflare. الهدف هو تعلم أي حالات الفشل يمكن استردادها عن طريق استرجاع الكود وأيها تتطلب إصلاح البيانات أو التكوين.

بالنسبة للتخزين المؤقت، يجب على المشتري اختبار سلوك الترويسات ونطاق المسح. خدم الأصول الثابتة والصفحات المخصصة واستجابات API وصفحات الخطأ من خلال نفس عملية الإصدار التي سيستخدمها موقع الإنتاج. تأكد من أن سلوك Set-Cookie وCache-Control يطابق افتراضات الفريق. تدرب على مسح ملف واحد، ومسح بادئة، واسترجاع بعد قاعدة تخزين مؤقت سيئة. قدر حمل الأصل بعد مسح واسع قبل أن يجبر حادث على الاختيار.

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

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

الحكم مشروط

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

الحالة الصعودية هي الأقوى للفرق التي تحتاج في وقت واحد إلى العديد من عناصر التحكم في Cloudflare: تطبيقات الويب العامة ذات التعرض الجاد للهجوم، وقواعد المستخدمين العالمية، وضغط حمل الأصل، وفرق المطورين التي يمكنها استخدام Workers، وفرق الأمان التي تقوم بدمج WAF وسياسة الوصول، وفرق الشبكة التي يمكنها تبرير Magic Transit. بالنسبة لهؤلاء العملاء، يمكن لـ Cloudflare تقليل عمل البنية التحتية المكرر ونقل الحماية بالقرب من المستخدمين.

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

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