هندسة موثوقية المواقع (SRE)

مشروع: سياسة SLO وميزانية الأخطاء

28 دقيقة الدرس 10 من 29

مشروع: سياسة SLO وميزانية الأخطاء

كل ما في هذا الدرس التعليمي كان يُمهّد لهذا الدرس. أنت تعرف الآن كيف تكتب SLIs وSLOs، وتحسب ميزانيات الأخطاء، وتبني تنبيهات معدل الاحتراق، وتقضي على التوليد، وتُجري مراجعات جاهزية الإنتاج. الآن ستضع كل ذلك في منتَج واحد متماسك — وثيقة سياسة SLO وميزانية الأخطاء — لخدمة إنتاج واقعية. هذا هو المنتَج الذي يقدمه فريق SRE لقيادة الهندسة وإدارة المنتج ومهندسي المناوبة. إنه العقد الذي يحكم سرعة الشحن، ومتى تجمّد النشر، وكيف تستعيد الموثوقية بعد الحوادث.

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

ما هي وثيقة السياسة فعلاً: سياسة SLO ليست ملف تهيئة مراقبة. إنها وثيقة حوكمة — عادةً صفحة إلى ثلاث صفحات — تحدد ما تعد به، وكيف تقيسه، وما يحدث حين تنتهكه، ومن يملك صلاحية الاستثناءات. إنها تحول الموثوقية من شعور إلى اتفاقية. كل خدمة إنتاج في شركة تقنية كبيرة يجب أن تملك واحدة؛ معظمها لا تملك حتى يُجبر فريق SRE على إجراء المحادثة.

الخطوة 1: تعريف الخدمة ومستخدميها

ابدأ بالسياق. كل سياسة SLO تفتح بالإجابة على: من يستخدم هذه الخدمة، وماذا تفعل لهم، وما التكلفة الفعلية للفشل؟ بالنسبة لـ PaymentService:

الخدمة: PaymentService — تعالج طلبات الشحن والاسترداد والتخويل عبر واجهات REST وgRPC.
المستخدمون: العملاء الخارجيون (تدفق الدفع عند السداد)، والخدمات الداخلية (محرك مكافحة الاحتيال، خدمة الطلبات)، والتجار الطرف الثالث عبر مفتاح API.
تأثير الفشل: دفعة فاشلة = إيرادات مفقودة، خطر محتمل لرسوم مزدوجة، تذبذب العملاء. سداد بطيء = تخلي عن سلة التسوق. كل 100ms إضافية في زمن الاستجابة عند المئين التاسع والتسعين تترابط مع انخفاض قابل للقياس في الإيرادات (موثق لدى Amazon وGoogle وShopify).
نافذة القياس: 28 يوماً متحركة. (نوافذ 28 يوماً تُخفف الموسمية الأسبوعية/الشهرية أفضل من الأشهر التقويمية.)

الخطوة 2: اختيار SLIs

بالنسبة لواجهة API مثل PaymentService، فئات SLI القانونية هي التوفر، والكمون، والصحة. لا تحتاج لقياس كل شيء — اختر SLIs التي تمثل بشكل مباشر ما يهتم به المستخدمون.

SLI التوفر: sum(rate(http_requests_total{service="payment",code!~"5.."}[5m])) / sum(rate(http_requests_total{service="payment"}[5m])) — نسبة الاستجابات غير-5xx من مجموع الطلبات.
SLI الكمون: نسبة الطلبات المكتملة خلال 200ms عند المئين التاسع والتسعين. استخدم دلاء الهيستوجرام، لا المتوسطات. المتوسطات تُخفي كمون الذيل؛ p99 هو ما يشعر به المستخدمون.
SLI الصحة: نسبة طلبات الشحن التي تنتج بالضبط قيد دفتر أستاذ واحد (فحص الأمانة). يُقاس عبر مهمة مطابقة تعمل في الخلفية تقارن قاعدة بيانات الدفع بخدمة دفتر الأستاذ الأدنى كل 5 دقائق.

ممارسة احترافية — استبعاد حركة المرور غير الخاصة بالمستخدمين: اكشط مقامات SLI بعناية. يجب استبعاد مجسات الفحص الصحي من موازنات الحمل، وحركة المرور الاصطناعية للكناري، وطلبات الوظائف الدورية الداخلية من حسابات SLI. موازن حمل يقصف /health 60 مرة في الدقيقة يمكنه تخفيف إشارة التوفر الفعلية بشكل ملحوظ. أضف فلتر تسمية: code!~"5..", path!="/health".

الخطوة 3: تحديد أهداف SLO

