الخلاصة

  • قطع أمر صيانة وصلات الشبكة الرئيسية، فتوقفت خوادم DNS عن إعلان المسارات المؤدية إليها، مع أنها ظلت تعمل.
  • استعادة وصول المهندسين، وعودة الشبكة، وتعافي التطبيقات مراحل مختلفة. لا تقيس المشاهدات الخارجية مدة كل مرحلة أو تجربة كل مستخدم.

قد يعمل الخادم كما ينبغي، ولا تصل إليه أي من الطلبات التي تنتظر إجابته. هذه المفارقة تفسر جانباً مهماً من عطل Facebook في 4 أكتوبر 2021. خوادم أسماء النطاقات، أو DNS، لم تتوقف عن العمل وفق رواية الشركة. الذي فُقد هو الطريق الذي يسمح للإنترنت بالوصول إليها.

لمن يحاول فتح Facebook أو Instagram أو WhatsApp، لا تبدو هذه التفاصيل مهمة ما دام التطبيق لا يعمل. لكنها تصنع فرقاً كبيراً حين يبدأ الإصلاح: إعادة تشغيل جهاز يعمل أصلاً لا تعيد بالضرورة المسار المفقود. والأسوأ أن بعض الطرق التي يحتاجها المهندسون أنفسهم لم تعد متاحة.

أمر لفحص السعة قطع الاتصال

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

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

هذه ليست رواية عن اختفاء كل عناوين الشركة. فقد رصدت Cloudflare زيادة كبيرة في تغييرات التوجيه نحو الساعة 15:40 بالتوقيت العالمي، ثم لاحظت عند 15:58 سحب مسارات نطاقات عناوين DNS. وظلت نطاقات عناوين أخرى تابعة لـFacebook تحتفظ بمساراتها.

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

الوصول إلى الشبكة صار جزءاً من المهمة

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

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

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

متى عادت الخدمة؟ يعتمد الجواب على ما نقيسه

رصدت Cloudflare نشاطاً جديداً في BGP نحو الساعة 21:00، بلغ ذروة عند 21:17. وعند 21:28 بدا أن الاتصال العالمي وحل أسماء النطاقات قد عادا. لكن التطبيقات كان يمكن أن تحتاج إلى وقت إضافي.

الفاصل بين 15:58 و21:28 هو 330 دقيقة. إنه فرق بين مشاهدتين، لا مدة موحدة لتعطل كل خدمة لدى كل مستخدم. وليس مقياساً للوقت الذي أمضاه المهندسون في الطريق. وبالمثل، لا تثبت الدقائق الثماني عشرة بين المشاهدتين الأوليين أنها كانت الفرصة الداخلية الوحيدة لاكتشاف العطل.

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

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

تصحيح في 21 أكتوبر 2026: فُصل فقدان الوصول الإداري عن تعطل الأدوات المعتمدة على DNS، ووُضحت حدود دلالة التوقيتات الخارجية. حُذفت مساواة مدة الرصد بزمن تنقل المهندسين أو بتعطل جميع الخدمات، وكذلك الاستنتاجات عن البنية الحالية التي لا تثبتها تقارير 2021.