كيف يمكن لتحديث قاعدة بيانات واحد أن يعطل 20% من الإنترنت العالمي

11 نوفمبر 18 تاريخ التنبيه عن العطل: عندما يحدث انقطاع في Cloudflare، من يدفع ثمن البنية التحتية؟

في الساعة 6:20 صباحًا بتوقيت شرق الولايات المتحدة، توقف حوالي 20% من حركة الإنترنت العالمية فجأة. أدى تعديل روتيني في صلاحيات قاعدة البيانات إلى سلسلة من ردود الفعل المتسلسلة، مما تسبب في انقطاع واسع للخدمات الأساسية التي تدعم تشغيل الإنترنت الحديث.

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

كارثة تبدأ من استعلام واحد لقاعدة البيانات

جدول الأحداث واضح وقاسٍ:

UTC 11:05 — قامت Cloudflare بتحديث صلاحيات مجموعة قواعد بيانات ClickHouse بهدف تعزيز الأمان والموثوقية.

UTC 11:28 — تم تطبيق التغييرات على بيئة المستخدم، وظهرت أول سجلات أخطاء.

UTC 11:48 — اعترفت الصفحة الرسمية للحالة بوجود عطل.

UTC 17:06 — استُعيدت الخدمة بالكامل، واستمر الانقطاع لأكثر من 5 ساعات.

الحقيقة التقنية

المشكلة الأساسية كانت في خطأ بسيط ظاهريًا: استعلام قاعدة البيانات الذي يُستخدم لإنشاء ملفات إعدادات حماية روبوت Cloudflare يفتقر إلى شرط تصفية باسم “اسم قاعدة البيانات”.

مما أدى إلى عودة النظام لمدخلات مكررة — واحدة من قاعدة البيانات الافتراضية، والأخرى من قاعدة البيانات المخزنة في الطبقة الأساسية r0. وبالتالي، تضاعف حجم ملف الإعدادات، من حوالي 60 ميزة إلى أكثر من 200.

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

تجاوز حجم الملف الحد المسموح، مما أدى إلى رمي خطأ في كود Rust: “thread fl2_worker_thread panicked: called Result::unwrap() on an Err value”

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

والأكثر سخرية هو أن هذا الملف يُعاد إنشاؤه كل 5 دقائق. طالما أن الاستعلام يُنفذ على عقدة المجموعة بعد التحديث، فسيتم إنتاج بيانات خاطئة. والنتيجة أن شبكة Cloudflare تتنقل بين “طبيعي” و"عطل" بشكل متكرر — أحيانًا يمكنها تحميل الملفات الصحيحة، وأحيانًا ترفع ملفات خاطئة.

هذا “التكرار في الانقطاع” جعل المهندسين يظنون أنهم يتعرضون لهجوم DDoS واسع النطاق. لأن الأخطاء الداخلية عادة لا تؤدي إلى دورة استعادة-انهيار متكررة كهذه.

وفي النهاية، بعد اكتمال تحديث جميع عقد ClickHouse، كانت جميع الملفات الناتجة خاطئة. وبدون إشارة نظام دقيقة، دخل نظام الحماية في وضع “حذر”، واعتبر معظم الخوادم “غير صحية”. وتدفقت حركة الإنترنت إلى عقد حافة Cloudflare، لكنها لم تُوجَّه بشكل صحيح.

لحظة الصمت في الشبكة العالمية

تعطل كامل منصة Web2

• X منصة تلقت 9,706 تقارير عن أعطال
• ChatGPT توقف عن الرد أثناء المحادثة
• Spotify انقطعت البث
• Uber وتطبيقات التوصيل تعطلت
• تعرض لاعبو الألعاب لفصل قسري
• وحتى أجهزة الطلب الذاتي في ماكدونالدز أظهرت واجهات خطأ

لا أحد في مجال التشفير في مأمن

واجهت واجهات الويب الخاصة بأكبر البورصات انهيارًا، مع ظهور صفحات تسجيل دخول وعملات غير قابلة للتحميل.

متصفحات blockchain (مثل Etherscan، Arbiscan) توقفت عن العمل مباشرة.

منصات تحليل البيانات (DeFiLlama) ظهرت بها أخطاء خادم متقطعة.

