لم تكن أعطال Cloudflare البارزة في 2025 و2026 نتيجة سبب واحد يمكن اختزاله في أن «الشبكة تعطلت». تكشف تقارير ما بعد الحوادث الرسمية عن أنماط فشل مختلفة: اعتماد حرج على بنية تخزين خارجية، أخطاء Configuration انتشرت عالميًا، خلل في Service Topology أدى إلى سحب مسارات DNS، Route Leak في BGP، ثم خطأ في مسار إدارة BYOIP أدى إلى سحب عناوين عملاء من الإنترنت.
هذه الحوادث مهمة حتى لمن لا يستخدم Cloudflare مباشرة، لأنها تقدم أمثلة واقعية على سؤال هندسي أوسع: كيف تتحول مشكلة صغيرة في Dependency أو Configuration أو Routing إلى عطل واسع، وكيف تصمم خدمة بحيث لا يؤدي خطأ واحد إلى إسقاط كل شيء؟
الخلاصة السريعة: ماذا تكشف أعطال Cloudflare؟
أبرز درس ليس أن البنية الموزعة عديمة الفائدة، ولا أن الاعتماد على Cloudflare خطأ بحد ذاته. الدرس هو أن توزيع الخوادم جغرافيًا لا يلغي وجود Failure Domains مشتركة. قد تكون لديك مئات نقاط الحضور، لكن خدمة تخزين واحدة أو Configuration Pipeline واحدة أو قرار Routing واحد قد يملك القدرة على التأثير في جزء كبير منها في وقت قصير.
| الحادث | ما الذي حدث؟ | نوع الفشل | الدرس الرئيسي |
|---|---|---|---|
| 12 يونيو 2025 | فشل بنية التخزين التي تعتمد عليها Workers KV وأثر في منتجات متعددة | Dependency Failure | التوزيع الجغرافي لا يعوض Dependency مشتركة غير معزولة |
| 14 يوليو 2025 | سحب مسارات 1.1.1.1 عالميًا بسبب خطأ Service Topology | Network Configuration | Control Plane الخاطئ يستطيع تعطيل خدمة سليمة تقنيًا |
| 18 نوفمبر 2025 | Feature File أكبر من المتوقع انتشر إلى الشبكة وتسبب في فشل Core Traffic | Configuration Propagation | سرعة النشر نفسها تزيد Blast Radius عندما يكون التغيير خاطئًا |
| 5 ديسمبر 2025 | تغيير Configuration عالمي فعّل خطأ قديمًا في Proxy وأنتج HTTP 500 | Software + Configuration | حتى Killswitch يحتاج Progressive Rollout وGuardrails |
| 22 يناير 2026 | Route Leak غير مقصود لمسارات IPv6 من ميامي | BGP Routing | خطأ Routing محلي قد يؤثر في شبكات وأطراف خارجية أيضًا |
| 20 فبراير 2026 | سحب نحو 1,100 BYOIP Prefix دون قصد | BYOIP / BGP Automation | الأتمتة تحتاج حدود تأثير وRollback آمن بقدر ما تحتاجه العمليات اليدوية |
12 يونيو 2025: عندما أصبحت Workers KV Dependency حرجة
في 12 يونيو 2025 استمر تأثير الحادث نحو ساعتين و28 دقيقة على الخدمات المتأثرة. أوضحت Cloudflare في تقرير ما بعد حادث 12 يونيو أن السبب كان فشلًا في بنية التخزين الأساسية التي تستخدمها Workers KV.
المهم هنا أن Workers KV لم تكن منتجًا معزولًا. كانت منتجات أخرى تعتمد عليها في وظائف مثل Configuration وAuthentication وتسليم بعض الأصول. وكان جزء من بنية التخزين الخلفية يعتمد على مزود Cloud خارجي تعرض هو نفسه لانقطاع.
لذلك امتد الأثر إلى خدمات من بينها Access وWARP وGateway وWorkers AI وTurnstile وأجزاء من Dashboard، بينما أكدت Cloudflare أن DNS وCache وProxy وWAF وMagic Transit وMagic WAN لم تتأثر مباشرة بهذا الحادث.
هذه نقطة مهمة في تصميم الأنظمة: عدد النسخ ليس هو نفسه استقلالية النسخ. إذا كانت عشر خدمات موزعة تعتمد جميعها على Backend واحد لاتخاذ قرار حرج، فقد يتحول هذا الـBackend عمليًا إلى Single Point of Failure منطقي حتى إن كانت بقية البنية موزعة عالميًا.
14 يوليو 2025: لماذا اختفى 1.1.1.1 رغم أن خوادم DNS لم تتلف؟
كان حادث 14 يوليو مختلفًا تمامًا. أصبحت خدمة Public DNS Resolver على 1.1.1.1 غير متاحة لمدة تقارب 62 دقيقة، مع تدهور متقطع في Gateway DNS.
بحسب التحليل الرسمي للحادث، أُدخل في 6 يونيو خطأ Configuration ضمن Service Topology لخدمة كانت قيد الإعداد. أُضيفت Prefixes الخاصة بـ1.1.1.1 إلى تلك البنية دون قصد، لكن الخطأ بقي خامدًا ولم يؤثر فورًا في المستخدمين.
في 14 يوليو أدى تغيير ثانٍ إلى تحديث Configuration العالمية، فتحولت Topology الخاصة بمسارات 1.1.1.1 من جميع المواقع إلى موقع واحد Offline. النتيجة كانت سحب Prefixes الخاصة بالخدمة عالميًا.
هذا يوضح الفرق بين أن تكون الخدمة نفسها سليمة وبين أن تكون قابلة للوصول عبر الشبكة. يمكن أن تعمل الخوادم والبرمجيات بصورة طبيعية، لكن إذا اختفى Route الذي يخبر بقية الإنترنت بكيفية الوصول إلى عنوانها، تصبح الخدمة عمليًا غير موجودة للمستخدم.
لمن يحتاج أساسًا أوسع عن عناوين IP والتوجيه وDNS قبل متابعة هذه الطبقة، يشرح دليل أساسيات الشبكات من الصفر العلاقة بين هذه المكونات دون الحاجة إلى تحويل هذا المقال إلى شرح كامل لبروتوكولات الشبكات.
18 نوفمبر 2025: Configuration صحيحة في الشكل وخطيرة في المحتوى
كان عطل 18 نوفمبر من أكثر الحوادث وضوحًا في إظهار خطر Configuration التي تنتشر بسرعة كبيرة.
بدأت المشكلة بعد تغيير في Permissions لنظام قواعد بيانات ClickHouse. أدى التغيير إلى ظهور Entries إضافية عند تنفيذ Query تستخدمها منظومة Bot Management لإنشاء Feature File. تضاعف حجم الملف تقريبًا، ثم جرى توزيعه إلى أجهزة الشبكة.
كان البرنامج الذي يعالج Traffic يفرض حدًا على عدد Features أقل من الحجم الذي وصل إليه الملف الجديد، فبدأت العمليات تفشل وظهرت HTTP 5xx على نطاق واسع. توضح Cloudflare تفاصيل السلسلة كاملة في Postmortem عطل 18 نوفمبر 2025.
اشتبهت الشركة في البداية في DDoS ضخم بسبب طبيعة الأعراض، لكنها أكدت لاحقًا أن الحادث لم يكن هجومًا إلكترونيًا ولا نشاطًا ضارًا.
المثير هندسيًا هنا أن نظام التوزيع فعل ما صُمم لفعله: أخذ Configuration جديدة ووصل بها بسرعة إلى عدد هائل من الأجهزة. المشكلة أن النظام لم يكن يملك Guardrails كافية لمنع بيانات غير متوقعة من الوصول إلى نطاق عالمي.
بمعنى آخر، آلية النشر السريع كانت تعمل؛ ما فشل هو التحكم في Blast Radius.
5 ديسمبر 2025: لماذا يمكن لـKillswitch أن يسبب عطلًا؟
بعد أقل من ثلاثة أسابيع وقع حادث عالمي آخر، لكنه نشأ من مسار مختلف. بدأ التأثير في 5 ديسمبر الساعة 08:47 UTC وانتهى نحو 09:12، أي قرابة 25 دقيقة. ووفق Cloudflare، كان العملاء المتأثرون يمثلون نحو 28% من HTTP Traffic التي تخدمها الشبكة.
كانت الشركة تجري تغييرات مرتبطة بمعالجة HTTP request bodies أثناء العمل على حماية العملاء من ثغرة في React Server Components. جرى اكتشاف أن أداة WAF اختبارية داخلية لم تكن متوافقة مع تغيير في Buffer Size، فاستُخدم Configuration عالمي لتعطيل الأداة.
المشكلة أن هذا التغيير الثاني لم يستخدم Rollout تدريجيًا؛ بل انتشر خلال ثوانٍ. وفي الإصدار القديم FL1 من Proxy فعّل التغيير خطأ برمجيًا قديمًا في معالجة Ruleset، ما أدى إلى HTTP 500 لبعض العملاء. تشرح Cloudflare الشروط الدقيقة في تقرير حادث 5 ديسمبر 2025.
الدرس هنا مهم: لا يكفي أن تسمي شيئًا Killswitch أو Emergency Control حتى يصبح آمنًا تلقائيًا. مسار الطوارئ نفسه يحتاج Testing، وحدود تأثير واضحة، وإمكانية Rollback سريعة.
22 يناير 2026: Route Leak من ميامي أثر في Cloudflare وشبكات أخرى
في 22 يناير 2026 تسبب خطأ في Automated Routing Policy Configuration في إعلان BGP Prefixes بصورة غير مقصودة من Router في مركز Cloudflare بمدينة ميامي.
استمر Route Leak نحو 25 دقيقة، واقتصر على IPv6، لكنه تسبب في ازدحام داخل جزء من Backbone في ميامي وارتفاع Packet Loss وLatency. كما تأثرت أطراف خارج Cloudflare لأن بعض Traffic الخاصة بها انجذبت إلى مسارات لم يكن يفترض أن تمر عبر شبكة Cloudflare في ميامي.
يقدم Postmortem حادث Route Leak مثالًا عمليًا على أن أخطاء BGP لا تحتاج إلى إسقاط Router أو قطع Fiber حتى تسبب مشكلة. يكفي أن تعلن شبكة Route لا ينبغي لها إعلانه.
يعرّف RFC 7908 الأنواع الشائعة لتسريبات المسارات، وهي ظاهرة تختلف عن مجرد فقد Prefix بالكامل.
إذا كانت مفاهيم Prefix وCIDR غير مألوفة، فإن شرح Subnetting وCIDR يوفر الأساس اللازم لفهم كيفية تمثيل نطاقات عناوين IP دون الخوض هنا في تفاصيل حساب الشبكات الفرعية.
20 فبراير 2026: خطأ BYOIP سحب عناوين عملاء من الإنترنت
وقع أحد أكثر الأمثلة مباشرة على تأثير Automation في 20 فبراير 2026. تأثر جزء من العملاء الذين يستخدمون Bring Your Own IP أو BYOIP، وهي خدمة تسمح للعميل باستخدام نطاقات IP التي يملكها ضمن خدمات Cloudflare.
كان الهدف من التغيير هو أتمتة عملية إزالة Prefixes التي يطلب العميل حذفها. لكن Cleanup Task أرسلت Query لمعلمة pending_delete بطريقة جعلتها تُفسر كطلب لجميع BYOIP Prefixes بدل تلك المنتظرة للحذف فقط.
بدأ النظام نتيجة ذلك في إزالة Prefixes وما يرتبط ببعضها من Service Bindings. قبل إيقاف العملية كان نحو 1,100 BYOIP Prefix قد سُحب من شبكة Cloudflare. ذكرت الشركة أن هذا مثّل نحو 25% من BYOIP Prefixes التي كانت تعلنها إلى الـPeer الذي استخدمته لشرح الأثر.
استمر الحادث الإجمالي ست ساعات وسبع دقائق، وكان جزء كبير من تلك المدة مرتبطًا باستعادة Configuration لبعض العملاء بعد إيقاف السبب المباشر. التفاصيل موثقة في Postmortem عطل BYOIP في فبراير 2026.
من المهم أيضًا عدم الخلط بين هذا الحادث وبين عطل 1.1.1.1 في يوليو. خلال حادث فبراير ظهرت أخطاء على موقع one.one.one.one، لكن Cloudflare أوضحت أن DNS Resolution عبر Public Resolver نفسه، بما في ذلك DNS over HTTPS، لم تتعطل بسبب حادث BYOIP.
لماذا كانت الأسباب مختلفة لكن النتيجة متشابهة؟
عند النظر إلى الحوادث معًا تظهر أربع طبقات مختلفة يمكنها إسقاط خدمة موزعة:
- Dependencies: خدمة حرجة تعتمد على Storage أوAuthentication أوDatabase مشتركة.
- Configuration: بيانات أو Flags صحيحة من حيث آلية التوزيع لكنها غير صالحة لحالة Production.
- Software: Configuration جديدة تصل إلى مسار برمجي يحتوي Bug لم يظهر سابقًا.
- Routing: الخدمة موجودة، لكن BGP لم يعد يوجه Traffic إليها بالطريقة الصحيحة.
وهذا سبب عدم دقة عبارة «Cloudflare تعطلت» من الناحية التقنية. ما يهم أثناء أي Incident هو تحديد أي Failure Domain تعطلت: هل المشكلة في Data Plane، أم Control Plane، أم DNS، أم Routing، أم Dependency تستخدمها منتجات بعينها؟
Control Plane وData Plane: فصل مهم لفهم الأعطال
في الأنظمة الكبيرة يوجد فرق عملي بين المسار الذي يعالج Traffic الفعلية للمستخدمين وبين الأنظمة التي ترسل إليه Configuration وتعليمات التشغيل.
قد تبقى الخوادم القادرة على معالجة الطلبات سليمة، لكن خطأ في Control Plane يرسل لها Configuration خاطئة فيفسد Data Plane. والعكس ممكن أيضًا: قد تبقى Dashboard وأنظمة الإدارة متاحة بينما تفشل معالجة Traffic نفسها.
لذلك لا يكفي القول إن البنية لديها «خوادم احتياطية». إذا كانت الخوادم الأساسية والاحتياطية تستقبل Configuration الخطرة نفسها في اللحظة نفسها، فإنها لا توفر استقلالية حقيقية ضد هذا النوع من الفشل.
ماذا غيرت Cloudflare بعد أعطال نوفمبر وديسمبر؟
في مايو 2026 أعلنت Cloudflare اكتمال برنامج هندسي أطلقت عليه Code Orange: Fail Small. وقالت الشركة إن العمل المنجز كان سيمنع الأعطال العالمية من النوع الذي وقع في 18 نوفمبر و5 ديسمبر 2025.
من أبرز التغييرات التي شرحتها Cloudflare في تحديث Code Orange المنشور في مايو 2026 نقل Configuration الحساسة نحو نمط Health-Mediated Deployment بدل إرسال التغيير فورًا إلى الشبكة كاملة.
يتضمن ذلك Progressive Rollout ومراقبة صحة الأنظمة أثناء النشر وAutomated Rollback عند ظهور مؤشرات فشل. كما طورت الشركة نظامًا داخليًا باسم Snapstone لتطبيق هذه الآلية على أنواع مختلفة من Configuration.
الفكرة أهم من الأداة نفسها: لا تجعل سرعة الانتشار أكبر من سرعة اكتشاف الخطأ وإيقافه.
ولا يعني اكتمال هذه المبادرة أن Cloudflare أو أي شبكة أخرى أصبحت غير قابلة للتعطل. Reliability ليست حالة تنتهي عند تنفيذ مشروع واحد؛ بل عملية مستمرة لاختبار Failure Modes والحد من آثارها.
كيف تصمم خدمتك لتقليل Blast Radius؟
1. ارسم Critical Path قبل شراء المزيد من الخوادم
ابدأ من تجربة المستخدم، وليس من قائمة مزودي الخدمات. ما الذي يجب أن يعمل حتى تكتمل زيارة واحدة بنجاح؟
User
↓
DNS
↓
CDN / Reverse Proxy / WAF
↓
Load Balancer
↓
Application
↓
Database / Authentication / External APIsثم اسأل عند كل مرحلة: ماذا يحدث إذا اختفى هذا المكون بالكامل؟
إذا كان فقد عنصر واحد يمنع كل المسارات البديلة أيضًا، فأنت أمام Failure Domain مشتركة تستحق المعالجة.
2. لا تنشر Configuration عالمية دفعة واحدة
التغييرات التي لا تتطلب Compilation لا تصبح آمنة لمجرد أنها «Configuration وليست Code».
عامل Configuration الحرجة كما تعامل Software Release:
- تحقق من Schema والقيم قبل قبولها.
- ابدأ بنسبة محدودة من Traffic أو عدد قليل من المواقع.
- راقب Error Rate وLatency وSaturation ومؤشرات التطبيق.
- أوقف التوسع تلقائيًا إذا تغيرت الصحة.
- احتفظ بنسخة Known-Good يمكن الرجوع إليها بسرعة.
هذا هو جوهر تقليل Blast Radius: الفشل قد يحدث، لكن لا تسمح له بأن يصل إلى جميع المستخدمين قبل أن تكتشفه.
3. افصل النسخة الاحتياطية عن Failure Domain الأساسي
Backup يستخدم Storage نفسها، وSecondary Service تعتمد Authentication نفسها، وStatus Page تعمل خلف CDN نفسها ليست بدائل مستقلة بالمعنى الكامل.
الاستقلالية يجب تقييمها عبر سلسلة الاعتماد كاملة، لا عند اسم المنتج فقط.
حتى تصميم الشبكة نفسه يؤثر في نقاط الفشل؛ ويوضح شرح أنواع توبولوجيا الشبكات لماذا توفر بعض البنى مسارات بديلة بينما تجعل أخرى عنصرًا مركزيًا نقطة حرجة.
4. راقب خدمتك من خارج البنية التي تراقبها
إذا كانت أداة Monitoring موجودة داخل البيئة نفسها التي فقدت الاتصال، فقد تصبح خدمتك معطلة ولوحة المراقبة خضراء أو غير قابلة للوصول.
يفضل للخدمات المهمة وجود Probes خارجية تفحص بصورة مستقلة:
- DNS Resolution.
- الاتصال بعنوان الخدمة.
- TLS Handshake.
- HTTP Response.
- وظيفة تطبيق حقيقية بدل فحص أن المنفذ مفتوح فقط.
5. اجعل Status Page مستقلة قدر الإمكان
عندما يقع العطل يحتاج العملاء إلى مصدر موثوق لمعرفة ما يحدث. إذا كانت صفحة الحالة تعتمد على المكون نفسه الذي تعطل، تفقد وسيلة الاتصال في أسوأ لحظة.
وعند الاشتباه في Incident عامة لدى Cloudflare يمكن مقارنة القياسات الخاصة بك مع Cloudflare Status، لكن صفحة الحالة ليست بديلًا عن Monitoring مستقل لأن مشكلتك قد تكون خاصة بخدمتك أو Origin الخاص بك.
6. اختبر Rollback وليس Deployment فقط
الفرق بين «لدينا Rollback» و«نستطيع تنفيذ Rollback أثناء Incident» كبير.
اختبر مسبقًا:
- كم يستغرق اكتشاف Configuration سيئة؟
- من يملك صلاحية إيقاف Rollout؟
- هل Known-Good State محفوظة فعلًا؟
- هل الاستعادة تعيد البيانات والعلاقات التابعة أم القيمة الرئيسية فقط؟
- ماذا يحدث إذا كانت أدوات الإدارة نفسها متضررة؟
حادث BYOIP يوضح أهمية النقطة الأخيرة: إيقاف العملية الخاطئة لم يكن مساويًا لاستعادة كل العملاء فورًا لأن بعض Service Bindings وحالات Configuration احتاجت إلى إعادة بناء.
7. صمم Degraded Mode عندما يكون ذلك منطقيًا
ليس كل خطأ يجب أن يؤدي إلى إسقاط الطلب بالكامل.
إذا فشل نظام Analytics أو Bot Scoring أو Recommendation مثلًا، قد يكون استمرار الخدمة بقدرات أقل أفضل من إرجاع HTTP 500 لكل المستخدمين. يسمى هذا أحيانًا Fail-Open، لكنه ليس قاعدة عامة.
في وظائف أمنية معينة قد يكون Fail-Closed هو القرار الصحيح، لأن السماح بالطلب عند فشل Policy Engine قد يخلق خطرًا أكبر من التوقف. القرار يجب أن يعتمد على Threat Model ووظيفة المكون، لا على شعار واحد.
هل Multi-CDN تمنع تكرار هذه المشكلة؟
يمكن لـMulti-CDN تقليل الاعتماد على مزود Delivery واحد، لكنها ليست زر High Availability.
حتى تعمل فعلًا تحتاج إلى التفكير في:
- كيف ستقرر تحويل Traffic؟
- من يدير DNS أو Traffic Steering؟
- هل WAF Rules متطابقة بين المزودين؟
- هل TLS Certificates جاهزة؟
- هل Origin قادر على استيعاب Traffic بعد التحويل؟
- هل Cache Behavior متوافق؟
- هل Logging وRate Limiting وAuthentication ستستمر؟
قد ينتهي بك الأمر أيضًا إلى نقل Single Point of Failure من CDN إلى DNS Provider الذي يتحكم في عملية Failover.
بالنسبة إلى موقع محتوى عادي، قد تتجاوز تكلفة وتعقيد Multi-CDN قيمة الدقائق النادرة التي تريد تجنبها. أما منصة تقيس تكلفة التوقف بالدقيقة أو الثانية، فقد يكون وجود Delivery Path ثانٍ مبررًا.
DNS Failover لا يعني Failover فوريًا
من السهل نظريًا القول: «إذا تعطلت Cloudflare سنغير DNS إلى مزود آخر». لكن الواقع يحتوي TTL وCaching وسلوك Resolvers مختلفة.
كما أن تغيير DNS لن يساعد إذا كانت Authoritative DNS نفسها داخل Failure Domain المتأثرة، أو إذا كان المسار البديل غير قادر على معالجة Traffic، أو كانت Security Policies المطلوبة غير موجودة عليه.
لذلك يجب اختبار DNS Failover مسبقًا من شبكات متعددة بدل افتراض أنه سيعمل لحظة وقوع الأزمة.
هل فتح Origin مباشرة حل جيد أثناء العطل؟
قد يبدو تجاوز Reverse Proxy وتوجيه المستخدمين مباشرة إلى Origin أسرع طريقة لاستعادة الموقع، لكنه يستطيع في الوقت نفسه إزالة طبقات WAF وDDoS Protection وRate Limiting وإظهار عنوان Origin الذي كنت تحاول حمايته.
إذا احتاج مشروعك Emergency Bypass، فصممه واختبره مسبقًا مع ضوابط أمنية خاصة بالمسار البديل. لا تجعل اكتشاف طريقة فتح الخادم مباشرة للإنترنت جزءًا من عملية Incident Response.
كيف تعرف أن المشكلة من Cloudflare فعلًا؟
وجود صفحة خطأ تحمل شعار Cloudflare لا يثبت أن Cloudflare نفسها تعاني Incident عامة. قد تعمل Edge بصورة طبيعية لكنها لا تستطيع الوصول إلى Origin الخاص بك.
ابدأ بالمقارنة بين عدة إشارات:
- تحقق من Cloudflare Status.
- نفذ اختبارًا خارجيًا من أكثر من شبكة أو منطقة.
- تحقق من DNS Resolution بصورة مستقلة.
- راقب Origin مباشرة من مسار إداري آمن.
- راجع Logs الخاصة بالتطبيق وLoad Balancer وFirewall.
- حدد هل المشكلة تؤثر في جميع الزوار أم ISP أو منطقة أو خدمة محددة.
إذا كان Origin متوقفًا أو Firewall يمنع عناوين Cloudflare أو توجد مشكلة TLS بين Proxy وOrigin، فقد ترى أخطاء عبر Cloudflare بينما أصل المشكلة موجود في بنيتك أنت.
ما الدرس الهندسي المشترك بين حوادث 2025 و2026؟
لا يوجد نظام واقعي يمكن ضمان عدم فشله. التصميم الجيد يحاول بدل ذلك التحكم في طريقة الفشل وحجمه وسرعة التعافي منه.
حوادث Cloudflare توضح عمليًا أن الاعتمادية الأقوى تأتي من مجموعة قرارات مترابطة:
- تقليل Dependencies المشتركة غير الضرورية.
- معرفة Failure Domains بدل عد الخوادم فقط.
- استخدام Progressive Rollout للتغييرات الخطرة.
- ربط Deployment بمؤشرات صحة حقيقية.
- إيقاف التغيير وRollback تلقائيًا عند ظهور فشل.
- تقليل الصلاحية التي يملكها أي Automation أو Configuration واحدة للتأثير في الشبكة كاملة.
- مراقبة الخدمة من خارج مزودها الأساسي.
- اختبار Failover وRecovery قبل الحاجة إليهما.
- فصل Emergency Controls عن Failure Domains التي يفترض بها إنقاذها.
لذلك فإن الاستنتاج المفيد من أعطال Cloudflare ليس «تجنب Cloudflare»، بل لا تجعل أي مزود أو خدمة أو Configuration Pipeline نقطة تستطيع وحدها إسقاط كل المسارات المهمة دون أن تملك خطة واضحة لاكتشاف ذلك واحتوائه والتعافي منه.
قد يكون Cloudflare أو أي CDN آخر جزءًا ممتازًا من تصميم متين، لكن مستوى Availability النهائي لا يحدده اسم المزود وحده. تحدده Architecture كاملة: ما الذي تعتمد عليه، كيف تفشل تلك الاعتماديات، وما حجم الجزء الذي يمكن أن يتأثر عندما يحدث الخطأ التالي.