استمرارية الأعمال والتعافي من الكوارث

9.1 نظرة عامة والغرض

يحدد هذا الفصل التزامات استمرارية الأعمال والتعافي من الكوارث (BCDR) التي تحكم تقديم المورّد لمنصة ProjectVIEW ERP. وهو يضع استراتيجية النسخ الاحتياطي، وبنية النسخ المتماثل، وإجراءات التحول، وأهداف زمن التعافي، والتزامات تكرار البيانات، ومتطلبات تخطيط الاستمرارية التي تضمن بقاء بيانات العميل متاحة، ودائمة، وقابلة للاسترداد طوال مدة الاشتراك.

يتوافق نظام إدارة استمرارية الأعمال لدى المورّد (BCMS) مع ISO 22301:2019 (الأمن والمرونة — أنظمة إدارة استمرارية الأعمال) ويستند إلى NIST SP 800-34 Rev. 1 (دليل تخطيط الطوارئ لأنظمة المعلومات الفيدرالية) وبرنامج Microsoft Cloud Enterprise Business Continuity Management (EBCM). ويكمّل هذا الفصل التزامات التوافر المحددة في الفصل 3 (اتفاقية مستوى الخدمة)، وضوابط أمن البنية التحتية الموضحة في الفصل 8 (أمن المعلومات والسرية)، وأحكام حماية البيانات في الفصل 7 (حماية البيانات والخصوصية).

يتم تجهيز بيئة كل عميل السيادية الخاصة المخصصة بضوابط استمرارية متعددة الطبقات تشمل الحوسبة وقاعدة البيانات والتخزين والشبكة، بما يضمن ألا يؤدي أي عطل منفرد إلى فقدان البيانات أو انقطاع الخدمة لفترة تتجاوز RPO وRTO المتعاقد عليهما.

9.2 النطاق

يغطي هذا الفصل ما يلي:

• (a) أهداف التعافي: التزامات تعاقدية ملزمة بشأن RPO وRTO لجميع طبقات المنصة.
• (b) إدارة النسخ الاحتياطية: جداول النسخ الاحتياطي وفترات الاحتفاظ والتحقق من السلامة وإجراءات الاستعادة للأجهزة الافتراضية وقواعد البيانات ومواد التطبيق.
• (c) تكرار البيانات والنسخ المتطابق: خيارات تكرار Azure Storage (LRS, ZRS, GRS)، ونسخ القراءة لقواعد البيانات، وبنية التحول الجغرافي المتكرر.
• (d) التعافي من الكوارث: إجراءات التحول، وتفعيل المنطقة الثانوية، وبروتوكولات الاتصال، وسير عمل استعادة الخدمة.
• (e) تخطيط استمرارية الأعمال: تحليل أثر الأعمال (BIA)، وصيانة خطة الاستمرارية، وجداول تمارين التعافي من الكوارث، وإجراءات المراجعة بعد الحوادث.
• (f) ملكية البيانات وقابليتها للنقل: حقوق ملكية بيانات العميل، وآليات تصدير البيانات، والتزامات إدارة السجلات، ودعم الاكتشاف الإلكتروني.
• (g) الأدوار والمسؤوليات: توزيع RACI عبر مؤسسات المورّد والعميل لجميع أنشطة BCDR. لا يغطي هذا الفصل ضوابط الأمن على مستوى التطبيق (انظر الفصل 8)، أو معالجة البيانات الشخصية (انظر الفصل 7)، أو سير عمل الدعم التشغيلي (انظر الفصل 4).

9.3 المعايير ومواءمة الأطر

يتوافق برنامج BCDR لدى المورّد مع المعايير والأطر المعترف بها دولياً التالية:

9.4 أهداف التعافي

تنطبق أهداف التعافي التالية الملزمة تعاقدياً على بيئة كل عميل السيادية الخاصة المخصصة. وتحدد هذه الأهداف أقصى فقدان مسموح به للبيانات (RPO) وأقصى مدة توقف مسموح بها (RTO) لكل طبقة من طبقات المنصة:

عندما يكون العميل قد اختار خيار التعافي المعزز من الكوارث (خادم ثانوي مع نسخ متماثلة لقاعدة البيانات للقراءة فقط ونسخ متماثل عالي التكرار بفواصل تصل إلى 15 دقيقة)، يُخفَّض RTO لطبقة قاعدة البيانات إلى ساعة واحدة، حيث يتولى الجهاز الافتراضي الثانوي الدور الرئيسي مع حد أدنى من فقدان البيانات والوقت. ويخضع خيار التعافي المعزز من الكوارث لرسوم اشتراك إضافية على النحو المنصوص عليه في العقد التجاري المطبق.

