ghaymah-exam-ahmed-abdelaziz-SRE/q2-postmortem/postmortem-report.md

📋 تقرير تحليل حادثة انقطاع الخدمة — Postmortem Report

---

1️⃣ تقرير الـ Postmortem التفصيلي

📑 الملخص التنفيذي (Executive Summary)

• اسم الحادثة: INC-2026-0728-OOM
• تاريخ الحادثة: 28 يوليو 2026
• مدة الانقطاع (Downtime): 45 دقيقة (10:00 - 10:45 UTC)
• مستوى الأهمية (Severity): Critical (SEV-1)
• السبب الرئيسي: حدوث حالات OOMKilled (Out Of Memory) متكررة للحاويات نتيجة ارتفاع مفاجئ في حركة المرور (Traffic Spike) مع عدم وجود سياسة للتوسع التلقائي (Auto-scaling) وضيق حدود الذاكرة المخصصة.
• الأثر على الخدمة: توقف تام لأحد الخدمات الأساسية (HTTP 502 Bad Gateway) وتضرر 100% من طلبات المستخدمين أثناء فترة الانقطاع.

---

⏱️ الجدول الزمني للحادثة (Timeline of Events)

الوقت (UTC)	الحدث
10:00	بدء ارتفاع مفاجئ في عدد الطلبات الموجهة للخدمة (تضاعف عدد الطلبات 5 مرات).
10:05	تجاوز استهلاك الذاكرة الحد الأقصى المخصص (Memory Limit = 512MiB)، وقام الـ Linux Kernel بإنهاء الحاوية (OOMKilled - Exit Code 137).
10:08	دخول الحاوية في حالة CrashLoopBackOff بسبب تكرار الـ OOM فور إعادة التشغيل.
10:12	انطلاق أول تنبيه (Health Check Failure) وفشلت فحوصات الجاهزية (Liveness & Readiness Probes).
10:20	استجابة فريق الـ SRE وبدء التحقيق في المشكلة عبر مراجعة السجلات والتنبيهات.
10:30	تحديد السبب الجذر: حدوث OOMKilled متكرر لجميع الـ Replicas الشغالة.
10:38	إجراء طارئ: رفع حدود الذاكرة يدويًا من 512MiB إلى 2GiB وزيادة عدد الـ Pods من 2 إلى 6.
10:45	استقرار جميع الحاويات، وعودة مؤشرات الخدمة إلى الوضع الطبيعي (HTTP 200 OK) وانتهاء الحادثة.

---

🔍 السبب الجذر (Root Cause Analysis - RCA)

1. قصور في تخصيص الموارد (Insufficient Memory Limits):
   • تم تخصيص حد ذاكرة منخفض جِدًّا (512MiB) لا يتناسب مع حجم العمل المرتفع، مما جعل التطبيق عرضة للإنهاء المباشر بواسطة الـ OOM Killer عند حدوث ضغط.
2. غياب التوسع التلقائي (No Auto-scaling):
   • لم يتم إعداد HorizontalPodAutoscaler (HPA) للتوسع الأفقي عند ارتفاع الضغط.
3. تنبيهات متأخرة للذاكرة:
   • التنبيهات كانت مجهزة فقط عند توقف الخدمة تمامًا (Health Check Failed) بدلاً من التنبيه المبكر عند وصول استهلاك الذاكرة إلى 80%.

---

🛠️ التوصيات والإجراءات التصحيحية (Action Items)

الرقم	الإجراء (Action Item)	النوع	الأولوية
1	زيادة الـ Memory Limits الأساسية من 512MiB إلى 1GiB وتحديد Requests عند 512MiB.	فوري (Immediate)	🔴 P0
2	تطبيق سياسة Auto-scaling أفقية (HPA) لمنصة غنيمة تعمل على الذاكرة والـ CPU.	متوسط (Medium)	🔴 P0
3	إضافة قواعد تنبيه مبكرة عند تجاوز الذاكرة نسبة 80% وقبل الوصول لـ 100%.	فوري (Immediate)	🟡 P1
4	إجبار إجراء اختبارات ضغط (Load & Stress Testing) قبل الترقية للإنتاج.	طويل المدى	🟢 P2

---

2️⃣ تصميم سياسة Auto-scaling لمنصة غنيمة (Ghanimah Auto-scaling Policy)

لتفادي تكرار حادثة OOMKilled مستقبلاً، تم تصميم سياسة Horizontal Pod Autoscaler (HPA) مخصصة لمنصة غنيمة:

📐 المكونات والحدود (Policy Configuration)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ghanimah-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ghanimah-sre-api
  minReplicas: 3          # الحد الأدنى لضمان العزل والتوافر العالي
  maxReplicas: 15         # الحد الأقصى للاستجابة للهجمات أو الضغط العالي
  metrics:
    # 1. التوسع بناءً على الذاكرة (Memory Utilization) - منع الـ OOM
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70  # التوسع فور وصول الذاكرة إلى 70%
    # 2. التوسع بناءً على المعالج (CPU Utilization)
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 75
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0 # توسع فوري (0 ثانية) لتجنب OOMKilled
      policies:
        - type: Percent
          value: 100               # مضاعفة عدد الـ Pods فوراً عند الضغط
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300 # الانتظار 5 دقائق قبل تقليص العدد لمنع Flapping

💡 قواعد الموارد في الحاوية (Resource Requests & Limits)

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1024Mi"

---

3️⃣ الكشف المبكر والمراقبة باستخدام أدوات غنيمة (Early Detection & Observability)

لكشف مشكلة الذاكرة قبل وصولها لمرحلة OOMKilled:

1. إعداد قواعد التنبيه المبكر (Prometheus Alert Rules)

• تنبيه تحذيري لارتفاع الذاكرة (Memory Usage Warning > 80%):

  alert: HighMemoryUsageWarning
  expr: (container_memory_working_set_bytes{container!=""} / container_spec_memory_limit_bytes{container!=""}) * 100 > 80
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "استهلاك الذاكرة تجاوز 80% في الحاوية {{ $labels.pod }}"
  

• تنبيه عاجل لحدث OOMKilled أو إعادة تشغيل متكررة:

  alert: ContainerOOMKilledDetected
  expr: increase(kube_pod_container_status_restarts_total[5m]) > 2
  for: 0m
  labels:
    severity: critical
  annotations:
    summary: "تم اكتشاف إعادة تشغيل متكررة للحاوية {{ $labels.pod }} - احتمال OOMKilled"
  

---

2. أهم المؤشرات في لوحة المراقبة (Dashboard Metrics)

1. container_memory_working_set_bytes: قياس حجم الذاكرة المستخدمة فعلياً مقارنة بالحد الأقصى (container_spec_memory_limit_bytes).
2. kube_pod_container_status_last_terminated_reason: الكشف الفوري عن قيمة OOMKilled.
3. rate(http_requests_total[1m]): متابعة نمو الطلبات للتنبؤ بالضغط والتوسع المبكر.