SRE (هندسة موثوقية الموقع) - طريقة لضمان توافر مشاريع الويب. يعتبر إطار عمل لـ DevOps ويحكي كيفية النجاح في تطبيق ممارسات DevOps. هذه المقالة هي ترجمة للفصل 4 من أهداف مستوى الخدمة من هندسة موثوقية الموقع من Google. أعددت هذه الترجمة بنفسي واعتمدت على تجربتي الخاصة في فهم عمليات المراقبة. في قناة telegram monitorim_it وآخر مشاركة على Habré ، نشرت أيضًا ترجمة للفصل 6 من نفس الكتاب حول مراقبة النظم الموزعة.

الترجمة عن طريق القط. هل لديك قراءة لطيفة!

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

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

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

مصطلحات مستوى الخدمة

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

مؤشرات

SLI هو مؤشر لمستوى الخدمة - مقياس كمي بعناية لجانب واحد من مستوى الخدمة المقدمة.

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

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

هناك نوع آخر من SLI مهم بالنسبة لـ SRE وهو مدى توفر الخدمة أو جزء منها. غالبًا ما يتم تعريفها على أنها النسبة المئوية للطلبات الناجحة ، والتي تسمى أحيانًا الجيل. (متوسط ​​العمر المتوقع - يعد احتمال تخزين البيانات لفترة طويلة من الوقت أمرًا مهمًا أيضًا لأنظمة تخزين البيانات.) على الرغم من أن إمكانية الوصول 100٪ مستحيلة ، فإن الوصول إلى ما يقرب من 100٪ يمكن تحقيقه في كثير من الأحيان ، ويتم التعبير عن قيم إمكانية الوصول كرقم "تسعة" »نسبة توافر. على سبيل المثال ، قد يشار إلى توفر 99 ٪ و 99.999 ٪ باسم "2 تسع" و "5 تسع". إن الهدف الحالي المعلن من إمكانية الوصول إلى Google Compute Engine هو "ثلاثة ونصف" أو 99.95٪.

أهداف

SLO هو هدف مستوى الخدمة: قيمة مستهدفة أو نطاق قيم لمستوى الخدمة الذي يتم قياسه بواسطة SLI. القيمة العادية لـ SLO هي "القيمة المستهدفة SLI" أو "الحد الأدنى" الحد الأعلى SLI ". على سبيل المثال ، يمكننا أن نقرر أننا سنرجع نتائج البحث عن أعمال شكسبير "بسرعة" ، مع الأخذ في شكل SLO قيمة التأخير المتوسط ​​لاستعلام البحث أقل من 100 مللي ثانية.

اختيار SLO الصحيح هو عملية معقدة. أولاً ، لا يمكنك دائمًا تحديد قيمة محددة. بالنسبة لطلبات HTTP الواردة الواردة إلى خدمتك ، يتم تحديد مقياس عدد الطلبات في الثانية (QPS) بشكل أساسي من خلال رغبة المستخدمين لديك في زيارة الخدمة الخاصة بك ، ولا يمكنك تثبيت SLO لذلك.

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

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

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

اتفاقية

اتفاقية مستوى الخدمة هي عقد صريح أو ضمني مع المستخدمين يتضمن عواقب بداية (أو غياب) SLOs التي تحتوي عليها. يتم التعرف بسهولة على العواقب عندما تكون مالية - خصم أو عقوبة - لكنها يمكن أن تتخذ أشكالًا أخرى. طريقة سهلة للحديث عن الفرق بين SLOs و SLAs هي طرح السؤال "ماذا يحدث إذا لم يتم الوفاء SLOs؟" إذا لم تكن هناك عواقب واضحة ، فمن المؤكد أنك ستنظر إلى SLO.

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

يُعد بحث Google مثالًا على خدمة مهمة لا تحتوي على SLA للجمهور: نريد من الجميع استخدام Search بأكثر كفاءة ممكنة ، لكننا لم نوقع عقدًا مع العالم بأسره. ومع ذلك ، لا تزال هناك عواقب في حالة عدم توفر البحث - يؤدي عدم الوصول إلى انخفاض في سمعتنا ، وكذلك إلى انخفاض في إيرادات الإعلانات. العديد من خدمات Google الأخرى ، مثل Google for Work ، لديها اتفاقيات مستوى خدمة صريحة مع المستخدمين. بغض النظر عما إذا كانت خدمة معينة تحتوي على SLA ، من المهم تحديد SLI و SLO واستخدامها لإدارة الخدمة.

