أنشطة العملاء المطلوبة
ما قبل الحدث
لخدمات Azure
- كن على دراية ب Azure Service Health في مدخل Microsoft Azure. ستكون هذه الصفحة بمثابة "متجر واحد" أثناء وقوع حادث
- ضع في اعتبارك استخدام تنبيهات حالة الخدمة، والتي يمكن تكوينها لإنتاج إعلامات تلقائيا عند حدوث حوادث Azure
ل Power BI
- كن على دراية بصحة الخدمة في مركز مسؤولي Microsoft 365. ستكون هذه الصفحة بمثابة "متجر واحد" أثناء وقوع حادث
- ضع في اعتبارك استخدام تطبيق الأجهزة المحمولة مسؤول Microsoft 365 للحصول على إعلامات تنبيه تلقائي لحوادث الخدمة
أثناء الحادث
لخدمات Azure
- ستوفر Azure Service Health داخل مدخل إدارة Azure آخر التحديثات
- إذا كانت هناك مشكلات في الوصول إلى حالة الخدمة، فراجع صفحة حالة Azure
- إذا كانت هناك مشكلات في الوصول إلى صفحة الحالة، فانتقل إلى @AzureSupport على X (المعروف سابقا ب Twitter)
- إذا لم يتطابق التأثير/المشكلات مع الحدث (أو استمرت بعد التخفيف)، فاتصل بالدعم لرفع تذكرة دعم الخدمة
ل Power BI
- ستوفر صفحة Service Health ضمن مركز مسؤولي Microsoft 365 آخر التحديثات
- إذا كانت هناك مشكلات في الوصول إلى حالة الخدمة، فراجع صفحة حالة Microsoft 365
- إذا لم يتطابق التأثير/المشكلات مع الحدث (أو إذا استمرت المشكلات بعد التخفيف)، فيجب عليك رفع تذكرة دعم الخدمة.
بعد استرداد Microsoft
راجع الأقسام أدناه للحصول على هذه التفاصيل.
نشر الحدث
لخدمات Azure
- ستقوم Microsoft بنشر PIR إلى مدخل Microsoft Azure - حالة الخدمة للمراجعة
ل Power BI
- ستقوم Microsoft بنشر PIR إلى مسؤول Microsoft 365 - حالة الخدمة للمراجعة
انتظر عملية Microsoft
تنتظر عملية "انتظار Microsoft" ببساطة حتى تقوم Microsoft باسترداد جميع المكونات والخدمات في المنطقة الأساسية المتأثرة. بمجرد الاسترداد، تحقق من ربط النظام الأساسي للبيانات بالخدمات المشتركة للمؤسسة أو الخدمات الأخرى، وتاريخ مجموعة البيانات، ثم قم بتنفيذ عمليات إحضار النظام إلى التاريخ الحالي.
بمجرد الانتهاء من هذه العملية، يمكن إكمال التحقق من صحة الشركات الصغيرة والمتوسطة الحجم التقنية والتجارية لتمكين موافقة المساهمين على استرداد الخدمة.
إعادة النشر عند حدوث كارثة
بالنسبة لاستراتيجية "إعادة التوزيع في حالات الكوارث"، يمكن وصف تدفق العملية عالية المستوى التالي.
استرداد Contoso – الخدمات المشتركة للمؤسسات وأنظمة المصدر
- هذه الخطوة هي شرط أساسي لاستعادة النظام الأساسي للبيانات
- ستنجز هذه الخطوة مختلف مجموعات الدعم التشغيلي لشركات Contoso المسؤولة عن الخدمات المشتركة للمؤسسة وأنظمة المصادر التشغيلية
استرداد خدمات Azure تشير خدمات Azure إلى التطبيقات والخدمات التي تجعل عرض Azure Cloud متوفرا داخل المنطقة الثانوية للنشر.
تشير خدمات Azure إلى التطبيقات والخدمات التي تجعل عرض Azure Cloud متاحا داخل المنطقة الثانوية للنشر.
- هذه الخطوة هي شرط أساسي لاستعادة النظام الأساسي للبيانات
- سيتم إكمال هذه الخطوة من قبل Microsoft وشركاء PaaS/SaaS الآخرين
استرداد أساس النظام الأساسي للبيانات
- هذه الخطوة هي نقطة الإدخال لأنشطة استرداد النظام الأساسي
- وبالنسبة لاستراتيجية إعادة التوزيع، سيتم شراء كل مكون/خدمة مطلوبة ونشرها في المنطقة الثانوية
- راجع قسم خدمة ومكون Azure في هذه السلسلة للحصول على تصنيف تفصيلي للمكونات واستراتيجيات التوزيع
- يجب أن تتضمن هذه العملية أيضا أنشطة مثل الربط بالخدمات المشتركة للمؤسسة، وضمان الاتصال بالوصول/المصادقة، والتحقق من أن تفريغ السجل يعمل، مع ضمان الاتصال بكل من عمليات المصدر والمصب
- يجب تأكيد البيانات/المعالجة. على سبيل المثال، التحقق من الطابع الزمني للنظام الأساسي المسترد
- إذا كانت هناك أسئلة حول تكامل البيانات، يمكن اتخاذ قرار بالتراجع أكثر في الوقت المناسب قبل تنفيذ المعالجة الجديدة لتحديث النظام الأساسي
- إن وجود ترتيب أولوية للعمليات (استنادا إلى تأثير الأعمال) سيساعد في تنظيم الاسترداد
- يجب إغلاق هذه الخطوة من خلال التحقق التقني ما لم يتفاعل مستخدمو الأعمال مباشرة مع الخدمات. إذا كان هناك وصول مباشر، فستحتاج إلى خطوة التحقق من صحة الأعمال
- بمجرد اكتمال التحقق من الصحة، يحدث تسليم إلى فرق الحلول الفردية لبدء عملية استرداد DR الخاصة بها
- يجب أن يتضمن هذا التسليم تأكيد الطابع الزمني الحالي للبيانات/العمليات
- إذا كان سيتم تنفيذ عمليات بيانات المؤسسة الأساسية، يجب توعية الحلول الفردية بهذا - التدفقات الواردة/الصادرة، على سبيل المثال
استرداد الحلول الفردية التي تستضيفها المنصة
- يجب أن يكون لكل حل فردي دفتر تشغيل DR الخاص به. يجب أن تحتوي دفاتر التشغيل على الأقل على أصحاب المصلحة التجاريين المرشحين الذين سيختبرون ويتأكدون من اكتمال استرداد الخدمة
- اعتمادا على خلاف الموارد أو الأولوية، قد يتم إعطاء الأولوية للحلول/أحمال العمل الرئيسية على غيرها - عمليات المؤسسة الأساسية عبر المختبرات المخصصة، على سبيل المثال
- بمجرد اكتمال خطوات التحقق من الصحة، يحدث تسليم إلى حلول انتقال البيانات من الخادم لبدء عملية استرداد الإصلاح بعد الكارثة
التسليم إلى أنظمة انتقال البيانات من الخادم والأنظمة التابعة
- بمجرد استرداد الخدمات التابعة، تكتمل عملية استرداد E2E DR
إشعار
في حين أنه من الممكن نظريا أتمتة عملية E2E DR بالكامل، إلا أنه من غير المحتمل نظرا لمخاطر الحدث مقابل تكلفة أنشطة SDLC المطلوبة لتغطية عملية E2E
العودة إلى المنطقة الأساسية الاحتياطية هي عملية نقل خدمة النظام الأساسي للبيانات وبياناتها مرة أخرى إلى المنطقة الأساسية، بمجرد أن تكون متاحة ل BAU.
واستنادا إلى طبيعة نظم المصدر ومختلف عمليات البيانات، يمكن إجراء النسخ الاحتياطي للنظام الأساسي للبيانات بشكل مستقل عن أجزاء أخرى من النظام الإيكولوجي للبيانات.
ينصح العملاء بمراجعة تبعيات النظام الأساسي للبيانات الخاصة بهم (في المنبع والمصب على حد سواء) لاتخاذ القرار المناسب. يفترض القسم التالي استردادا مستقلا للنظام الأساسي للبيانات.
- بمجرد أن تصبح جميع المكونات/الخدمات المطلوبة متاحة في المنطقة الأساسية، سيكمل العملاء اختبار الدخان للتحقق من صحة استرداد Microsoft
- سيتم التحقق من صحة تكوين المكون/الخدمة. ستتم معالجة دلتا عن طريق إعادة التوزيع من التحكم بالمصادر
- سيتم تحديد تاريخ النظام في المنطقة الأساسية عبر المكونات ذات الحالة. يجب معالجة دلتا بين تاريخ الترسيخ والطوابع الزمنية في المنطقة الثانوية عن طريق إعادة تنفيذ أو إعادة تشغيل عمليات استيعاب البيانات من تلك النقطة إلى الأمام
- وبموافقة كل من أصحاب المصلحة التجاريين والتقنيين، سيتم تحديد نافذة احتياطية. من الناحية المثالية، خلال فترة هدوء في نشاط النظام ومعالجته
- أثناء العودة إلى الحالة الاحتياطية، ستتم مزامنة المنطقة الأساسية مع المنطقة الثانوية، قبل تبديل النظام
- بعد فترة تشغيل موازية، سيتم نقل المنطقة الثانوية دون اتصال من النظام
- سيتم إما إسقاط المكونات في المنطقة الثانوية أو تجريدها مرة أخرى، اعتمادا على استراتيجية الإصلاح بعد الكوارث المحددة
عملية احتياطية دافئة
وفيما يتعلق باستراتيجية "الاحتياطي الدافئ"، فإن تدفق العمليات رفيع المستوى يتماشى بشكل وثيق مع تدفق "إعادة التوزيع عند وقوع الكوارث"، والفرق الرئيسي هو أن المكونات قد تم شراؤها بالفعل في المنطقة الثانوية. تلغي هذه الاستراتيجية مخاطر التنازع على الموارد من المؤسسات الأخرى التي تتطلع إلى إكمال الإصلاح بعد الكوارث في تلك المنطقة.
عملية احتياطية ساخنة
تعني استراتيجية "قطع الغيار السريع" أن خدمات النظام الأساسي بما في ذلك أنظمة PaaS وIaaS ستستمر على الرغم من وقوع الكارثة مع تشغيل الأنظمة الثانوية جنبا إلى جنب مع الأنظمة الأساسية. كما هو الحال مع استراتيجية "الاحتياطي الدافئ"، فإن هذه الاستراتيجية تلغي خطر الخلاف على الموارد من المؤسسات الأخرى التي تتطلع إلى إكمال الإصلاح بعد الكوارث الخاصة بها في تلك المنطقة.
سيقوم عملاء Hot Spare بمراقبة استرداد Microsoft للمكونات/الخدمات في المنطقة الأساسية. بمجرد الانتهاء، سيقوم العملاء بالتحقق من صحة أنظمة المنطقة الأساسية وإكمال العودة إلى المنطقة الأساسية. ستكون هذه العملية مشابهة لعملية تجاوز الفشل DR أي التحقق من قاعدة التعليمات البرمجية والبيانات المتوفرة وإعادة التوزيع كما هو مطلوب.
إشعار
وينبغي ملاحظة خاصة هنا لضمان اتساق أي بيانات تعريف للنظام بين المنطقتين.
- بمجرد اكتمال الرجوع إلى الأساسي، يمكن تحديث موازنات تحميل النظام لإعادة المنطقة الأساسية إلى طبولوجيا النظام. إذا كان متوفرا، يمكن استخدام نهج إصدار الكناري لتشغيل المنطقة الأساسية للنظام بشكل متزايد.
بنية خطة الإصلاح بعد الكوارث
تقدم خطة الإصلاح بعد الكوارث الفعالة دليلا خطوة بخطوة لاسترداد الخدمة يمكن تنفيذه بواسطة مورد تقني Azure. على هذا النحو، يسرد التالي بنية MVP مقترحة لخطة الإصلاح بعد الكوارث.
- متطلبات العملية
- أي تفاصيل خاصة بعملية الاسترداد بعد الكوارث للعميل، مثل التخويل الصحيح المطلوب لبدء الاسترداد بعد الكوارث، واتخاذ القرارات الرئيسية حول الاسترداد حسب الضرورة (بما في ذلك "تعريف تم")، وخدمة دعم مرجع تذاكر DR، وتفاصيل غرفة الحرب
- تأكيد المورد، بما في ذلك العميل المتوقع DR والنسخ الاحتياطي للمنفذ. يجب توثيق جميع الموارد مع جهات الاتصال الأساسية والثانوية ومسارات التصعيد وترك التقويمات. في حالات الإصلاح بعد الكوارث الحرجة، قد تحتاج أنظمة القوائم إلى النظر فيها
- الكمبيوتر المحمول وحزم الطاقة و/أو طاقة النسخ الاحتياطي واتصال الشبكة وتفاصيل الهاتف المحمول لمنفذ DR والنسخ الاحتياطي DR وأي نقاط تصعيد
- العملية التي يجب اتباعها إذا لم يتم استيفاء أي من متطلبات العملية
- قائمة جهات الاتصال
- مجموعات دعم وقيادة الإصلاح بعد الكوارث
- الشركات الصغيرة والمتوسطة التي ستستكمل دورة الاختبار/المراجعة للتعافي التقني
- مالكو الأعمال المتأثرون، بما في ذلك موافقو استرداد الخدمة
- المالكون الفنيون المتأثرون، بما في ذلك الموافقون على الاسترداد التقني
- دعم الشركات الصغيرة والمتوسطة في جميع المجالات المتأثرة، بما في ذلك الحلول الرئيسية التي تستضيفها المنصة
- التأثير على أنظمة انتقال البيانات من الخادم - الدعم التشغيلي
- أنظمة المصدر المصدر - الدعم التشغيلي
- جهات اتصال الخدمات المشتركة للمؤسسة. على سبيل المثال، دعم الوصول/المصادقة ومراقبة الأمان ودعم البوابة
- أي مورد خارجي أو خارجي، بما في ذلك جهات اتصال الدعم لموفري السحابة
- تصميم البنية
- وصف تفاصيل سيناريو النهاية إلى E2E، وإرفاق جميع وثائق الدعم المقترنة
- التبعيات
- سرد جميع علاقات المكون وتبعياته
- متطلبات الإصلاح بعد الكوارث
- تأكيد توفر أنظمة المصدر حسب الحاجة
- تم منح وصول مرتفع عبر المكدس إلى موارد منفذ DR
- تتوفر خدمات Azure كما هو مطلوب
- العملية التي يجب اتباعها إذا لم يتم استيفاء أي من المتطلبات الأساسية
- الاسترداد التقني - إرشادات خطوة بخطوة
- ترتيب التشغيل
- وصف الخطوة
- المتطلبات الأساسية للخطوة
- خطوات عملية مفصلة لكل إجراء منفصل، بما في ذلك عنوان URL
- إرشادات التحقق من الصحة، بما في ذلك الأدلة المطلوبة
- الوقت المتوقع لإكمال كل خطوة، بما في ذلك الطوارئ
- العملية التي سيتم اتباعها إذا فشلت الخطوة
- نقاط التصعيد في حالة الفشل أو دعم الشركات الصغيرة والمتوسطة
- الاسترداد التقني - متطلبات النشر
- تأكيد الطابع الزمني للتاريخ الحالي للنظام عبر المكونات الرئيسية
- تأكيد عناوين URL لنظام التعافي من الكوارث وعناوين IP
- الاستعداد لعملية مراجعة أصحاب المصلحة في الأعمال، بما في ذلك تأكيد الوصول إلى الأنظمة وإكمال الشركات الصغيرة والمتوسطة للتحقق من الصحة والموافقة
- مراجعة أصحاب المصلحة في الأعمال والموافقة عليها
- تفاصيل جهة اتصال مورد الأعمال
- خطوات التحقق من صحة الأعمال وفقا للاسترداد التقني أعلاه
- مسار الأدلة المطلوب من موافقة العمل على تسجيل الخروج من الاسترداد
- متطلبات نشر الاسترداد
- التسليم إلى الدعم التشغيلي لتنفيذ عمليات البيانات لتحديث النظام
- تسليم عمليات وحلول انتقال البيانات من الخادم - تأكيد تفاصيل التاريخ والاتصال لنظام الإصلاح بعد الكوارث
- تأكيد اكتمال عملية الاسترداد مع عميل التعافي من الكوارث - تأكيد مسار الأدلة ودفتر التشغيل المكتمل
- إعلام إدارة الأمان بأنه يمكن إزالة امتيازات الوصول المرتفعة من فريق الإصلاح بعد الكوارث
الشرح
- يوصى بتضمين لقطات شاشة للنظام لكل عملية خطوة. ستساعد لقطات الشاشة هذه في معالجة التبعية على المؤسسات الصغيرة والمتوسطة الحجم للنظام لإكمال المهام
- للتخفيف من المخاطر الناجمة عن الخدمات السحابية المتطورة بسرعة، يجب إعادة النظر في خطة الاسترداد بعد الكوارث بانتظام واختبارها وتنفيذها بواسطة الموارد ذات المعرفة الحالية ب Azure وخدماتها
- وينبغي أن تعكس خطوات الاسترداد التقني أولوية المكون والحل للمنظمة. على سبيل المثال، يتم استرداد تدفقات بيانات المؤسسة الأساسية قبل مختبرات تحليل البيانات المخصصة
- يجب أن تتبع خطوات الاسترداد التقني ترتيب مهام سير العمل (عادة من اليسار إلى اليمين)، بمجرد استرداد المكونات/الخدمة الأساسية مثل Key Vault. ستضمن هذه الاستراتيجية توفر تبعيات المصدر ويمكن اختبار المكونات بشكل مناسب
- وبمجرد الانتهاء من الخطة المفصلة خطوة بخطوة، ينبغي الحصول على الوقت الإجمالي للأنشطة ذات الطوارئ. إذا كان هذا الإجمالي فوق RTO المتفق عليه، فهناك العديد من الخيارات المتاحة:
- أتمتة عمليات الاسترداد المحددة (حيثما أمكن)
- ابحث عن فرص لتشغيل خطوات الاسترداد المحددة بالتوازي (حيثما أمكن). ومع ذلك، لاحظ أن هذه الاستراتيجية قد تتطلب موارد إضافية لمنفذ DR.
- رفع المكونات الرئيسية إلى مستويات أعلى من مستويات الخدمة مثل PaaS، حيث تتحمل Microsoft مسؤولية أكبر عن أنشطة استرداد الخدمة
- توسيع RTO مع أصحاب المصلحة
اختبار الإصلاح بعد الكوارث
تؤدي طبيعة خدمة Azure Cloud التي تقدم إلى قيود لأي سيناريوهات اختبار DR. لذلك، فإن التوجيه هو الوقوف في اشتراك DR مع مكونات النظام الأساسي للبيانات كما ستكون متاحة في المنطقة الثانوية.
من هذا الأساس، يمكن تنفيذ دفتر تشغيل خطة DR بشكل انتقائي، مع إيلاء اهتمام خاص للخدمات والمكونات التي يمكن نشرها والتحقق من صحتها. ستتطلب هذه العملية مجموعة بيانات اختبار منسقة، مما يتيح تأكيد عمليات التحقق من صحة التقنية والأعمال وفقا للخطة.
يجب اختبار خطة الإصلاح بعد الكارثة بانتظام ليس فقط للتأكد من أنها محدثة، ولكن أيضا لبناء "ذاكرة العضلات" للفرق التي تقوم بأنشطة تجاوز الفشل والاسترداد.
- يجب أيضا اختبار النسخ الاحتياطية للبيانات والتكوين بانتظام للتأكد من أنها "مناسبة للغرض" لدعم أي أنشطة استرداد.
المجال الرئيسي الذي يجب التركيز عليه أثناء اختبار الإصلاح بعد الكوارث هو التأكد من أن الخطوات الوصفية لا تزال صحيحة وأن التوقيتات المقدرة لا تزال ذات صلة.
- إذا كانت الإرشادات تعكس شاشات المدخل بدلا من التعليمات البرمجية - يجب التحقق من صحة الإرشادات كل 12 شهرا على الأقل بسبب إيقاع التغيير في السحابة.
في حين أن الطموح هو أن يكون لديك عملية DR مؤتمتة بالكامل، قد يكون من غير المحتمل أن تكون الأتمتة الكاملة بسبب ندرة الحدث. لذلك، يوصى بإنشاء أساس الاسترداد باستخدام DSC IaC المستخدم لتقديم النظام الأساسي ثم رفع مستوى المشاريع الجديدة بناء على الأساس.
- مع مرور الوقت مع تمديد المكونات والخدمات، يجب فرض NFR، ما يتطلب إعادة بناء التعليمات البرمجية لمسار توزيع الإنتاج لتوفير تغطية الإصلاح بعد الكوارث.
إذا تجاوزت توقيتات دفتر التشغيل RTO الخاص بك، فهناك العديد من الخيارات:
- توسيع RTO مع أصحاب المصلحة
- تقليل الوقت المطلوب لأنشطة الاسترداد، عبر الأتمتة، أو تشغيل المهام بالتوازي أو الترحيل إلى مستويات خادم سحابية أعلى
Azure Chaos Studio
Azure Chaos Studio هي خدمة مدارة لتحسين المرونة عن طريق إدخال الأخطاء في تطبيقات Azure. يمكنك Chaos Studio من تنسيق إدخال الخطأ على موارد Azure بطريقة آمنة ومتحكم بها، باستخدام التجارب. راجع وثائق المنتج للحصول على وصف أنواع الأخطاء المدعومة حاليا.
لا يغطي التكرار الحالي ل Chaos Studio سوى مجموعة فرعية من مكونات وخدمات Azure. حتى تتم إضافة المزيد من مكتبات الأخطاء، يعد Chaos Studio نهجا موصى به لاختبار المرونة المعزول بدلا من اختبار الإصلاح بعد الكوارث للنظام الكامل.
يمكن العثور على مزيد من المعلومات حول Chaos studio هنا
استرداد موقع Azure
بالنسبة لمكونات IaaS، سيحمي Azure Site Recovery معظم أحمال العمل التي تعمل على جهاز ظاهري مدعوم أو خادم فعلي
هناك إرشادات قوية ل:
- تنفيذ Azure VM Disaster Recovery Drill
- تنفيذ تجاوز فشل DR إلى منطقة ثانوية
- تنفيذ احتياطي DR إلى المنطقة الأساسية
- تمكين أتمتة خطة الإصلاح بعد الكوارث
الموارد ذات الصلة
- التصميم للمرونة والتوافر
- استمرارية العمل والإصلاح بعد الكارثة
- النسخ الاحتياطي والتعافي من الكوارث لتطبيقات Azure
- المرونة في Azure
- ملخص اتفاقيات مستوى الخدمة
- خمس أفضل الممارسات لتوقع الفشل
الخطوات التالية
الآن بعد أن تعلمت كيفية نشر السيناريو، يمكنك قراءة ملخص DR لسلسلة النظام الأساسي لبيانات Azure.