المستوى المطلوب: متوسط — مفترض إنك مرتاح مع kubectl والـ Deployment والـ Service، وعندك cluster تجريبي (minikube أو kind أو staging حقيقي). لو لسه ما اشتغلتش على Kubernetes في الإنتاج، ابدأ بالأساسيات أولاً قبل المقال ده.

لو الـ pod الواحد بيقع في إنتاجك كل أسبوعين، تطبيقك هيتعرّض لـ 26 حادثة فشل في السنة. Chaos Engineering بيخلّيك تكتشف نقاط الضعف دي في بيئة staging في ساعتين، بدل ما تتفاجأ بيها 3 الفجر مع تليفون من العميل. ده مش فلسفة فضفاضة؛ ده experiment محدد بـ YAML وأرقام قياس فعلية.

Chaos Engineering في Kubernetes: تكسير محسوب بدل انهيار مفاجئ

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

أغلب الأنظمة شغّالة تمام في staging لأن الـ pods كلها صحية، الـ DB متاحة، والـ network مستقرة. لكن في الإنتاج بيحصل اللي مش متوقع: الـ DNS أحياناً بيفشل لـ 4 ثواني، الـ node بياخد reboot أثناء الـ midnight maintenance، وملف لوج كبير بيملأ الـ disk فجأة. لو ما اختبرتش الفشل ده عمداً وأنت قاعد على مكتبك، أول مرة هتشوفه فيها هتكون لما الموقع يقع والـ Slack بيرن.

مثال للمبتدئ: شركة الكهربا

لما شركة الكهربا تختبر شبكة الطوارئ، هي مش بتنتظر العاصفة. هي بتفصل خط رئيسي عمداً يوم الإجازة الفجر علشان تتأكد إن الـ generator الاحتياطي بيشتغل تلقائياً والمنطقة ما تطفّيش. بدل ما تكتشف إن الـ generator مش شغّال يوم الإعصار الحقيقي، اكتشفه يوم تجربة محسوبة. Chaos Engineering هو نفس الفكرة بالظبط على السيرفرات: تفصل pod عمداً، وتقيس بالثانية إن الـ replica الاحتياطي شال الترافيك من غير ما المستخدم يحس.

التعريف العلمي

حسب principlesofchaos.org — الوثيقة اللي خرجت من فريق Netflix بعد تجربة Simian Army في 2014 — Chaos Engineering هو "تخصص يقوم على إجراء تجارب على نظام بهدف بناء الثقة في قدرته على تحمّل ظروف اضطراب في الإنتاج". الفكرة الجوهرية: بدل ما تتمنى إن النظام يتحمل، حدد فرضية مقاسة (مثلاً "الـ p99 latency هيفضل تحت 300ms حتى لو وقع 30% من الـ pods")، شغّل experiment، اقيس النتيجة، وعدّل الكود لو الفرضية فشلت. الفرضية بدون قياس مش experiment، دي مجرد تمنّي.

تركيب Chaos Mesh وتشغيل أول Experiment

Chaos Mesh أداة CNCF Sandbox مفتوحة المصدر، بتدير experiments على Kubernetes كـ CRDs. التركيب على cluster تجريبي بأمر Helm واحد:

helm repo add chaos-mesh https://charts.chaos-mesh.org
kubectl create ns chaos-mesh
helm install chaos-mesh chaos-mesh/chaos-mesh \
  -n chaos-mesh --version 2.6.3 \
  --set chaosDaemon.runtime=containerd \
  --set chaosDaemon.socketPath=/run/containerd/containerd.sock

بعد كده، عرّف experiment يقتل 30% من الـ pods في namespace اسمه staging كل 5 دقائق:

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: kill-30-percent
  namespace: chaos-mesh
spec:
  action: pod-kill
  mode: fixed-percent
  value: "30"
  selector:
    namespaces: [staging]
    labelSelectors:
      app: api-server
  scheduler:
    cron: "@every 5m"

طبّقه بـ kubectl apply -f podchaos.yaml. الـ Service هيفقد 30% من الـ replicas لمدة 60 ثانية. لو الـ Deployment معمول صح: الـ replicas تتعوّض في 6 إلى 8 ثوانٍ بفضل الـ ReplicaSet controller، الـ p99 latency يطلع لـ 240ms بدل 80ms العادية، والـ error rate يفضل تحت 0.1%. لو الـ p99 طلع لـ 4 ثوانٍ والـ error rate وصل 12%، عندك مشكلة حقيقية في الـ readinessProbe أو الـ HPA cooldown — والمكسب إنك اكتشفتها على staging، مش على إنتاج.