نظرية الكثير - الآن لتجربة.

المؤشرات في الممارسة العملية

بالنظر إلى أننا توصلنا إلى أنه من المهم اختيار المؤشرات المناسبة لقياس مستوى الخدمة ، كيف تعرف الآن ما هي المؤشرات ذات الصلة بالخدمة أو النظام؟

ما تهتم به أنت ومستخدميك

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

يمكن ، كقاعدة عامة ، تقسيم الخدمات إلى عدة أجزاء من حيث SLI ، وهي ذات صلة بها:

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

مجموعة المؤشر

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

تجميع

من أجل البساطة وسهولة الاستخدام ، نجمع غالبًا الأبعاد الخام. يجب أن يتم ذلك بعناية.

تبدو بعض المؤشرات بسيطة ، على سبيل المثال ، عدد الاستعلامات في الثانية الواحدة ، ولكن حتى هذا القياس الواضح والمباشر يجمع البيانات ضمنيًا بمرور الوقت. هل تم الحصول على القياس بالتحديد مرة واحدة في الثانية أم هل تم حساب هذا القياس على متوسط ​​عدد الاستعلامات في الدقيقة؟ قد يخفي الخيار الأخير عددًا فوريًا أكبر من الطلبات المخزنة لبضع ثوانٍ فقط. فكر في نظام يخدم 200 طلب في الثانية مع أرقام زوجية و 0 في بقية الوقت. ثابت في شكل متوسط ​​قيمة 100 طلبات في الثانية ومضاعفة التحميل الفوري ليست هي الشيء نفسه. وبالمثل ، قد يبدو متوسط ​​زمن استحقاق الطلبات جذابًا ، لكنه يخفي تفاصيل مهمة: من المحتمل أن تكون معظم الطلبات سريعة ، ولكن سيكون هناك العديد من الطلبات التي ستكون بطيئة.

يُنظر إلى معظم المؤشرات على أنها توزيعات وليست متوسطات. على سبيل المثال ، بالنسبة لتأخيرات SLI ، ستتم معالجة بعض الطلبات بسرعة ، بينما سيستغرق البعض دائمًا وقتًا أطول ، وأحيانًا أطول من ذلك بكثير. متوسط ​​بسيط يمكن أن يخفي هذه التأخيرات الطويلة. يوضح الشكل مثالًا: على الرغم من تقديم طلب نموذجي لحوالي 50 مللي ثانية ، إلا أن 5٪ من الطلبات أبطأ 20 مرة! لا تُظهر المراقبة والتنبيهات التي تستند إلى متوسط ​​زمن الوصول فقط تغييرات في السلوك خلال اليوم ، بينما في الواقع هناك تغييرات ملحوظة في وقت معالجة بعض الطلبات (السطر العلوي).


50 و 85 و 95 و 99 مئوية من تأخير النظام. المحور ص في شكل لوغاريتمي.

يتيح لك استخدام النسب المئوية للمؤشرات رؤية شكل التوزيع وخصائصه: المستوى المرتفع للنسبة المئوية ، مثل 99 أو 99.9 ، يُظهر أسوأ قيمة ، وعند 50 مئوية (يُعرف أيضًا باسم الوسيط) ، يمكنك رؤية حالة القياس الأكثر شيوعًا. كلما زاد التباين في زمن الاستجابة ، كلما كانت الاستعلامات طويلة الأجل أقوى تؤثر على تجربة المستخدم. يتم تحسين التأثير عند الحمل العالي في وجود قوائم الانتظار. أظهرت دراسات تجربة المستخدم أن الناس يفضلون عادةً نظامًا أبطأ مع تشتت عالٍ لوقت الاستجابة ، لذلك تركز بعض أوامر SRE فقط على القيم المئوية المرتفعة ، بناءً على افتراض أنه إذا كان السلوك المتري على 99.9٪ جيدًا ، فلن يختبر معظم المستخدمين مشاكل.

