ما وراء الكواليس: انقطاع خدمة AWS في 20 أكتوبر 2025

في صباح يوم 20 أكتوبر 2025، واجهت أجزاء من الإنترنت وقتاً عصيباً. أبلغت خدمات أمازون ويب (AWS) عن مشاكل في مجموعة مراكز البيانات الخاصة بها في شمال فيرجينيا (US-EAST-1). لعدة ساعات، كانت العديد من التطبيقات والمواقع الشهيرة بطيئة أو غير متاحة — مثل Vercel، وFigma، وVenmo، وSnapchat، على سبيل المثال لا الحصر. سجلت وكالات الأنباء وخدمات المراقبة ملايين التقارير من المستخدمين، وحتى بعض خدمات أمازون نفسها عانت من تقطع في الخدمة.

ومع ذلك، شهد عملاء Namefi يوماً هادئاً. ظلت أنظمتنا تعمل كالمعتاد — ليس عن طريق الصدفة، ولكن لأننا نستثمر بشكل كبير في الهندسة والدقة التشغيلية التي تجعل عملية حل أسماء النطاقات (DNS resolution) مرنة وقادرة على الصمود أمام العثرات الإقليمية.

ومع ذلك، يقوم فريق هندسة Namefi بمراجعة الانقطاعات العالمية مثل هذه والتعلم منها، كما يفعل مع جميع الحوادث الكبرى. إليكم ما تم تعلمه حتى الآن:

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

ما الخطأ الذي حدث بالفعل في AWS — بعيداً عن المصطلحات المعقدة

يحتاج كل تطبيق وموقع ويب إلى طريقة "للبحث" عن مكان الاتصال. يُسمى دليل عناوين الإنترنت هذا DNS — اختصاراً لنظام أسماء النطاقات (Domain Name System). في 20 أكتوبر، تسببت مشكلة في التسمية داخل AWS في عدم قدرة بعض أجهزة الكمبيوتر على العثور على خدمة قواعد بيانات رئيسية لـ AWS بالاسم. إذا لم يتمكن "دليل العناوين" من توفير الإدخال الصحيح في اللحظة المناسبة، فلن تتمكن حتى الأنظمة السليمة من التحدث مع بعضها البعض.

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

من تأثر (وماذا يقول ذلك عن إنترنت اليوم)

كان نطاق التأثير واسعاً ومألوفاً للمستخدمين العاديين. أبلغت تطبيقات المستهلكين مثل Snapchat وReddit، ووسائل الاتصال مثل Zoom وSignal، ومنصات الألعاب بما في ذلك Fortnite وRoblox عن مشكلات. شهدت الخدمات المالية انقطاعات في Coinbase وRobinhood، بينما في المملكة المتحدة واجهت عدد من الخدمات العامة — بما في ذلك HMRC (بوابة الضرائب) والبنوك التابعة لمجموعة Lloyds/Halifax/Bank of Scotland — انقطاعات. تأثرت أيضاً تطبيقات عملاء الاتصالات من Vodafone وBT، على الرغم من أن شبكاتهم الأساسية ظلت متاحة.

واجهت ممتلكات أمازون الخاصة مشاكل أيضاً: Amazon.com، وPrime Video، وAlexa، وRing، جميعها شهدت اضطرابات، مما يوضح مدى تداخل AWS مع خدمات المستهلكين لشركتها الأم. سجلت أجهزة التتبع المباشر مثل Downdetector ملايين التقارير عن مشاكل المستخدمين في جميع أنحاء العالم، مما يؤكد عدد تطبيقات الحياة اليومية التي تعتمد على AWS. أشارت بعض الملخصات أيضاً إلى تأثيرات مضاعفة طالت تطبيقات الترفيه (مثل Apple Music) وتطبيقات الهاتف المحمول للعلامات التجارية الاستهلاكية الكبرى خلال تلك الفترة.

نظرة تقنية من الداخل

تشير الجداول الزمنية لـ AWS إلى فشل في استجابة DNS لواجهة برمجة تطبيقات DynamoDB في منطقة US-EAST-1. يُعزى السبب الأساسي إلى نظام فرعي داخلي في EC2 يراقب صحة موازنات تحميل الشبكة (Network Load Balancers - NLBs)؛ عندما تعطل هذا النظام الفرعي، ظهر ذلك خارجياً كعمليات بحث سيئة عن الأسماء لنقطة نهاية DynamoDB. قامت AWS بتخفيف مشكلة DNS في الساعة 2:24 صباحاً بتوقيت المحيط الهادئ وأعلنت أن جميع الخدمات طبيعية بحلول الساعة 3:01 مساءً بتوقيت المحيط الهادئ، بينما استمرت الأعمال المتراكمة في الانحسار خلال فترة ما بعد الظهر. (Amazon، Reuters)

لاحظت قياسات الشبكة المستقلة عدم وجود شذوذ أوسع في توجيه الإنترنت (على سبيل المثال، لا يوجد حادث BGP)، وهو ما يتماشى مع الاستنتاج بأن الخطأ يكمن داخل "مستوى التحكم" (Control Plane) الخاص بـ AWS وليس على الإنترنت العام. (ThousandEyes)