مُزوِّدو المحافظ الصلبة أصدروا إعلانات عن انخفاض في توفر الخدمة.

الاستثناء الوحيد: بروتوكولات blockchain نفسها

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

وهذا يكشف عن تناقض حاد: إذا كانت البلوكتشين لا تزال تنتج كتلًا، ولكن لا يمكن الوصول إليها، فهل العملات المشفرة لا تزال “على الإنترنت” حقًا؟

دور Cloudflare في حركة الإنترنت العالمية

Cloudflare لا تستضيف مواقع، ولا تقدم خدمات خوادم سحابية. دورها هو “الوسيط” — بين المستخدم والشبكة.

البيانات الأساسية:

• تقدم خدماتها لـ 24 مليون موقع
• تتوزع على 120 دولة و330 مدينة عبر نقاط الحافة
• تتعامل مع حوالي 20% من حركة الإنترنت العالمية
• تسيطر على 82% من سوق الحماية من هجمات DDoS
• عرض النطاق الإجمالي لنقاط الحافة يصل إلى 449 تيرابت/ثانية (Tbps)

عندما يفشل هذا “الوسيط”، تتعطل جميع الخدمات التي تعتمد عليه في الخلفية بشكل متزامن.

قال الرئيس التنفيذي لـ Cloudflare، ماثيو برنس، في بيان رسمي: “هذه أسوأ مشكلة تعطّل منذ عام 2019… خلال أكثر من 6 سنوات، لم نواجه عطلًا يمنع معظم حركة الإنترنت الأساسية من المرور عبر شبكتنا.”

4 حالات كبيرة خلال 18 شهرًا: لماذا لم يتغير القطاع بعد؟

يوليو 2024 — ثغرة أمنية في تحديثات CrowdStrike أدت إلى تعطيل أنظمة تكنولوجيا المعلومات العالمية (إلغاء الرحلات، تأخير المستشفيات، تجميد الخدمات المالية)

20 أكتوبر 2025 — عطل AWS استمر 15 ساعة، وانقطاع خدمة DynamoDB في المنطقة الشرقية للولايات المتحدة، مما أدى إلى توقف عدة شبكات بلوكتشين

29 أكتوبر 2025 — مشكلة في مزامنة إعدادات Azure، تعطلت خدمات Microsoft 365 وXbox Live

18 نوفمبر 2025 — عطل في Cloudflare، أثر على حوالي 20% من حركة الإنترنت العالمية

مخاطر نموذج المقاول الواحد

تسيطر AWS على حوالي 30% من سوق البنية التحتية السحابية، وMicrosoft Azure على 20%، وGoogle Cloud على 13%. وتسيطر هذه الشركات الثلاث على أكثر من 60% من بنية الإنترنت الأساسية.

كان من المفترض أن يكون قطاع التشفير “حلاً لامركزيًا”، لكنه الآن يعتمد بشكل قسري على أكبر مزودي البنية التحتية المركزية عالميًا.

عند حدوث عطل، فإن الاستراتيجية الوحيدة للقطاع هي: الانتظار. انتظار إصلاح Cloudflare، واستعادة AWS، وتحديث Azure.

وهم “اللامركزية”: بروتوكولات لا تعني الوصول اللامركزي

كان القطاع التشفيري يصور لنفسه رؤية:

التمويل اللامركزي، العملات المضادة للرقابة، أنظمة لا تتطلب الثقة، عدم وجود نقطة فشل واحدة، القانون هو الكود

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

على المستوى التقني: لم يُبلغ عن أي بروتوكول بلوكتشين عن عطل.

وعلى أرض الواقع: تعطلت واجهات المعاملات، توقفت المتصفحات، تعطلت منصات البيانات، وظهرت صفحات خطأ 500 بشكل متكرر.

المستخدمون غير قادرين على الوصول إلى “اللامركزية” التي يُفترض أن يمتلكوها على بلوكتشين. البروتوكولات تعمل بشكل طبيعي — بشرط أن تتمكن من “الوصول” إليها.

لماذا يختار القطاع “الراحة” على “المبادئ”؟

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

أما استخدام Cloudflare فيتطلب فقط: الضغط على زر، إدخال معلومات البطاقة الائتمانية، وإتمام النشر خلال دقائق.

