اختبار مرونة الأداء والأمان

مسودة الخطة بنداً بنداً. البند 1: «سريع» و«لا يتعطل» ليسا هدفين؛ يحتاج الاختبار إلى رقم قبل تشغيله، والأهداف T1–T3 تعطي بالفعل مئينات وحملاً ومعدل خطأ. البند 2: نقطة نهاية واحدة في حلقة ليست نموذج عبء العمل، وهو هنا ⁦450⁩ طلباً في الثانية بمزيج نقاط النهاية المتفق عليه. وعبارة «⁦200⁩ مستخدم افتراضي» لا تعني الكثير وحدها، لأن المستخدم الافتراضي ينتظر زمن تفكير بين الطلبات: اذكر الحمل بالطلبات في الثانية، وحدّد عدد المستخدمين الافتراضيين حتى تصل الأداة إليه. البند 3: لا تُشغَّل اختبارات الحمل على بيئة الإنتاج، لا في الساعة ⁦03:00⁩ ولا في غيرها: فهي تُضعف الخدمة للعملاء الحقيقيين وقد تُفعّل ضوابط الاحتيال أو تحديد المعدل، ومنها ضوابط بوابة الدفع. استخدم staging-perf، ولا يُشغَّل في الإنتاج إلا فحوص اصطناعية للقراءة فقط بوصفها مراقبة. البند 4: المتوسط يخفي الذيل البطيء؛ سجّل p50 وp95 وp99، وسجّل معدل الخطأ ونوعه كلاً على حدة. البند 5: نسخ ⁦50,000⁩ عميل حقيقي يخالف نظام حماية البيانات الشخصية وقاعدة الدليل؛ ولّد بيانات اصطناعية بالشكل الصحيح (أسماء، وأرقام جوال سعودية، وحسابات واختيارات مقاعد كثيرة ومتنوعة، وبعض الطلبات غير الصالحة). البند 6: اختبار تحمّل مدته ⁦15⁩ دقيقة لا يرى شيئاً لا يراه اختبار الحمل؛ والبيع يستمر أربع ساعات، فيُشغَّل اختبار التحمّل عند ⁦300⁩ طلب في الثانية أربع ساعات على الأقل. البند 7: يجد الماسح الأنماط المعروفة لكنه لا يجد التحكم المعطّل في الوصول، وتشغيله في الليلة السابقة للبيع لا يترك وقتاً لإصلاح أي شيء؛ مكانه خط الأنابيب من الآن، إلى جانب فحوص خط الأساس اليدوية.

وما ينقص الخطة كلياً: اختبار ذروة مفاجئة، مع أن الإشعار الفوري ينقل المنصة من نحو ⁦40⁩ إلى ⁦450⁩ طلباً في الثانية خلال ثوانٍ؛ واختبار إجهاد يجد الهامش؛ وحقن أعطال على بوابة الدفع ومزوّد SMS؛ وفحص التخزين المؤقت؛ وقاعدة لحفظ النتائج. خطة من صفحة واحدة لهذا البيع. الأهداف: T1–T3 بمزيج نقاط النهاية عند ⁦450⁩ طلباً في الثانية وعند ⁦300⁩ طلب في الثانية، طوال البيع من ⁦20:00⁩ حتى ⁦24:00⁩، مكتوبة قبل الاختبار. نموذج عبء العمل: مزيج التوقعات، ومستخدمون ورموز اصطناعية، وحجوزات مقاعد موزعة على الملعب مع تنافس على المقاعد نفسها، ونسبة من الطلبات غير الصالحة. التشغيلات على staging-perf: اختبار حمل عند ⁦450⁩ طلباً في الثانية لمدة ⁦30⁩ دقيقة؛ واختبار ذروة مفاجئة من ⁦40⁩ إلى ⁦450⁩ طلباً في الثانية في أقل من دقيقة؛ واختبار إجهاد من ⁦450⁩ طلباً في الثانية صعوداً حتى نقطة الانكسار؛ واختبار تحمّل عند ⁦300⁩ طلب في الثانية أربع ساعات على الأقل. حقن الأعطال: تُجعل بوابة الدفع ومزوّد SMS كلٌّ منهما بطيئاً وخاطئاً (جسم مشوّه، و500، و503، و429 مع Retry-After) وغير متاح، ويُراقب التعافي. خط أساس OWASP: التحكم في الوصول برمز صالح لمستخدم خطأ ولدور خطأ، والحقن، وتسجيل الدخول والجلسات، والترويسات وملفات تعريف الارتباط، والرموز، وCORS، والأخطاء المفصّلة، والبيانات الشخصية في السجلات. التخزين المؤقت: Cache-Control وETag على أثقل الاستجابات (صفحات الفعالية، والصور، ومخطط المقاعد)، مع مقارنتها بمدى الحداثة التي تحتاجها كل استجابة. السجلات: نموذج عبء العمل ووصف البيئة والنتائج الخام لكل تشغيل؛ وتنبيهات أهداف مستوى الخدمة (SLO) مضبوطة من T1–T3؛ وإعادة تشغيل الحزمة مع كل إصدار يمس البنية التحتية أو المصادقة أو مسار البيع.