نظرة عامة على استمرارية أعمال قاعدة بيانات Azure SQL

9.5 إدارة النسخ الاحتياطية

يحافظ المورّد على نظام نسخ احتياطي شامل يغطي جميع مكوّنات بيئة كل عميل السيادية الخاصة المخصصة. وتُنفذ عمليات النسخ الاحتياطي باستخدام Azure Backup وقدرات النسخ الاحتياطي الأصلية لـ SQL Server.

9.5.1 جدول النسخ الاحتياطي والاحتفاظ

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

نظرة عامة على Azure Backup النسخ الاحتياطي لـ SQL Server إلى Azure

9.5.2 التحقق من سلامة النسخ الاحتياطية

يجب على المورّد تنفيذ إجراءات التحقق التالية من سلامة النسخ الاحتياطية:

• (a) التحقق الآلي من قيمة التحقق: تولد كل عملية نسخ احتياطي قيمة تحقق تشفيرية (SHA-256). ويتم التحقق من قيمة التحقق تلقائياً عند اكتمال العملية وتسجيله في سجل تدقيق النسخ الاحتياطي.
• (b) اختبار استعادة شهري: مرة واحدة على الأقل كل شهر تقويمي، يتعين على المزود تنفيذ استعادة اختبارية لنسخة احتياطية مختارة عشوائياً من قاعدة البيانات إلى بيئة معزولة، مع التحقق من اكتمال البيانات، وسلامة المراجع، ووظائف طبقة التطبيق.
• (c) تمرين استعادة كامل للنظام ربع سنوي: مرة واحدة على الأقل كل ربع سنة تقويمية، يتعين على المزود تنفيذ استعادة كاملة للمنصة (VM + قاعدة البيانات + التطبيق + الإعدادات) إلى بيئة معزولة، بما يحاكي سيناريو كامل للتعافي من الكوارث. وتوثق النتائج في تقرير تمرين التعافي من الكوارث.
• (d) المراقبة والتنبيه للنسخ الاحتياطي: يتم إعداد تنبيهات Azure Monitor لإخطار فريق عمليات السحابة لدى المزوّد خلال 15 دقيقة من أي فشل في النسخ الاحتياطي أو انتهاء مهلة أو فشل في التحقق من السلامة. وتؤدي النسخ الاحتياطية الفاشلة إلى إعادة محاولة تلقائية خلال ساعة واحدة.

9.6 تكرار البيانات والنسخ المتماثل

تستفيد بيئة السيادة الخاصة المخصّصة لكل عميل من بنية Azure متعددة الطبقات لتكرار البيانات، وذلك للحماية من فشل الأجهزة، وفشل المنشأة، والكوارث الإقليمية:

افتراضيًا، يتم تزويد حساب Azure Storage الخاص بكل عميل باستخدام التخزين الجغرافي المتكرر (GRS)، مع الاحتفاظ بست نسخ من بيانات العميل، ثلاث داخل منطقة Azure الأساسية وثلاث داخل منطقة ثانوية مقترنة جغرافيًا. في حال حدوث فشل في المنطقة الأساسية، يقوم Azure Storage تلقائيًا بالتحويل إلى المنطقة الثانوية، بما يضمن تحمّل البيانات دون تدخل يدوي.

تكرار Azure Storage

9.6.1 تكرار قاعدة البيانات

تدعم قواعد بيانات SQL Server 2022 داخل بيئة كل عميل التكوينات التالية للنسخ المتماثل:

• (a) التكوين القياسي: نسخ احتياطية كاملة يومية مع احتفاظ لمدة 7 أيام، مخزنة في GRS. ويتم نسخ سجلات المعاملات الاحتياطية وفقًا للجدول الزمني المكوّن (الافتراضي: كل ساعة؛ Enhanced DR: كل 15 دقيقة).
• (b) تكوين Enhanced DR (اختياري): يتم تزويد مثيل ثانٍ من SQL Server بنسخ متماثلة للقراءة فقط لجميع قواعد بيانات العميل. ويضمن شحن السجلات عالي التواتر (بفواصل تصل إلى 15 دقيقة) مزامنة شبه فورية للبيانات. وفي حال فشل الخادم الأساسي، يتولى الخادم الثانوي تلقائيًا الدور الأساسي، بما يوفّر استمرارية مع فقدان بيانات محدود للغاية (RPO ≤ 15 دقيقة) واستعادة سريعة (RTO ≤ 1 ساعة).
• (c) الامتثال لمتطلبات إقامة البيانات: يقتصر نسخ البيانات على النطاق الجغرافي الذي اختاره العميل ما لم يصرّح العميل صراحةً كتابةً بالنسخ عبر المناطق. ولا يمكن نقل البيانات خارج النطاق الجغرافي المختار دون موافقة العميل، وذلك امتثالًا للمادة 44 من اللائحة العامة لحماية البيانات GDPR ومتطلبات النقل عبر الحدود الواردة في المادة 22 من قانون حماية البيانات الشخصية في دولة الإمارات UAE PDPL (انظر الفصل 7، §7.14).

9.7 إجراءات التعافي من الكوارث

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

9.7.1 تصنيف الحوادث والتصعيد

تُصنَّف أحداث التعافي من الكوارث وفقًا للتصنيف التالي لمستويات الشدة:

9.7.2 إجراءات التحويل عند الفشل

تُنفَّذ إجراءات التحويل التالية بالتسلسل عند إعلان حدث DR-1 أو DR-2:

9.7.3 التحويل إلى المنطقة الثانوية

عندما تُعلن Microsoft أو CTO لدى المزوّد أن منطقة Azure الأساسية غير قابلة للاستعادة، يتعين على المزوّد تنفيذ تحويل كامل إلى المنطقة الثانوية إلى منطقة Azure الثانوية المقترنة جغرافيًا. وتشمل هذه العملية:

• (a) بدء تحويل GRS عند الفشل: يقوم Azure Storage تلقائيًا بالتحويل إلى المنطقة الثانوية. وتتيح حسابات RA-GRS وصولًا فوريًا للقراءة إلى البيانات المنسوخة.
• (b) إعادة تزويد الخوادم الافتراضية: يتم تزويد خوادم افتراضية جديدة في المنطقة الثانوية من أحدث Azure Backup vault (مع تمكين الاستعادة عبر المناطق).
• (c) استعادة قاعدة البيانات: يتم استعادة قواعد بيانات SQL Server من النسخ الاحتياطية الجغرافية المتكررة أو، حيثما يكون Enhanced DR مهيأً، من خادم النسخة المتماثلة الثانوية للقراءة في المنطقة المقترنة.
• (d) إعادة تهيئة DNS: يتم تحديث Azure Traffic Manager أو سجلات DNS لتوجيه جميع حركة مرور العميل إلى نقاط نهاية المنطقة الثانوية.
• (e) التحقق والإعلان: يتم تنفيذ حزمة التحقق الكاملة من التطبيق قبل إعلان استعادة الخدمة من المنطقة الثانوية. ويبلغ RTO المستهدف للتحويل الكامل إلى المنطقة الثانوية 24 ساعة من لحظة إعلان المنطقة الأساسية. ويجب إبقاء العميل على اطلاع كل ساعتين على الأقل أثناء إجراء التحويل عبر قناة الاتصال المتفق عليها.

التعافي من الكوارث عبر مناطق Azure

9.8 تخطيط استمرارية الأعمال

9.8.1 تحليل أثر الأعمال (BIA)

يحافظ المزوّد على تحليل أثر الأعمال لمنصة ProjectVIEW ERP الذي يحدد العمليات التجارية الحرجة ويربطها بمكوّنات المنصة ويقيس أثر تعطل الخدمة. ويُراجع تحليل أثر الأعمال ويُحدّث:

• (a) مرة واحدة على الأقل سنويًا كجزء من دورة مراجعة إدارة BCMS.
• (b) عقب أي تغيير جوهري في بنية المنصة أو إعدادات منطقة Azure أو طوبولوجيا نشر العميل.
• (c) عقب أي حادث DR-1 أو DR-2 يكشف عن ثغرات في تحليل أثر الأعمال القائم.

يوجه تحليل أثر الأعمال معايرة أهداف الاستعادة (RPO/RTO)، وقرارات تواتر النسخ الاحتياطي، وتصميم بنية النسخ المتماثل لكل بيئة عميل.

9.8.2 خطة استمرارية الأعمال (BCP)

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

