SLO و Error Budget بالعربي: إزاي تاخد قرار الـ Deploy بالأرقام

لو الفريق بتاعك بيتخانق كل أسبوع حول "نعمل deploy دلوقتي ولا نستنى؟" المشكلة مش في المهندسين — المشكلة إنكم ما عندكوش رقم متفقين عليه. SLO و Error Budget هما الرقم ده بالظبط، وبيحوّلوا القرار من إحساس لعملية حسابية واضحة الكل شايفها.

المشكلة باختصار

99.9% uptime بتبان كويسة على الورق. في الواقع دي معناها 43 دقيقة ونص downtime مسموح بيها شهرياً. لو النظام عدّى الحد ده في يوم 15 من الشهر، باقي الـ 15 يوم لازم يبقوا شبه 100% stable — أي deploy فيه risk بقى خطر.

الفرق بين فريق بيتحكم في الـ risk ده وفريق بيتفاجأ بيه: الأول بيقيس، والتاني بيتمنى. هذا الشرح مبني على فرضية إن عندك application production بيخدم ≥ 1000 مستخدم يومياً، وعندك Prometheus أو أي metrics store شبيه.

مثال بسيط قبل المصطلحات

تخيّل إنك بتدير مطعم بيوصل طلبات. وعدت عملاءك إن الطلب هيوصل في 45 دقيقة أو أقل. اتفقت مع نفسك إن 5% من الطلبات ممكن تتأخر في حالات استثنائية (زحمة، مطر، عطل موتوسيكل).

الـ 5% دي ميزانيتك للفشل. لو خلصت في أول أسبوع من الشهر، معناها ممنوع تاخد طلبات بعيدة (فيها risk تأخير) لحد آخر الشهر، ولازم تركّز على الطلبات القريبة بس. بكده بتحمي وعدك للعملاء.

ده بالظبط المبدأ العلمي اللي بنشتغل بيه في الـ SLO. الفرق إننا بنقيسه بأرقام من نظام الـ metrics، مش بالحس.

SLI و SLO و Error Budget بدقة

هنطبّق المفاهيم الثلاثة على شركة توصيل طعام. الـ API بتاع "إنشاء طلب" هو القلب:

• SLI (Service Level Indicator): الرقم اللي بنقيسه فعلاً. مثال: نسبة الطلبات اللي بترجع HTTP 2xx في أقل من 500ms.
• SLO (Service Level Objective): الهدف المعلن داخلياً. مثال: 99.5% من الطلبات لازم تحقق الـ SLI ده خلال 30 يوم rolling window.
• Error Budget: الفرق بين 100% والـ SLO. في المثال ده: 0.5% = 3.6 ساعة فشل مسموح بيها شهرياً.

القاعدة اللي بتحكم الفريق: طول ما الـ Error Budget فيه رصيد، ممكن تعمل deploy وتجرّب features. لما الرصيد يخلص، الأولوية بتتحول لتثبيت النظام.

الفرق بين SLO و SLA

ناس كتير بتخلط. الـ SLA التزام خارجي للعملاء، غالباً مع تعويض مادي لو اتخرق. الـ SLO هدف داخلي أقل منه بشوية (يعني لو SLA = 99.9%، SLO = 99.95% علشان فيه safety margin). SLI هو الرقم اللي بيقيس الاتنين.

إزاي تقيس SLI بـ Prometheus

لو عندك Prometheus بيجمع metrics من الـ API، الـ query ده بيحسب نسبة النجاح (availability SLI) على 30 يوم:

# نسبة الطلبات الناجحة (status 2xx) خلال آخر 30 يوم
sum(rate(http_requests_total{status=~"2.."}[30d]))
/
sum(rate(http_requests_total[30d]))

ولحساب Latency SLI (نسبة الطلبات تحت 500ms):

# نسبة الطلبات اللي latency أقل من 500ms
sum(rate(http_request_duration_seconds_bucket{le="0.5"}[30d]))
/
sum(rate(http_request_duration_seconds_count[30d]))

ولحساب الـ Error Budget المتبقي بالساعات في recording rule:

groups:
  - name: slo_error_budget
    interval: 1m
    rules:
      - record: slo:error_budget_remaining_hours
        expr: |
          (0.005 - (1 -
            sum(rate(http_requests_total{status=~"2.."}[30d]))
            /
            sum(rate(http_requests_total[30d]))
          )) * 720

الرقم 720 هو عدد ساعات 30 يوم. الناتج: ساعات متبقية في الميزانية. لما الرقم ينزل تحت صفر، الميزانية اتخطت والنظام دخل في خطر.

