توصيات لتصميم استراتيجية الإصلاح بعد كارثة

  • مقالة

ينطبق على توصية قائمة التحقق من موثوقية Azure Well-Architected Framework هذه:

RE:09 تنفيذ خطط استمرارية الأعمال والإصلاح بعد كارثة (BCDR) المنظمة والمختبرة والموثقة التي تتوافق مع أهداف الاسترداد. يجب أن تغطي الخطط جميع المكونات والنظام ككل.

يصف هذا الدليل توصيات لتصميم استراتيجية موثوقة للإصلاح بعد كارثة لحمل العمل. لتحقيق أهداف مستوى الخدمة الداخلية (SLOs) أو حتى اتفاقية مستوى الخدمة (SLA) التي ضمنتها لعملائك، يجب أن يكون لديك استراتيجية قوية وموثوقة للإصلاح بعد كارثة. ومن المتوقع حدوث حالات فشل ومشكلات رئيسية أخرى. تحدد الاستعدادات الخاصة بك للتعامل مع هذه الحوادث مقدار ما يمكن لعملائك الوثوق به في عملك لتقديمه لهم بشكل موثوق. استراتيجية التعافي من الكوارث هي العمود الفقري للتحضير للحوادث الكبرى.

التعريفات

المصطلح التعريف
تجاوز الفشل التحول التلقائي و/أو اليدوي لحركة مرور حمل عمل الإنتاج من منطقة غير متوفرة إلى منطقة جغرافية غير متأثرة.
إرجاع الموارد التحول التلقائي و/أو اليدوي لحركة مرور حمل عمل الإنتاج من منطقة تجاوز الفشل مرة أخرى إلى المنطقة الأساسية.

استراتيجيات التصميم الرئيسية

يفترض هذا الدليل أنك قمت بالفعل بتنفيذ المهام التالية كجزء من تخطيط الموثوقية:

تعتمد استراتيجية الإصلاح بعد كارثة (DR) الموثوق بها على أساس بنية حمل عمل موثوق بها. معالجة الموثوقية في كل مرحلة من مراحل بناء حمل العمل الخاص بك للتأكد من وجود القطع الضرورية للاسترداد الأمثل قبل البدء في تصميم استراتيجية الإصلاح بعد كارثة. يضمن هذا الأساس أن أهداف موثوقية حمل العمل الخاص بك، مثل هدف وقت الاسترداد (RTO) وهدف نقطة الاسترداد (RPO)، واقعية وقابلة للتحقيق.

الحفاظ على خطة الإصلاح بعد كارثة

حجر الزاوية لاستراتيجية الإصلاح بعد كارثة الموثوق بها لحمل العمل هو خطة الإصلاح بعد كارثة. يجب أن تكون خطتك وثيقة حية تتم مراجعتها وتحديثها بشكل روتيني مع تطور بيئتك. تقديم الخطة إلى الفرق المناسبة (العمليات والقيادة التكنولوجية وأصحاب المصلحة في الأعمال) بانتظام (كل ستة أشهر، على سبيل المثال). قم بتخزينه في مخزن بيانات آمن ومتاح للغاية مثل OneDrive for Business.

