إطار لتطوير أهداف مستوى الخدمة: الإرشادات الأساسية وأفضل الممارسات لبناء أهداف الاعتمادية الفعالة

الدروس التعليمية

ملاحظة المحرر: ما يلي هو مقال مكتوب ونشر في تقرير الاتجاهات لعام 2024 الخاص بـ DZone، المراقبة والأداء: حافة بناء أنظمة برمجية عالية الأداء.

“الجودة ليست فعلًا، إنها عادة”، قال أرسطو، وهو مبدأ يصدق أيضًا في عالم البرمجيات. خاصة للمطورين، هذا يعني أن تقديم رضا المستخدم ليس مجهودًا لمرة واحدة بل التزام مستمر. لتحقيق هذا الالتزام، تحتاج فرق الهندسة إلى تحديد أهداف موثوقية التي تُعرف الأداء الأساسي الذي يمكن للمستخدمين توقعه. هذا هو بالضبط المكان الذي تأتي فيه أهداف مستوى الخدمة (SLOs) إلى الصورة.

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

خطوات لتحديد أهداف مستوى الخدمة

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

الشكل 1. خطوات لتحديد SLOs

الخطوة 1: اختر رحلات المستخدم الحرجة

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

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

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

الخطوة 2: تحديد مؤشرات مستوى الخدمة التي يمكنها تتبع رحلات المستخدمين

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

على سبيل المثال، عند إطلاق VM، يمكن أن تكون بعض مؤشرات SLIs هي التوفر والتباطؤ.

التوفر: من بين X طلبات لإطلاق VM، كم منها نجح؟ صيغة بسيطة لحساب هذا هي:

إذا كان هناك 1,000 طلب و998 طلبًا منها نجح، فإن التوفر هو = 99.8%.

التباطؤ: من إجمالي عدد طلبات إطلاق VM، ما هو الوقت الذي استغرقه الـ 50، 95، أو 99 بالمئة من الطلبات لإطلاق VM؟ النسب المئوية هنا هي مجرد أمثلة ويمكن أن تختلف بناءً على الحالة الاستخدامية المحددة أو توقعات مستوى الخدمة.

  • في سيناريو يحتوي على 1,000 طلب حيث تم إكمال 900 طلب في 5 ثوانٍ والـ 100 المتبقية استغرقت 10 ثوانٍ، فإن تأخير النسبة الـ 95 سيكون = 10 ثوانٍ.
  • بينما يمكن استخدام المتوسطات لحساب التأخيرات، يُنصح عادةً باستخدام النسب المئوية لأنها تأخذ في الاعتبار تأخيرات الذيل، مما يوفر تمثيلاً أكثر دقة للتجربة المستخدم.

الخطوة 3: تحديد الأرقام المستهدفة للأهداف الخدمية (SLOs)

ببساطة، الأهداف الخدمية (SLOs) هي الأرقام المستهدفة التي نريد أن تحققها مقاييس الأداء الخدمي (SLIs) في نافذة زمنية محددة. في سيناريو VM، يمكن أن تكون الأهداف الخدمية (SLOs) كالتالي:

  • يجب أن تكون جاهزية الخدمة أكبر من 99% على مدار نافذة متداوله لمدة 30 يوم.
  • لا يجب أن يتجاوز تأخير النسبة الـ 95 لإطلاق VMs ثماني ثوانٍ.

عند تحديد هذه الأهداف، هناك بعض الأمور التي يجب مراعاتها:

  • استخدام البيانات التاريخية.إذا كنت بحاجة إلى تحديد أهداف خدمية (SLOs) بناءً على فترة متداوله لمدة 30 يوم، اجمع بيانات من نوافذ متعددة لمدة 30 يوم لتعريف الأهداف.

    • إذا لم يكن لديك هذه البيانات التاريخية، ابدأ بهدف أكثر إدارةً، مثل السعي لتحقيق 99% من الجاهزية كل يوم، وقم بتعديله مع مرور الوقت مع جمع المزيد من المعلومات.
    • تذكر، الأهداف الخدمية (SLOs) ليست مكتوبة في الحجر؛ يجب أن تستمر في التطور لتعكس التغيرات في احتياجات خدمتك وزبائنك.

  • النظر في SLOs التبعية. تعتمد الخدمات عادةً على خدمات أخرى ومكونات بنية تحتية، مثل قواعد البيانات وموزعي الحمل.

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

تحديات SLOs

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

الخطوة 4: احتساب ميزانية الخطأ

ميزانية الخطأ هي مقياس للوقت الذي يمكن للنظام أن يتحمله دون إزعاج العملاء أو انتهاك الالتزامات التعاقدية. يلي طريقة واحدة لرؤيتها:

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

هناك نهجان شائعان لقياس ميزانية الخطأ: حسب الزمن و حسب الحدث. دعونا نستكشف كيفية تطبيق العبارة، “يجب أن تكون توفر الخدمة أكبر من 99% على نافذة متدحرجة لمدة 30 يومًا”، على كل منهما.

قياس حسب الزمن

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

  1. تحديد عدد نقاط البيانات. ابدأ بتحديد عدد وحدات الزمن (نقاط البيانات) ضمن نافذة SLO الزمنية. على سبيل المثال، إذا كانت وحدة الزمن الأساسية هي 1 دقيقة ونافذة SLO هي 30 يومًا:

  1. حساب ميزانية الخطأ. بعد ذلك، احسب عدد نقاط البيانات التي يمكن أن ” تفشل” (أي، وقت التوقف). ميزانية الخطأ هي النسبة المئوية للفشل المسموح به.

حوّل هذا إلى وقت:

هذا يعني أن النظام يمكن أن يواجه 7 ساعات و14 دقيقة من وقت التوقف في نافذة 30 يومًا.

وأخيرًا وليس آخرًا، الميزانية المتبقية للخطأ هي الفرق بين إجمالي وقت التوقف الممكن ووقت التوقف المستخدم بالفعل.

قياس بناءً على الحدث

بالنسبة لقياس بناءً على الحدث، تُقاس ميزانية الخطأ بالنسب المئوية. العبارة المذكورة أعلاه تترجم إلى ميزانية خطأ بنسبة 1% في نافذة متداوله مدتها 30 يومًا.

لنفترض أن هناك 43,200 نقطة بيانات في تلك النافذة الزمنية التي مدتها 30 يومًا، و 100 منها سيئة. يمكنك حساب مقدار ميزانية الخطأ التي تم استهلاكها باستخدام هذه الصيغة:

الآن، لمعرفة مقدار ميزانية الخطأ المتبقية، اطرح هذا الرقم من إجمالي ميزانية الخطأ المسموح بها (1%):

وبالتالي، يمكن للخدمة أن تتحمل ما يزال 0.77% من نقاط البيانات السيئة الإضافية.

مزايا ميزانية الخطأ

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

الاحتياطات الواجب اتخاذها مع ميزانيات الخطأ

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

الخاتمة

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

مصادر إضافية:

هذا مقتطف من تقرير DZone لعام 2024 حول الاتجاهات، المراقبة والأداء: حافة بناء أنظمة برمجية عالية الأداء.

اقرأ التقرير المجاني

Source:
https://dzone.com/articles/framework-for-service-level-objectives