الـ 4 سيناريوهات اللي تختبرها أولاً

1. PodChaos: قتل pod عشوائي. بيكشف لو الـ session sticky مش متظبط، أو الـ reconnect logic ضعيف، أو لو فيه in-memory state مش متخزن في Redis.
2. NetworkChaos: latency 200ms مفروض بين microservices. بيكشف الـ timeouts اللي مش مضبوطة (default 30s غالباً غلط)، والـ retry storms.
3. StressChaos: استهلاك CPU 90% على pod محدد. بيكشف لو الـ HorizontalPodAutoscaler بيفعّل scale-out في الوقت اللي حاطّه في الـ SLO، ولا بيتأخر دقيقتين.
4. IOChaos: تأخير قراءة الـ disk بـ 500ms. بيكشف لو الـ caching layer (Redis، CDN، in-process cache) شغّال فعلاً ولا الـ DB بتتقري في كل request.

أرقام مقاسة من Production حقيقي

حسب تقرير State of Chaos Engineering 2023 من Gremlin، الفرق اللي بتشغّل Chaos Engineering منتظم (شهرياً على الأقل) سجّلت: متوسط MTTR بقى 26 دقيقة بدل 79 دقيقة، عدد الـ incidents شهرياً انخفض 36%، و30% تقريباً من نقاط الضعف بتتلاقى قبل ما توصل للإنتاج. Netflix نفسها بتشغّل Chaos Monkey منذ 2011 على آلاف الـ instances يومياً، والنتيجة اللي اشتهرت: تطبيق Netflix استمر شغّال أثناء AWS US-East-1 outage الكبير في 2012 لأن البنية التحتية كانت متعوّدة على فقدان instances كل يوم.

Trade-offs اللي لازم تعرفها

• المكسب: ثقة قابلة للقياس في النظام، اكتشاف bugs قبل العميل، تقليل MTTR لما incident حقيقي يحصل لأن الفريق متمرّن على الفشل ومش بيتفاجأ.
• التكلفة: يوم تركيب وإعداد لـ Chaos Mesh، ساعتين تخطيط لكل experiment جديد، واحتمال إن أول 5 إلى 10 experiments تكشف bugs خطيرة محتاج تتعمل reroll قبل ما تكمل.
• الخطر الحقيقي: لو شغّلت experiment بدون scope محدد على إنتاج فعلي، ممكن تسقّط النظام بنفسك. القاعدة: ابدأ على staging دايماً، استخدم namespace selector صريح، وحدد blast radius صغير (5 إلى 10% من الـ pods فقط في أول جلسة).

متى لا تستخدم Chaos Engineering

الأداة دي ليها شروط ومش مناسبة لكل فريق ولا كل مرحلة:

• لو التطبيق لسه مش deployed في staging يحاكي الإنتاج بشكل واقعي. الـ chaos على بيئة فيها 3 pods بدون real traffic مفيهوش معنى.
• لو ما عندكش observability كامل (Prometheus + Grafana + distributed tracing على الأقل). الـ experiment بدون metrics زي حقن دواء بدون فحص دم — مش هتعرف الفرق.
• لو الفريق أقل من 3 مهندسين والـ MVP لسه مش جاهز. ركّز على الـ shipping أولاً، الـ resilience بعدين.
• لو شغّال على نظام طبي أو مالي حسّاس بدون مراجعة قانونية ومراجعة من الـ compliance team. الـ chaos لازم تتم في بيئة معتمدة فقط.

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

نزّل minikube أو kind على جهازك، ثبّت Chaos Mesh بأمر الـ Helm اللي فوق، اعمل deployment لـ nginx بـ 5 replicas، وشغّل أول PodChaos experiment يقتل pod واحد كل دقيقة لمدة 10 دقائق. اقيس time-to-recovery من الـ Grafana. لو طلع أكتر من 30 ثانية، شوف الـ readinessProbe وقلّل الـ periodSeconds لـ 5 وجرّب تاني. ده الفرق العملي بين تطبيق "بيقع" وتطبيق "بيتعافى".

المصادر

• principlesofchaos.org — Principles of Chaos Engineering
• Chaos Mesh Official Documentation (CNCF Sandbox)
• Netflix Tech Blog — The Netflix Simian Army
• كتاب Chaos Engineering: System Resiliency in Practice — Casey Rosenthal & Nora Jones, O'Reilly Media 2020
• Gremlin — State of Chaos Engineering Report 2023
• Kubernetes Docs — Liveness, Readiness and Startup Probes