بعض سلوكيات DNS التي تفسر "الأثر الممتد" بعد الإصلاح:

التخزين المؤقت (Caching)، بما في ذلك التخزين المؤقت السلبي (Negative Caching): تقوم المحللات (Resolvers) بتخزين الإجابات لفترة تسمى TTL (وقت العيش). كما أنها تخزن حالات الفشل بشكل مؤقت، وفقاً للمعايير القياسية. إذا قام المحلل بتخزين استجابة "لم يتم العثور عليه" مؤقتاً أثناء الحادث، فقد يستمر في تقديم هذا الفشل حتى انتهاء المؤقت، حتى بعد أن تكون AWS قد صححت المصدر. (المعايير: RFC 2308، تم تحديثها في RFC 9520)
مستوى التحكم (Control Plane) مقابل مستوى البيانات (Data Plane): تفصل المنصات السحابية بين التنسيق (مستوى التحكم) والخدمة المستقرة (مستوى البيانات). يمكن لعثرة في مستوى التحكم تكسر عمليات البحث عن الأسماء أن تمنع مسارات الخدمة السليمة، لأن العملاء لا يزالون بحاجة إلى اكتشاف نقاط النهاية (endpoints) بالاسم. تميز إرشادات المرونة الخاصة بـ AWS بين هذه المستويات وتشير إلى التعقيد العالي ومعدل التغيير في أنظمة التحكم. (ورقة عمل AWS)
المركزية الإقليمية: تستضيف US-EAST-1 مكونات تعتمد عليها العديد من الميزات العالمية؛ يفسر هذا التركيز سبب شعور المستخدمين بأن مشكلة التسمية الإقليمية لها تأثير عالمي. (السياق في التقارير العامة: Reuters)

ما الذي يمكن لشركات الإنترنت الأصغر استخلاصه من ذلك

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

لماذا يعتبر DNS بالغ الأهمية وكيف يتناسب Namefi مع ذلك

الدرس ليس أن السحابة هشة؛ بل هو أن الاعتماد على مسار تسمية وتحكم واحد يركز المخاطر. تقلل فرق الإنترنت الحديثة من هذه المخاطر من خلال التعامل مع DNS كطبقة توجيه مستقلة ومرنة لحركة المرور الخاصة بهم ومن خلال إعداد نقاط نهاية بديلة قبل حدوث المشاكل. مع وجود نظام DNS قوي في مكانه، تحتفظ التطبيقات بالقدرة على إعادة التوجيه، والعمل بكفاءة أقل (degrade gracefully)، والتعافي بشكل أسرع عندما يواجه المزود يوماً سيئاً.

هذه الفلسفة هي السبب وراء وجود Namefi. توفر منصة Namefi مرونة النطاق وDNS كمنتج، حيث تجمع بين أفضل الممارسات، وTTLs المصممة بعناية، وأسطح الاتصال. والنتيجة هي طبقة تسمية مصممة لمواصلة اتخاذ قرارات توجيه جيدة عندما تكون السحابة الأساسية في طور الشفاء، أو الخنق (throttling)، أو محاولة اللحاق بالركب. تحصل الفرق التي تعتمد Namefi على هذا الوضع "خارج الصندوق" (out of the box)، جنباً إلى جنب مع الأدوات التشغيلية لمراقبته وتعديله دون ربط تلك الضوابط بنفس المستوى الذي قد يواجه مشاكل.

عندما تحدث حوادث مثل 20 أكتوبر، فإن هذا الفصل هو ما يبقي الخريطة سليمة.

المصادر وقراءات إضافية

Amazon — توقيتات الحادث الرسمية وخطوات التعافي (التخفيف في الساعة 2:24 صباحاً بتوقيت المحيط الهادئ؛ جميع الخدمات طبيعية بحلول الساعة 3:01 مساءً بتوقيت المحيط الهادئ؛ خنق EC2 أثناء التعافي). (Amazon)
Reuters — السبب الجذري في النظام الفرعي لمراقبة صحة NLB الداخلي لـ EC2؛ نطاق التأثير؛ تقارير ملايين المستخدمين؛ ومسح التراكمات. (Reuters)
ThousandEyes — القياس عن بعد (Telemetry) الذي يركز على US-EAST-1، وDNS إلى DynamoDB، وغياب شذوذ التوجيه الأوسع. (ThousandEyes)
The Verge / Tom’s Guide — جداول زمنية عامة، وتأكيد أن الحدث كان متعلقاً بـ DNS/مستوى التحكم وليس هجوماً سيبرانياً، وأمثلة على المنصات المتأثرة. (The Verge)
IETF / Cloudflare Docs — سلوك التخزين المؤقت السلبي لـ DNS (RFC 2308، RFC 9520) وأنماط DNSSEC متعددة التواقيع للنشر الموثوق متعدد المزودين (RFC 8901، وثائق المشغلين). (RFC Editor، RFC Editor)