مشاركة عبر

ما هي استمرارية الأعمال، وقابلية الوصول العالية، والتعافي من الكوارث؟

  • مقالة

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

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

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

تتعلق قابلية الوصول العالية بتصميم حل ليكون مرنا للمشكلات اليومية ولتلبية احتياجات الأعمال للتوفر.

يتعلق التعافي من الكوارث بالتخطيط لكيفية التعامل مع المخاطر غير الشائعة وانقطاعات الكوارث التي يمكن أن تنتج.

استمرارية الأعمال

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

يمكن أن تشمل الآثار الشديدة على استمرارية الأعمال ما يلي:

  • فقدان دخل الأعمال.
  • عدم القدرة على توفير خدمة مهمة للمستخدمين.
  • خرق الالتزام الذي تم إجراؤه لعميل أو جهة أخرى.

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

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

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

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

يجب أن يتضمن تخطيط استمرارية الأعمال الخطوات المتسلسلة التالية:

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

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

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

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

تحديد المخاطر

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

الجدول التالي هو قائمة غير شاملة من المخاطر، مرتبة عن طريق تقليل احتمالية:

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

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

إليك بعض الأمثلة:

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

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

تصنيف المخاطر

يجب أن تعالج خطط استمرارية الأعمال كلا من المخاطر الشائعة وغير الشائعة.

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

    يجب مراعاة استراتيجية قابلية الوصول العالية والتحكم في كل خطر من هذا النوع.

  • عادة ما تكون المخاطر غير الشائعة نتيجة لحدث غير متوقع، مثل كارثة طبيعية أو هجوم كبير على الشبكة، يمكن أن يؤدي إلى انقطاع كارثي.

    تتعامل عمليات التعافي من الكوارث مع هذه المخاطر النادرة.

التوفر العالي والتعافي من الكوارث مترابطان، لذلك من المهم تخطيط استراتيجيات لكليهما معا.

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

تخفيف المخاطر

يتكون التخفيف من المخاطر من تطوير استراتيجيات ل HA أو DR لتقليل المخاطر على استمرارية الأعمال أو التخفيف منها. يمكن أن يكون التخفيف من المخاطر مستندا إلى التكنولوجيا أو مستندا إلى الإنسان.

التخفيف من المخاطر المستندة إلى التكنولوجيا

يستخدم التخفيف من المخاطر المستندة إلى التكنولوجيا عناصر التحكم في المخاطر التي تستند إلى كيفية تنفيذ حمل العمل وتكوينه، مثل:

  • التكرار
  • النسخ المتماثل البيانات
  • تجاوز الفشل
  • نسخ احتياطية

يجب النظر في ضوابط المخاطر القائمة على التكنولوجيا داخل سياق خطة استمرارية الأعمال.

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

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

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

التخفيف من المخاطر المستندة إلى الإنسان

يستخدم التخفيف من المخاطر المستندة إلى الإنسان عناصر التحكم في المخاطر التي تستند إلى العمليات التجارية، مثل:

  • تشغيل دليل مبادئ الاستجابة.
  • الرجوع إلى العمليات اليدوية.
  • التدريب والتغيرات الثقافية.

هام

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

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

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

التوافر العالي

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

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

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

  • يسمح شرط وقت التشغيل بنسبة 99.9٪ (ثلاث تسعات) بحوالي 43 دقيقة من وقت التعطل في الشهر.
  • يسمح شرط وقت التشغيل بنسبة 99.95٪ (ثلاث تسعات ونصف) بحوالي 21 دقيقة من وقت التعطل في الشهر.

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

هام

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

عناصر تصميم قابلية وصول عالية

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

إشعار

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

خدمات Azure والمستويات التي تدعم قابلية الوصول العالية

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

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

استخدم كل دليل موثوقية الخدمة لفهم قدرات الخدمة، وتحديد المستويات التي يجب استخدامها، وتحديد القدرات التي يجب تضمينها في استراتيجية قابلية الوصول العالية.

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

التسامح مع الخطأ

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

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

التكرار

التكرار هو ممارسة تكرار المثيلات أو البيانات لزيادة موثوقية حمل العمل.

يمكن تحقيق التكرار عن طريق توزيع النسخ المتماثلة أو المثيلات المكررة في واحد أكثر من كل الطرق التالية:

  • داخل مركز بيانات (التكرار المحلي)
  • بين مناطق التوفر داخل منطقة (تكرار المنطقة)
  • عبر المناطق (التكرار الجغرافي).

فيما يلي بعض الأمثلة على كيفية توفير بعض خدمات Azure لخيارات التكرار:

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

لمعرفة المزيد حول التكرار، راجع توصيات التصميم للتكرار وتوصيات لاستخدام مناطق التوفر والمناطق.

قابلية التوسع والمرونة

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

