أسس قابلية الرصد

مشروع: خطة القابلية للمراقبة

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

مشروع: خطة القابلية للمراقبة

بنى كل درس في هذا البرنامج التعليمي نحو نتيجة واحدة: خطة مراقبة بمستوى الإنتاج لخدمة حقيقية. في Google، يجب أن تجتاز كل خدمة جديدة مراجعة جاهزية الإنتاج (PRR) قبل الإطلاق. والقابلية للمراقبة — تعريف SLIs وSLOs ولوحات المعلومات وقواعد التنبيه — هي بوابة إلزامية في PRR. يأخذك هذا الدرس في إنتاج هذا المنتج بالضبط، من البداية إلى النهاية، لنموذج خدمة إتمام الطلبات في التجارة الإلكترونية.

ناتج هذا الدرس هو مجموعة من الملفات يمكنك حفظها في المستودع: تعريفات SLO بصيغة YAML، وملف قواعد التنبيه في Prometheus، ونموذج JSON للوحة Grafana. هذه ليست أمثلة مصطنعة — بل تتبع نفس الهيكل الذي تستخدمه فرق SRE على نطاق واسع.

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

قبل كتابة أي استعلام مقاييس، وثّق ما تفعله الخدمة وأي إجراءات المستخدم بالغة الأهمية. لخدمة checkout-service:

الرحلة الأساسية: يُرسل المستخدم طلباً — تتحقق خدمة الإتمام من السلة، وتستدعي معالج الدفع، وتحجز المخزون، وتُعيد تأكيداً في غضون 3 ثوانٍ.
الرحلة الثانوية: استرداد الطلبات السابقة لصفحة سجل الطلبات (حساسة للزمن لكن لا تعيق الإيرادات).
المهمة الخلفية: إرسال بريد ما بعد الشراء (غير متزامن، القبول بالفشل مع إعادة المحاولة).

حدّد أهداف الموثوقية التي يلاحظها المستخدمون فعلاً. الدفع الذي يستغرق 15 ثانية يبدو معطلاً حتى لو نجح تقنياً. البريد الذي يصل بعد 30 دقيقة غير مرئي للمستخدم.

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

لكل رحلة، عرّف مؤشر مستوى الخدمة (المقياس) وهدف مستوى الخدمة (الهدف). استخدم صيغ SLI للتوافر والزمن القائمة على الطلبات المعيارية في كتاب عمل Google SRE.

تعريفات SLI لخدمة checkout-service:

SLI التوافر: الطلبات_الجيدة / إجمالي_الطلبات، حيث الطلب الجيد هو أي استجابة HTTP 2xx أو 3xx لـ POST /checkout.
SLI الزمن: نسبة طلبات POST /checkout المكتملة في أقل من ثانيتين، مقيسةً عند الشريحة المئوية التاسعة والتسعين على نافذة 5 دقائق.
SLI زمن استرداد الطلبات: نسبة طلبات GET /orders المكتملة في أقل من 500 مللي ثانية عند الشريحة المئوية الخامسة والتسعين.

أهداف SLO (نافذة متداولة 28 يوماً):

التوافر: 99.9% (يسمح بنحو 43 دقيقة من الطلبات الفاشلة شهرياً)
زمن الإتمام p99 أقل من 2 ثانية: 99.5% من الطلبات
زمن استرداد الطلبات p95 أقل من 500 مللي ثانية: 99% من الطلبات

الميزانية التفصيلية = 1 - SLO. يمنحك هدف SLO بنسبة 99.9% ميزانية خطأ بنسبة 0.1% شهرياً — نحو 43 دقيقة من الفشل. تتبع معدل الحرق. إذا استنفدت 100% من الميزانية في 72 ساعة، فهناك خطأ جسيم. وإذا بقيت لديك ميزانية غير مستخدمة في نهاية الشهر، فلديك مجال لتحمّل مخاطر النشر أو الاستثمار في أعمال الموثوقية.

رمّز هذه الـ SLOs بصيغة قابلة للقراءة آلياً. توفر مواصفة OpenSLO (مشروع CNCF) مخطط YAML محايداً من الموردين؛ يمكن لـ Sloth وPyrra توليد قواعد Prometheus منه تلقائياً:

# slo/checkout-availability.yaml  (OpenSLO format)
apiVersion: openslo/v1
kind: SLO
metadata:
  name: checkout-availability
  namespace: checkout-service
spec:
  service: checkout-service
  description: "Availability of the checkout endpoint for order submission"
  timeWindow:
    - duration: 28d
      isRolling: true
  budgetingMethod: Occurrences
  objectives:
    - displayName: "99.9% availability"
      target: 0.999
  indicator:
    metadata:
      name: checkout-good-requests
    spec:
      ratioMetric:
        good:
          metricSource:
            type: Prometheus
            spec:
              query: |
                sum(rate(http_server_requests_total{
                  job="checkout-service",
                  route="/checkout",
                  status_class=~"2xx|3xx"
                }[5m]))
        total:
          metricSource:
            type: Prometheus
            spec:
              query: |
                sum(rate(http_server_requests_total{
                  job="checkout-service",
                  route="/checkout"
                }[5m]))

