حين يتعطل نظام إنتاجي في الساعة الثالثة صباحًا، السؤال الأول الذي يطرحه كل مهندس هو: "هل انتهكنا اتفاقية مستوى الخدمة؟" أما السؤال الثاني — الذي يُميّز المهندسين الكبار عن غيرهم — فهو: "هل استُنفد ميزانية الأخطاء قبل هذه الحادثة؟" إن فهم مصطلحات الموثوقية كاملة، من القياس الخام وصولًا إلى العقد القانوني، هو أساس تشغيل الخدمات بمستوى Google وAmazon وStripe. هذه ليست مفاهيم مجردة؛ بل هي عقود تشغيلية تحدد أولويات الهندسة وتصعيد المناوبة وما إذا كانت الشركة ستُصدر استردادًا للأموال.
مؤشرات مستوى الخدمة (SLIs)
مؤشر مستوى الخدمة هو قياس كمي لجانب معين من مستوى الخدمة المُقدَّمة. يجيب المؤشر على السؤال: "كيف تؤدي الخدمة الآن، معبّرًا عنه كنسبة مئوية؟" الصيغة القياسية للمؤشر هي نسبة الأحداث الجيدة إلى الأحداث الصالحة عبر نافذة زمنية متحركة:
SLI = (الأحداث الجيدة) / (الأحداث الصالحة)
تُختار المؤشرات الجيدة بعناية — ليس كل مقياس مؤشرًا. الفئات الأربع التي تهم على نطاق الإنتاج هي:
التوفر: نسبة الطلبات المخدومة بنجاح. لواجهات برمجية HTTP: (الطلبات ذات الحالة < 500) / (إجمالي الطلبات). في Google، أي طلب يعيد HTTP 500 أو ينتهي بمهلة يُعدّ سيئًا.
الكمون: نسبة الطلبات المخدومة أسرع من عتبة معينة. مثال: (الطلبات المكتملة في < 200ms) / (إجمالي الطلبات). لاحظ أن مؤشرات الكمون تقيس نسبة، لا قيمة p99 خامة — هذا يجعلها قابلة للتركيب مع إطار عمل SLO.
الإنتاجية: نسبة الوقت الذي تعالج فيه الخدمة حجم طلبات كافيًا. تُستخدم لخطوط أنابيب المعالجة الدُّفعية.
الجودة / الصحة: نسبة الاستجابات الصحيحة. تُستخدم لمحركات البحث والتوصيات وخطوط أنابيب البيانات.
المؤشرات نسب وليست أرقامًا خامة. "p99 للكمون = 450ms" هو مقياس. "92% من الطلبات اكتملت في < 200ms" هو مؤشر. الصيغة النسبية ضرورية لأنها تجعل المؤشر قابلًا للمقارنة مباشرة مع هدف SLO، وتجعل حساب ميزانية الأخطاء بسيطًا. لا تضع هدف SLO على percentile خام — ضعه على مؤشر النسبة الذي يقيس أي نسبة من المستخدمين حظوا بتجربة جيدة.
أهداف مستوى الخدمة (SLOs)
هدف مستوى الخدمة هو القيمة المستهدفة للمؤشر عبر نافذة قياس. الهدف هو الاتفاق الداخلي حول مدى موثوقية الخدمة. الصيغة القياسية هي:
SLO = هدف SLI × النافذة الزمنية — مثلًا: "99.9% من الطلبات ستعود في < 200ms، مقاسة عبر نافذة متحركة مدتها 28 يومًا."
النافذة الزمنية بالغة الأهمية. النافذة المتحركة لـ 28 يومًا مُفضَّلة على الشهر الميلادي في شركات مثل Google لأنها ذات طول ثابت وتتقدم باستمرار. هدف SLO البالغ 99.9% عبر 28 يومًا يعني أن الخدمة مسموح لها بـ 28 × 24 × 60 × (1 - 0.999) = 40.32 دقيقة من الأحداث السيئة قبل اعتبارها خارج الامتثال. هذا الرقم يقود قرارات الهندسة:
إذا كانت الميزانية بصحة جيدة (>50% متبقية): اشحن المميزات بعدوانية، أجرِ تجارب الفوضى، نفّذ ترحيلات مخطط الإنتاج المحفوفة بالمخاطر.
إذا كانت الميزانية عند 25%: أبطئ عمليات النشر المحفوفة بالمخاطر، جمّد التغييرات غير الحرجة، أعطِ الأولوية لأعمال الموثوقية.
إذا استُنفدت الميزانية: جمّد الإصدارات، أوقف التجارب، وجّه كل الجهود نحو الموثوقية حتى تتقدم النافذة الزمنية.
اضبط أهداف SLO أكثر إحكامًا من SLA، وأكثر مرونة من أدائك الحالي. إذا كانت خدمتك تعمل فعلًا بنسبة 99.97% توفر لكنك تعد SLA بـ 99.5%، اضبط SLO على 99.9%. هذا يمنحك تحذيرًا (خرق SLO) قبل الوصول لعواقب تجارية (خرق SLA)، ويترك هامشًا بين الأداء الحالي والهدف.
ميزانية الأخطاء
ميزانية الأخطاء هي كمية انعدام الموثوقية المسموح لك بإنفاقها قبل خرق هدف SLO. وهي أقوى أداة قدّمها نظام SRE لهندسة البرمجيات. تُحوّل ميزانية الأخطاء المفهوم المجرد للموثوقية إلى مورد محدود قابل للإنفاق. الفرق الذي تفهم هذا تتوقف عن الجدال اللانهائي حول "الموثوقية مقابل المميزات" — الميزانية تجيب عليه موضوعيًا.
# حسابات ميزانية الأخطاء لأهداف SLO الشائعة
# النافذة: 28 يومًا = 28 * 24 * 60 * 60 = 2,419,200 ثانية = 40,320 دقيقة
echo "SLO 99.9% -> ميزانية الأخطاء = $(echo 'scale=2; 40320 * 0.001' | bc) دقيقة = ~40 دقيقة/28 يوم"
echo "SLO 99.95% -> ميزانية الأخطاء = $(echo 'scale=2; 40320 * 0.0005' | bc) دقيقة = ~20 دقيقة/28 يوم"
echo "SLO 99.99% -> ميزانية الأخطاء = $(echo 'scale=2; 40320 * 0.0001' | bc) دقيقة = ~4 دقائق/28 يوم"
echo "SLO 99.999% -> ميزانية الأخطاء = $(echo 'scale=2; 40320 * 0.00001' | bc) دقيقة = ~24 ثانية/28 يوم"
# معدل الحرق: سرعة استهلاك الميزانية نسبةً للمعدل المسموح به
# إذا كان SLO = 99.9% ومعدل الأخطاء الحالي للساعة = 5%، معدل الحرق = 5% / 0.1% = 50x
# عند معدل حرق 50x، ستستنفد ميزانية 28 يومًا في 28 يوم / 50 = 13.4 ساعة
echo "معدل الحرق 50x يستنفد ميزانية 28 يومًا في $(echo 'scale=1; 672 / 50' | bc) ساعة"
التنبيه على معدل الحرق هو النهج الاحترافي للتنبيهات المبنية على SLO. بدلًا من التنبيه على عتبات مقاييس فردية، تُنبّه عندما تستهلك ميزانية الأخطاء بوتيرة أسرع مما سيتجدد. يُعرّف كتاب SRE Workbook من Google تنبيهات ذات نافذتين: تنبيه سريع (نافذة ساعة، معدل حرق >14x) وتنبيه بطيء (نافذة 6 ساعات، معدل حرق >6x).
هرم عقد الموثوقية: المؤشرات تغذّي الأهداف، التي تُعرّف ميزانية الأخطاء، التي تفرض هامش سياسة النشر دون اتفاقية مستوى الخدمة.
اتفاقيات مستوى الخدمة (SLAs)
اتفاقية مستوى الخدمة هي العقد الخارجي الملزم قانونًا بين مزود الخدمة وعملائه، يُحدد فيه عواقب عدم تحقيق الهدف. تتضمن اتفاقيات SLA عادةً: المقياس الموعود، فترة القياس، منهجية القياس، والعلاج (رصيد الخدمة، الاستردادات، إنهاء العقد). تعد اتفاقيات SLA لـ AWS عادةً بـ 99.9% لـ EC2 و99.99% لـ S3، مع رصيد خدمة بنسبة 10-30% من الفاتورة الشهرية عند الخرق.
أخطر خطأ في تصميم SLA: تحديد هدف SLA يساوي أداءك التشغيلي الفعلي. إذا كنت تعمل بنسبة 99.95% وتعد بـ 99.95%، فأي تفاوت عادي — نشر سيئ، تدهور خدمة تابعة، انقطاع طاقة في مركز بيانات — يضعك فورًا في وضع الخرق. يجب دائمًا تحديد SLA بمستوى تثق في تحقيقه حتى في الأشهر السيئة.
تعريف المؤشرات عمليًا: Prometheus وOpenTelemetry
على نطاق الإنتاج الكبير، تُحسَب المؤشرات من قياس المقاييس في الخدمة نفسها. المعيار الصناعي هو قياس عدادات الطلبات والمدرّجات التكرارية، ثم حساب نسبة المؤشر في نظام المراقبة. إليك كيف يبدو ذلك من البداية للنهاية مع Prometheus:
# قواعد تسجيل Prometheus — حساب نسب SLI من المقاييس الخام
# الملف: /etc/prometheus/rules/sli-rules.yaml
groups:
- name: sli_availability
interval: 30s
rules:
# نسبة خام: نسبة طلبات HTTP ذات الحالة < 500
- record: job:http_requests_success:rate5m
expr: |
sum(rate(http_requests_total{status!~"5.."}[5m])) by (job)
/
sum(rate(http_requests_total[5m])) by (job)
- name: sli_latency
interval: 30s
rules:
# نسبة الطلبات المكتملة في < 200ms
- record: job:http_request_latency_sli:rate5m
expr: |
sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m])) by (job)
/
sum(rate(http_request_duration_seconds_count[5m])) by (job)
- name: slo_compliance
interval: 30s
rules:
# مؤشر توفر 28 يومًا (نافذة متحركة)
- record: job:slo_availability_28d:ratio
expr: |
sum(rate(http_requests_total{status!~"5.."}[28d])) by (job)
/
sum(rate(http_requests_total[28d])) by (job)
# ميزانية الأخطاء المتبقية (SLO = 0.999)
- record: job:slo_error_budget_remaining:ratio
expr: |
(job:slo_availability_28d:ratio - 0.999) / (1 - 0.999)
# قاعدة Alertmanager: تنبيه معدل حرق SLO (نهج النافذتين)
# يُطلَق التنبيه عند حرق ميزانية الأخطاء أسرع بـ >14x (حرق سريع)
groups:
- name: slo_burn_rate
rules:
- alert: AvailabilitySLOFastBurn
expr: |
(
sum(rate(http_requests_total{status=~"5.."}[1h])) by (job)
/
sum(rate(http_requests_total[1h])) by (job)
) > (14 * 0.001)
for: 2m
labels:
severity: critical
slo: availability
annotations:
summary: "حرق سريع: {{ $labels.job }} يستنفد ميزانية الأخطاء"
description: |
معدل الأخطاء للساعة الواحدة يتجاوز 14x معدل الحرق المسموح به.
بهذا المعدل ستُستنفَد ميزانية 28 يومًا في < 48 ساعة.
SLO: 99.9% توفر عبر 28 يومًا.
معدل الخطأ الحالي: {{ $value | humanizePercentage }}
- alert: AvailabilitySLOSlowBurn
expr: |
(
sum(rate(http_requests_total{status=~"5.."}[6h])) by (job)
/
sum(rate(http_requests_total[6h])) by (job)
) > (6 * 0.001)
for: 15m
labels:
severity: warning
slo: availability
annotations:
summary: "حرق بطيء: {{ $labels.job }} استنزاف بطيء لميزانية الأخطاء"
description: |
معدل الأخطاء لـ 6 ساعات يتجاوز 6x معدل الحرق المسموح به.
بهذا المعدل ستُستنفَد ميزانية 28 يومًا في < 5 أيام.
الأخطاء الشائعة على نطاق الإنتاج
حركة فحص الصحة في مقام المؤشر: الفحوصات الاصطناعية من موازن التحميل أو مراقب وقت التشغيل تجعل مؤشر التوفر يبدو أفضل مما هو عليه للمستخدمين الحقيقيين. استبعدها بتصفية على وسم source=synthetic أو استخدام عدادات مقاييس منفصلة.
استخدام التوفر كمؤشرك الوحيد: خدمة ترد بـ HTTP 200 تحتوي على JSON خطأ هي "متاحة" لكنها معطوبة. أضف مؤشر صحة للمسارات الحرجة.
ضبط أهداف SLO على نسخ فردية: مؤشر يقيس pod واحد سيكون صاخبًا. يجب تجميع المؤشرات عبر أسطول الخدمة بأكمله.
عدم تمييز الأخطاء المؤثرة على المستخدم من أخطاء البنية التحتية: مهلة ناجمة عن فحص صحة مُهيأ بشكل خاطئ لا ينبغي أن تُحسَب على مؤشر توفرك المواجه للمستخدم.
هدف SLO هو تفاوض وليس مرسومًا. في Google، تُحدَّد أهداف SLO بالتعاون بين فريق الخدمة وأصحاب المصلحة. مديرو المنتج يحتاجون لفهم أن هدفًا أعلى لـ SLO يعني مزيدًا من وقت الهندسة على الموثوقية وأقل على المميزات. المحادثة "هل نحتاج أربعة تسعات أم ثلاثة؟" هي قرار منتج مدعوم بتحليل تكلفة هندسية، لا اختيارًا تقنيًا أحاديًا. معظم الخدمات الداخلية في Google تعمل بنسبة 99.9% — لا 99.99% — لأن التكلفة الهامشية للتسعة الأخيرة ضخمة.
نستخدم ملفات تعريف الارتباط لتشغيل هذا الموقع وتحليل الزيارات وعرض إعلانات مخصّصة. يمكنك قبول كل ملفات تعريف الارتباط أو رفض غير الأساسية منها.
سياسة الخصوصية