تدعم العديد من خدمات Azure قابلية التوسع. إليك بعض الأمثلة:

  • تدعم Azure Virtual Machine Scale Sets وAzure API Management والعديد من الخدمات الأخرى التحجيم التلقائي ل Azure Monitor. باستخدام التحجيم التلقائي ل Azure Monitor، يمكنك تحديد نهج مثل "عندما يتجاوز CPU الخاص بي باستمرار 80٪، أضف مثيلا آخر".
  • يمكن ل Azure Functions توفير مثيلات بشكل ديناميكي لخدمة طلباتك.
  • يدعم Azure Cosmos DB معدل النقل التلقائي، حيث يمكن للخدمة إدارة الموارد المعينة لقواعد البيانات تلقائيا استنادا إلى النهج التي تحددها.

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

لمزيد من المعلومات حول كيفية تصميم نظام قابل للتطوير والمرونة، راجع توصيات لتصميم استراتيجية تحجيم موثوق بها.

تقنيات توزيع وقت التعطل الصفري

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

يمكن أن تتضمن تقنيات النشر بدون توقف ما يلي:

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

لمعرفة المزيد حول تقنيات النشر بدون توقف، راجع ممارسات النشر الآمنة.

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

  • توفر Azure Container Apps مراجعات متعددة للتطبيق الخاص بك، والتي يمكن استخدامها لتحقيق عمليات نشر بدون توقف.
  • تدعم خدمة Azure Kubernetes (AKS) مجموعة متنوعة من تقنيات النشر بدون توقف.

بينما غالبا ما تقترن عمليات نشر وقت التعطل الصفري مع عمليات نشر التطبيق، يجب استخدامها أيضا لتغييرات التكوين. فيما يلي بعض الطرق التي يمكنك من خلالها تطبيق تغييرات التكوين بأمان:

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

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

الاختبار الآلي

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

لمعرفة المزيد، راجع توصيات لتصميم استراتيجية اختبار الموثوقية.

المراقبة والتنبيه

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

يوفر Azure مجموعة متنوعة من قدرات المراقبة والتنبيه، بما في ذلك ما يلي:

لمزيد من المعلومات، راجع توصيات لتصميم استراتيجية مراقبة وتنبيه موثوق بها.

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

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

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

يتعلق التعافي من الكوارث بالتخطيط لكيفية الاستجابة لهذه الأنواع من المواقف.

إشعار

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

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

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

  • هدف نقطة الاسترداد (RPO) هو الحد الأقصى لمدة فقدان البيانات المقبولة في حالة وقوع كارثة. يتم قياس RPO بوحدات زمنية، مثل "30 دقيقة من البيانات" أو "أربع ساعات من البيانات".

  • هدف وقت الاسترداد (RTO) هو الحد الأقصى لمدة التوقف المقبولة في حالة وقوع كارثة، حيث يتم تحديد "وقت التعطل" حسب مواصفاتك. يتم قياس RTO أيضا بوحدات زمنية، مثل "ثماني ساعات من وقت التعطل".

لقطة شاشة لمدد RTO وRPO بالساعات.

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

إشعار

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

خطط التعافي من الكوارث

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

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

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

تجاوز الفشل وإرجاع الموارد

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

  • يوفر Azure Site Recovery تجاوز الفشل التلقائي للبيئات المحلية والحلول المستضافة على الجهاز الظاهري في Azure.
  • يدعم Azure Front Door وAzure Traffic Manager تجاوز الفشل التلقائي لنسبة استخدام الشبكة الواردة بين عمليات النشر المختلفة للحل الخاص بك، كما هو الحال في مناطق مختلفة.

يستغرق الأمر عادة بعض الوقت لعملية تجاوز الفشل للكشف عن فشل المثيل الأساسي والتبديل إلى المثيل الثانوي. تأكد من محاذاة RTO لحمل العمل مع وقت تجاوز الفشل.

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

نسخ احتياطية

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

عند استخدام النسخ الاحتياطية كجزء من خطة التعافي من الكوارث، من المهم مراعاة ما يلي:

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

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

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

تدعم العديد من خدمات تخزين وبيانات Azure النسخ الاحتياطية، مثل ما يلي:

  • يوفر Azure Backup نسخا احتياطية تلقائية لأقراص الجهاز الظاهري وحسابات التخزين وAKS ومجموعة متنوعة من المصادر الأخرى.
  • تحتوي العديد من خدمات قاعدة بيانات Azure، بما في ذلك Azure SQL Database وAzure Cosmos DB، على إمكانية النسخ الاحتياطي التلقائي لقواعد البيانات الخاصة بك.
  • يوفر Azure Key Vault ميزات لنسخ البيانات السرية والشهادات والمفاتيح احتياطيا.

عمليات النشر التلقائية

لنشر الموارد المطلوبة وتكوينها بسرعة في حالة وقوع كارثة، استخدم أصول البنية الأساسية كتعليق برمجي (IaC)، مثل ملفات Bicep أو قوالب ARM أو ملف تكوين Terraform. يؤدي استخدام IaC إلى تقليل وقت الاسترداد واحتمال حدوث خطأ، مقارنة بتوزيع الموارد وتكوينها يدويا.

الاختبارات والتنقلات

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

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

لمعرفة المزيد، راجع توصيات لتصميم استراتيجية اختبار الموثوقية.

المحتوى ذو الصلة