إدارة استمرارية الأعمال في Azure

  • مقالة

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

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

An image describing how elements such as people (those who work on the service and are required to support it), process (any process to do tasks that support the service), and technology (the technology used to deliver the service or the technology provided as the service itself) combine to create a service that benefits a cloud user.

على سبيل المثال:

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

نموذج المسؤولية المشتركة

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

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

تقسيم المسؤولية

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

A visual showing what responsibilities belong to the cloud customer versus the cloud provider.

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

تحتوي جميع خدمات التعافي من الكوارث التي يدعمها العميل على وثائق عامة لإرشادك. للحصول على مثال للوثائق العامة لاسترداد البيانات بعد عطل فادح ممكن من قبل العميل، راجع Azure Data Lake Analytics.

لمزيد من المعلومات حول نموذج المسؤولية المشتركة، راجع مركز توثيق Microsoft.

التوافق مع استمرارية الأعمال: مسؤولية مستوى الخدمة

كل خدمة مطلوبة لإكمال سجلات التعافي من الكوارث لاستمرارية الأعمال في أداة Azure Business Continuity Manager. يمكن لمالكي الخدمة استخدام الأداة للعمل ضمن نموذج متحد لإكمال ودمج المتطلبات التي تتضمن:

  • خصائص الخدمة: تحدد الخدمة وكيفية تحقيق التعافي من الكوارث والمرونة وتحدد الطرف المسؤول عن التعافي من الكوارث (للتكنولوجيا). للحصول على تفاصيل حول ملكية الاسترداد، راجع المناقشة حول نموذج المسؤولية المشتركة في القسم والرسم التخطيطي السابقين.

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

    إشعار

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

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

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

  • الموردين الخارجيين: تحتفظ Microsoft بقائمة شاملة من الموردين الخارجيين، ويتم قياس الموردين الذين يعتبرون مهمين للقدرات. إذا تم تحديدها بواسطة خدمة على أنها تبعية، تتم مقارنة قدرات المورد باحتياجات الخدمة لضمان عدم تعطيل انقطاع الخدمة من جهة خارجية لخدمات Azure.

  • تصنيف الاسترداد: هذا التصنيف فريد من نوعه لبرنامج Azure Business Continuity Management. يقيس هذا التصنيف عدة عناصر رئيسية لإنشاء درجة مرونة:

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

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

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

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

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

التحقق من توافق استمرارية الأعمال

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

اختبار الخدمات

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

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

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

تتضمن هذه الاختبارات الخدمات التي تكون فيها مسؤولا عن إعداد التعافي من الكوارث بعد وثائق Microsoft العامة. تنشئ فرق الخدمة مثيلات تشبه العملاء لإظهار أن التعافي من الكوارث الذي يدعمه العميل يعمل كما هو متوقع وأن الإرشادات المقدمة دقيقة.

لمزيد من المعلومات حول الشهادات، راجع مركز توثيق Microsoft وقسم التوافق.

الخطوات التالية