147 أسطر
7.4 KiB
Markdown
147 أسطر
7.4 KiB
Markdown
# 📋 تقرير تحليل حادثة انقطاع الخدمة — 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)
|
||
|
||
```yaml
|
||
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)
|
||
```yaml
|
||
resources:
|
||
requests:
|
||
cpu: "250m"
|
||
memory: "512Mi"
|
||
limits:
|
||
cpu: "1000m"
|
||
memory: "1024Mi"
|
||
```
|
||
|
||
---
|
||
|
||
## 3️⃣ الكشف المبكر والمراقبة باستخدام أدوات غنيمة (Early Detection & Observability)
|
||
|
||
لكشف مشكلة الذاكرة قبل وصولها لمرحلة `OOMKilled`:
|
||
|
||
### 1. إعداد قواعد التنبيه المبكر (Prometheus Alert Rules)
|
||
|
||
* **تنبيه تحذيري لارتفاع الذاكرة (Memory Usage Warning > 80%):**
|
||
```yaml
|
||
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 أو إعادة تشغيل متكررة:**
|
||
```yaml
|
||
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])`**: متابعة نمو الطلبات للتنبؤ بالضغط والتوسع المبكر.
|