توصيات لتحديد أهداف الموثوقية

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

RE:04	حدد أهداف الموثوقية والاسترداد للمكونات والتدفقات والحل العام. تصور الأهداف للتفاوض واكتساب توافق الآراء وتحديد التوقعات ودفع الإجراءات لتحقيق الحالة المثالية. استخدم الأهداف المحددة لإنشاء نموذج الحماية. يحدد نموذج الصحة الحالات الصحية والمتدهورة وغير الصحية التي تبدو عليها.

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

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

ضع في اعتبارك استخدام المقاييس التالية لتحديد متطلبات العمل.

المصطلح	التعريف
هدف مستوى الخدمة (SLO)	هدف النسبة المئوية الذي يمثل صحة المكون وطبقة الموثوقية. كلما ارتفع المستوى، كان المكون أكثر موثوقية. يمثل SLO المركب الهدف الإجمالي لحمل العمل بأكمله والحسابات ل SLO المكون.
مؤشر مستوى الخدمة (SLI)	مقياس منبعثة من خدمة. يتم تجميع مقاييس SLI لتحديد قيمة SLO.
اتفاقية على مستوى الخدمة (SLA)	اتفاقية تعاقدية بين موفر الخدمة وعميل الخدمة. تحدد الاتفاقية SLOs. قد يكون لعدم الوفاء بالاتفاقية عواقب مالية على موفر الخدمة.
متوسط وقت الاسترداد (MTTR)	الوقت المستغرق لاستعادة مكون بعد اكتشاف فشل.
متوسط الوقت بين الفشل (MTBF)	المدة التي يمكن أن يؤدي فيها حمل العمل الوظيفة المتوقعة دون انقطاع، حتى يفشل.
هدف وقت الاسترداد (RTO)	الحد الأقصى للوقت المقبول الذي يمكن أن يكون فيه التطبيق غير متوفر بعد وقوع حادث.
هدف نقطة الاسترداد (RPO)	الحد الأقصى للمدة المقبولة لفقدان البيانات أثناء وقوع حادث.

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

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

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

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

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

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

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

قياسات التوفر

SLOs وSLA

ترتبط مقاييس التوفر ب SLOs، والتي تستخدمها لتعريف اتفاقيات مستوى الخدمة. يحدد حمل العمل SLO مقدار وقت التعطل الذي يمكن تحمله في فترة معينة، على سبيل المثال، أقل من ساعة واحدة في الشهر. للتأكد من أنه يمكنك تلبية هدف SLO، راجع اتفاقيات مستوى الخدمة من Microsoft لكل مكون. انتبه إلى مقدار التكرار الذي تحتاجه لتلبية اتفاقيات مستوى الخدمة العالية. على سبيل المثال، تضمن Microsoft اتفاقيات مستوى الخدمة (SLAs) أعلى لعمليات التوزيع متعددة المناطق ل Azure Cosmos DB مما تضمنه لعمليات التوزيع أحادية المنطقة.

ملاحظة

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

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

ملاحظة

قيم اتفاقية مستوى الخدمة في الأمثلة التالية افتراضية وهي لأغراض العرض التوضيحي فقط.لا يقصد بها تمثيل القيم الحالية التي تدعمها Microsoft.

تتضمن اتفاقيات مستوى الخدمة المركبة خدمات متعددة تدعم التطبيق، مع مستويات مختلفة من التوفر. على سبيل المثال، ضع في اعتبارك تطبيق ويب Azure App Service الذي يكتب إلى قاعدة بيانات Azure SQL. من الناحية الافتراضية، قد تكون اتفاقيات مستوى الخدمة هذه:

• تطبيقات ويب App Service = 99.95 بالمائة
• قاعدة بيانات SQL = 99.99 بالمائة

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

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

في هذا التصميم، لا يزال التطبيق متوفرا حتى إذا تعذر عليه الاتصال بقاعدة البيانات. ومع ذلك، فإنه يفشل إذا فشلت قاعدة البيانات وقائمة الانتظار في نفس الوقت. النسبة المئوية المتوقعة للوقت للفشل المتزامن هي 0.0001 × 0.001، لذلك إليك اتفاقية مستوى الخدمة المركبة لهذا المسار المدمج:

قاعدة البيانات أو قائمة الانتظار = 1.0 - (0.0001 × 0.001) = 99.99999 في المئة