• (a) تكوين فريق إدارة الأزمات (CMT): CTO (قائد الحادث)، قائد عمليات السحابة، قائد DBA، مدير حساب العميل، وقائد الاتصالات.
• (b) خطة الاتصال: قوالب محددة مسبقًا لإخطار العميل (تنبيه أولي، تحديث التقدم، إشعار الحل، توزيع PIR)، ومصفوفات التصعيد الداخلية، وسجلات جهات الاتصال لدى المورّدين (Microsoft Azure Support، وسطاء تسجيل النطاقات، ومزوّدي SSL).
• (c) جرد الموارد: جرد موثّق لجميع موارد Azure لكل بيئة عميل (الخوادم الافتراضية، مثيلات SQL، حسابات التخزين، مكوّنات الشبكات، أسرار Key Vault)، ويتم حفظه في CMDB والتحقق منه ربع سنويًا.
• (d) إجراءات الموقع البديل: إجراءات خطوة بخطوة لتفعيل منطقة Azure الثانوية، بما في ذلك قوالب البنية التحتية المُعدّة مسبقًا (Azure Resource Manager / Bicep) وبرامج النشر المؤتمتة.
• (e) استمرارية الموردين: تقييم الاعتماديات الحرجة على الأطراف الثالثة (التزامات SLA من Microsoft Azure، ووسطاء تسجيل النطاقات، وسلطات الشهادات) وإجراءات الطوارئ لكل منها.

9.8.3 برنامج تمارين DR

يتعين على المزوّد إجراء تمارين DR منتظمة للتحقق من فعالية خطة BCDR وضمان الجاهزية التشغيلية:

تُوثق جميع نتائج التمارين، وتُحفظ لمدة لا تقل عن ثلاث (3) سنوات، وتُتاح للعميل عند الطلب الخطي. وإذا كشف أي تمرين عن انحراف عن أهداف RPO/RTO المتعاقد عليها، فيتعين على المزوّد تنفيذ الإجراءات التصحيحية خلال ثلاثين (30) يومًا تقويميًا وإعادة التمرين ذي الصلة للتحقق من المعالجة.

9.9 ملكية بيانات العميل وقابليتها للنقل

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

لا تعرف Microsoft، بصفتها مزوّد البنية التحتية الأساسي، نوع البيانات التي يختار العملاء تخزينها في Azure، ولا تدّعي ملكية البيانات على معلومات العميل المدخلة في خدمات Azure.

9.9.1 تصدير البيانات وقابليتها للنقل

يتيح المزوّد بيانات العميل للتصدير على النحو التالي:

• (a) التصدير عند الطلب: يجوز للعميل طلب تصدير كامل أو جزئي لبيانات العميل في أي وقت خلال مدة الاشتراك. وعلى المزوّد تسليم التصدير خلال يومي عمل (2) من استلام طلب خطي صحيح، بصيغة قابلة للقراءة آليًا وبصيغة معيارية في القطاع (ملف نسخ احتياطي SQL أو CSV أو JSON أو XML حسب الاتفاق).
• (b) تصدير عند الإنهاء: عند انتهاء أو إنهاء الإطار، يتيح المزوّد جميع بيانات العميل للتصدير خلال يومي عمل (2) من الطلب الخطي للعميل، وذلك وفقًا لأحكام إعادة البيانات في الفصل 7، §7.13 (إعادة البيانات عند الإنهاء). وتبقى نافذة التصدير العامة مفتوحة لمدة لا تقل عن ستين (60) يومًا تقويميًا من تاريخ سريان الإنهاء.
• (c) تصدير التدقيق والامتثال: يجوز للعميل طلب سجلات التدقيق وسجلات الوصول وسجلات تتبع التغييرات لأغراض الامتثال. وتُقدَّم هذه الصادرات خلال يومي عمل (2) من الطلب الخطي.

9.9.2 إدارة السجلات

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

• (a) سياسات احتفاظ قابلة للتهيئة: تدعم المنصة قواعد احتفاظ بالبيانات قابلة للتهيئة على مستوى التطبيق، بما يتيح للعميل تحديد فترات الاحتفاظ لفئات السجلات المختلفة.
• (b) الحفاظ على أثر التدقيق: توفر سياسات الاحتفاظ في Azure Storage وتتبع التغييرات في SQL Server أثر تدقيق غير قابل للتغيير لجميع تعديلات البيانات. وتُحتفظ سجلات التدقيق لمدة دنيا متفق عليها في العقد التجاري (الافتراضي: سبع سنوات).
• (c) التصدير للأرشفة الخارجية: يجوز للعميل تصدير البيانات وتقارير التدقيق للأرشفة الخارجية في أي وقت خلال مدة الاشتراك. ويقوم المزوّد بتسهيل التصدير بالجملة بالصيَغ القياسية عند الطلب الخطي.