أهداف SLO ليست طموحية — بل مُعيَّرة على ما يحتاجه المستخدمون فعلاً وما يستطيع نظامك تقديمه واقعياً. العملية: ابدأ من البيانات التاريخية، وحدد مستوى الموثوقية الذي ينتج دونه شكاوى مستخدمين موثقة (انظر في تذاكر الدعم، وبيانات التذبذب، وسجل خرق SLA)، ثم ضع SLO الداخلي أعلى بقليل من ذلك العتبة. اترك هامشاً بين SLO وأي SLA خارجي التزمت به.

بالنسبة لـ PaymentService، بعد تحليل 12 شهراً من بيانات الإنتاج وربط معدلات الخطأ بحجم الدعم:

SLO التوفر: 99.95% من الطلبات تنجح (غير-5xx) على نافذة 28 يوماً متحركة. ميزانية الأخطاء: 0.05% ≈ 21.6 دقيقة من توقف مكافئ.
SLO الكمون: 99% من الطلبات تكتمل خلال 200ms؛ 95% خلال 80ms. (هدفا كمون يلتقطان تجربة الذيل والكتلة معاً.)
SLO الصحة: 99.999% من طلبات الشحن تنتج بالضبط قيد دفتر أستاذ واحد. (خمسة تسعات هنا لأن انتهاكات سلامة البيانات كارثية وقابلة للإبلاغ تنظيمياً.)
SLA الخارجي (للعملاء): 99.9% توفر شهري. SLO الداخلي عند 99.95% يعطيك هامش 0.05% قبل خرق SLA.

سياسة SLO لـ PaymentService في لمحة: ثلاثة SLIs، وأهدافها، وميزانيات الأخطاء الناتجة، وإجراء السياسة المُفعَّل عند كل عتبة ميزانية.

الخطوة 4: كتابة قواعد تنبيه معدل الاحتراق

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

# file: alerts/paymentsvc-slo.yaml
# تنبيهات معدل احتراق SLO لـ PaymentService (Prometheus + Alertmanager)
# SLO: توفر 99.95% على 28 يوماً
# ميزانية الأخطاء: 0.05%
# مضاعفات معدل الاحتراق:
#   14.4x = نفاد في ساعتين      (تنبيه فوري)
#    6.0x = نفاد في 8 ساعات    (تنبيه، أقل إلحاحاً)
#    3.0x = نفاد في 4 أيام     (تذكرة، لا تنبيه)
#    1.0x = خط الأساس / مستدام (لا تنبيه)

groups:
  - name: paymentsvc.slo.alerts
    rules:

      # --- احتراق سريع: تنبيه فوري ---
      - alert: PaymentSvcAvailabilityBurnCritical
        expr: |
          (
            sum(rate(http_requests_total{service="paymentsvc",code=~"5.."}[1h]))
            /
            sum(rate(http_requests_total{service="paymentsvc"}[1h]))
          ) > (14.4 * 0.0005)
          and
          (
            sum(rate(http_requests_total{service="paymentsvc",code=~"5.."}[5m]))
            /
            sum(rate(http_requests_total{service="paymentsvc"}[5m]))
          ) > (14.4 * 0.0005)
        for: 2m
        labels:
          severity: critical
          team: sre-payments
          slo: availability
        annotations:
          summary: "PaymentSvc: معدل احتراق حرج للتوفر"
          description: "احتراق ميزانية بمعدل 14.4x — نفاد في ~2 ساعة. معدل الخطأ: {{ $value | humanizePercentage }}"
          runbook: "https://wiki.internal/runbooks/paymentsvc-availability"

      # --- احتراق بطيء: تذكرة + Slack ---
      - alert: PaymentSvcAvailabilityBurnWarning
        expr: |
          (
            sum(rate(http_requests_total{service="paymentsvc",code=~"5.."}[6h]))
            /
            sum(rate(http_requests_total{service="paymentsvc"}[6h]))
          ) > (6.0 * 0.0005)
          and
          (
            sum(rate(http_requests_total{service="paymentsvc"}[30m]))
            /
            sum(rate(http_requests_total{service="paymentsvc"}[30m]))
          ) > (6.0 * 0.0005)
        for: 15m
        labels:
          severity: warning
          team: sre-payments
          slo: availability
        annotations:
          summary: "PaymentSvc: معدل احتراق توفر مرتفع"
          description: "احتراق بمعدل 6x — نفاد في ~8 ساعات إذا استمر."

      # --- متتبع نفاد الميزانية (للوحات القيادة، لا للتنبيه) ---
      - alert: PaymentSvcBudgetExhausted
        expr: |
          (
            1 - (
              sum(rate(http_requests_total{service="paymentsvc",code!~"5.."}[28d]))
              /
              sum(rate(http_requests_total{service="paymentsvc"}[28d]))
            )
          ) >= 0.0005
        labels:
          severity: critical
          team: sre-payments
        annotations:
          summary: "PaymentSvc: SLO 28 يوم مُخترَق — ميزانية الأخطاء نفدت"

