SLA و SLO والموثوقية KPI

1) الشروط والاختلافات

SLI (مؤشر مستوى الخدمة) - مؤشر قابل للقياس للجودة (على سبيل المثال، نسبة الطلبات الناجحة، زمن الانتقال p95).
SLO (هدف مستوى الخدمة) - استهداف قيمة SLI لكل نافذة زمنية (على سبيل المثال، "النجاح ≥ 99. 9 في المائة في 28 يوما").
ميزانية الخطأ - معدل فشل SLO المسموح به هو «1 − SLO».
SLA (اتفاق مستوى الخدمة) - التزامات تعاقدية مع غرامات/ائتمانات (خارجية).
مؤشرات الأداء الرئيسية الموثوقة - مقاييس العمليات التشغيلية (MTTD/MTTA/MTTR/MTBF، النسبة المئوية للتخفيف التلقائي، تغطية التنبيه، إلخ).

2) كيفية اختيار SLI (بناءً على الإشارات الذهبية)

1. الكمون - p95/p99 لنقاط النهاية الرئيسية.
2. حركة المرور - RPS/RPM/تدفق الرسائل.
3. الأخطاء - انخفاض حصة أخطاء 5xx/الأعمال (على سبيل المثال، باستثناء الدفع "بسبب خطأ PSP).
4. التشبع - تشبع الموارد (CPU/RAM/IO/lag).

• يرتبط بالخبرة التي ينظر إليها المستخدم.
• متاح تقنيا ومستقر في القياس.
• نحن نسيطر (إجراءات التحسين ممكنة).
• تكلفة جمع منخفضة.

3) الصيغ والأمثلة

3. 1 التوافر

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

مثال: SLO 99. 9٪ في 30 يومًا → ميزانية الخطأ = 0. 1٪، وهو ما يعادل 43 دقيقة 12 ثانية من عدم التوافر.

3. 2 زمن الكمون

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 المدفوعات (مستوى الأعمال)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) الميزانية المعيبة ومعدل الحرق

خطأ في الميزانية - «خزان الوقود» الخاص بك للابتكار (الإصدارات والتجارب).

• قناة سريعة (الكشف في ~ 1 ساعة)،
• (الاتجاه على مدى ~ 6-12 ساعة/24 ساعة).

• إذا كان معدل الحرق> 14. 4 في 1 ساعة - SEV-1 (سنأكل الميزانية اليومية في ~ 100 دقيقة).
• إذا كان معدل الحرق أقل من 6 في 6 ساعات - SEV-2 (تدهور سريع).

5) التنبيه بواسطة SLO (متعدد النوافذ ومتعدد الحروق)

مؤشر الخطأ: نسبة 5xx أو مخالفات زمن الكمون.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) أمثلة SLI/SLO حسب المجال

6. 1 بوابة API/Edge

أخطاء SLI: معدل استجابة 5xx <0. 1٪ (28 د).
SLI-Latency: p95 ≤ 250 ms (day).
SLO: التوافر ≥ 99. 95٪ (ربع).

6. 2 المدفوعات

نجاح SLI: الدفع مقابل النجاح (باستثناء إخفاقات العملاء) ≥ 99. 8٪ (28 د).
SLI-Latency: إذن ≤ 2 ثانية 99% (يوم).
SLO: Time-to-Wallet p95 ≤ 3 мин (24 ساعة).

6. 3 قواعد بيانات (PostgreSQL)

SLI-Lag: النسخ المتأخر p95 ≤ 1 ثانية (اليوم).
أخطاء SLI: معدل خطأ الاستعلام ≤ 0. 05٪ (28 د).
توافر مجموعة SLO ≥ 99. 95%.

6. 4 قوائم انتظار/بث (كافكا)

SLI-Lag: تأخر المستهلك p95 ≤ N رسائل (ساعة).
SLI-Durability - تأكيد الدخول ≥ 99. 99٪ (28 د).
SLO: توافر السماسرة ≥ 99. 9%.

7) عملية الموثوقية KPI

MTTD (متوسط وقت الكشف)

MTTA (... للاعتراف)

MTTR (... لاستعادة)

MTBF (... بين الإخفاقات)

النسبة المئوية لحوادث التخفيف التلقائي

تغطية SLO/التنبيه لمسارات المرور العليا (الهدف ≥ 95٪)

حصة الإطلاقات مع مرحلة الكناري

استهلاك الأفرقة/الميزات للميزانية الخاطئة

8) كيفية وضع SLO واقعيًا

1. قياس موثوقية خط الأساس الحالي (3-4 أسابيع).
2. حدد مسارات المستخدم «الحساسة» (تسجيل الدخول، الإيداع، اللعبة).
3. ضع في اعتبارك تكلفة كل انحراف (الوقت والمال والسمعة).
4. اختر هدفًا طموحًا ولكن يمكن تحقيقه (تحسن بنسبة 10-30٪ على خط الأساس).
5. مراجعة ربع سنوية.