9.9.3 الاكتشاف الإلكتروني (e-Discovery)

يقع على عاتق العميل الالتزام بمتطلبات الاكتشاف الإلكتروني في استخدامه للمنصة. ويدعم المزوّد التزامات الاكتشاف الإلكتروني لدى العميل من خلال:

• (a) أوامر حفظ البيانات: بناءً على طلب خطي من العميل يذكر متطلب أمر حفظ بسبب نزاع قضائي أو تحقيق تنظيمي، يضع المزوّد أمر حفظ على بيانات العميل المحددة، مع تعليق جميع عمليات الحذف الآلي وإنفاذ سياسات الاحتفاظ لمجموعات البيانات المتأثرة.
• (b) تصدير البيانات للاكتشاف الإلكتروني: يتعين على المزوّد تصدير مجموعات البيانات المحددة وتسليمها بصيغة مناسبة لمراجعة الاكتشاف الإلكتروني، بما في ذلك البيانات الوصفية وأثر التدقيق، خلال يومي عمل (2) من طلب أمر الحفظ.
• (c) توثيق سلسلة الحيازة: يقدّم المزوّد توثيق سلسلة الحيازة لجميع صادرات الاكتشاف الإلكتروني، مع التصديق على اكتمال البيانات المصدّرة وسلامتها.

9.10 مرونة منصة Azure

يستفيد المزوّد من قدرات المرونة الأصلية في Azure التالية داخل البيئة السيادية الخاصة المخصّصة لكل عميل:

• (a) مناطق التوافر: حيثما كانت متاحة في منطقة Azure التي اختارها العميل، يتم نشر الموارد الحرجة (الخوادم الافتراضية، الأقراص المُدارة، موازنات التحميل) عبر عدة مناطق توافر للحماية من فشل منطقة واحدة.
• (b) Azure Resource Health: تراقب صحة الخادم الافتراضي وتتحقق مما إذا كانت الموارد تعمل كما هو متوقع، مع اكتشاف مشكلات منصة Azure المعروفة التي تؤثر في الموارد القائمة. وتُوجَّه التنبيهات إلى فريق عمليات السحابة عبر Azure Monitor.
• (c) Azure Backup Vault: إدارة مركزية للنسخ الاحتياطي مع إمكانية الاستعادة عبر المناطق، وحماية الحذف المؤقت (14 يومًا)، وصلاحيات متعددة المستخدمين لعمليات حذف النسخ الاحتياطية الحرجة.
• (d) Azure Resource Locks: يتم تطبيق أقفال CanNotDelete وReadOnly على جميع موارد الإنتاج لمنع الحذف أو التعديل العرضي أو الخبيث لمكوّنات البنية التحتية الحرجة.
• (e) Azure DDoS Protection: يتم تمكين الحماية من DDoS من الطبقة القياسية على جميع الشبكات الافتراضية الخاصة بالعميل، بما يوفر تخفيفًا تلقائيًا للهجمات مع قياس لحظي وتقارير ما بعد الهجوم.
• (f) Azure Key Vault: تُخزن مفاتيح التشفير والأسرار والشهادات في Azure Key Vault مع تمكين الحذف المؤقت والحماية من المسح النهائي، بما يضمن إمكانية استعادة المواد التشفيرية حتى في حالة الحذف العرضي.

نظرة عامة على Azure Availability Zones نظرة عامة على Azure Resource Health بنية Azure Backup

9.11 مسؤوليات العميل

يقر العميل ويوافق على المسؤوليات التالية دعمًا لبرنامج BCDR:

• (a) تعيين جهات الاتصال: يتعين على العميل تعيين والحفاظ على ما لا يقل عن اثنين (2) من جهات الاتصال المخولة للاتصالات المتعلقة بالتعافي من الكوارث، بما في ذلك تفاصيل الاتصال الطارئ خارج ساعات العمل. وتُحدَّث تفاصيل الاتصال خلال خمسة (5) أيام عمل من أي تغيير في الموظفين.
• (b) المشاركة في تمارين DR: يتعين على العميل بذل جهود معقولة للمشاركة في تمارين التحويل السنوية إلى المنطقة الثانوية وفي التمارين المكتبية الفصلية، مع تقديم ملاحظات حول فعالية الاتصال ودقة أثر الأعمال.
• (c) تحديد سياسة الاحتفاظ: يتعين على العميل تحديد متطلبات الاحتفاظ بالبيانات كتابةً أثناء الإعداد وتحديثها حسب الحاجة. ويقوم المزوّد بتهيئة سياسات الاحتفاظ في المنصة وفقًا لذلك.
• (d) التحقق من تصدير البيانات: عقب أي عملية تصدير بيانات، سواء عند الطلب أو عند الإنهاء، يتعين على العميل التحقق من اكتمال البيانات المصدّرة وسلامتها خلال نافذة التحقق المتفق عليها. ويُعد عدم إثارة اعتراض على اكتمال البيانات خلال نافذة التحقق قبولًا للتصدير.
• (e) تخطيط استمرارية المستخدمين النهائيين: يتولى العميل مسؤولية تخطيط استمرارية الأعمال الداخلية الخاصة به، بما في ذلك التواصل مع المستخدمين النهائيين، والبدائل اليدوية للعمليات، والاعتماديات على الأنظمة الداخلية الخارجة عن نطاق المنصة.

9.12 التحسين المستمر

يخضع برنامج BCDR لدى المزوّد لدورة تحسين مستمر متوافقة مع منهجية الخطط والتنفيذ والتحقق والتصرف (PDCA) المنصوص عليها في ISO 22301:2019:

• (a) الخطط: مراجعة سنوية لتحليل أثر الأعمال، ومعايرة أهداف الاستعادة، وتحديث خطة BCDR استنادًا إلى التغييرات في المنصة وقدرات Azure ومتطلبات العميل.
• (b) التنفيذ: تنفيذ جداول النسخ الاحتياطي، وتكوينات النسخ المتماثل، وبرنامج تمارين DR كما هو محدد في هذا الفصل.
• (c) التحقق: مراقبة معدلات نجاح النسخ الاحتياطي، ونتائج تمارين DR (RPO/RTO المقاس مقابل المستهدف)، ومراجعات ما بعد الحوادث، وملاحظات العميل.
• (d) التصرف: تنفيذ الإجراءات التصحيحية، والتحسينات المعمارية، وتحسينات الإجراءات المحددة من خلال مرحلة التحقق. وتُتبع جميع التحسينات في سجل تحسين BCDR ويُبلّغ عنها في اجتماع مراجعة الخدمة الفصلي (انظر الفصل 4، §4.10).

9.13 ضمان البرنامج مدى الحياة

يضمن المزوّد أن المنصة ستظل، طوال المدة الكاملة للاقـتـران بالاشتراك وأي تجديد له (ويُشار إليها بـ"فترة الضمان"):

• (a) الامتثال: تؤدي بصورة جوهرية وفقًا للمواصفات والوظائف ومستويات الخدمة الموصوفة في هذا الإطار والعقد التجاري المعمول به؛
• (b) معالجة العيوب: خالية من العيوب الجوهرية التي تمنع العميل من استخدام المنصة لأغراضه التجارية المقصودة. ويعالج المزوّد أي عيب مؤكد دون أي تكلفة إضافية على العميل ضمن أهداف الاستجابة والمعالجة المنصوص عليها في SLA المعمول به والمحددة في الفصل 3؛
• (c) حداثة الإصدارات: تظل على حزمة تقنية مدعومة ومصانة حاليًا. ويتعين على المزوّد ترقية جميع مكوّنات COTS الأساسية بشكل استباقي (محرك قاعدة البيانات، إطار التطبيق، نظام التشغيل، البرمجيات الوسيطة) إلى الإصدارات المدعومة من المورّد ضمن دورة الإصدار المحددة في القسم 4.7؛
• (d) الصيانة الأمنية: تلقي ترقيعات أمنية مستمرة طوال فترة الضمان، بما في ذلك معالجة الثغرات الحرجة والعالية ضمن الجداول الزمنية المحددة في الفصل 8;
• (e) عدم التدهور: الحفاظ على خصائص الأداء التي تفي بأهداف مستوى الخدمة وأهداف الاستعادة (RPO/RTO) المحددة في هذا الإطار أو تتجاوزها. لا يجوز لمقدم الخدمة إدخال تغييرات تؤدي إلى تدهور جوهري في أداء المنصة دون موافقة العميل. هذا الضمان هو ضمان مدى الحياة ويظل ساريًا طوال مدة الاشتراك النشط للعميل. ولا تنتهي صلاحيته، ولا يضيق نطاقه، ولا يتطلب تجديدًا منفصلًا. ويظل هذا الضمان نافذًا خلال الانتقال بين الإصدارات بموجب الفصل 10 وينطبق على الإصدار اللاحق ابتداءً من تاريخ الإتاحة العامة له.