الخطوة 5: كتابة سياسة ميزانية الأخطاء

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

سياسة ميزانية الأخطاء للإنتاج لها أربعة أقسام: عتبات الميزانية ومُحفّزاتها، ومصفوفة التصعيد وصلاحية القرار، وعملية طلب الاستثناءات، وإيقاع المراجعة. إليك سياسة PaymentService:

# PaymentService — سياسة ميزانية الأخطاء
# المالك: فريق SRE للمدفوعات | فعّالة: 2025-Q3 | مراجعة: فصلية
# SLO: توفر 99.95%، 28 يوماً متحركة
# إجمالي الميزانية لكل 28 يوم: ~21.6 دقيقة توقف مكافئ

## عتبات الميزانية والإجراءات

| الميزانية المتبقية | الحالة     | الإجراء                                               | الصلاحية        |
|--------------------|------------|-------------------------------------------------------|-----------------|
| > 50%           | صحية       | إيقاع نشر عادي. الشحن بحرية.                         | فرق التطوير     |
| 25%–50%            | حذر        | مراجعة النشر المعلق لنطاق التأثير. تفضيل             | SRE + قائد Dev  |
|                    |            | كناري / طرح تدريجي للتغييرات المحفوفة بالمخاطر.     |                 |
| 10%–25%            | تحذير      | تجميد نشر الميزات غير الحيوية. إصلاحات الموثوقية    | فريق SRE        |
|                    |            | وإصلاحات Sev-1 العاجلة فقط.                          |                 |
| 0%–10%             | حرج        | تجميد كامل للنشر. جميع التغييرات تتطلب             | قائد SRE        |
|                    |            | موافقة SRE. إعلان حادثة إذا لم تكن مفتوحة.          |                 |
| مُخترَق (0%)       | SLO مُنتهَك | تجميد النشر يبقى. تحليل مطلوب.                       | نائب رئيس الهندسة|
|                    |            | بدء عملية رصيد SLA. مستوى مجلس الإدارة إذا           |                 |
|                    |            | انتُهك SLO الصحة أيضاً.                              |                 |

## عملية الاستثناء
أي فريق يرغب في النشر أثناء التجميد يجب عليه:
  1. تقديم طلب استثناء في قائمة انتظار مناوبة SRE.
  2. توفير: وصف التغيير، نطاق التأثير المقدر، خطة التراجع.
  3. الحصول على موافقة قائد SRE المناوب.
  4. النشر بحضور SRE في قناة النشر.
  5. مراقبة معدل الاحتراق لمدة 30 دقيقة بعد النشر قبل الانسحاب.

## إعادة تعيين الميزانية والتعافي
الميزانية لا تُعاد تعيينها مبكراً. SLO مُخترَق يعني نافذة 28 يوماً
يجب أن تتجاوز الحادثة قبل استعادة الميزانية. إجراءات التعافي
(قواطع دائرة محسّنة، نطاق تأثير أقل للنشر، تحليل كناري محسّن)
تُتتبع في قائمة بنود إجراء التحليل وتُراجع في مراجعة SLO الفصلية التالية.

## إيقاع المراجعة
- أسبوعياً: قائد المناوبة يراجع اتجاه معدل الاحتراق (اجتماع دائم 5 دقائق)
- شهرياً: فريق SRE يراجع تحقق SLO 28 يوم مقابل الهدف
- فصلياً: مراجعة كاملة لـ SLO وسياسة الميزانية مع قيادة المنتج
  - تعديل أهداف SLO إذا تغيرت توقعات المستخدم أو قدرة النظام
  - ترقية/خفض تصنيف الخدمات بين طبقات SLO بناءً على الأهمية

مصيدة إنتاجية — SLOs قديمة: سياسات SLO المكتوبة مرة واحدة وغير المُراجَعة خطيرة. خدمة انتقلت من 100 طلب/ثانية إلى 50,000 طلب/ثانية لها ملف فشل مختلف تماماً. فريق شحن إعادة هيكلة رئيسية غيّر معنى "الصحيح". راجع SLOs فصلياً كقاعدة صارمة. إذا لم تلمس وثيقة SLO خلال ستة أشهر، افترض أنها خاطئة.

الخطوة 6: ربطها بلوحة القيادة ودليل التشغيل