---
# توليد قواعد تسجيل + تنبيه Prometheus من هذا الـ SLO:
# sloth generate -i slo/checkout-availability.yaml -o alerts/checkout-slo.yaml

الخطوة 3: تصميم لوحة المعلومات

تجيب لوحة المعلومات الإنتاجية على أربعة أسئلة دفعةً واحدة: هل الخدمة بصحة جيدة الآن؟ هل تحقق SLOs؟ ما الذي تغيّر مؤخراً؟ أين عنق الزجاجة؟ بنِّ كل لوحة خدمة حول هذه الأقسام بهذا الترتيب:

صف حالة SLO — معدل حرق الميزانية الحالي، الميزانية المتبقية في هذه النافذة، نسبة الامتثال لـ SLO. إذا كان هذا الصف أحمر، لا شيء آخر يهم.
صف الإشارات الذهبية — الزمن (p50/p95/p99)، حركة المرور (RPS)، معدل الخطأ (%)، الإشباع (CPU% وذاكرة% وعمق الطابور).
صف صحة التبعيات — زمن الاستجابة ومعدلات الخطأ للخدمات اللاحقة (معالج الدفع، خدمة المخزون، قاعدة البيانات).
صف التغييرات الأخيرة — علامات النشر من نظام CI/CD مُركّبة على رسم بياني الزمن. معظم الحوادث تسببها التغييرات الأخيرة.

من رحلات المستخدم إلى SLIs وSLOs، عبر Prometheus، إلى لوحات Grafana وتوجيه المناوبة في Alertmanager.

في Grafana، عرّف لوحاتك كأكواد باستخدام ملفات نموذج JSON محفوظة في git. لا تُهيّئ لوحات الإنتاج بالنقر أبداً — فهي تنحرف وتُفقد إلى الأبد بعد الحذف العرضي. استخدم دليل توفير Grafana أو مورد Terraform grafana-dashboard لنشرها تلقائياً.

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

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

# alerts/checkout-slo-alerts.yaml
groups:
  - name: checkout-slo-alerts
    rules:

      # حرق سريع: استنزاف الميزانية بمعدل 14x في آخر 5 دقائق
      # يعني أن SLO سيُستنفد في ~ساعتين إذا استمر
      - alert: CheckoutAvailabilityFastBurn
        expr: |
          (
            sum(rate(http_server_requests_total{job="checkout-service",route="/checkout",status_class=~"4xx|5xx"}[5m]))
            /
            sum(rate(http_server_requests_total{job="checkout-service",route="/checkout"}[5m]))
          ) > (14 * 0.001)
        for: 2m
        labels:
          severity: critical
          team: checkout
          slo: availability
        annotations:
          summary: "Checkout SLO fast burn — error budget draining"
          description: "Error rate {{ $value | humanizePercentage }} is 14x above the SLO threshold. Budget exhaustion in ~2h."
          runbook: "https://wiki.example.com/runbooks/checkout-availability"
          dashboard: "https://grafana.example.com/d/checkout-slo"

      # حرق بطيء: معدل 6x على مدى الساعة الماضية — سيُستنفد في ~5 أيام
      - alert: CheckoutAvailabilitySlowBurn
        expr: |
          (
            sum(rate(http_server_requests_total{job="checkout-service",route="/checkout",status_class=~"4xx|5xx"}[1h]))
            /
            sum(rate(http_server_requests_total{job="checkout-service",route="/checkout"}[1h]))
          ) > (6 * 0.001)
        for: 15m
        labels:
          severity: warning
          team: checkout
          slo: availability
        annotations:
          summary: "Checkout SLO slow burn — error budget degrading"
          description: "Sustained 6x burn rate over 1h. Budget exhaustion in ~5 days without remediation."
          runbook: "https://wiki.example.com/runbooks/checkout-availability"

      # SLO الزمن: p99 > 2 ثانية لأكثر من 5 دقائق
      - alert: CheckoutLatencySLOBreach
        expr: |
          histogram_quantile(0.99,
            sum by (le) (
              rate(http_server_request_duration_seconds_bucket{
                job="checkout-service",
                route="/checkout"
              }[5m])
            )
          ) > 2.0
        for: 5m
        labels:
          severity: critical
          team: checkout
          slo: latency
        annotations:
          summary: "Checkout p99 latency exceeds 2s SLO"
          description: "p99 latency is {{ $value | humanizeDuration }}. SLO target is 2s."
          runbook: "https://wiki.example.com/runbooks/checkout-latency"

      # التبعية: ارتفاع معدل أخطاء معالج الدفع
      - alert: PaymentProcessorErrorRate
        expr: |
          sum(rate(http_client_requests_total{
            job="checkout-service",
            target="payment-processor",
            status_class=~"4xx|5xx"
          }[5m]))
          /
          sum(rate(http_client_requests_total{
            job="checkout-service",
            target="payment-processor"
          }[5m])) > 0.05
        for: 3m
        labels:
          severity: critical
          team: checkout
        annotations:
          summary: "Payment processor returning >5% errors"
          description: "External payment gateway error rate {{ $value | humanizePercentage }} — likely causing checkout failures."