الاستثناءات: لا يغطي هذا الضمان العيوب الناشئة عن: (i) تعديلات العميل على المنصة خارج عملية إدارة التغيير لدى مقدم الخدمة؛ (ii) استخدام المنصة بطريقة لا تتوافق مع وثائقها؛ (iii) أي برمجيات أو أجهزة تابعة لطرف ثالث غير مقدمة أو معتمدة من مقدم الخدمة؛ أو (iv) أحداث القوة القاهرة.

9.14 إيداع الشفرة المصدرية

لتوفير ضمان استمرارية طويلة الأجل للعميل، يلتزم مقدم الخدمة بالإبقاء على ترتيب إيداع للشفرة المصدرية على النحو الآتي:

9.14.1 الإيداع

• (a) وكيل الإيداع: يلتزم مقدم الخدمة بتعيين وكيل إيداع مستقل وذا سمعة طيبة من طرف ثالث («وكيل الإيداع») للاحتفاظ بالشفرة المصدرية للمنصة. وتُفصح هوية وكيل الإيداع للعميل عند الطلب.
• (b) محتويات الإيداع: يجب أن يتضمن الإيداع ما يلي: (i) الشفرة المصدرية الكاملة للمنصة؛ (ii) نصوص البناء وتعليمات الترجمة البرمجية؛ (iii) مخططات قواعد البيانات ونصوص الترحيل؛ (iv) بيانات اعتماد/جرد التبعيات التابعة لجهات خارجية ووثائق التراخيص؛ (v) وثائق بنية النظام؛ و(vi) إجراءات النشر الكافية لتمكين مختص برمجيات كفؤ من ترجمة المنصة ونشرها وتشغيلها.
• (c) تواتر التحديث: يجب تحديث الإيداع خلال ثلاثين (30) يومًا من كل إصدار رئيسي (Upgrade) وعلى الأقل مرة واحدة كل ربع سنة تقويمي للإصدارات التدريجية (Updates).
• (d) التحقق: يلتزم وكيل الإيداع بإجراء تحقق سنوي من الإيداع للتأكد من اكتماله وإمكانية بنائه. وتُقدَّم شهادة تحقق موجزة للعميل عند الطلب.

9.14.2 شروط الإفراج

يقوم وكيل الإيداع بالإفراج عن الشفرة المصدرية المودعة للعميل عند تحقق أي من شروط الإفراج الآتية:

• (a) الإعسار: دخول مقدم الخدمة في التصفية أو الإدارة القضائية أو الحراسة القضائية أو أي إجراء إعسار مماثل في أي ولاية قضائية؛
• (b) التوقف عن النشاط: توقف مقدم الخدمة عن مباشرة أعماله أو معظمها بصورة جوهرية؛
• (c) الإخلال الجوهري: ارتكاب مقدم الخدمة إخلالًا جوهريًا بهذا الإطار لا تتم معالجته خلال ستين (60) يومًا من تاريخ إخطار العميل الخطي؛
• (d) الإيقاف: إيقاف مقدم الخدمة المنصة نهائيًا دون توفير منتج بديل أو مسار انتقال معقول تجاريًا.

9.14.3 حقوق العميل عند الإفراج

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

9.14.4 التكاليف

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

9.15 الأدوار والمسؤوليات (مصفوفة RACI)

توزع مصفوفة RACI التالية المسؤوليات عن أنشطة استمرارية الأعمال والتعافي من الكوارث الرئيسية بين أدوار مقدم الخدمة والعميل:

المفتاح: R = مسؤول التنفيذ (ينفذ النشاط) · A = معتمد/مسؤول نهائيًا عن القرار · C = يُستشار (يقدم مدخلات قبل القرار) · I = مُبلغ (يُخطر بعد القرار).

9.16 سجل الإجراءات