R1: ناجح. p95 لخريطة المقاعد ⁦620 ≤ 800⁩ وp99 ⁦1,350 ≤ 1,500⁩ (T1)، وp95 للدفع ⁦2,400 ≤ 3,000⁩ (T2)، والأخطاء ⁦0.04% < 0.1%⁩ (T3): المنصة تفي بوعدها عند ذروة ثابتة. R2: فشل في الأهداف الثلاثة. p95 لخريطة المقاعد ⁦2,900⁩ وp99 ⁦7,800⁩ مقابل ⁦800⁩ و⁦1,500⁩، وp95 للدفع ⁦5,100⁩ مقابل ⁦3,000⁩، والأخطاء ⁦2.1%⁩ مقابل ⁦0.1%⁩. تنطبق الأهداف T1–T3 من الدقيقة الأولى، والإشعار يحوّل الدقائق الأولى إلى ذروة مفاجئة، لذلك فإن R2 هو ما سيبدو عليه افتتاح البيع: إنه يوقف الإطلاق. ومن الدقيقة السادسة تطابق القيم قيم R1، أي أن المنصة تلحق بالحمل، لكن بعد فوات الأوان على المشترين الأوائل. وكان معيار المسودة سيعدّ هذا التشغيل ناجحاً: المتوسط ⁦520⁩ مللي ثانية أقل من ثانية، بينما يستغرق طلب من كل عشرين ⁦2.9⁩ ثانية أو أكثر.

R3: ناجح في الساعة الأولى، وفشل في الساعة الرابعة. p95 لخريطة المقاعد ⁦1,450⁩ وp99 ⁦3,900⁩، وp95 للدفع ⁦4,800⁩، والأخطاء ⁦0.9%⁩ كلها تتجاوز أهدافها مع أن الحمل لم يتغير، واتصالات قاعدة البيانات المستخدمة ترتفع من ⁦60⁩ إلى الحد الأقصى للمجمّع ⁦200⁩. هذا نمط اتصالات تؤخذ ولا تُعاد، ولا يكشفه إلا اختبار يستمر ساعات. وهو يوقف الإطلاق أيضاً لأن البيع يستمر أربع ساعات؛ وكان اختبار التحمّل ذو الدقائق الخمس عشرة في المسودة ومعيار المتوسط فيها (⁦410⁩ مللي ثانية في الساعة الرابعة) سيفوّتانه كلاهما. R4: لا يُحكم عليه مقابل T1–T3 لأن الحمل فوق الهدف؛ فاختبار الإجهاد يجيب عن سؤالين آخرين. أين الحد؟ تبقى الأخطاء دون ⁦0.1%⁩ حتى ⁦800⁩ طلب في الثانية وتقفز عند ⁦850⁩، فالحد بينهما؛ سجّل آخر خطوة صمدت، ⁦800⁩ طلب في الثانية، أي قرابة ⁦1.8⁩ ضعف ذروة التوقعات، بوصفها الهامش. وكيف يفشل؟ على نحو سيئ: خطوة واحدة من ⁦50⁩ طلباً في الثانية ترفع الأخطاء من أقل من ⁦0.1%⁩ إلى ⁦41%⁩ مع أن الحمل زاد نحو ⁦6%⁩ فقط، أي أنه يفشل دفعة واحدة لا ببطء وأمان. والنصف الجيد أنه يتعافى وحده خلال دقيقتين دون إعادة تشغيل. وليس p95 البالغ ⁦95⁩ مللي ثانية أداءً جيداً أيضاً؛ إنه منخفض فقط لأن ⁦41%⁩ من الإجابات أخطاء سريعة، والنظام الذي يبقى سريعاً بإرجاع الأخطاء لم ينجح. وصفحة HTML عامة إجابة خاطئة أيضاً لواجهة برمجية؛ المتوقع: خطأ 503 واضح يستطيع التطبيق عرضه، مع ترويسة Retry-After (يسمح بها RFC 9110 مع 503)، وأخطاء تزداد بقدر الحمل الزائد بدل أن تقفز.