• على الفور «خمسة تسعة» دون مبرر.
• SLO بواسطة مقاييس غير مرئية للمستخدم (على سبيل المثال، وحدة المعالجة المركزية بدون اتصال مع UX).
• الكثير من SLO → بخاخ التركيز.

9) SLO والإبلاغ عن الميزانية

• الإنجاز لكل SLO: هدف فعلي مقابل هدف، اتجاهات، ثقة.
• ملخص استهلاك الخطأ: مقدار الميزانية «المحروقة» مقارنة بمن (الإصدار/الحادث).
• الأسباب الخمسة الأولى للتدهور، خطة CAPA وحالة المهمة.
• تأثير الأعمال: التحويل، ND، الاحتفاظ، LTV.

10) التواصل مع سياسة الإفراج

ميزانية الخطأ <50٪ → الإصدارات المجانية.
50-80٪ → «الوضع الحذر»: فقط حسابات منخفضة المخاطر/الكناري.

11) نماذج بنود جيش تحرير السودان (تعاقدية)

الالتزام بالتوافر: على سبيل المثال، 99. 9 ٪/شهر.
القوة القاهرة: DDoS خارج نطاق السيطرة المعقولة، مزودو الطرف الثالث.
نافذة القياس ومنطقة المسؤولية: مصادر القياسات، طريقة الحساب.
الاعتمادات/العقوبات: جدول بالمستويات (على سبيل المثال، عدم توافر 60-120 دقيقة → الائتمان X٪).
إجراءات التصعيد والإخطار: المواعيد النهائية والقنوات.
البيانات والخصوصية: إخفاء، تخزين، عقد قانوني.
خطة منع التكرار في حالة الانتهاك.

12) أدوات القياس

المقاييس السلبية: Prometheus/Mimir/Thanos، المصدرون.
السجلات: Loki/ELK لحساب النجاحات/الأخطاء على مستوى الأعمال.
المواد الاصطناعية: عينات نشطة (تسجيل الدخول/الإيداع/اللعبة) بواسطة cron.
التعقب: Tempo/Jaeger للاختناقات p99.
الدفع/التمويل: مصادر الحقيقة الأساسية للدفع SLI.

13) أمثلة استفسار (قوالب)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

المفتاح> صقل المرشحات لاستبعاد «الانخفاض حسب العميل».

14) FinOps والموثوقية

التكلفة لكل 9: تكلفة إضافة تسعة تنمو بشكل كبير.
منحنى الفوائد: الأمثل حيث ≥ الزيادة في الإيرادات/النقصان في الخسائر تكلفة «9» إضافية.
محفظة SLO: مستويات مختلفة لمسارات مختلفة (المدفوعات الحرجة «أغلى»، والإبلاغ «أرخص»).

15) SLO/تنبيه الجودة - قائمة التحقق

• ترتبط SLI بمقاييس UX والأعمال.
• النافذة والتجميع متسقان (rolling 28d/quarter).
• تنبيهات متعددة النوافذ، بدون رفرفة، توجيه قائم على الأدوار.
• الوثائق: المالك، الصيغة، المصادر، دفتر التشغيل.
• لوحة عرض SLO مع مؤشرات خاطئة للميزانية والحرق.
• استعراض الأهداف بانتظام (كل ثلاثة أشهر).
• الاختبارات التركيبية على السيناريوهات الرئيسية.

16) خطة التنفيذ (4 تكرارات)

1. الأسبوع 1: جرد مسارات المستخدمين، ومسودات SLI، ولوحات القيادة الأساسية.
2. الأسبوع 2: إضفاء الطابع الرسمي على SLO، والميزنة، والتنبيهات (حرق سريع/بطيء).
3. الأسبوع 3: التكامل مع عملية الحادث/الإفراج، قواعد التجميد.

4. الأسبوع 4 +: اتفاقيات SLA التعاقدية، المراجعات الفصلية، «التكلفة لكل 9» نموذج Finops

17) الأسئلة الشائعة المصغرة

هل أحتاج إلى SLO واحد لكل خدمة ؟

أفضل 2-3 أساسية (النجاح + زمن الوصول) بدلاً من العشرات من الثانوية.

ماذا لو استنفدت الميزانية ؟

إطلاقات التجميد، مع التركيز على التثبيت و CAPA، وإزالة السمات التجريبية.

كيف تتجنب التعارض بين سرعة الإطلاق والموثوقية ؟

إصدارات الخطة «على الميزانية»، وتنفيذ حسابات الكناري وأعلام الميزات.

النتيجة

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