Written with AI assistance from the source video. The video is the authority.
50:56The PrimeTime
Log in to leave a comment
No posts yet
في أكتوبر 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 | تنسيق سير العمل بالكامل | أوركسترا نشر التحديثات |
تم تصميم النظام لقطع حركة المرور عن أي قسم يواجه مشكلة عن طريق جعل الوزن () صفراً. كانت النظرية مثالية، لكن في التشغيل الفعلي ظهرت متغيرات غير متوقعة.
في يوم الحادث، وبسبب الضغط الشديد، تأخرت معالجة 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) في حالات الفشل غير المتوقعة ويسترد عافيته بشكل مؤكد.
قائمة التحقق الأساسية للاستقرار
الخبير الحقيقي هو من يسأل بإلحاح ليس فقط عن كيفية تعطل النظام، بل عن سبب عدم استرداده لعافيته. هل نظامك مستعد للفشل بأمان الآن؟