Chaos Engineering في Kubernetes للمتوسط: كسّر الـ Cluster عمداً قبل ما العميل يكسره

طبّقه بـ 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