الخلاصة

  • بدأ الحدث عند الساعة 12:47 بعد منتصف الليل بتوقيت المحيط الهادئ في 21 أبريل/نيسان 2011، حين حوّل تغيير في سعة الشبكة حركة EBS خطأً إلى شبكة نسخ احتياطية أقل سعة داخل منطقة توافر متأثرة في إقليم US East.
  • بعد عودة الاتصال، أدت عمليات البحث المتزامنة عن نسخ جديدة إلى استنزاف السعة الحرة، ثم ضاعفت آليات التراجع غير الكافية وحالة تسابق نادرة الضغط إلى عاصفة إعادة نسخ.
  • قالت AWS إن نحو 13% من وحدات التخزين في منطقة التوافر المتأثرة كانت عالقة عند تثبيت المجموعة، وإن 0.07% من وحدات المنطقة نفسها لم يمكن إعادتها إلى حالة متسقة؛ الرقمان لا يصفان الإقليم كله ولا عدد العملاء أو حجم البيانات.
  • المسؤولية العملية تتوزع بين المزود، الذي يملك شبكات النسخ والتحكم والعزل وطاقة التعافي، والعميل، الذي يملك تصميم التطبيق واختبارات الاستعادة. ولا تقدم الأدلة أساساً لحكم قانوني أو لإسناد اللوم إلى فرد.

نطاق الحادث وتسلسله

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

هذا التحديد مهم. فالخلل الجوهري في التخزين لم يكن انقطاعاً عالمياً لـAWS، ولم يشمل كل وحدات US East. حدثت آثار أوسع داخل الإقليم لأن طبقة التحكم الإقليمية تعرضت لاحقاً للضغط، لكن ذلك لا يحول المشكلة الأصلية إلى فشل موحد في كل مناطق التوافر. والفصل بين مكان الضرر المباشر ومكان امتداد أعراض التحكم شرط لفهم المسؤولية بدقة.

لماذا لم تكن عودة الاتصال نهاية الأزمة؟

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

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

انتقال الضغط إلى طبقة التحكم

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

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

ماذا تعني النسبتان 13% و0.07%؟

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

أما نسبة 0.07% فكانت، وفق الإفصاح النهائي لـAWS، حصة وحدات التخزين في منطقة التوافر المتأثرة التي تعذر استعادتها إلى حالة متسقة. مقامها هو مجموعة وحدات المنطقة المتأثرة نفسها، لكنها تصف نتيجة نهائية مختلفة عن حالة الـ13%. ولا تكشف المصادر الخمسة عدد البايتات أو السجلات المفقودة، ولا عدد العملاء المتأثرين، ولا قيمة الضرر الاقتصادي. لذلك فإن عبارة واسعة مثل «فُقد 0.07% من بيانات AWS» ستكون غير صحيحة.

اعتماد RDS والتعافي غير التلقائي

اعتمدت Amazon RDS على EBS لتخزين قواعد البيانات والسجلات. وذكرت AWS أن ظرفاً لم يسبق مواجهته منع التحويل التلقائي لبعض مثيلات Multi-AZ، فتطلب الأمر تدخلاً يدوياً. لا يعني ذلك أن كل مثيلات Multi-AZ فشلت، ولا أن نتائجها تطابقت مع مثيلات Single-AZ أو مع وحدات EBS عموماً. لكنه يكشف حدّاً مهماً: التكرار على مستوى التطبيق قد يعتمد على خدمات تحكم وتخزين مشتركة، وقد يحتاج مسار التحويل نفسه إلى اختبار تحت ضغط الحادث.

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

دليل الأثر downstream وحدوده

قدمت Heroku دليلاً مباشراً من مشغل منصة متأثرة، إذ وصفت انقطاعاً واسعاً للتطبيقات واستجابتها التشغيلية. كما سمّت تغطية TechCrunch خدمات عامة، من بينها Reddit وFoursquare وQuora، في سياق آثار الحادث. تدعم هذه الشهادات حقيقة أن الاعتماد على مزود مشترك يمكن أن ينقل الضرر إلى خدمات عديدة.

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

الإجراءات التي أعلنتها AWS

أعلنت AWS بعد الحادث زيادة هوامش سعة التعافي، وجعل التراجع التدريجي أكثر شدة، وإصلاح حالة التسابق، وتحسين المهل وخفض الحمل. وشملت الخطط أيضاً عزل مناطق التوافر بصورة أقوى، وأتمتة ضوابط التعافي، وتحسين أدوات Multi-AZ، وتوفير اتصالات أكثر تكراراً ورؤية أفضل على مستوى الموارد.

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

من كان يملك القدرة على تقليل الضرر؟

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

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

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

المصادر

  1. Amazon Web Services، رسالة ما بعد الحادث: https://aws.amazon.com/tw/message/65648/
  2. Heroku، تقرير ما بعد انقطاع 21 أبريل: https://www.heroku.com/blog/post_mortem_on_april_21_outage/
  3. TechCrunch، تغطية متزامنة لأثر تعطل EC2: https://techcrunch.com/2011/04/21/amazon-ec2-goes-down-taking-with-it-reddit-foursquare-and-quora-2/
  4. The Register، تدقيق في التعافي وسلامة البيانات: https://www.theregister.com/off-prem/2011/04/26/amazon-some-data-wont-be-recovered-after-cloud-outage/388333
  5. InfoQ، تحليل تقني لشرح انقطاع Amazon EC2: https://www.infoq.com/news/2011/04/Amazon-EC2-Outage-Explained/