الخلاصة

  • أرسلت مهمة تنظيف قيمة فارغة للمعامل pending_delete. ففسّرت Addressing API الطلب على أنه يشمل جميع بادئات BYOIP، ثم حذفت المهمة البادئات وروابط الخدمة التابعة لها.
  • سُحبت نحو 1,100 بادئة. أمكن استعادة نحو 800 بإعادة الإعلان عنها، بينما فقدت قرابة 300 إعدادات الخدمة على الحافة أيضاً، ما استلزم استعادة عامة لاحقة. عودة المسار لم تكن سوى طبقة واحدة من التعافي.

ساعة ثانية للتعافي

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

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

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

قالت Cloudflare إن الحادث لم ينتج من هجوم أو نشاط خبيث. اكتمل نشر إصدار Addressing API عند 17:46 بالتوقيت العالمي، وبدأت المهمة التنفيذ بعد عشر دقائق. حدد المهندسون العملية وأوقفوها عند 18:46. وخلال تلك الفترة سُحبت نحو 1,100 بادئة. وذكرت الشركة أن ذلك يمثل 25% من 4,306 بادئات BYOIP معلنة عالمياً. كما ذكر التقرير رقماً منفصلاً قدره 6,500 بادئة لدى نظير شبكي؛ هذا مقام إحصائي آخر، ولا ينبغي خلطه بإجمالي بادئات BYOIP عالمياً.

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

الإعلان ليس تقديم الخدمة

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

لذلك لم يكن إجراء لوحة التحكم مناسباً لكل الحالات. عند 19:19، طلبت Cloudflare من العملاء إعادة إعلان بادئاتهم. وبحلول نحو 20:20 استعيدت قرابة 800 بادئة. أما نحو 300 فلم يمكن إصلاحها بمجرد تغيير حالة الإعلان، لأن إعدادات الخدمة المقابلة حُذفت من أنظمة الحافة. لم يكن بإمكان العميل إنشاء رابط لم يعد موجوداً في الإعدادات التي يستطيع حسابه الوصول إليها. وكان على المهندسين استعادة الحالة ثم توزيع إعداد عام على الشبكة، واكتمل ذلك عند 23:03. وأعلنت الشركة أن مدة الحادث الإجمالية كانت ست ساعات وسبع دقائق.

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

كما عرض موقع one.one.one.one أخطاء HTTP 403. وأوضحت Cloudflare أن حل DNS عبر المحلل العام 1.1.1.1، بما في ذلك DNS عبر HTTPS، لم يتأثر. كان خطأ الموقع دليلاً على أثر في واجهة ويب تستخدم BYOIP، لا على توقف المحلل عن الإجابة. والخلط بينهما قد يوجه فرق الاستجابة إلى مكوّن غير متعطل.

الإعداد جزء من البنية الشبكية

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

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

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

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

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

ما الذي ينبغي أن يثبته وعد الاستمرارية؟

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

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

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

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

المصادر