أضف رابط كتاب التشغيل ورابط لوحة المعلومات إلى كل تنبيه. في الساعة الثالثة صباحاً، لا ينبغي أن يحتاج مهندس المناوبة إلى البحث عن السياق. يُطلق التنبيه، ينقر على رابط كتاب التشغيل، يتبع خطوات التشخيص، ينقر على رابط لوحة المعلومات لرؤية البيانات. تسمي Google SRE ذلك "جعل الإجراء الصحيح هو الإجراء السهل." التنبيه المجرد بوصف وخطورة فقط تنبيه ناقص.

الخطوة 5: وثيقة خطة القابلية للمراقبة

اجمع كل شيء في وثيقة هيكلية واحدة — مرجع حي محفوظ في مستودع الخدمة في docs/observability-plan.md. في شركات التقنية الكبرى، هذه هي الوثيقة التي يقرأها مهندس المناوبة الجديد في دورته الأولى. يجب أن تتضمن:

نظرة عامة على الخدمة: ما تفعله، تبعياتها، وأنماط حركة المرور (ذروة RPS، زمن الاستجابة المعتاد، جدول المهام الدورية).
كتالوج SLI: كل SLI معرّف مع استعلام PromQL الخاص به والسبب وراء تلك العتبة المحددة.
جدول SLO: الهدف والنافذة وميزانية الخطأ الشهرية ومعنى "خرق SLO" للأعمال.
فهرس لوحات المعلومات: روابط لوحات Grafana مع وصف جملة واحدة لما تجيب عليه كل منها.
كتالوج التنبيهات: كل تنبيه وخطورته ومضاعف معدل الحرق ورابط كتاب التشغيل الخاص به.
سياسة الاحتفاظ بالبيانات: المدة التي تُحتفظ فيها المقاييس والتتبعات والسجلات الخام، وبأي دقة (مثلاً: مقاييس خام 15 يوماً، تجمعات 5 دقائق مختصرة 13 شهراً).
مسار تصعيد المناوبة: من يُستدعى للتنبيهات الحرجة مقابل التحذيرية، وسلسلة التصعيد إذا لم يتم التأكيد خلال N دقيقة.

خطة القابلية للمراقبة التي لا تُراجع هي خطة خاطئة. تنجرف SLOs عن الواقع: تتغير أنماط حركة المرور، تُضاف ميزات جديدة، تتغير التبعيات. جدوِل مراجعة ربع سنوية لـ SLO — قارن الهدف بالأداء المقاس الفعلي، راجع اتجاه معدل حرق الميزانية، واسأل عما إذا كان SLO لا يزال ذا معنى. خدمة تعمل بتوافر 99.99% مع SLO بنسبة 99.9% تترك طاقة مخاطرة هندسية غير مستغلة؛ وأخرى عند 99.85% بنفس SLO في حالة خرق مزمن دون علمها.

الجمع معاً: هيكل الملفات

تعيش خطة القابلية للمراقبة ذات المستوى الإنتاجي في التحكم بالإصدار إلى جانب كود الخدمة. فيما يلي التخطيط الموصى به:

checkout-service/
├── slo/
│   ├── checkout-availability.yaml     # تعريف OpenSLO
│   └── checkout-latency.yaml
├── alerts/
│   ├── checkout-slo-alerts.yaml       # تنبيهات معدل الحرق متعددة النوافذ
│   └── checkout-dependencies.yaml    # معالج الدفع، قاعدة البيانات، الكاش
├── dashboards/
│   ├── checkout-slo.json              # نموذج JSON للوحة Grafana
│   └── checkout-golden-signals.json
└── docs/
    └── observability-plan.md          # وثيقة مرجعية حية للمناوبة

# التحقق من صحة YAML للتنبيهات قبل الدمج:
promtool check rules alerts/checkout-slo-alerts.yaml

# التحقق من صحة تعبيرات PromQL على نسخة Prometheus حقيقية:
promtool query instant http://prometheus:9090 \
  'histogram_quantile(0.99, sum by(le)(rate(http_server_request_duration_seconds_bucket{job="checkout-service"}[5m])))'

# نشر لوحات Grafana عبر Terraform:
# resource "grafana_dashboard" "checkout_slo" {
#   config_json = file("${path.module}/dashboards/checkout-slo.json")
#   folder      = grafana_folder.checkout.id
# }

هذا هو المعيار الذي تحمله لنفسك كمهندس DevOps محترف. الخدمة القابلة للمراقبة ليست تلك التي ثُبّت عليها Prometheus — بل هي التي، عند وقوع حادثة في الساعة الثانية صباحاً، يفتح مهندس المناوبة لوحة المعلومات ويعرف بالضبط ما المعطل ولماذا في غضون خمس دقائق. بناء هذه القدرة بنية متعمدة، قبل وقوع الحوادث، هو ما يميز التميز التشغيلي عن إطفاء الحرائق.