From a94290da822abf4696127ce9487754cb6be99c41 Mon Sep 17 00:00:00 2001
From: AyaShosha <ayaalaashoshaa@gmail.com>
Date: Wed, 29 Jul 2026 14:20:10 +0300
Subject: [PATCH] Update postmortem-report.md

---
 q2-postmortem/postmortem-report.md | 106 +++++++++++++++++++++++++++++
 1 file changed, 106 insertions(+)

diff --git a/q2-postmortem/postmortem-report.md b/q2-postmortem/postmortem-report.md
index e69de29..f955b5a 100644
--- a/q2-postmortem/postmortem-report.md
+++ b/q2-postmortem/postmortem-report.md
@@ -0,0 +1,106 @@
+1. اكتب تقرير Postmortem (ملخص + timeline + root cause + توصيات)
+- الملخص : تطبيق على غيمة تعطّل 45 دقيقة بسبب OOMKilled متكرر.
+  **التاثير :
+  التطبيق أصبح غير متاح للمستخدمين لمدة 45 دقيقة.
+جميع الطلبات (Requests) فشلت أثناء فترة الانقطاع.
+أثر ذلك على تجربة المستخدم وتوفر الخدمة (Service Availability).
+** الحل :
+  تم إعادة تشغيل الـ Pods، وزيادة حدود الذاكرة (Memory Limits)، وتحسين إعدادات الـ Kubernetes لمنع تكرار المشكلة.
+  - root cause :
+    السبب الرئيسي
+
+الـ Application استهلك ذاكرة أكبر من الحد المحدد داخل الـ Kubernetes.
+
+عندما تجاوز الاستهلاك الـ Memory Limit قام Linux Kernel بتفعيل OOM Killer، فقام Kubernetes بإنهاء الـ Container وإعادة تشغيله.
+
+وبسبب استمرار الحمل المرتفع تكرر نفس السيناريو عدة مرات، مما أدى إلى انقطاع الخدمة.
+
+العوامل المساعدة
+Memory Limits منخفضة.   
+عدم وجود Horizontal Pod Autoscaler.
+عدم وجود مراقبة استباقية لاستهلاك الذاكرة.
+عدم وجود Alerts قبل الوصول للحد الأقصى.
+الحمل المفاجئ لم يكن متوقعًا.
+- timeline :
+  Time	Event
+10:00 AM	زيادة مفاجئة في عدد المستخدمين والطلبات.
+10:05 AM	استهلاك الذاكرة بدأ يقترب من الحد الأقصى.
+10:10 AM	أول Pod تعرض لـ OOMKilled.
+10:15 AM	Kubernetes أعاد تشغيل الـ Pod ولكن المشكلة استمرت.
+10:20 AM	عدة Pods دخلت في CrashLoop بسبب تكرار OOMKilled.
+10:25 AM	المستخدمون بدأوا يواجهون أخطاء وعدم استجابة التطبيق.
+10:35 AM	فريق التشغيل بدأ التحقيق في المشكلة.
+10:45 AM	زيادة Memory Limits وتشغيل Pods جديدة.
+10:45–10:50 AM	الخدمة عادت للعمل بصورة طبيعية.
+
+-توصيات : 
+**Short-term : 
+زيادة Memory Limits.
+مراجعة Memory Requests.
+إعادة تشغيل Pods المتأثرة.
+مراجعة Logs للتأكد من عدم وجود Memory Leak.
+**Long-term : 
+تفعيل Horizontal Pod Autoscaler (HPA).
+استخدام Cluster Autoscaler إذا امتلأت الـ Nodes.
+إضافة Prometheus وGrafana للمراقبة.
+إنشاء Alerts عند وصول استهلاك الذاكرة إلى 80%.
+إجراء Load Testing قبل نشر الإصدارات الجديدة.
+تحسين كفاءة التطبيق وتقليل استهلاك الذاكرة.
+
+
+
+---------------------------------------------------------------------------------------------------------------------------------------
+
+2. صمم سياسة auto-scaling لمنصة غيمة تمنع التكرار :
+لمنع تكرار المشكلة يتم استخدام Horizontal Pod Autoscaler (HPA).
+
+السياسة المقترحة
+Minimum Replicas: 2
+Maximum Replicas: 10
+Target CPU Utilization: 70%
+Target Memory Utilization: 75%
+
+عند زيادة الحمل يقوم Kubernetes بإنشاء Pods جديدة تلقائيًا لتوزيع الطلبات، وعند انخفاض الحمل يقلل عدد الـ Pods لتوفير الموارد.
+
+وإذا لم تعد موارد الـ Nodes كافية، يتم استخدام Cluster Autoscaler لإضافة Nodes جديدة تلقائيًا.
+------------------------------------------------------------------------------------------------------------------------------------------------
+
+
+3. اشرح كيف تكشف هذه المشكلة مبكراً باستخدام أدوات مراقبة غيمة :
+يمكن اكتشاف المشكلة مبكرًا باستخدام أدوات المراقبة التالية:
+
+Prometheus
+
+يجمع Metrics مثل:
+
+Memory Usage
+CPU Usage
+Container Restarts
+OOMKilled Events
+Pod Status
+Grafana
+
+تعرض Dashboard تحتوي على:
+
+استهلاك الذاكرة.
+استخدام المعالج.
+عدد الـ Pods.
+عدد مرات إعادة التشغيل.
+Response Time.
+Error Rate.
+Alerting
+
+يتم إرسال Alert عندما:
+
+Memory Usage > 80%
+عدد Restarts أكبر من 3 خلال 5 دقائق.
+ظهور حدث OOMKilled.
+أحد الـ Pods يدخل CrashLoopBackOff.
+Availability أقل من 99%.
+
+يمكن إرسال التنبيهات عبر:
+
+Email
+Slack
+Microsoft Teams
+