ملاحظة على الأخطاء الإحصائية

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

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

توحيد المؤشرات

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

• فترات التجميع: "بلغ متوسطها أكثر من دقيقة واحدة"
• مناطق التجميع: "جميع المهام في المجموعة"
• عدد مرات أخذ القياسات: "كل 10 ثوانٍ"
• يتم تضمين الطلبات: "HTTP GET من مهام مراقبة الصندوق الأسود"
• كيف تم استلام البيانات: "بفضل المراقبة التي تم قياسها على الخادم" ،
• تأخير وصول البيانات: "الوقت إلى البايت الأخير"

لتوفير الجهد ، قم بإنشاء مجموعة من قوالب SLI القابلة لإعادة الاستخدام لكل مقياس شائع ؛ كما أنها تجعل من السهل على الجميع فهم معنى SLI معين.

أهداف الممارسة

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

تحديد الأهداف

لتحقيق أقصى قدر من الوضوح ، يجب تحديد كيفية قياس SLOs والشروط التي تكون صالحة فيها. على سبيل المثال ، يمكننا أن نقول ما يلي (السطر الثاني هو نفس السطر ، ولكن يستخدم قيم SLI افتراضيًا):

• سيتم إكمال 99٪ (متوسط ​​أكثر من دقيقة واحدة) من مكالمات Get RPC في أقل من 100 مللي ثانية (تقاس على جميع الخوادم الخلفية).
• سيتم إكمال 99٪ من مكالمات Get RPC في أقل من 100ms.

إذا كان شكل منحنيات الأداء مهمًا ، يمكنك تحديد العديد من أهداف SLO:

• 90٪ من مكالمات Get RPC مكتملة في أقل من 1 مللي ثانية.
• 99٪ من مكالمات Get RPC مكتملة في أقل من 10 مللي ثانية.
• 99.9٪ من مكالمات Get RPC مكتملة في أقل من 100 مللي ثانية.

إذا كان المستخدمون يولدون أحمالًا غير متجانسة: المعالجة الجماعية (التي يكون النطاق الترددي مهمًا لها) والمعالجة التفاعلية (التي يكون مقدار التأخير فيها مهمًا) ، فقد يكون من المستحسن تحديد أهداف منفصلة لكل فئة تحميل:

• 95 ٪ من طلبات العملاء هي عرض النطاق الترددي المهم. قم بتعيين عدد مكالمات RPC قيد التقدم <1 ثانية.
• 99 ٪ من العملاء قيمة مقدار التأخير. قم بإعداد عدد مكالمات RPC باستخدام حركة مرور <1 كيلو بايت ومستمرة <10 مللي ثانية.

من غير الواقعي وغير المرغوب فيه الإصرار على أن يتم تنفيذ SLOs في 100 ٪ من الحالات: هذا يمكن أن تبطئ وتيرة إدخال وظائف جديدة ونشر ، وتتطلب حلولا باهظة الثمن. بدلاً من ذلك ، من الأفضل السماح بميزانية للأخطاء - جزء صغير من وقت تعطل النظام ومراقبة هذه القيمة يوميًا أو أسبوعيًا. , . ( — SLO SLO).

SLO (. 3 « » ), , , .

(SLO) - , SLI, SLO (, , SLA). , , , , . SRE . , :

,
, : , .


SLI .


, — . , , , , , .

SLO
SLO, . SLO, : , SLO, , SLO. , SLO: SLO.


SLO , . , , , , , .

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

قياسات التحكم

SLI و SLO هما العنصران الأساسيان المستخدمان في إدارة الأنظمة:

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

, 2 , , SLO , , 3 , . SLO ( ) .

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

لتعيين توقعات واقعية للمستخدمين ، استخدم واحدًا من التكتيكات التالية أو كليهما:

• . SLO, . , . SLO , .
• . , , . , SLO, . , .

, , , . , , , , .

SLA , - . SRE , SLO, SLA. SLO SLA. , , , SLA, .

, . - monitorim_it .