F1: مقبول. الإجابة المشوّهة تنتج خطأً محدداً مسجَّلاً، ورسالة واضحة، وطلباً غير مدفوع. F2: فشل. تنتظر خدمة الدفع البوابة حتى ⁦60⁩ ثانية، أي أكثر مما ينتظر مستدعيها نفسه، بوابة API ‏(⁦20⁩ ثانية)، فيرى العميل خطأً بينما يتم الدفع بعد ⁦11⁩ ثانية، وقد يدفع مرة ثانية. المتوقع: مهلة للاستدعاء الصادر أقل بوضوح من ⁦20⁩ ثانية؛ وحين تكون النتيجة غير معروفة، يبيّن الطلب أن الدفع قيد التأكيد، ويتحقق التطبيق من حالة الطلب بدل أن يعرض الدفع مجدداً. F3: فشل، ويوقف الإطلاق. طلب غير متكافئ (non-idempotent) يُعاد على نحو أعمى، ثلاث مرات دفعة واحدة دون تراجع؛ ومع البوابة الحقيقية، فإن خصماً تمّ لكن ضاعت إجابته أو تأخرت سيُخصم مرة أخرى. المتوقع: لا إعادة تلقائية لـ POST /charges، أو إعادة محدودة بتراجع فقط مع مفتاح منع تكرار تدعمه البوابة. F4: فشل. عشر محاولات خلال ثانية تتجاهل Retry-After: 30؛ يعرّف RFC 6585 الحالة 429 ويتيح للخادم أن يقول متى يُعاد الطلب، والإعادة الفورية تزيد الحمل على بوابة طلبت للتو حملاً أقل. ثم يتلقى التطبيق خطأ 500 عاماً. المتوقع: لا طلب جديد قبل وقت Retry-After، وخطأ محدد يستطيع التطبيق عرضه، مثل أن الدفع مزدحم ويمكن للعميل المحاولة بعد ⁦30⁩ ثانية. F5: فشل، لأن التعافي ليس تلقائياً. المتوقع: حين تعود البوابة يُستأنف الدفع دون إعادة تشغيل، وهذا ما يوفره قاطع دارة يجرّب الاعتمادية من جديد بعد مهلة. لم يُختبر بعد: الفحوص نفسها لمزوّد SMS، فبلا الرمز لا يستطيع أحد تسجيل الدخول.

S1: ترويسة X-Content-Type-Options: nosniff وسمة Secure في ملف تعريف الارتباط صحيحتان. الناقص (الإعداد): Strict-Transport-Security وContent-Security-Policy وحماية الإطارات (X-Frame-Options أو توجيه frame-ancestors في CSP). ولا يحمل ملف الجلسة HttpOnly، فيستطيع أي سكربت في الصفحة قراءته، ومنه سكربت محقون عبر عيب من نوع البرمجة النصية عبر المواقع (XSS)، ولا يحمل SameSite (الجلسات)؛ اضبط السمتين صراحةً بدل الاعتماد على الإعدادات الافتراضية للمتصفحات، فهي تختلف. S2 (المصادقة والجلسات، عمر الرمز): exp - iat يساوي ⁦2,592,000⁩ ثانية، أي ⁦30⁩ يوماً، من ⁦13⁩ أكتوبر إلى ⁦12⁩ نوفمبر ⁦2026⁩، الساعة ⁦07:00⁩ UTC. رمز الوصول المسرَّب يعمل شهراً كاملاً؛ والمتوقع: عمر قصير يُتفق عليه مع الفريق، بالدقائق، ويُجدَّد برمز التحديث (Refresh token). ولا توجد مطالبة aud، فلا تستطيع أي واجهة برمجية التحقق من أن الرمز صدر لها. ولا يُظهر الرمز هل يثبّت الخادم الخوارزمية: اختبر ذلك على بيئة الاختبار برمز تقول ترويسته none وليس له توقيع؛ والمتوقع 401.

