التوافر قبل ذروة الامتحان: NovaCommerce، الجزء الأول

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

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

عن الحالة: NovaCommerce اسم مستعار لإخفاء هوية مشروع حقيقي. الإعدادات والقياسات أدناه مأخوذة من سجلات سبتمبر وأكتوبر 2026. وهي تخص تلك المنصة وحملها، وليست اختبار أداء لـ Store Console. روجعت الشروحات التقنية العامة في 3 نوفمبر 2026.

ابدأ بالحدث الذي يهم العمل

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

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

كانت هذه متطلبات، لا ادعاءً بأن جميع سيناريوهات الفشل قد اختُبرت بالفعل.

البنية الأصلية ونقاط ضعفها

شغّلت الواجهة حاوية Next.js واحدة على Droplet بموارد 8 vCPU و16 GB، من دون موزّع أحمال أمامها. تعطل هذه العقدة قد يجعل الموقع العام غير متاح. أما الخلفية فشغّلت Laravel عبر nginx وPHP-FPM على عقدتين، لكل منهما 4 vCPU و8 GB. وعمل منفصلًا عامل واحد للمهام الخلفية والمجدول وWebSockets.

استهدف موزّع أحمال الخلفية معرّفات Droplet ثابتة. لذلك احتاج الخادم الجديد إلى التسجيل؛ ولم يكتشف هذا الإعداد السعة الجديدة تلقائيًا. وكانت الجلسات والتخزين المؤقت والطوابير في Valkey مُدار، ما سهّل استبدال عقد الويب.

كان لدى MySQL عقدة مُدارة واحدة بموارد 8 vCPU و32 GB، من دون عقدة احتياطية مهيأة. يمكن للخدمة المُدارة استبدال عقدة معطلة، لكن ذلك يختلف عن وجود نسخة متماثلة جاهزة للترقية إلى عقدة أساسية. وكان العامل الوحيد نقطة فشل أخرى للعمل غير المتزامن.

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

دقة شرح Node.js: قد تقيد حلقة أحداث JavaScript الواحدة أعمال التصيير الكثيفة على المعالج. لكن Node.js يستخدم أيضًا مجموعة عمال وعمليات أصلية. وجود حاوية واحدة لا يثبت أن سبعة من ثمانية أنوية كانت خاملة. يجب اختيار عدد العمليات بعد التحليل واختبار الحمل.

عرّف التوافر باختبارات واضحة

بدل وصف المنصة كلها بأنها «عالية التوافر»، حددنا ما ينبغي أن يراه المستخدم عند كل فشل:

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

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

ثلاث نتائج وثلاث استجابات مختلفة

1. HTTP 429: احتساب الحد بهوية خاطئة

في 25 سبتمبر تلقى طلاب يتشاركون شبكة مدرسة أو شركة اتصالات رسالة «طلبات كثيرة جدًا». اعتمد محدد المعدل على عنوان IP لأن هوية المستخدم الموثقة لم تُستخرج بصورة صحيحة. فتشارك أشخاص كثيرون حصة واحدة.

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

2. مهلات Valkey: تعطل اعتماد مشترك تحت الحمل

سجل اختبار 6 أكتوبر 2,854 خطأ تطبيق بسبب انتهاء مهلة الاتصال بـ Valkey. تصف سجلات الحالة تكلفة فتح اتصالات TLS جديدة وزيادة موارد العقدة الأساسية والاحتياطية من 4 GB إلى 8 GB لكل عقدة.

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

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

3. معالج الخلفية: القيد التالي

مع مزيج API المختبر، بلغت عقدة خلفية من 4 vCPU نحو 65–70 طلبًا/ثانية عند امتلاء المعالج. هذه نقطة تشبع مرصودة؛ ليست هدف تشغيل آمنًا ولا معيارًا قابلًا للنقل إلى أي نظام. تقليل عمل المعالج وإضافة السعة خياران يستحقان التقييم.

في اختبار واحد وصلت أول عقدة إضافية بعد نحو سبع دقائق من بلوغ المعالج 99%. هذا زمن خاص بذلك الإعداد. للاستعداد لامتحان معلوم الموعد، كان القرار العملي زيادة السعة مسبقًا والتحقق من الجاهزية قبل البداية.

قارن التكلفة ضمن النطاق نفسه

قدرت الميزانية الأصلية طبقة الويب بنحو 416 دولارًا شهريًا، منها 112 دولارًا شهريًا للخادمين المطفأين. هذه أرقام تاريخية من سبتمبر وأكتوبر 2026، لا تشمل قواعد البيانات أو Valkey أو التخزين. لا تقارنها مباشرة بفاتورة لاحقة للبنية كاملة.

لا يزال DigitalOcean يفوتر موارد CPU المحجوزة لـ Droplet حتى وهو مطفأ. تعتمد قيمة السعة الباردة على زمن الاستعادة الفعلي: ما الفشل الذي تغطيه، وكم تحتاج لتساعد، ومتى اختُبر الإجراء آخر مرة؟

تتغير الخطط أيضًا. تعلن وثائق DigitalOcean الحالية قيودًا على PostgreSQL وMySQL Standard Edition تبدأ في 15 أكتوبر 2026 للحسابات التي لم تنشئ أي مجموعة PostgreSQL أو MySQL من قبل و30 نوفمبر 2026 لجميع الحسابات. تحقق من الأهلية والأسعار الحالية قبل إعادة بناء إعداد تاريخي.

طبّق المراجعة قبل ذروتك المقبلة

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

التالي: يتناول الجزء الثاني مجموعات الواجهة والخلفية وزيادة السعة مسبقًا وتسلسل النشر. عند تقييم Store Console لحمل حرج، ابدأ بـ متطلبات النشر وتحقق من نمط زياراتك الفعلي.

المصادر والأدلة

أرقام الحالة من سجلات المشروع التاريخية. تدعم هذه المصادر الشروحات العامة، لا القياسات الخاصة.

• Node.js
• DigitalOcean: Droplets
• DigitalOcean: MySQL
• DigitalOcean: Managed Databases

مراجعة: 6 نوفمبر 2026. قبول الإجابة يحتاج إيصال حفظ دائم ومعرف عملية وإعادة محاولة لا تكرر الأثر. لا تكن مهمة الطابور نسخة الإجابة الوحيدة. تحل العقدة الاحتياطية والنسخة الاحتياطية واختبار الاستعادة الناجح مشكلات مختلفة؛ لا يثبت أي منها وحده انعدام فقد البيانات. حُفظت أعداد الحوادث من سجل الحالة الموجود، ولم تُقَس مستقلًا من جديد في هذه المراجعة التحريرية.