اتبع هذه التوصيات لتطوير خطة الإصلاح بعد كارثة:

  • حدد بوضوح ما يشكل كارثة، وبالتالي يتطلب تنشيط خطة الإصلاح بعد كارثة.

    • الكوارث هي مشكلات واسعة النطاق. قد تكون انقطاعات إقليمية أو انقطاعات في الخدمات مثل معرف Microsoft Entra أو Azure DNS أو هجمات ضارة شديدة مثل هجمات برامج الفدية الضارة أو هجمات DDoS.

    • حدد أوضاع الفشل التي لا تعتبر كوارث، مثل فشل مورد واحد، بحيث لا يستدعي المشغلون عن طريق الخطأ تصعيدات الإصلاح بعد كارثة الخاصة بهم.

  • إنشاء خطة الإصلاح بعد كارثة على وثائق FMA الخاصة بك. تأكد من أن خطة الإصلاح بعد كارثة تلتقط أوضاع الفشل واستراتيجيات التخفيف من حدة الانقطاعات التي يتم تعريفها على أنها كوارث. قم بتحديث كل من خطة الإصلاح بعد كارثة ومستندات FMA بالتوازي بحيث تكون دقيقة عند تغيير البيئة أو عندما يكشف الاختبار عن سلوكيات غير متوقعة.

    • يعتمد ما إذا كنت تقوم بتطوير خطط الإصلاح بعد كارثة للبيئات غير الإنتاجية على متطلبات عملك وتأثيرات التكلفة. على سبيل المثال، إذا كنت تقدم بيئات ضمان الجودة (QA) لبعض العملاء للاختبار التجريبي، فقد تحتاج إلى تضمين هذه البيئات في تخطيط الإصلاح بعد كارثة.

  • حدد الأدوار والمسؤوليات بوضوح داخل فريق حمل العمل وفهم أي أدوار خارجية ذات صلة داخل مؤسستك. يجب أن تتضمن الأدوار ما يلي:

    • الطرف المسؤول عن الإعلان عن كارثة.

    • الطرف المسؤول عن الإعلان عن إغلاق الحادث.

    • أدوار العمليات.

    • أدوار الاختبار والتحقق من الصحة.

    • أدوار الاتصالات الداخلية والخارجية.

    • الأدوار الرئيسية لتحليل السبب الجذري (RCA) بأثر رجعي.

  • حدد مسارات التصعيد التي يجب أن يتبعها فريق حمل العمل لضمان توصيل حالة الاسترداد إلى أصحاب المصلحة.

  • التقاط إجراءات الاسترداد على مستوى المكون والاسترداد على مستوى ملكية البيانات وعمليات الاسترداد على مستوى حمل العمل. قم بتضمين ترتيب محدد للعمليات لضمان استرداد المكونات بأقل طريقة مؤثرة. على سبيل المثال، استرداد قواعد البيانات والتحقق منها قبل استرداد التطبيق.

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

    • حدد مسؤوليات فريقك مقابل مسؤوليات موفر استضافة السحابة. على سبيل المثال، تتحمل Microsoft مسؤولية استعادة PaaS (النظام الأساسي كخدمة)، ولكنك مسؤول عن إعادة تحميل البيانات وتطبيق التكوين الخاص بك على الخدمة.

    • قم بتضمين المتطلبات الأساسية لتشغيل الإجراء. على سبيل المثال، قم بإدراج البرامج النصية أو بيانات الاعتماد المطلوبة التي يجب جمعها.

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

  • اعتمادا على تصميم التكرار لحمل العمل الخاص بك، قد تحتاج إلى القيام بعمل كبير بعد تجاوز الفشل قبل إتاحة حمل العمل لعملائك مرة أخرى. يمكن أن يتضمن عمل ما بعد تجاوز الفشل تحديثات DNS وتحديثات سلسلة الاتصال قاعدة البيانات وتغييرات توجيه نسبة استخدام الشبكة. التقط جميع أعمال ما بعد تجاوز الفشل في إجراءات الاسترداد الخاصة بك.

    ملاحظة

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

  • إذا كنت بحاجة إلى إعادة توزيع تطبيقك في بيئة تجاوز الفشل، فاستخدم الأدوات لأتمتة عملية النشر قدر الإمكان. تأكد من أن مسارات DevOps الخاصة بك قد تم توزيعها مسبقا وتكوينها في بيئات تجاوز الفشل بحيث يمكنك بدء عمليات توزيع التطبيق على الفور. استخدم عمليات التوزيع التلقائية الشاملة، مع بوابات الموافقة اليدوية عند الضرورة، لضمان عملية توزيع متسقة وفعالة. يجب أن تتوافق مدة النشر الكاملة مع أهداف الاسترداد الخاصة بك.

    • عندما تتطلب مرحلة من مراحل عملية النشر تدخلا يدويا، قم بوثيق الخطوات اليدوية. تحديد الأدوار والمسؤوليات بوضوح.

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

    ملاحظة

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

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

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

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

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

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

اتبع هذه التوصيات لإجراء تدريبات الإصلاح بعد كارثة الناجحة:

  • إجراء تدريب واحد على الأقل على الإصلاح بعد كارثة للإنتاج في السنة. تساعد تدريبات Tabletop (التشغيل الجاف) أو التدريبات غير الإنتاجية على ضمان أن الأطراف المعنية على دراية بأدوارها ومسؤولياتها. تساعد هذه التدريبات أيضا المشغلين على بناء الإلمام ("ذاكرة العضلات") باتباع عمليات الاسترداد. ولكن تدريبات الإنتاج فقط هي التي تختبر حقا صحة خطة الإصلاح بعد كارثة ومقاييس RTO وRPO. استخدم تدريبات الإنتاج الخاصة بك لعمليات استرداد الوقت للمكونات والتدفقات للتأكد من أن أهداف RTO وRPO التي تم تحديدها لحمل العمل الخاص بك قابلة للتحقيق. بالنسبة للدالات الخارجة عن سيطرتك، مثل نشر DNS، تأكد من أن أهداف RTO وRPO للتدفقات التي تتضمن تلك الوظائف حساب التأخيرات المحتملة خارج نطاق سيطرتك.

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

الاعتبارات

  • يمكن أن يؤدي إجراء تدريبات الإصلاح بعد كارثة في الإنتاج إلى فشل كارثي غير متوقع. تأكد من اختبار إجراءات الاسترداد في البيئات غير الإنتاجية أثناء عمليات التوزيع الأولية.

  • امنح فريقك أكبر قدر ممكن من وقت الصيانة أثناء التدريبات. عند التخطيط لوقت الصيانة، استخدم مقاييس الاسترداد التي تلتقطها أثناء الاختبار كحد أدنى من المخصصات اللازمة للوقت .

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

تسهيل Azure

تحتوي العديد من منتجات Azure على قدرات تجاوز الفشل المضمنة. تعرف على هذه الإمكانات وقم بتضمينها في إجراءات الاسترداد.

بالنسبة لأنظمة IaaS (البنية الأساسية كخدمة)، استخدم Azure Site Recovery لأتمتة تجاوز الفشل والاسترداد. راجع المقالات التالية لمنتجات PaaS الشائعة:

مثال

راجع DR لسلسلة النظام الأساسي لبيانات Azure للحصول على إرشادات حول إعداد ملكية بيانات المؤسسة للإصلاح بعد كارثة.

قائمة التحقق من الموثوقية

راجع المجموعة الكاملة من التوصيات.

قائمة التحقق من الموثوقية