مؤشرات مستوى الخدمة وأهدافها عمليًا
مؤشرات مستوى الخدمة وأهدافها عمليًا
تُشكّل مؤشرات مستوى الخدمة (SLIs) وأهداف مستوى الخدمة (SLOs) العمود الفقري الكمي لهندسة موثوقية الموقع. كل نقاش حول الموثوقية — توزيع الميزانية، تصعيد الحوادث، تقييد الميزات — يعود في نهاية المطاف إلى رقم واحد: ما نسبة التفاعلات "الجيدة" الآن؟ الخطأ في هذا الرقم يعني إما الإفراط في الاستثمار في الموثوقية (ما يبطئ وتيرة المنتج) أو التقصير في الاستثمار (ما يُضرّ بالمستخدمين). يُعلّمك هذا الدرس كيفية اختيار مؤشرات SLI وقياسها وإدارة SLOs بالأسلوب الذي تتبعه جوجل ونتفليكس وسترايب في الإنتاج.
ما الذي يجعل مؤشر SLI جيدًا؟
مؤشر SLI هو نسبة: الأحداث الجيدة / الأحداث الصالحة. تعريف "الجيد" و"الصالح" هو المكان الذي تُخطئ فيه معظم الفرق. يتمتع مؤشر SLI المُصاغ بشكل صحيح بأربع خصائص:
- قريب من المستخدم — يقيس ما يختبره المستخدم فعليًا، لا عمق الطابور الداخلي أو استخدام المعالج.
- قابل للتنفيذ — عند تدهور المؤشر، يمكن تتبعه إلى نطاق عطل محدد.
- لا لبس فيه — مهندس جديد يقرأ التعريف يصل إلى الرقم نفسه الذي يصل إليه المهندس الأقدم.
- مستقل عن الحمل — ارتفاع حركة المرور 50 % لا ينبغي أن يُحرّك المؤشر آليًا دون وجود تدهور حقيقي.
عائلات مؤشرات SLI الأربع الذهبية
تقع معظم الخدمات ضمن إحدى أربع فئات. اختر مؤشرات SLI من العائلة التي تتناسب مع نوع خدمتك:
- خدمات الطلب والاستجابة (REST APIs, gRPC) — التوفر (غير 5xx / الإجمالي)، الزمن الكامن (النسبة المُخدَّمة دون الحد)، الصحة (جسم استجابة صالح).
- خطوط أنابيب معالجة البيانات (Kafka consumers, ETL) — الحداثة (التأخر دون الحد)، الإنتاجية، الاكتمال (لا أحداث مفقودة).
- أنظمة التخزين (قواعد البيانات، مخازن الكائنات) — المتانة (القراءات تُعيد البيانات المكتوبة بنجاح)، توفر عمليات القراءة/الكتابة.
- تدفقات رحلة المستخدم (الدفع، تسجيل الدخول) — معدل نجاح التدفق الشامل، يُقاس في المتصفح أو عميل الجوال.
اختيار الحد الصحيح
لمؤشر زمن كامن على واجهة برمجية متزامنة، الأسلوب القياسي هو: قياس p95/p99 الحالية على مدى 30 يومًا كخط أساس، إيجاد نقطة الانعطاف في منحنى التوزيع، ثم ضبط الحد بنسبة 20–30 % فوق متوسط زمن الاستجابة المقبول. للتوفر، ثلاثة تسعات (99.9 %) هدف معقول لمعظم الخدمات الداخلية؛ 99.95 % لواجهات برمجية مواجهة للعملاء؛ 99.99 % فقط عند الضرورة الحقيقية (مصادقة الدفع، خدمات الطوارئ) — كل تسعة إضافية تُكلّف تشغيلًا أعلى بمقدار 10 أضعاف تقريبًا.
نوافذ القياس
النافذة الزمنية التي تُقيّم عليها الامتثال تحدد سرعة اكتشاف المشكلات واستقرار الإشارة. نمطان يسيطران على الإنتاج:
- النافذة المتدحرجة — نافذة زائلة مدتها 28 أو 30 يومًا، تُحسب كل دقيقة. تُعطي صورة دقيقة ومستمرة للموثوقية الأخيرة. هذا هو توصية SRE من جوجل وما تُنفّذه معظم الأكوام القائمة على Prometheus.
- النافذة التقويمية — شهر ثابت (1 يناير – 31 يناير). تتوافق مع دورات الفواتير وSLAs لكنها تُنشئ "حافة" عند حدود الشهر حيث يمكن الانتهاك 30 يومًا دون عواقب حتى تفتح النافذة التالية.
لمعظم الفرق، استخدم نافذة متدحرجة مدتها 28 يومًا للقرارات التشغيلية (ميزانية الخطأ) ونافذة تقويمية فقط لتقارير SLA التعاقدية.
قياس مؤشرات SLI في Prometheus
النمط القانوني في Prometheus لمؤشر SLI قائم على الطلبات يستخدم مقياسَين: عدّادًا _total لجميع الأحداث الصالحة وعدّادًا _total (أو مدرّجًا تكراريًا) للأحداث الجيدة. فيما يلي PromQL لمؤشر SLI للتوفر على نافذة متدحرجة مدتها 28 يومًا:
لفّ هذه في قواعد تسجيل لتجنب إعادة تقييم استعلامات النطاق المُكلفة في كل استقصاء:
أنماط الفشل الشائعة عند ضبط SLOs
- القياس عند موازن الحمل لا عند العميل. طلب يُعيد موازن الحمل محاولته ثلاث مرات قبل النجاح يبدو "جيدًا" من جانب الخادم لكن المستخدم انتظر 3 أضعاف. قِس الزمن الكامن كما يدركه العميل حيثما أمكن، أو احسب الإعادات صراحةً.
- استبعاد الأخطاء "المتوقعة". تستبعد الفرق أحيانًا HTTP 429 (تجاوز معدل الحد) أو 503 (صيانة) من مقام مؤشر SLI. لا تفعل ذلك — من منظور المستخدم هذه إخفاقات. ضع ضغط الميزانية على نظامك لا على حساباتك.
- ضبط هدف SLO ليطابق الأداء الحالي. إذا كانت خدمتك تعمل بنسبة 99.92 % اليوم وضبطت SLO = 99.9 %، فلا ضغط على الميزانية — SLO لا معنى له. اضبطه عند مستوى الموثوقية الذي يحتاجه المستخدمون فعليًا أو أدناه قليلًا.
- كثرة مؤشرات SLI. توجيه جوجل الداخلي: مؤشران إلى أربعة لكل مستوى خدمة. الزيادة تُنشئ إجهاد التنبيهات وتُشتت تركيز الهندسة. اختر الاثنين اللذين يُمثّلان بصدق رضا المستخدم.
نظرة مسبقة على التنبيه متعدد النوافذ ومتعدد معدلات الاحتراق
بمجرد أن تُصدر قواعد التسجيل نسبة SLI الخاصة بك، الخطوة التالية (تُغطّى في الدرس 8) هي التنبيه. الرؤية الأساسية هنا أن نافذة 28 يومًا الواحدة تحترق ببطء شديد للتنبيه عليها. تحتاج إلى نافذة قصيرة (ساعة واحدة، 6 ساعات) لاكتشاف الاحتراقات السريعة ونافذة طويلة (يوم واحد، 3 أيام) لاكتشاف الاحتراقات البطيئة. النسبة بين معدل الاحتراق والوقت المتبقي في النافذة تُحدد الإلحاحية. كل هذه الحسابات مدفوعة بقواعد تسجيل SLI نفسها التي أعددتها هنا — الحصول على SLI صحيح هو الشرط المسبق للتنبيه الموثوق.
خلاصة
اختر مؤشرات SLI كنسب أحداث جيدة/صالحة قريبة من المستخدم. استخدم العائلات الأربع الذهبية كمنطلق. اضبط أهداف SLO بناءً على احتياجات المستخدم لا الأداء الحالي. استخدم نوافذ متدحرجة مدتها 28 يومًا للقرارات التشغيلية. عبّر عن كل شيء كقواعد تسجيل Prometheus لتستند لوحات القيادة والتنبيهات وحسابات ميزانية الخطأ جميعها إلى رقم موثوق واحد.