السياسة مفيدة فقط إذا استطاع مهندس المناوبة رؤية استهلاك الميزانية للوهلة الأولى ويعرف بالضبط ماذا يفعل حين تُتجاوز عتبة. منتجان ختاميان يكملان الحزمة:

لوحات Grafana SLO — لوحة واحدة لكل SLI تظهر: تحقق SLO الحالي لـ 28 يوماً مقابل الهدف، والميزانية المتبقية (كنسبة مئوية وكدقائق)، ومعدل الاحتراق خلال آخر 1h/6h/24h، ومؤشر حالة مُرمَّز بالألوان (أخضر/أصفر/أحمر/أسود يطابق عتبات السياسة الأربع). استخدم قواعد التسجيل لحساب استعلامات نطاق 28 يوماً مسبقاً — استعلامات PromQL الخام لنطاق 28 يوماً مكلفة على المجموعات الكبيرة.

روابط دليل التشغيل في كل تنبيه: تعليق توضيحي runbook على كل تنبيه يجب أن يشير إلى صفحة تجيب، بالترتيب: ما هذا التنبيه، ما تأثير المستخدم، ما هي أوامر التشخيص الثلاثة الأولى، ما الأسباب الشائعة وإصلاحاتها، ومتى تُصعِّد. دليل التشغيل هو السياسة مُشغَّلة — يترجم قرار الحوكمة ("تجميد النشر") إلى رسالة Slack المحددة للإرسال، وقناة الحادثة لفتحها، والأشخاص للتنبيه.

ممارسة احترافية — اجعل السياسة تُطبَّق ذاتياً: في Google وStripe، حالة ميزانية SLO مربوطة بخط أنابيب CI/CD. نظام النشر يستعلم عن ميزانية الأخطاء الحالية قبل السماح بدفع إنتاجي. إذا كانت الميزانية دون 10%، يتطلب خط الأنابيب موافقة يدوية من قائد SRE المناوب. هذا يزيل الحاجة لأي شخص ليتذكر التحقق — تعمل السياسة تلقائياً على كل عملية نشر. نفذ هذا بواجهة API صغيرة يستدعيها نظام CI: GET /slo/paymentsvc/budget تعيد نسبة الميزانية؛ خط الأنابيب يفشل (أو ينشئ بوابة موافقة يدوية) حين تكون دون العتبة.

قائمة تحقق المنتج الكامل

حين تقدم سياسة SLO وميزانية أخطاء لخدمة ما، يجب أن تحتوي على:

سياق الخدمة: من يستخدمها، وتكلفة الفشل، ولماذا اختيرت هذه SLIs دون البدائل.
تعريفات SLI: استعلامات PromQL أو SQL الدقيقة لكل SLI. لا غموض — نفس الاستعلام يجب أن ينتج نفس الرقم في كل مرة.
أهداف SLO: النسبة والنافذة والمبرر المبني على البيانات (التحقق التاريخي، عتبة شكوى المستخدم).
جدول ميزانية الأخطاء: الميزانية بالدقائق وبعدد الطلبات عند حجم المرور المتوسط، لكل SLO.
قواعد تنبيه معدل الاحتراق: YAML لتنبيهات الاحتراق السريع والبطيء، مع تسميات الخطورة وروابط دليل التشغيل.
مصفوفة سياسة الميزانية: العتبات الأربع، والإجراء الذي تُفعّله كل واحدة، ومن يملك الصلاحية.
عملية الاستثناء: كيف تطلب الفرق استثناء نشر أثناء التجميد.
جدول المراجعة: الإيقاع الأسبوعي والشهري والفصلي مع أصحاب مُسمَّيين.
رابط لوحة القيادة: URL للوحة Grafana SLO الحية حتى يتمكن أي صاحب مصلحة من التحقق من الحالة الراهنة.

هذا هو المنتَج. تسعة أقسام، صفحة إلى ثلاث صفحات. إنه الفرق بين ممارسة SRE وثقافة SRE — لأنه حين يوقع القيادة على السياسة، كل تجميد نشر يحمل صلاحية تنظيمية، وكل استثناء قابل للتتبع، وكل مراجعة SLO تنتج تحسينات قابلة للتنفيذ بدلاً من جدالات.

تهانينا — أكملت دروس SRE التعليمية. يمكنك الآن تعريف SLIs وSLOs من المبادئ الأولى، وحساب ميزانيات الأخطاء، وكتابة تنبيهات احتراق متعددة النوافذ، وإجراء مراجعات جاهزية الإنتاج، وإنتاج سياسة حوكمة كاملة يمكن لمنظمة هندسية استخدامها فعلاً. هذه هي المهارات التي تُميز مهندس SRE الأول عن رجل إطفاء حوادث المناوبة. اطبّقها على كل خدمة تلمسها.