يسرد سجل الإجراءات التالي جميع العمليات الرسمية المعرفة في هذا الفصل. ويُخصص لكل عملية معرف فريد، وشرط تشغيل، ومسؤول تنفيذ، ومعتمد، ونتيجة متوقعة، وإشارة مرجعية إلى القسم الحاكم.

9.17 مخطط سير الإجراءات

يوضح مسار الحياة المكوّن من تسع مراحل التالي التدفق الشامل لإدارة استمرارية الأعمال والتعافي من الكوارث ضمن برنامج BCDR لدى مقدم الخدمة:

① تحليل أثر الأعمال وتقييم المخاطر → ② تطوير خطة استمرارية الأعمال وخطة DR → ③ النسخ الاحتياطي والتكرار

التهيئة

↓

④ المراقبة والكشف → ⑤ تصنيف الحادث والتصعيد → ⑥ التحويل الفاشل والاستعادة

التنفيذ

↓

⑦ استعادة الخدمة والتحقق → ⑧ مراجعة ما بعد الحادث وPIR → ⑨ التحسين المستمر

وبرنامج التمارين

المرحلة ① تحليل أثر الأعمال وتقييم المخاطر: يحدد تحليل أثر الأعمال السنوي العمليات الحرجة، ويرسم تبعيات المنصة، ويقيس أثر التعطل. وتُعاير ترتيبات أولوية الاستعادة وأهداف RPO/RTO استنادًا إلى مخرجات BIA (P-9.01).

المرحلة ② تطوير خطة استمرارية الأعمال وخطة DR: تُطور أو تُحدّث خطة استمرارية الأعمال وإجراءات DR استنادًا إلى نتائج BIA، مع تضمين تركيبة فريق إدارة الأزمات (CMT)، وقوالب الاتصال، وجرد الموارد، وإجراءات تفعيل المنطقة الثانوية (P-9.02).

المرحلة ③ تهيئة النسخ الاحتياطي والتكرار: تُهيأ جداول النسخ الاحتياطي وسياسات الاحتفاظ وبنية التكرار (LRS/ZRS/GRS/RA-GRS) لكل بيئة عميل. وتُوفَّر نسخ قراءة مكررة محسّنة للتعافي من الكوارث عند اختيارها (P-9.03).

المرحلة ④ المراقبة والكشف: تراقب Azure Monitor وSIEM وResource Health جميع مكونات المنصة باستمرار. ويُتحقق تلقائيًا من اكتمال النسخ الاحتياطي وسلامته مع التنبيه عند الفشل (P-9.04، P-9.05، P-9.06).

المرحلة ⑤ تصنيف الحادث والتصعيد: تُصنف الحوادث المكتشفة (من DR-1 إلى DR-4) وتُصعّد وفق تصنيف الشدة. وتُفعَّل جداول إخطار العميل بناءً على مستوى الشدة (P-9.07، P-9.08).

المرحلة ⑥ تنفيذ التحويل الفاشل والاستعادة: يُنفذ التحويل الفاشل لقاعدة البيانات واستعادة الآلة الافتراضية والتحقق من التطبيق بالتسلسل وفق جدول إجراءات التحويل الفاشل. ويُفعَّل التحويل إلى المنطقة الثانوية في حالات DR-1 عندما تكون المنطقة الأساسية غير قابلة للاستعادة (P-9.09 إلى P-9.11، P-9.14).

المرحلة ⑦ استعادة الخدمة والتحقق: تُعلن الخدمة مستعادة عند اكتمال جميع مراحل الاستعادة. وتُستأنف ساعة SLA وتُحافظ على مراقبة معززة لمدة 72 ساعة. ويُتحقق من تحويل DNS/الشبكة (P-9.12).

المرحلة ⑧ مراجعة ما بعد الحادث وPIR: يُجرى تحليل السبب الجذري خلال 5 أيام عمل. ويُسلم تقرير ما بعد الحادث للعميل متضمنًا الإجراءات التصحيحية وتحديثات خطة BCDR والدروس المستفادة (P-9.13).

المرحلة ⑨ التحسين المستمر وبرنامج التمارين: تُنفذ تمارين DR (مكتبية، أو على مستوى المكون، أو كاملة النطاق، أو إقليمية) وفق البرنامج المجدول. وتؤدي الانحرافات عن أهداف RPO/RTO إلى إجراءات تصحيحية تُتابع في سجل التحسينات. وتعود دورة PDCA إلى المرحلة ① (P-9.15، P-9.18).