CLOUDFLARE

إيقاف الاختيار الآلي لا يلغي القيود على الخوارزميات. بقاء الواجهة القديمة يستدعي مراجعة ما تتحكم فيه أدوات التشغيل فعلاً.

قالت كلاودفلير إن بعض العملاء ربما واجهوا زيادة في أخطاء 5xx وانتهاء مهلة الاتصال بين مصادر موجودة في أميركا الشمالية ومركز بياناتها في سنغافورة، من 01:06 إلى 01:54 بالتوقيت العالمي في 23 أغسطس. أُغلقت الواقعة، لكن الوصف العلني المحدد ظهر بعد انتهاء نافذة التأثير.

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

أغلقت Cloudflare في 4 أغسطس حادثتين مختلفتين في Workers. في الأولى ظهر كائن `Temporal` عام من دون قصد، وكانت ساعته تعيد عام 1970. وفي الثانية رفضت بوابة النشر إعداداً يجمع `nodejs_compat` مع تاريخ توافق يبدأ من 4 أغسطس. لم تقل الشركة إن السبب واحد. لكن الحادثتين توضحان أن السيطرة في الحوسبة عديمة الخوادم موزعة على حدّين: ما تسمح المنصة بنشره، وما تعطيه للكود من معنى عند التشغيل.

أغلقت Cloudflare في 3 أغسطس حادثة استمرت نحو ساعة و51 دقيقة في Workers Builds. لكن لحظة الاستعادة الأهم سبقت الإغلاق: عند 15:38 بالتوقيت العالمي قالت الشركة إن عمليات البناء لم تعد تفشل، مع بقاء احتمال التأخير. هذا الفاصل يضع الإدارة أمام سؤالين مختلفين: هل النسخة المنشورة تعمل، وهل تستطيع المؤسسة بناء التغيير التالي ونشره بأمان؟ لا تكشف الصفحة سبب العطل أو عدد العملاء أو أثره على وقت التشغيل، ولذلك يجب إبقاء الاستنتاج ضمن مسار البناء المسمّى وعدم تحويله إلى ادعاء بانقطاع شامل.

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

لم تكن واقعة 27 يونيو 2024 مجرد انقطاع عابر لخدمة DNS، بل اختباراً عملياً لسلسلة الضوابط التي تقرر ما إذا كان مسار BGP غير سليم سيُرفض عند الحافة، أم يُقبل في شبكة عبور، أم ينتشر عبر مزيد من العلاقات التشغيلية. فقد أبلغت Cloudflare عن حدثين منفصلين: إعلان منشأ للمسار الأكثر تحديداً 1.1.1.1/32، وتسريب مختلف للمسار 1.1.1.0/24. يكشف الفصل بينهما حدود RPKI، وسياسات التصدير، وضوابط RTBH، والمراقبة، والاستجابة التشغيلية، ويوضح أن المساءلة تتبع السيطرة الفعلية على المسار لا مجرد وجود سجل صحيح للعنوان.

تكشف واقعة 22 يناير 2026 أن سلامة صياغة سياسة BGP لا تعني سلامة أثرها، وأن المساءلة الحقيقية تبدأ بإثبات ما سمحت به السياسة المولّدة وما أرسله الموجّه فعلياً، لا بما كان التعديل يقصد تحقيقه.

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

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

سجلت Cloudflare في 31 يوليو عند 11:51:07 بالتوقيت العالمي حادثا طفيفا بدأ في Analytics ولوحة التحكم وواجهات مرتبطة، ثم امتد إلى بناء Pages وWorkers. دخل الإصلاح مرحلة المراقبة عند 12:43:57 وأغلق الحادث عند 13:01:59. وأكدت الشركة أن تقديم الملفات المخزنة مؤقتا عبر شبكة CDN وميزات الحماية الأخرى عند الحافة لم يتأثر. كان الخلل في إدارة الخدمات ونشر التغييرات، لا انقطاعا شاملا للحافة.