S3 (التحكم في الوصول): تفويض معطّل على مستوى الكائن، وهو API1:2023 في OWASP API Security Top 10، والتحكم المعطّل في الوصول في OWASP Top 10. عميل يقرأ البيانات الشخصية لعميل آخر بتغيير معرّف. الخطورة: حرج (Critical)، وهو يوقف الإطلاق. المتوقع: 403 أو 404 لطلب لا يخص المستدعي. كرّر الفحص على كل نقطة نهاية تأخذ معرّفاً (الطلبات، والتذاكر، وحجوزات المقاعد) وبالدور الخطأ، أي برمز عميل على نقاط نهاية الموظفين؛ ولم يكن الماسح ليجده. S4 ‏(CORS): تعكس الواجهة البرمجية أي أصل وتسمح ببيانات الاعتماد، فلا تفعل سياسة الأصل شيئاً. وهذا أسوأ من حرف البدل: المتصفحات ترفض * مع بيانات الاعتماد، لكنها تقبل الأصل المعكوس. المتوقع: قائمة سماح بأصول المنصة نفسها، ولا Access-Control-Allow-Origin لأي أصل آخر. S5 (الإعداد): الأخطاء المفصّلة مفعّلة، واستثناء مع مسار ملف يخبر أي شخص كيف بُني النظام. المتوقع: جسم خطأ عام مع معرّف ارتباط (Correlation id)، والتفاصيل في السجل فقط. وهو أيضاً دليل على سبب R2 وR3: مجمّع اتصالات قاعدة البيانات ينفد تحت الذروة المفاجئة ويُستنزف أثناء اختبار التحمّل. لم يُغطَّ بعد: الحقن على كل مدخل يصل إلى قاعدة البيانات؛ وحدود محاولات رمز SMS وإعادة إرساله؛ وتسجيل خروج يبطل الجلسة والرمز فعلاً؛ وإعداد TLS؛ والبيانات الشخصية في السجلات.

مذكرة مدير الإصدار. القرار: لا إطلاق للبيع بالحالة التي اختُبرت (No-go). يجب إصلاحه وإعادة اختباره قبل ⁦22⁩ أكتوبر: R2 (الدقائق الأولى تتجاوز كل هدف)، وR3 (تنفد الاتصالات بحلول الساعة الرابعة)، وF2 وF3 (قد يُخصم من العملاء مرتين)، وF5 (لا تعافي دون إعادة تشغيل)، وS3 (يستطيع العملاء قراءة طلبات بعضهم). ويُصلَح أيضاً قبل البيع، مع إعادة فحص سريعة لكل منها: F4 وS1 وS2 وS4 وS5، واستجابة الحمل الزائد التي ظهرت في R4. ويبقى تشغيله قبل البيع: حقن الأعطال على مزوّد SMS، وفحوص خط الأساس التي لم تُغطَّ بعد. بعد الإصلاحات: اختبار التأكيد لكل بند فشل، ومنه اختبار التحمّل كاملاً لأربع ساعات؛ وR1 مرة أخرى بوصفه اختبار انحدار بعبء العمل نفسه، لأن الإصلاحات تمس مسار البيع ويجب أن تكون المقارنة صادقة؛ وR4 مرة أخرى لتسجيل الهامش الجديد. احتفظ بنموذج عبء العمل ووصف staging-perf والنتائج الخام لـ R1–R4 مع المذكرة، واضبط تنبيهات مساء البيع على T1–T3، وإن كانت المنصة ضمن نطاق الضوابط الأساسية للأمن السيبراني (ECC) الصادرة عن الهيئة الوطنية للأمن السيبراني، فاحفظ التقرير دليلاً على الضوابط المرتبطة.

للتحقق من عملك: R1 هو التشغيل الوحيد الناجح، وR4 الوحيد الذي لا يُحكم عليه مقابل الأهداف؛ ومن F1–F5 لا يُقبل إلا F1، ومن S1–S5 لا يصح إلا ترويسة nosniff وسمة Secure في ملف تعريف الارتباط. إن عددت R2 أو R3 ناجحاً لأن المتوسط بقي دون ثانية، فأعد قراءة بند المئينات في الدليل؛ وإن عددت ⁦95⁩ مللي ثانية في R4 خبراً جيداً، فأعد قراءة البند عن النظام الذي يبقى سريعاً بإرجاع الأخطاء. ولا بأس بتقسيم مختلف بين ما يوقف الإطلاق وبقية الإصلاحات ما دام لكل قرار سببه؛ أما الحكم الذي لا يستند إلى رقم أو قاعدة فغير مقبول.