الشركات الناشئة تسعى لـ “السوق بسرعة”، والمؤسسات الاستثمارية تطالب بـ “كفاءة رأس المال” — والجميع يختار “الراحة” على “مقاومة الأعطال”.

حتى تتوقف “الراحة” عن أن تكون مريحة.

لماذا “البدائل اللامركزية” لا تحظى بشعبية؟

هناك حلول مثل التخزين اللامركزي (مثل Arweave)، نقل الملفات الموزع (IPFS)، الحوسبة اللامركزية (Akash)، والاستضافة اللامركزية (Filecoin).

لكن تواجهها مشكلات منها:

• أداؤها أضعف من الحلول المركزية، ويشعر المستخدمون بالتأخير مباشرة
• انتشارها منخفض جدًا، وعملياتها معقدة
• تكلفتها غالبًا أعلى من استئجار البنية التحتية من أكبر ثلاثة مزودين سحابة

بناء بنية تحتية لامركزية حقيقية أمر في غاية الصعوبة، ويتجاوز التصور.

معظم المشاريع تكتفي بقول “اللامركزية” على لسانها، ولكن نادرًا ما تنفذها فعليًا. الاعتماد على الحلول المركزية دائمًا هو الخيار الأسهل والأرخص — حتى يحدث العطل.

تحديات التنظيم الجديدة

ثلاثة أعطال كبيرة خلال 30 يومًا أثارت اهتمام الجهات التنظيمية بشكل كبير:

• هل تعتبر هذه الشركات “مؤسسات ذات أهمية نظامية”؟
• هل ينبغي تنظيم خدمات الشبكة الأساسية كـ “مرافق عامة”؟
• ما المخاطر التي قد تنجم عن ارتباط “الضخمة التي لا يمكن أن تنهار” بالبنية التحتية التكنولوجية؟
• هل يشكل سيطرة Cloudflare على 20% من حركة الإنترنت احتكارًا؟

تعمل وزارة الخزانة الأمريكية على دمج شهادات الهوية في العقود الذكية، وتطلب أن تمر كل تفاعل DeFi عبر عملية KYC. وعند حدوث عطل في البنية التحتية، لن يفقد المستخدمون فقط حقوق المعاملات — بل سيفقدون القدرة على “إثبات هويتهم” في النظام المالي.

الخلل الذي كان يستغرق 3 ساعات قد يتحول إلى “عجز عن اجتياز التحقق البشري والآلي” لمدة 3 ساعات — فقط لأن خدمة التحقق تعمل على بنية تحتية معطلة.

من “الراحة” إلى “الضرورة”: متى يكون نقطة التحول؟

18 نوفمبر، لم تفشل صناعة التشفير — بل عملت البلوكتشين بشكل مثالي.

الفشل الحقيقي هو أن القطاع يضلل نفسه جماعيًا:

• يظن أنه يمكن بناء تطبيقات “لا يمكن إيقافها” على بنية تحتية “مُعطلة”
• يعتقد أن السيطرة على “قنوات الوصول” من قبل ثلاث شركات تعني أن “مقاومة الرقابة” لها معنى حقيقي
• يظن أن مجرد وجود ملف تكوين واحد في Cloudflare يمكن أن يحدد ما إذا كان يمكن للملايين التداول — فـ"اللامركزية" لا تزال ذات معنى

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

الخلل القادم في الطريق — قد يكون من AWS، أو Azure، أو Google Cloud، أو حتى عطل ثانوي في Cloudflare. قد يحدث الشهر القادم، أو الأسبوع القادم.

الاعتماد على الحلول المركزية لا يزال الخيار الأرخص والأسرع والأكثر راحة — حتى تتوقف عن أن تكون كذلك.

عندما يُحدث التغيير التالي في إعدادات Cloudflare الاعتيادية ثغرة مخفية في خدمة حيوية، سنشهد مرة أخرى سيناريو مألوفًا: أخطاء 500، توقف كامل للمعاملات، بلوكتشين يعمل بشكل طبيعي لكن لا يمكن الوصول إليه، ووعود الشركات بـ “التحسين في المرات القادمة” التي لم تتحقق أبدًا.

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