SRE (هندسة موثوقية الموقع) هي طريقة لضمان توافر مشاريع الويب. ويعتبر إطار عمل لـ DevOps ويتحدث عن كيفية تحقيق النجاح في تطبيق ممارسات DevOps. الترجمة في هذه المقالة الكتب من جوجل. لقد قمت بإعداد هذه الترجمة بنفسي واعتمدت على تجربتي الخاصة في فهم عمليات المراقبة. في قناة التليجرام и كما قمت بنشر ترجمة للفصل السادس من نفس الكتاب عن أهداف مستوى الخدمة.
الترجمة عن طريق القطة. استمتع بالقراءة!
من المستحيل إدارة خدمة ما إذا لم يكن هناك فهم للمؤشرات المهمة بالفعل وكيفية قياسها وتقييمها. ولتحقيق هذه الغاية، نقوم بتحديد وتقديم مستوى معين من الخدمة لمستخدمينا، بغض النظر عما إذا كانوا يستخدمون إحدى واجهات برمجة التطبيقات الداخلية لدينا أو منتجًا عامًا.
نحن نستخدم حدسنا وخبرتنا وفهمنا لرغبة المستخدمين في فهم مؤشرات مستوى الخدمة (SLIs) وأهداف مستوى الخدمة (SLOs) واتفاقيات مستوى الخدمة (SLAs). تصف هذه الأبعاد المقاييس الرئيسية التي نريد مراقبتها والتي سنتفاعل معها إذا لم نتمكن من تقديم جودة الخدمة المتوقعة. في النهاية، يساعد اختيار المقاييس الصحيحة في توجيه الإجراءات الصحيحة إذا حدث خطأ ما، كما يمنح فريق SRE الثقة في صحة الخدمة.
يصف هذا الفصل النهج الذي نستخدمه لمعالجة مشاكل النمذجة المترية، واختيار المقاييس، والتحليل المتري. أغلب الشرح سيكون بدون أمثلة، لذا سنستخدم خدمة شكسبير الموضحة في مثال تنفيذها (البحث عن أعمال شكسبير) لتوضيح النقاط الرئيسية.
مصطلحات مستوى الخدمة
من المحتمل أن يكون العديد من القراء على دراية بمفهوم SLA، لكن المصطلحين SLI وSLO يستحقان تعريفًا دقيقًا لأنه بشكل عام مصطلح SLA محمل بشكل زائد وله عدد من المعاني اعتمادًا على السياق. وللتوضيح، نريد فصل هذه القيم.
المؤشرات
مؤشر SLI هو مؤشر لمستوى الخدمة - وهو مقياس كمي محدد بعناية لجانب واحد من مستوى الخدمة المقدمة.
بالنسبة لمعظم الخدمات، يعتبر SLI الرئيسي بمثابة زمن استجابة الطلب - المدة التي يستغرقها إرجاع الاستجابة للطلب. تشتمل واجهات SLI الشائعة الأخرى على معدل الخطأ، والذي يتم التعبير عنه غالبًا كجزء صغير من جميع الطلبات المستلمة، ومعدل نقل النظام، والذي يتم قياسه عادةً بالطلبات في الثانية. غالبًا ما يتم تجميع القياسات: يتم جمع البيانات الأولية أولاً ثم تحويلها إلى معدل تغير أو متوسط أو نسبة مئوية.
من الناحية المثالية، يقوم SLI بقياس مستوى الخدمة محل الاهتمام بشكل مباشر، ولكن في بعض الأحيان لا يتوفر سوى مقياس ذي صلة للقياس نظرًا لصعوبة الحصول على المقياس الأصلي أو تفسيره. على سبيل المثال، غالبًا ما يكون زمن الاستجابة من جانب العميل مقياسًا أكثر ملاءمة، ولكن هناك أوقات لا يمكن فيها قياس زمن الاستجابة إلا على الخادم.
هناك نوع آخر من SLI مهم بالنسبة إلى SREs وهو التوفر، أو الجزء من الوقت الذي يمكن خلاله استخدام الخدمة. يتم تعريفه غالبًا على أنه معدل الطلبات الناجحة، ويسمى أحيانًا العائد. (يعتبر مدى الحياة - وهو احتمال الاحتفاظ بالبيانات لفترة طويلة من الزمن - أمرًا مهمًا أيضًا لأنظمة تخزين البيانات.) على الرغم من عدم إمكانية التوفر بنسبة 100%، إلا أن التوفر الذي يقترب من 100% غالبًا ما يكون قابلاً للتحقيق؛ ويتم التعبير عن قيم التوفر على النحو التالي: عدد "تسعة" » نسبة التوفر. على سبيل المثال، قد يتم تصنيف التوفر بنسبة 99% و99,999% على أنه "تسعتان" و"خمس تسعات". هدف التوفر المعلن حاليًا لـ Google Compute Engine هو "ثلاث تسعات ونصف" أو 2%.
الأهداف
SLO هو هدف مستوى الخدمة: قيمة مستهدفة أو نطاق من القيم لمستوى الخدمة الذي يتم قياسه بواسطة SLI. القيمة العادية لـ SLO هي "SLI ≥ الهدف" أو "الحد الأدنى ≥ SLI ≥ الحد الأعلى". على سبيل المثال، قد نقرر أننا سنعيد نتائج بحث شكسبير "بسرعة" عن طريق تعيين SLO على متوسط زمن وصول استعلام البحث أقل من 100 مللي ثانية.
يعد اختيار SLO الصحيح عملية معقدة. أولاً، لا يمكنك دائمًا اختيار قيمة محددة. بالنسبة لطلبات HTTP الخارجية الواردة إلى خدمتك، يتم تحديد مقياس الاستعلام في الثانية (QPS) بشكل أساسي من خلال رغبة المستخدمين في زيارة خدمتك، ولا يمكنك تعيين SLO لذلك.
من ناحية أخرى، يمكنك القول أنك تريد أن يكون متوسط زمن الوصول لكل طلب أقل من 100 مللي ثانية. قد يجبرك تحديد مثل هذا الهدف على كتابة الواجهة الأمامية الخاصة بك بزمن وصول منخفض أو شراء معدات توفر مثل هذا الكمون. (من الواضح أن 100 مللي ثانية هو رقم تعسفي، ولكن من الأفضل أن يكون لديك أرقام زمن وصول أقل. هناك أدلة تشير إلى أن السرعات السريعة أفضل من السرعات البطيئة، وأن زمن الوصول في معالجة طلبات المستخدم أعلى من قيم معينة يجبر الأشخاص في الواقع على الابتعاد من خدمتك.)
مرة أخرى، هذا أكثر غموضًا مما قد يبدو للوهلة الأولى: لا ينبغي عليك استبعاد QPS تمامًا من الحساب. والحقيقة هي أن QPS وزمن الاستجابة يرتبطان بقوة ببعضهما البعض: غالبًا ما يؤدي ارتفاع QPS إلى فترات استجابة أعلى، وعادة ما تواجه الخدمات انخفاضًا حادًا في الأداء عندما تصل إلى حد تحميل معين.
يؤدي تحديد SLO ونشره إلى تعيين توقعات المستخدم حول كيفية عمل الخدمة. يمكن لهذه الإستراتيجية تقليل الشكاوى التي لا أساس لها ضد مالك الخدمة، مثل الأداء البطيء. بدون SLO صريح، غالبًا ما يقوم المستخدمون بإنشاء توقعاتهم الخاصة حول الأداء المطلوب، والتي قد لا يكون لها أي علاقة بآراء الأشخاص الذين يصممون الخدمة ويديرونها. يمكن أن يؤدي هذا الموقف إلى تضخيم التوقعات من الخدمة، عندما يعتقد المستخدمون خطأً أن الخدمة ستكون أكثر سهولة مما هي عليه في الواقع، ويسبب عدم الثقة عندما يعتقد المستخدمون أن النظام أقل موثوقية مما هو عليه في الواقع.
الاتفاقيات
اتفاقية مستوى الخدمة هي عقد صريح أو ضمني مع المستخدمين يتضمن عواقب تلبية (أو عدم تلبية) متطلبات مستوى الخدمة التي تحتوي عليها. يتم التعرف على العواقب بسهولة عندما تكون مالية – خصم أو غرامة – ولكنها يمكن أن تتخذ أشكالًا أخرى. إحدى الطرق السهلة للحديث عن الفرق بين SLOs وSLAs هي طرح السؤال "ماذا يحدث إذا لم يتم استيفاء SLOs؟" إذا لم تكن هناك عواقب واضحة، فمن المؤكد أنك تبحث عن SLO.
عادةً لا تشارك SRE في إنشاء اتفاقيات مستوى الخدمة لأن اتفاقيات مستوى الخدمة ترتبط ارتباطًا وثيقًا بقرارات الأعمال والمنتجات. ومع ذلك، تشارك SRE في المساعدة على التخفيف من عواقب عمليات SLO الفاشلة. يمكنهم أيضًا المساعدة في تحديد SLI: من الواضح أنه يجب أن تكون هناك طريقة موضوعية لقياس SLO في الاتفاقية وإلا سيكون هناك خلاف.
يعد بحث Google مثالاً على خدمة مهمة لا تحتوي على اتفاقية مستوى خدمة عامة: نريد أن يستخدم الجميع البحث بأكبر قدر ممكن من الكفاءة، ولكننا لم نوقع عقدًا مع العالم. ومع ذلك، لا تزال هناك عواقب إذا كان البحث غير متاح - حيث يؤدي عدم التوفر إلى انخفاض سمعتنا بالإضافة إلى انخفاض إيرادات الإعلانات. لدى العديد من خدمات Google الأخرى، مثل Google for Work، اتفاقيات واضحة لمستوى الخدمة مع المستخدمين. بغض النظر عما إذا كانت خدمة معينة تحتوي على اتفاقية مستوى الخدمة، فمن المهم تحديد SLI وSLO واستخدامهما لإدارة الخدمة.
الكثير من النظرية - الآن للتجربة.
المؤشرات في الممارسة العملية
بما أننا توصلنا إلى أنه من المهم اختيار المقاييس المناسبة لقياس مستوى الخدمة، كيف يمكنك الآن معرفة المقاييس المهمة بالنسبة لخدمة أو نظام ما؟
ما الذي يهمك أنت والمستخدمين لديك؟
لا تحتاج إلى استخدام كل مقياس باعتباره SLI يمكنك تتبعه في نظام المراقبة؛ إن فهم ما يريده المستخدمون من النظام سيساعدك على تحديد عدة مقاييس. إن اختيار عدد كبير جدًا من المؤشرات يجعل من الصعب التركيز على المؤشرات المهمة، في حين أن اختيار عدد صغير يمكن أن يترك أجزاء كبيرة من نظامك دون مراقبة. نستخدم عادةً العديد من المؤشرات الرئيسية لتقييم وفهم صحة النظام.
يمكن تقسيم الخدمات بشكل عام إلى عدة أجزاء من حيث SLI ذات الصلة بها:
- أنظمة الواجهة الأمامية المخصصة، مثل واجهات البحث الخاصة بخدمة شكسبير من مثالنا. ويجب أن تكون متاحة، وليس بها أي تأخير، ولها نطاق ترددي كافٍ. وعليه يمكن طرح أسئلة: هل يمكننا الاستجابة للطلب؟ كم من الوقت استغرق الرد على الطلب؟ كم عدد الطلبات التي يمكن معالجتها؟
- أنظمة التخزين. إنهم يقدرون زمن الاستجابة المنخفض والتوافر والمتانة. الأسئلة ذات الصلة: كم من الوقت تستغرق قراءة البيانات أو كتابتها؟ هل يمكننا الوصول إلى البيانات عند الطلب؟ هل البيانات متاحة عندما نحتاج إليها؟ راجع الفصل 26 سلامة البيانات: ما تقرأه هو ما تكتبه للحصول على مناقشة تفصيلية لهذه القضايا.
- تعتمد أنظمة البيانات الضخمة، مثل خطوط أنابيب معالجة البيانات، على زمن استجابة الإنتاجية ومعالجة الاستعلامات. الأسئلة ذات الصلة: ما مقدار البيانات التي تتم معالجتها؟ ما الوقت الذي تستغرقه البيانات للانتقال من تلقي الطلب إلى إصدار الرد؟ (قد تعاني بعض أجزاء النظام أيضًا من تأخيرات في مراحل معينة.)
مجموعة من المؤشرات
يتم جمع العديد من مؤشرات مستوى الخدمة بشكل طبيعي على جانب الخادم، باستخدام نظام مراقبة مثل Borgmon (انظر أدناه). ) أو Prometheus، أو ببساطة تحليل السجلات بشكل دوري، وتحديد استجابات HTTP ذات الحالة 500. ومع ذلك، يجب أن تكون بعض الأنظمة مجهزة بجمع المقاييس من جانب العميل، نظرًا لأن الافتقار إلى المراقبة من جانب العميل يمكن أن يؤدي إلى فقدان عدد من المشكلات التي تؤثر على المستخدمين، ولكنها لا تؤثر على المقاييس من جانب الخادم. على سبيل المثال، التركيز على زمن استجابة الواجهة الخلفية لتطبيق اختبار بحث شكسبير الخاص بنا قد يؤدي إلى زمن استجابة من جانب المستخدم بسبب مشكلات JavaScript: في هذه الحالة، يعد قياس المدة التي يستغرقها المتصفح لمعالجة الصفحة مقياسًا أفضل.
تجميع
من أجل البساطة وسهولة الاستخدام، غالبًا ما نقوم بتجميع القياسات الأولية. يجب أن يتم ذلك بعناية.
تبدو بعض المقاييس بسيطة، مثل الطلبات في الثانية، ولكن حتى هذا القياس الذي يبدو واضحًا يؤدي ضمنيًا إلى تجميع البيانات بمرور الوقت. هل يتم تلقي القياس على وجه التحديد مرة واحدة في الثانية أم يتم حساب متوسط القياس على عدد الطلبات في الدقيقة؟ يمكن للخيار الأخير إخفاء عدد أكبر بكثير من الطلبات الفورية التي تدوم بضع ثوانٍ فقط. خذ بعين الاعتبار نظامًا يخدم 200 طلب في الثانية بأرقام زوجية و0 لبقية الوقت. الثابت في شكل قيمة متوسطة تبلغ 100 طلب في الثانية وضعف التحميل اللحظي ليسا نفس الشيء. وبالمثل، قد يبدو متوسط زمن استجابة الاستعلام أمرًا جذابًا، ولكنه يخفي تفاصيل مهمة: من الممكن أن تكون معظم الاستعلامات سريعة، ولكن سيكون هناك العديد من الاستعلامات البطيئة.
ومن الأفضل النظر إلى معظم المؤشرات على أنها توزيعات وليس متوسطات. على سبيل المثال، بالنسبة لزمن انتقال SLI، ستتم معالجة بعض الطلبات بسرعة، في حين أن بعضها سيستغرق وقتًا أطول دائمًا، وأحيانًا أطول بكثير. يمكن للمتوسط البسيط أن يخفي هذه التأخيرات الطويلة. يوضح الشكل مثالاً: على الرغم من أن الطلب النموذجي يستغرق حوالي 50 مللي ثانية للتنفيذ، إلا أن 5% من الطلبات تكون أبطأ 20 مرة! لا تُظهر المراقبة والتنبيه المستندة إلى متوسط زمن الوصول فقط تغيرات في السلوك على مدار اليوم، في حين أن هناك في الواقع تغييرات ملحوظة في وقت معالجة بعض الطلبات (السطر العلوي).
50، 85، 95، و99 زمن الوصول المئوي للنظام. المحور Y بتنسيق لوغاريتمي.
يتيح لك استخدام النسب المئوية للمؤشرات رؤية شكل التوزيع وخصائصه: يُظهر المستوى المئوي المرتفع، مثل 99 أو 99,9، أسوأ قيمة، بينما يُظهر المستوى المئوي 50 (المعروف أيضًا بالوسيط) الحالة الأكثر شيوعًا المقياس. كلما زاد تشتت وقت الاستجابة، زاد تأثير الطلبات طويلة الأمد على تجربة المستخدم. يتم تعزيز التأثير تحت الحمل العالي وفي وجود قوائم الانتظار. أظهرت أبحاث تجربة المستخدم أن الأشخاص يفضلون عمومًا نظامًا أبطأ مع تباين كبير في وقت الاستجابة، لذلك تركز بعض فرق SRE فقط على الدرجات المئوية العالية، على أساس أنه إذا كان سلوك المقياس عند النسبة المئوية 99,9 جيدًا، فلن يواجه معظم المستخدمين مشكلات .
ملاحظة على الأخطاء الإحصائية
نحن نفضل بشكل عام العمل مع النسب المئوية بدلاً من المتوسط (المتوسط الحسابي) لمجموعة من القيم. وهذا يسمح لنا بالنظر في قيم أكثر تشتتًا، والتي غالبًا ما تكون لها خصائص مختلفة بشكل كبير (وأكثر إثارة للاهتمام) عن المتوسط. نظرًا للطبيعة الاصطناعية لأنظمة الحوسبة، غالبًا ما تكون القيم المترية منحرفة، على سبيل المثال، لا يمكن لأي طلب تلقي استجابة في أقل من 0 مللي ثانية، كما أن مهلة 1000 مللي ثانية تعني أنه لا يمكن أن تكون هناك استجابات ناجحة بقيم أكبر من المهلة. ونتيجة لذلك، لا يمكننا أن نقبل أن يكون المتوسط والوسيط متماثلين أو قريبين من بعضهما البعض!
وبدون إجراء اختبارات مسبقة، وما لم تصمد بعض الافتراضات القياسية والتقديرات التقريبية، فإننا نحرص على عدم استنتاج أن بياناتنا يتم توزيعها بشكل طبيعي. إذا لم يكن التوزيع كما هو متوقع، فإن عملية الأتمتة التي تعمل على إصلاح المشكلة (على سبيل المثال، عندما ترى القيم المتطرفة، فإنها تعيد تشغيل الخادم مع فترات استجابة عالية لمعالجة الطلبات) قد تقوم بذلك كثيرًا أو لا تكون كافية (كلاهما ليسا جيد جدًا).
توحيد المؤشرات
نوصي بتوحيد الخصائص العامة لـ SLI حتى لا تضطر إلى التكهن بها في كل مرة. قد يتم استبعاد أي ميزة تلبي الأنماط القياسية من مواصفات SLI الفردية، على سبيل المثال:
- فترات التجميع: "متوسطها أكثر من دقيقة واحدة"
- مناطق التجميع: "جميع المهام في المجموعة"
- عدد مرات أخذ القياسات: "كل 10 ثوانٍ"
- ما هي الطلبات المضمنة: "HTTP GET من مهام مراقبة الصندوق الأسود"
- كيفية الحصول على البيانات: "بفضل مراقبتنا المقاسة على الخادم"
- زمن الوصول إلى البيانات: "الوقت حتى آخر بايت"
لتوفير الجهد، قم بإنشاء مجموعة من قوالب SLI القابلة لإعادة الاستخدام لكل مقياس مشترك؛ كما أنها تسهل على الجميع فهم معنى SLI معين.
الأهداف في الممارسة العملية
ابدأ بالتفكير (أو اكتشاف!) ما يهتم به المستخدمون لديك، وليس ما يمكنك قياسه. غالبًا ما يكون ما يهتم به المستخدمون لديك أمرًا صعبًا أو مستحيلًا، لذلك ينتهي بك الأمر إلى الاقتراب من احتياجاتهم. ومع ذلك، إذا بدأت بما يسهل قياسه، فسوف ينتهي بك الأمر إلى أهداف SLO أقل فائدة. ونتيجة لذلك، وجدنا في بعض الأحيان أن تحديد الأهداف المرغوبة في البداية ثم العمل مع مؤشرات محددة يعمل بشكل أفضل من اختيار المؤشرات ثم تحقيق الأهداف.
حدد الأهداف
للحصول على أقصى قدر من الوضوح، ينبغي تحديد كيفية قياس مستويات مستوى الخدمة والشروط التي تكون صالحة بموجبها. على سبيل المثال، يمكننا أن نقول ما يلي (السطر الثاني هو نفس الأول، ولكنه يستخدم إعدادات SLI الافتراضية):
- سيتم إكمال 99% (بمتوسط أكثر من دقيقة واحدة) من مكالمات Get RPC في أقل من 1 مللي ثانية (يتم قياسها عبر جميع الخوادم الخلفية).
- ستكتمل 99% من مكالمات Get RPC في أقل من 100 مللي ثانية.
إذا كان شكل منحنيات الأداء مهمًا، فيمكنك تحديد SLOs متعددة:
- تم إكمال 90% من مكالمات Get RPC في أقل من 1 مللي ثانية.
- تم إكمال 99% من مكالمات Get RPC في أقل من 10 مللي ثانية.
- تم إكمال 99.9% من مكالمات Get RPC في أقل من 100 مللي ثانية.
إذا قام المستخدمون لديك بإنشاء أحمال عمل غير متجانسة: المعالجة المجمعة (التي تعد الإنتاجية مهمة لها) والمعالجة التفاعلية (التي يكون زمن الاستجابة مهمًا لها)، فقد يكون من المفيد تحديد أهداف منفصلة لكل فئة تحميل:
- 95% من طلبات العملاء تتطلب الإنتاجية. قم بتعيين عدد مكالمات RPC التي تم تنفيذها <1 ثانية.
- 99% من العملاء يهتمون بزمن الوصول. قم بتعيين عدد مكالمات RPC ذات حركة مرور أقل من 1 كيلو بايت وتشغيل أقل من 10 مللي ثانية.
من غير الواقعي وغير المرغوب فيه الإصرار على تلبية متطلبات مستوى الخدمة بنسبة 100% من الوقت: فهذا يمكن أن يقلل من وتيرة تقديم وظائف جديدة ونشرها، ويتطلب حلولاً باهظة الثمن. بدلاً من ذلك، من الأفضل السماح بميزانية الخطأ - النسبة المئوية لوقت توقف النظام المسموح به - ومراقبة هذه القيمة يوميًا أو أسبوعيًا. قد ترغب الإدارة العليا في إجراء تقييمات شهرية أو ربع سنوية. (ميزانية الخطأ هي ببساطة SLO للمقارنة مع SLO آخر.)
يمكن مقارنة النسبة المئوية لانتهاكات مستوى مستوى الخدمة (SLO) بموازنة الخطأ (راجع الفصل الثالث والقسم )، مع استخدام قيمة الفرق كمدخل للعملية التي تقرر متى يتم نشر الإصدارات الجديدة.
اختيار القيم المستهدفة
لا يعد تحديد قيم التخطيط (SLOs) نشاطًا تقنيًا بحتًا بسبب اهتمامات المنتج والأعمال التي يجب أن تنعكس في SLIs وSLOs المحددة (وربما SLAs). وبالمثل، قد يلزم تبادل المعلومات فيما يتعلق بالقضايا المتعلقة بالتوظيف، ووقت الوصول إلى السوق، وتوافر المعدات، والتمويل. يجب أن تكون SRE جزءًا من هذه المحادثة وتساعد في فهم مخاطر الخيارات المختلفة وقابلية تطبيقها. لقد توصلنا إلى بعض الأسئلة التي قد تساعد في ضمان مناقشة أكثر إنتاجية:
لا تختار هدفًا بناءً على الأداء الحالي.
في حين أن فهم نقاط القوة وحدود النظام أمر مهم، فإن تكييف المقاييس دون تفكير يمكن أن يمنعك من الحفاظ على النظام: سيتطلب الأمر جهودًا بطولية لتحقيق أهداف لا يمكن تحقيقها دون إعادة تصميم كبيرة.
كن بسيطا
يمكن أن تؤدي حسابات SLI المعقدة إلى إخفاء التغييرات في أداء النظام وتجعل من الصعب العثور على سبب المشكلة.
تجنب المطلقات
على الرغم من أنه من المغري أن يكون لديك نظام يمكنه التعامل مع الحمل المتزايد إلى أجل غير مسمى دون زيادة زمن الوصول، إلا أن هذا المطلب غير واقعي. من المرجح أن يتطلب النظام الذي يقترب من مثل هذه المُثُل الكثير من الوقت للتصميم والبناء، وسيكون تشغيله مكلفًا، وسيكون جيدًا للغاية بالنسبة لتوقعات المستخدمين الذين قد يفعلون أي شيء أقل من ذلك.
استخدم أقل عدد ممكن من SLOs
حدد عددًا كافيًا من كائنات مستوى الخدمة (SLO) لضمان التغطية الجيدة لسمات النظام. قم بحماية وحدات SLO التي تختارها: إذا لم تتمكن أبدًا من الفوز بحجة حول الأولويات من خلال تحديد SLO محدد، فربما لا يستحق الأمر التفكير في SLO هذا. ومع ذلك، ليست كل سمات النظام قابلة لـ SLOs: فمن الصعب حساب مستوى فرحة المستخدم باستخدام SLOs.
لا تسعى إلى الكمال
يمكنك دائمًا تحسين تعريفات وأهداف SLO بمرور الوقت حيث تتعلم المزيد حول سلوك النظام تحت التحميل. من الأفضل أن تبدأ بهدف عائم ستعمل على تحسينه بمرور الوقت بدلاً من اختيار هدف صارم للغاية يجب أن تسترخي عندما تجد أنه بعيد المنال.
يمكن لـ SLOs، بل وينبغي لها، أن تكون محركًا رئيسيًا في تحديد أولويات العمل بالنسبة إلى SREs ومطوري المنتجات لأنها تعكس اهتمامًا بالمستخدمين. يعد SLO الجيد أداة تنفيذ مفيدة لفريق التطوير. ولكن يمكن أن يؤدي SLO المصمم بشكل سيء إلى إهدار العمل إذا بذل الفريق جهودًا بطولية لتحقيق SLO شديد العدوانية، أو منتجًا سيئًا إذا كان SLO منخفضًا جدًا. SLO هي رافعة قوية، استخدمها بحكمة.
السيطرة على القياسات الخاصة بك
تعد SLI وSLO من العناصر الأساسية المستخدمة لإدارة الأنظمة:
- مراقبة وقياس أنظمة SLI.
- قارن SLI بـ SLO وحدد ما إذا كان الإجراء مطلوبًا أم لا.
- إذا كان هناك حاجة إلى اتخاذ إجراء، فاكتشف ما يجب أن يحدث لتحقيق الهدف.
- أكمل هذا الإجراء.
على سبيل المثال، إذا أظهرت الخطوة 2 أن مهلة الطلب قد انتهت وسيتم قطع SLO في غضون ساعات قليلة إذا لم يتم فعل أي شيء، فقد تتضمن الخطوة 3 اختبار الفرضية القائلة بأن الخوادم مرتبطة بوحدة المعالجة المركزية وأن إضافة المزيد من الخوادم ستؤدي إلى توزيع الحمل. بدون SLO، لن تعرف ما إذا كان (أو متى) يجب عليك اتخاذ الإجراء.
قم بتعيين SLO - ثم سيتم تعيين توقعات المستخدم
يؤدي نشر SLO إلى تعيين توقعات المستخدم لسلوك النظام. غالبًا ما يرغب المستخدمون (والمستخدمون المحتملون) في معرفة ما يمكن توقعه من الخدمة لفهم ما إذا كانت مناسبة للاستخدام. على سبيل المثال، قد يرغب الأشخاص الذين يرغبون في استخدام موقع ويب لمشاركة الصور في تجنب استخدام خدمة تعد بطول العمر وتكلفة منخفضة مقابل توفر أقل قليلاً، على الرغم من أن نفس الخدمة قد تكون مثالية لنظام إدارة سجلات الأرشيف.
لتعيين توقعات واقعية للمستخدمين، استخدم أحد الأساليب التالية أو كليهما:
- الحفاظ على هامش الأمان. استخدم SLO داخليًا أكثر صرامة مما يتم الإعلان عنه للمستخدمين. سيعطيك هذا الفرصة للرد على المشكلات قبل أن تصبح مرئية للخارج. يتيح لك المخزن المؤقت لـ SLO أيضًا الحصول على هامش أمان عند تثبيت الإصدارات التي تؤثر على أداء النظام والتأكد من سهولة صيانة النظام دون الحاجة إلى إحباط المستخدمين بسبب التوقف.
- لا تتجاوز توقعات المستخدم. يعتمد المستخدمون على ما تقدمه، وليس على ما تقوله. إذا كان الأداء الفعلي لخدمتك أفضل بكثير من مستوى SLO المذكور، فسيعتمد المستخدمون على الأداء الحالي. يمكنك تجنب الاعتماد الزائد عن طريق إيقاف تشغيل النظام عمدًا أو الحد من الأداء في ظل الأحمال الخفيفة.
إن فهم مدى تلبية النظام للتوقعات يساعد في تحديد ما إذا كان سيتم الاستثمار في تسريع النظام وجعله أكثر سهولة ومرونة. وبدلاً من ذلك، إذا كان أداء الخدمة جيدًا للغاية، فيجب قضاء بعض وقت الموظفين في أولويات أخرى، مثل سداد الديون الفنية، أو إضافة ميزات جديدة، أو تقديم منتجات جديدة.
الاتفاقيات في الممارسة العملية
يتطلب إنشاء اتفاقية مستوى الخدمة (SLA) من الفرق التجارية والقانونية تحديد العواقب والعقوبات المترتبة على انتهاكها. ويتمثل دور SRE في مساعدتهم على فهم التحديات المحتملة في تلبية أهداف مستوى الخدمة الواردة في اتفاقية مستوى الخدمة. تنطبق معظم التوصيات الخاصة بإنشاء اتفاقيات مستوى الخدمة أيضًا على اتفاقيات مستوى الخدمة. من الحكمة أن تكون متحفظًا فيما تعد به المستخدمين لأنه كلما كان لديك المزيد، أصبح من الصعب تغيير أو إزالة اتفاقيات مستوى الخدمة التي تبدو غير معقولة أو يصعب الوفاء بها.
شكرا لقرائتكم الترجمة للنهاية. اشترك في قناتي على التليجرام خاصة بالمراقبة и .
المصدر: www.habr.com