عرّف الاستعداد حول نتيجة العميل
ابدأ بالنتائج، لا بتسميات البُنى التحتية. صفحة رئيسية قابلة للوصول لا تكفي إذا لم يستطع الزائر إتمام المهمة التي تهمه. لكل رحلة حرجة، اذكر من يحاول فعل ماذا، ماذا يعني النجاح، وأي نتيجة غير مقبولة. ابدأ بعدد قليل من الرحلات كي يتمكن الفريق من اتخاذ قرارات واقعية.
صنّف كل خطوة على أنها أساسية أو مهمة أو قابلة للتأجيل. الأساسيات تعني أن الرحلة لا تنتهي بدونها؛ المهم قد يسمح بحل مؤقت زمنياً؛ القابلة للتأجيل يمكن حذفها أو تأخيرها أو تبسيطها. هذا قرار منتَج تستند إليه الهندسة، وليس ترتيبًا فنيًا عامًا.
سجل نتيجة قابلة للاستخدام، مثل قبول الطلب وتخزين التأكيد، بدلاً من هدف يعتمد فقط على استجابة صفحة.
خرِّط الاعتماديات وقرّر ما يمكن أن ينهار تدريجياً
لكل مسار حرج، خرِّط الاستضافة أو التسليم، DNS، خدمات التطبيق، قواعد البيانات، المصادقة، البريد الإلكتروني، الدفع، البحث، العلامات، أدوات الموافقة (consent)، وواجهات برمجة التطبيقات الخارجية. سجّل المُلك، مسار الدعم، الحد المعني، وتأثير العطل على المستخدم لكل منها. توصي OWASP بوضوح الاعتماديات البرمجية؛ الانضباط نفسه في التعيين يساعد مع الاعتماديات التشغيلية.
الاعتمادية الصلبة توقف المهمة عند فشلها. الاعتمادية اللينة يمكن غيابها أو أن تكون غير محدثة بينما تظل الوظيفة الأساسية تعمل. تصف AWS التدهور المرن (graceful degradation) بأنه الحفاظ على الوظيفة الأساسية متاحة عندما تكون الاعتماديات غير صحية. حدّد خيارًا خاصًا بالمنتج: إخفاء عنصر غير أساسي، تأجيل تقرير، أو عرض حل بديل صادق. لا تختلق جردًا أو أسعارًا أو حالات طلب أو نتائج دفع.
التقط الغرض، المُلك، الحد المعروف، الاستبدال، جهة الاتصال للتغيير، وآخر تاريخ اختبار لكل بند.
حوّل توقع الحركة إلى تجربة قدرة
استخدم سيناريو، لا رقم حركة واحد. اشترِح الحدث، نمط الوصول، مزيج الطلبات، نسبة المسجلين للدخول، الجغرافيا، نشاط الخروج أو الكتابة المتزامن، وفترة الذروة. أدرج حالة عالية وافتراضاتها. تلاحظ Google أن الطلبات ممكن أن تكون لها تكاليف موارد مختلفة جداً، لذا قد يكون عدد الطلبات في الثانية نموذج سعة ضعيف.
اختبر حركة مستمرة وممثلة من الطرف إلى الطرف ضد تكوين قريب من الإنتاج، مع موافقات ووسائل حماية. تحذّر AWS من اختبار المكونات فقط، استخدام مجموعة طلبات غير ممثلة، أو التوقف عند هامش صغير فوق الحمل المتوقع. وثّق القيد أو البطء الأول الملحوظ. يمكن للاختبارات على الإنتاج الحي أن تؤثر على العملاء؛ استخدم بيئة مراقبة إلا إذا كانت هناك تمرين مخطط ومجهز بالطاقم.
احتفظ بالسيناريو، التكوين، مزيج الطلبات، المدة، القيد الملحوظ، تغيير السعة، وصاحب المتابعة.
حضّر خيارات التغيير، التراجع، والتعافي
قبل تغيير عالي المخاطر، حدّد العنصر أو التكوين الذي سيُستعاد، الموافقات المطلوبة، الشخص المخوّل، وطريقة التحقق. احتفظ بدليل تشغيل قصير لإيقاف إصدار، التراجع عن نشر، تعطيل علم ميزة، تقليل تكامل غير حاسم، أو استعادة بيانات باستخدام إجراء معتمد. اختبر الآليات قبل الحدث؛ النسخة الاحتياطية أو خطة التراجع غير المختبرة افتراض.
حدّد أهداف التعافي من تأثير الأعمال. هدف زمن الاسترداد (Recovery Time Objective، RTO) هو أقصى تأخير مقبول قبل استعادة الخدمة. هدف نقطة الاسترداد (Recovery Point Objective، RPO) هو أقصى خسارة بيانات مقبولة مقاسة من آخر نقطة استرداد. تحذّر AWS من الأهداف التعسفية أو غير الواقعية وتذكر أن أهداف الاعتماديات تؤثر فيما هو قابل للتحقيق. عامل الأهداف كأهداف تخطيطية، لا وعود للعملاء.
تحقق من تراجع محدود وآمن أو استعادة وسجل ما فُحِص، ومن قِبَل من، وأي فجوة وُجدت.
عيّن الملكية قبل أن تصبح القرارات عاجلة
قائمة جهات الاتصال وحدها ليست ملكية. لكل مسار حرج، عيّن مالكًا تجاريًا للنتيجة المقبولة، ومالكًا تقنيًا للتنفيذ، ومالك قرار مخوّل لاتخاذ تغيير وقائي. سمِّ بدائل ووضّح متى يكون المزود أو الوكالة أو معالج الدفع أو الفريق الداخلي هو الطرف المسؤول عن الإجراء التالي.
قم بمراجعة استعداد قصيرة قبل وصول الحركة. استعرض فشل اعتماد واحد: ما الذي يبقى متاحًا، أي ذراع آمن، من يوافق عليه، وكيف يُتحقق النجاح. هذه بروفة استباقية، ليست تقرير حالة حي. سجّل الإجراءات المؤرخة، المالكون، وتواريخ الاستحقاق.
فَوِّض مسبقًا إجراءات ضيقة وآمنة حيثما كان ذلك مناسبًا حتى لا تنتظر الحماية سلسلة موافقات غير واضحة.
عامِل مسارات الدفع والحساسة للأمن بعناية إضافية
يجب أن يحافظ استعداد صفحة الخروج على الصحة الصحيحة بالإضافة إلى التوافر. لا تتجاوز التفويض، لا تضعف ضوابط الوصول، لا تكشف بيانات الاعتماد، ولا تغير سكربتات صفحة الدفع بشكل عفوي. تتناول إرشادات PCI SSC التفويض، السلامة من العبث، وكشف العبث لسكربتات صفحة الدفع والرؤوس HTTP التي تؤثر على الأمن. إذا كان الموقع يقبل بطاقات أو يستخدم إطار دفع مضمّن، فليُراجع التغييرات المادية التاجر والمعالج والمكتتب والمستشارون المؤهلون للأمن أو الامتثال.
احتفظ بجرد لسكربتات الإنتاج، التكاملات، الإصدارات، وملكية الحساب، وقيد من يمكنه تغييرها. تلاحظ OWASP أن جرد الاعتماديات وتثبيت الإصدارات يمكن أن يقلل عدم اليقين حول ما يدخل البناء، بينما تحتاج النتائج الآلية تحققًا يدويًا. تدعم هذه الممارسات الاستعداد لكنها لا تُثبت امتثال PCI أو تستبدل تقييم أمني.
استخدم فقط تدفقًا بديلًا معتمدًا ومراجعًا من المعالج؛ لا تجمع بيانات البطاقة عبر قنوات غير رسمية.