تحذير من تعطل AWS DynamoDB: ثغرات التصميم أخطر من ظروف السباق (Race Condition)

في أكتوبر 2025، توقف قلب عالم الحوسبة السحابية، منطقة AWS US-EAST-1، عن العمل. توقفت EC2 عن الإنشاء، ورفضت Lambda الاستجابة. وفي نهاية سلسلة أحجار الدومينو المتساقطة، كان هناك DynamoDB. وصفت AWS الأمر في تقريرها الرسمي بأنه ظرف سباق محتمل (Potential Race Condition). ولكن، هل كان الأمر مجرد سوء توقيت؟ من وجهة نظر مهندس برمجيات خبير، هذا الحادث هو مأساة نتجت عن خلل منطقي في الأنظمة الموزعة وغياب آليات الاسترداد.

الوجه الحقيقي لأنظمة توزيع حركة المرور المعقدة

يستخدم DynamoDB بنية شجرية لـ DNS وسجلات تعتمد على الأوزان (Weight-based records) لضمان التوافر العالي. يتم إدارة حركة المرور بواسطة ثلاثة مكونات أساسية.

المكون	الدور	طريقة التشغيل
DNS Planner	حساب نسب توزيع حركة المرور	إنشاء خطط تحسين على مستوى المنطقة
DNS Enactor	تحديث سجلات Route 53	يعمل بشكل مستقل في 3 مناطق توافر (AZs)
DWFM	تنسيق سير العمل بالكامل	أوركسترا نشر التحديثات

تم تصميم النظام لقطع حركة المرور عن أي قسم يواجه مشكلة عن طريق جعل الوزن () صفراً. كانت النظرية مثالية، لكن في التشغيل الفعلي ظهرت متغيرات غير متوقعة.

السيناريو الأسوأ: عندما يلتقي التجاوز (Overwrite) مع الحذف

في يوم الحادث، وبسبب الضغط الشديد، تأخرت معالجة Enactor 1. وفي غضون ذلك، قام Enactor 2 بتطبيق أحدث إصدار، وهي الخطة 102. وهنا حدث رد فعل متسلسل كارثي.

أولاً، استيقظ Enactor 1 المتأخر وقام بكتابة البيانات القديمة (الخطة 100) فوق المعلومات الأحدث. وفي مرحلة التنظيف (Cleanup) التالية، بدأ Enactor 2 في حذف السجلات القديمة التي لم تكن مدرجة في الخطة 102 (المعيار الحالي من وجهة نظره). البيانات التي أعاد Enactor 1 إحياءها للتو كانت بالنسبة لـ Enactor 2 مجرد أهداف للحذف. في النهاية، تبخرت سجلات DNS الخاصة بنقطة النهاية (Endpoint) الرئيسية لـ DynamoDB.

المشكلة الحقيقية كانت غياب منطق الاسترداد

يتوقف معظم الناس عند هذا الحد في التحليل، مستنتجين أن البيانات حُذفت بسبب تداخل التوقيت. لكن الجوهر يكمن في السؤال: لماذا لم يتمكن النظام من النهوض بنفسه رغم رؤيته لسجلات فارغة؟

بمجرد اختفاء نقطة النهاية، بدأت الأنظمة المسؤولة عن الاسترداد في إطلاق استثناءات وقت التشغيل (Runtime Exceptions) الواحد تلو الآخر. لم يفترض كود Enactor حالة عدم وجود سجلات على الإطلاق. وانهار النظام تماماً كما يحدث في خطأ إدارة الذاكرة Use-after-free، حيث تمت الإشارة إلى كائن قد اختفى بالفعل.

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

دروس ما وراء التقرير الرسمي

أعلنت AWS أنها ستقدم ميزة تحديد معدل السرعة (Rate Limiting). هذا مجرد تخفيف للأعراض وليس علاجاً جذرياً. إذا لم يمتلك النظام القدرة على إدراك الحالة غير الطبيعية ومعالجة نفسه ذاتياً، فستتكرر المأساة.

التصنيف	التفسير الرسمي	رؤية الخبير
سبب العطل	تعارض التحديثات المتزامنة	غياب التحقق من الصلاحية عند الكتابة (CAS)
ظاهرة العطل	توقف الأتمتة عن العمل	نقص في تصميم "الفشل الآمن" (Safe Default)
خطة المواجهة	تحديد سرعة التحديثات	ضمان التكرارية (Idempotency) في منطق الاسترداد

صمم أنظمة تنهار بوقار

يثبت حادث عام 2025 ثقل سطر واحد من الكود. ما أطاح ببنية تحتية بمليارات الدولارات لم يكن عملية اختراق ضخمة، بل كان قصوراً بسيطاً في معالجة الاستثناءات، حيث لم يتم تعريف كيفية التصرف عند مواجهة سجلات DNS فارغة.

جوهر الهندسة ليس في بناء وظائف معقدة، بل في القدرة على تصميم نظام ينهار بوقار (Gracefully) في حالات الفشل غير المتوقعة ويسترد عافيته بشكل مؤكد.

قائمة التحقق الأساسية للاستقرار

• التحقق من التراجع (Rollback): هل يعمل النظام بقيم افتراضية آمنة عندما لا تكون هناك بيانات للرجوع إليها؟
• ضمان الذرية (Atomicity): هل تمت حماية الفجوة بين التحقق (Check) والاستخدام (Use) بتقنيات مثل CAS؟
• إدارة التبعيات: هل توجد استراتيجية للحفاظ على الحد الأدنى من الوظائف حتى لو انقطع الاتصال بقاعدة البيانات الأساسية؟

الخبير الحقيقي هو من يسأل بإلحاح ليس فقط عن كيفية تعطل النظام، بل عن سبب عدم استرداده لعافيته. هل نظامك مستعد للفشل بأمان الآن؟