إجمالي اتفاقية مستوى الخدمة المركبة:

تطبيق الويب و (قاعدة البيانات أو قائمة الانتظار) = 99.95 بالمائة × 99.99999 بالمائة = ~99.95 بالمائة

ويطرح هذا النهج مفاضلات:

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

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

• N هي اتفاقية مستوى الخدمة المركبة للتطبيق الذي يتم نشره في منطقة واحدة.

• R هو عدد المناطق التي يتم نشر التطبيق فيها.

الفرصة المتوقعة لفشل التطبيق في كافة المناطق في نفس الوقت ((1 - N) ^ R). على سبيل المثال، إذا كانت اتفاقية مستوى الخدمة أحادية المنطقة الافتراضية هي 99.95 بالمائة:

• اتفاقية مستوى الخدمة المجمعة لمنطقتين = (1 - (1 - 0.9995) ^ 2) = 99.999975 بالمائة

• اتفاقية مستوى الخدمة المجمعة لأربع مناطق = (1 - (1 - 0.9995) ^ 4) = 99.999999 في المئة

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

قيم اتفاقية مستوى الخدمة

يحدد الجدول التالي قيم اتفاقية مستوى الخدمة الشائعة.

اتفاقية على مستوى الخدمة «SLA»	وقت التعطل في الأسبوع	وقت التعطل في الشهر	وقت التعطل في السنة
99%	1.68 ساعة	7.2 ساعات	3.65 أيام
99.9%	10.1 دقائق	43.2 دقيقة	8.76 ساعات
99.95%	5 دقائق	21.6 دقيقة	4.38 ساعات
99.99%	1.01 دقيقة	4.32 دقائق	52.56 دقيقة
99.999%	6 ثوانٍ	25.9 ثانية	5.26 دقائق

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

ملاحظة

تحتوي أحمال العمل التي تواجه العملاء وأحمال العمل الداخلية على SLOs مختلفة. عادة، يمكن أن يكون لأحمال العمل ذات الاستخدام الداخلي اتفاقيات مستوى الخدمة أقل تقييدا من أحمال العمل التي تواجه العملاء.

SLIs

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

لتجنب جمع مقاييس عديمة الفائدة، حدد عدد SLIs لكل تدفق. هدف إلى ثلاثة SLIs لكل تدفق إذا كان ذلك ممكنا.

قياسات الاسترداد

تتوافق أهداف الاسترداد مع مقاييس RTO وRPO وMTTR وMTBF. على النقيض من أهداف التوفر، لا تعتمد أهداف الاسترداد لهذه القياسات بشكل كبير على اتفاقيات مستوى الخدمة ل Microsoft. تنشر Microsoft ضمانات RTO وRPO فقط لبعض المنتجات، مثل قاعدة بيانات SQL.

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

ملاحظة

يمكن أن يكون MTBF تحديا لتحديد وضمان. يمكن أن تفشل الأنظمة الأساسية كخدمة (PaaS) أو برنامج كخدمة (SaaS) وتسترد دون أي إعلام من موفر السحابة، ويمكن أن تكون العملية شفافة تماما لك أو لعملائك. إذا قمت بتعريف أهداف لهذا المقياس، فغط فقط المكونات التي تقع تحت سيطرتك.

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

بناء نموذج صحي

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

تعتمد كيفية تحديد الحالات الصحية والمتدهورة وغير الصحية على أهداف الموثوقية الخاصة بك. فيما يلي بعض الأمثلة على الطرق التي قد تحدد بها الحالات:

• تشير الحالة الخضراء أو الصحية إلى استيفاء المتطلبات والأهداف الرئيسية غير الوظيفية بالكامل واستخدام الموارد على النحو الأمثل. على سبيل المثال، تتم معالجة 95 بالمائة من الطلبات في <=500 مللي ثانية باستخدام عقدة Azure Kubernetes Service (AKS) عند X بالمائة.

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

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

ملاحظة

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

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

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

عرض البيانات بشكل بياني

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

تسهيل Azure

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

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

الروابط ذات الصلة

• Well-Architected Framework إرشادات مهمة مهمة لنمذجة الصحة: نمذجة الصحة ومراقبة أحمال العمل الحرجة للمهام على Azure

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

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

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