تحويل وصف الحمل إلى متطلبات قابلة للفحص

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

عرّف الطلب بمقام واضح. «300 طلب في الدقيقة» يعني في المتوسط خمسة طلبات في الثانية خلال الدقيقة المقاسة، لكنه لا يحدد الذروة داخل ثوانٍ أو نسبة الطلبات التي تصل إلى قاعدة البيانات. اكتب نافذة الرصد، نوع الطلب، توزيع القراءة والكتابة، وزمن الخدمة الذي سيقاس. إذا كان المتوسط اليومي 40 طلبًا في الدقيقة والذروة 300 لمدة 15 دقيقة، فلا تضرب المتوسط في يوم كامل ثم تتعامل مع الناتج كحد الذروة. استخدم بيانات تاريخية حين توجد، ووسم أرقام التدريب بأنها مفترضة. افحص نسبة الطلبات الناجحة وزمن استجابة عند شريحة محددة، مثل 95% من طلبات الحجز دون ثلاث ثوانٍ في اختبار ذروة محدد. هذه عتبة تصميمية افتراضية يقررها صاحب الخدمة، وليست معيارًا عامًا لكل موقع.

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

افصل هدف الإتاحة عن هدف الاستعادة. قد تبقي نسخ تشغيلية متعددة الواجهة متاحة عند فقد مثيل، لكنها لا تعيد سجلًا حُذف خطأ. اطلب من صاحب الخدمة أقصى مدة توقف مقبولة وأقصى عمر لبيانات يمكن فقدها في انقطاع محدد. سجّلها كمتطلبات RTO وRPO مقترحة، ثم افحص إن كان ترتيب النسخ والاستعادة قادرًا على تحقيقها؛ لا تستنتجها من شعار «نسخ يومي». فإذا أخذت نسخة عند منتصف الليل فقط وحدث تلف عند الساعة 23:00، فاستعادة النسخة وحدها قد تفقد نحو 23 ساعة من التغييرات، قبل حساب أي سجل معاملات مستقل. هذه نتيجة حسابية للمثال، لا ضمان لواقع نظام. وزمن نقل النسخة وتشغيل التطبيق والتحقق من الحجز يدخل في اختبار زمن الاستعادة.

ورقة المتطلبات الجيدة تفصل «حقيقة مرصودة» و«افتراض تخطيط» و«قرار يطلب موافقة». مثال: سجل اختبار يبيّن أن طلب الحجز يولّد قراءتين وكتابة واحدة؛ هذه مشاهدة ضمن بيئة محددة. توقع مضاعفة عدد العملاء العام المقبل افتراض تجاري. شراء مورد محجوز لعام كامل قرار مالي يحتاج صاحب صلاحية. ضع مصدر كل رقم وتاريخه ودرجة الثقة. إن لم يُعرف حجم ملفات المرفقات، ضع تجربة قياس قبل ميزانية التخزين، لا صفراً. إذا كانت هناك 20 ألف حجز متوقعة ومتوسط سجل 4 كيلوبايت، فالبيانات الخام المفترضة 80 ميغابايت تقريبًا وفق وحدات عشرية، قبل الفهارس والنسخ والسجلات والمرفقات؛ لا تعرض 80 ميغابايت كسعة نهائية.

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

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