قواعد القرار بناءً على Error Budget

القاعدة العملية اللي كتاب Google SRE موصى بيها، وبيطبّقها فرق زي Netflix و Shopify:

1. Budget > 50%: deploy بحرية. فيه مساحة لتجربة features جديدة و migrations كبيرة.
2. Budget بين 10% و 50%: deploys بس للـ features الضرورية مع review أدق و canary لفترة أطول.
3. Budget < 10%: freeze جزئي. deploys بس للإصلاحات اللي بتحسّن الـ reliability.
4. Budget ≤ 0: freeze كامل. ممنوع أي deploy غير rollback أو hotfix لتقليل الـ error rate.

القرار بيتم بدون خناقة لأن الكل شايف نفس الرقم. الـ Product Manager ما بيقدرش يضغط "لازم تنزل الـ feature"، لأن الرقم قال لا، والرقم مش رأي حد.

مثال بالأرقام من إنتاج حقيقي

فريق بيشغّل API بـ 2 مليون طلب يومياً. SLO = 99.9% availability (يعني 0.1% خطأ مسموح):

• الميزانية الشهرية: 0.1% × 60,000,000 طلب = 60,000 طلب فاشل مسموح بيها.
• حصل incident يوم 8: وقع 45,000 طلب فاشل في ساعة.
• المتبقي: 15,000 طلب فقط لـ 22 يوم.
• القرار: كل deploy لازم يعدّي canary بـ 1% traffic لمدة 48 ساعة قبل الـ rollout الكامل.

قبل تطبيق الـ SLO، الفريق كان بيعمل deploy يومي ويتفاجأ بـ incidents. بعد 3 شهور من تتبع الـ Error Budget: الـ MTTR نزل من 47 دقيقة لـ 12 دقيقة، ونسبة الـ rollbacks نزلت من 18% لـ 4%. حالات مماثلة موثقة في Google SRE Workbook.

الـ trade-offs اللي لازم تفهمها

الـ SLO مش مجاني. بتدفع تمنه في ثلاث نقاط:

• وقت إعداد: أول SLO بياخد 2-3 أسابيع لو الفريق مش متعوّد. لازم تشتغل على تعريف SLI الصح (availability, latency, freshness, correctness) وتتفق مع الـ business على الرقم.
• Cultural shift: الـ Product لازم يقبل إن فيه وقت ممنوع فيه shipping. ده بياخد تغيير في التفكير أكتر من تغيير في الأدوات.
• Monitoring overhead: SLO يعني metrics دقيقة و storage أطول (30-90 يوم على الأقل). Prometheus بيكلّف ~5-10GB شهرياً لكل 1000 metric، أو استخدم Thanos/Cortex للـ long retention.

متى لا تستخدم SLO

تجنّب SLOs بشكل رسمي في الحالات دي:

• MVP أو prototype: لسه مش عارف الـ usage pattern. افتراض SLO بدون بيانات = تخمين.
• خدمات داخلية صغيرة بيستخدمها 5 أشخاص. الـ overhead أكبر من الفايدة.
• فريق أقل من 3 مهندسين: غالباً مش هيقدر يلتزم بـ freeze rules من غير ما الـ velocity تنهار.
• Batch jobs أو data pipelines: الـ SLO الكلاسيكي مصمم للـ request/response. للـ batch استخدم SLO مختلف (freshness أو correctness).

الخطوة التالية

اختار خدمة واحدة من نظامك (الأهم فيه)، وعرّف SLI واحد بس: availability. حط الرقم في Prometheus وخلّيه يشتغل 14 يوم بدون ما تحدد SLO. بعد أسبوعين هيبقى عندك بيانات حقيقية تبني عليها SLO مش تخمين. الرقم الأول اللي بتحطه ما ينفعش يكون من كتاب — لازم يكون من نظامك أنت.

مصادر

• Google SRE Book — Chapter 4: Service Level Objectives (sre.google/sre-book/service-level-objectives)
• Google SRE Workbook — Implementing SLOs (sre.google/workbook/implementing-slos)
• Prometheus docs — rate() & histogram_quantile() (prometheus.io/docs/prometheus/latest/querying/functions)
• Alex Hidalgo — "Implementing Service Level Objectives", O'Reilly 2020
• Sloth — SLO generator for Prometheus (github.com/slok/sloth)
• OpenSLO spec — معيار مفتوح لتعريف الـ SLO (github.com/OpenSLO/OpenSLO)