هندسة الفوضى والمرونة

أدوات الفوضى

18 دقيقة الدرس 6 من 27

أدوات الفوضى

لا تكون هندسة الفوضى صارمةً ومنضبطةً إلا بقدر الأدوات التي تُنفِّذها. تشغيل kill -9 في سكريبت شل ليس هندسةَ فوضى — بل هو انقطاع خدمة. توفر أدوات الفوضى الاحترافية ضوابط نطاق التأثير، وفحوصات الحالة المستقرة الآلية، وسجلات التدقيق، وخطافات التراجع، والتكامل مع منظومة CI/CD والمراقبة. يستعرض هذا الدرس الأدوات الأربع المهيمنة على برامج الفوضى الإنتاجية في 2025: Chaos Monkey (السلالة التي أطلقتها Netflix)، وLitmus (اختيار CNCF لـ Kubernetes)، وChaos Mesh (مشغّل Kubernetes الأغنى بالميزات)، وAWS Fault Injection Service (الخيار المُدار للمؤسسات المعتمدة على AWS). ستخرج من هذا الدرس مُلمًّا بما تفعله كل أداة، ومتى تلجأ إليها، وكيف تشغّلها بأمان.

Chaos Monkey وسلالة Netflix

أطلقت Netflix الكود المصدري لـ Chaos Monkey عام 2012 بوصفه خادم خلفي يُنهي نسخ EC2 عشوائيًا خلال ساعات العمل. كانت الفلسفة صريحة: إن كنت تخشى إيقاف نسخة عشوائية، فأنت لم تبنِ التكرار الذي تستوجبه اتفاقيات مستوى الخدمة — أصلح ذلك قبل أن تفعل الطبيعة. أُعيدت كتابة Chaos Monkey الأصلية بـ Go، وتطورت إلى منظومة Simian Army ثم ChAP، غير أن الفكرة الجوهرية ظلت راسخة.

تُشغّل Netflix Chaos Monkey بصفة مستمرة في بيئة الإنتاج. يشترك كل فريق خدمة طوعًا (أو اشتراكًا إلزاميًا وفق السياسة). يستدعي الخادم الخلفي AWS API لإيقاف النسخ في مجموعات التوسع التلقائي (ASG)، مع احترام حدٍّ أدنى قابل للإعداد يضمن عدم إيقاف أكثر من نسخة واحدة في أي وقت. كل عملية إيقاف مُصنَّفة بسبب ومرتبطة بـ Atlаs (مخزن المقاييس الداخلي لـ Netflix) لتكون مرئية فورًا في لوحات المعلومات.

الدرس الأساسي من سلالة Netflix: يجب أن تعمل الفوضى باستمرار وتلقائيًا، وليس فقط خلال أيام اللعب. توقف فرق Netflix عن الخوف من الإنهاء العشوائي تحديدًا لأنه يحدث كل أسبوع — فهم مضطرون للبناء على هذا الأساس. شغّل الفوضى وفق جدول زمني، لا كتمرين استثنائي.

الملف الثنائي chaos-monkey المكتوب بـ Go قابل للإعداد عبر REST API وتكامل مع Spinnaker. للفرق غير المستخدمة لبنية Netflix، يمكن تطبيق المبدأ بـ CronJob يستدعي kubectl delete pod عشوائيًا خلال ساعات العمل — مبدئيًا للبدء قبل الحاجة إلى ضوابط على مستوى التجارب.

Litmus: فوضى Kubernetes-Native من CNCF

يُعدّ Litmus (LitmusChaos، تخرّج من CNCF عام 2022) منصة الفوضى المرجعية لـ Kubernetes. يُصوِّر كل تجربة كـ ChaosEngine — موردٍ مخصص. توفر لوحة التحكم (LitmusPortal) داخل المجموعة واجهة مستخدم وجدولة وـ RBAC وتكاملًا مع GitOps. التجارب عبارة عن CRDs مُصدَّرة قابلة للمشاركة، محمية في مركز عام على hub.litmuschaos.io.

يُثبِّت إعداد Litmus النموذجي المشغّل ويُنشئ تعريفَي موارد مخصصَين، ثم يُشير إلى التجارب المُجهَّزة مسبقًا بالاسم. تُحكم مواصفة المحرك التجربة بالعبء المستهدف، وتُحقن فيها مجسّات الحالة المستقرة، وتُصدر حكمًا: نجاح (ثبتت الحالة المستقرة طوال نافذة التجربة) أو فشل (انتهاك SLO).

# تثبيت Litmus 3.x عبر Helm
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update
helm install chaos litmuschaos/litmus \
  --namespace=litmus --create-namespace \
  --set portal.frontend.service.type=ClusterIP

# تطبيق تجربة حذف pod مُجهَّزة مسبقًا من ChaosHub
kubectl apply -f https://hub.litmuschaos.io/api/chaos/3.0.0?file=charts/generic/pod-delete/experiment.yaml \
  -n litmus

# ChaosEngine تستهدف خدمة المدفوعات
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: payments-pod-delete
  namespace: payments
spec:
  appinfo:
    appns: payments
    applabel: "app=payments-api"
    appkind: deployment
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"          # بالثواني
            - name: CHAOS_INTERVAL
              value: "20"          # حذف كل N ثانية
            - name: FORCE
              value: "false"       # حذف لطيف (SIGTERM أولًا)
            - name: PODS_AFFECTED_PERC
              value: "50"          # أقصى 50% من الـ pods المطابقة
  steadyStateHypothesis:
    title: "زمن استجابة P99 للمدفوعات أقل من 300 ms"
    probes:
      - name: prom-latency-probe
        type: promProbe
        mode: Continuous
        runProperties:
          probeTimeout: 5
          interval: 10
          retry: 2
        promProbe/inputs:
          endpoint: "http://prometheus.monitoring:9090"
          query: 'histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{service="payments"}[1m])) by (le))'
          comparator:
            type: float
            criteria: "<="
            value: "0.3"

المجسّات هي أهم عناصر تجربة Litmus. بدون promProbe أو httpProbe يتحقق من SLO طوال نافذة الفوضى، لا تقول التجربة شيئًا — بل تحذف pods فحسب. احرص دائمًا على تعريف مجسّ مستمر واحد على الأقل مرتبط بمقياس حقيقي يواجه المستخدم.

يتكامل Litmus أصلًا مع Argo Workflows لتشغيل الفوضى بوصفها مرحلة في خطوط الأنابيب (شغّل التجربة → انتظر الحكم → بوّب مرحلة النشر التالية). كما يدعم جدولة الفوضى عبر CRDs من نوع ChaosSchedule، ما يتيح تجارب دورية تحاكي فلسفة Chaos Monkey في الاشتغال الدائم.

Chaos Mesh: مشغّل فوضى Kubernetes غني بالميزات

بنت PingCAP (صانعة TiDB) Chaos Mesh، وهو الآن مشروع في CNCF sandbox. يتبنى Chaos Mesh نطاقًا أوسع من Litmus؛ إذ يوفر مجموعة أغنى من أنواع الأخطاء المدمجة، وAPI محاكاة شبكة أدق — يشمل التحكم في عرض النطاق الترددي، وإعادة ترتيب الحزم، والتقسيم وفق محدد التسميات.

معمارية Chaos Mesh: تكتب لوحة التحكم CRDs، يُطابقها Controller Manager، وينفّذ Chaos Daemon المُميَّز الأخطاء على مستوى النواة والشبكة في كل عقدة.

يعمل Chaos Daemon كـ DaemonSet مُميَّز بصلاحية الوصول إلى PID المضيف وفضاء أسماء الشبكة. هذا ما يجعل الأخطاء على مستوى الشبكة — قواعد tc netem الفعلية، وقطرات iptables، وتحديد عرض النطاق — دقيقةً لا محاكاةً على مستوى التطبيق. غير أن ذلك يعني ضرورة مراجعة RBAC للـ daemon بعناية في المجموعات متعددة المستأجرين.

# تثبيت Chaos Mesh عبر Helm (Kubernetes 1.26+)
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update
helm install chaos-mesh chaos-mesh/chaos-mesh \
  --namespace=chaos-mesh --create-namespace \
  --set chaosDaemon.runtime=containerd \
  --set chaosDaemon.socketPath=/run/containerd/containerd.sock

# NetworkChaos: حقن تأخير 200 ms وتذبذب 20 ms في خدمة المخزون
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: inventory-latency
  namespace: inventory
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - inventory
    labelSelectors:
      app: inventory-api
  delay:
    latency: "200ms"
    jitter: "20ms"
    correlation: "25"
  duration: "5m"
  direction: to

---
# PodChaos: قتل pod عشوائية واحدة كل 90 ثانية
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: inventory-pod-kill
  namespace: inventory
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - inventory
    labelSelectors:
      app: inventory-api
  scheduler:
    cron: "@every 90s"

لا تشغّل Chaos Mesh بوضع mode: all على نطاق إنتاجي دون حد duration وسياسة تراجع آلي. يحترم المتحكم حقل duration ويُزيل الأخطاء المُحقَنة تلقائيًا عند انتهائها — لكن إن تعطّل نطاق chaos-mesh ذاته، ستحتاج مسارًا يدويًا للتنظيف. اختبر دائمًا تدفقَي الإيقاف المؤقت والحذف في الاختبار قبل الإنتاج.

AWS Fault Injection Service (FIS)

AWS FIS، المتاح رسميًا منذ مارس 2021، هو لوحة التحكم المُدارة للفوضى على مستوى البنية التحتية في AWS. يعمل على مبادئ IAM — تمنح FIS دورًا تنفيذيًا يسمح بإجراءات أخطاء محددة، ولا يحتاج إلى RBAC داخل المجموعة. يجعله ذلك الخيار الطبيعي للمؤسسات الثقيلة الاعتماد على AWS التي تريد فوضى دون تشغيل مشغّل داخلي.

يُصوِّر FIS التجارب كـ ExperimentTemplates. يحدد كل قالب: مجموعة إجراءات (كل منها بدائي خطأ AWS)، وأهداف (مُصفَّاة بالوسوم أو ARNs أو نسبة عشوائية)، وشروط إيقاف (إنذارات CloudWatch تُوقف التجربة تلقائيًا)، ودور IAM. شروط الإيقاف هي البدائي الأمني الأساسي — اربطها بإنذارات معدل الأخطاء أو الكمون لتتراجع FIS ذاتيًا إن تجاوز التأثير المتوقع.

# قالب تجربة FIS (JSON عبر AWS CLI) — إجهاد CPU على 25% من نسخ EC2 الموسومة
aws fis create-experiment-template --cli-input-json '{
  "description": "CPU stress on api-server fleet",
  "targets": {
    "ApiServers": {
      "resourceType": "aws:ec2:instance",
      "resourceTags": {"Role": "api-server", "Env": "prod"},
      "selectionMode": "PERCENT(25)"
    }
  },
  "actions": {
    "cpu-stress": {
      "actionId": "aws:ssm:send-command",
      "description": "stress-ng 60s via SSM",
      "parameters": {
        "documentArn": "arn:aws:ssm:::document/AWSFIS-Run-CPU-Stress",
        "documentParameters": "{\"DurationSeconds\":\"60\",\"CPU\":\"0\",\"InstallDependencies\":\"True\"}",
        "duration": "PT2M"
      },
      "targets": {"Instances": "ApiServers"}
    }
  },
  "stopConditions": [
    {
      "source": "aws:cloudwatch:alarm",
      "value": "arn:aws:cloudwatch:us-east-1:123456789012:alarm:api-error-rate-high"
    }
  ],
  "roleArn": "arn:aws:iam::123456789012:role/FISExperimentRole",
  "tags": {"Purpose": "chaos-cpu-resilience"}
}'

# بدء التجربة
aws fis start-experiment --experiment-template-id EXT123EXAMPLE

يدعم FIS أكثر من 50 إجراء خطأ مدمجًا في 2025: إيقاف نسخ EC2 وإيقافها مؤقتًا وإجهادها بـ CPU، وإيقاف pods على EKS، والتبديل عند الإخفاق في RDS، وإعادة تشغيل مدير ElastiCache الأساسي، وتقليص S3، وتأخير الشبكة عبر تعطيل شبكة VPC، ومحاكاة مقاطعة Spot. يتكامل مع AWS Systems Manager (SSM) للأخطاء داخل المضيف دون إدارة عامل ثنائي.

استخدم دائمًا شروط إيقاف FIS مرتبطة بإنذارات CloudWatch حقيقية — لا إنذارات وهمية. يجب أن يكون دور التجربة محدود الصلاحيات: فقط إجراءات fis:* وخدمة الهدف الضرورية. راجعه بـ IAM Access Analyzer قبل أول تشغيل إنتاجي. يوفر FIS أيضًا سجل تجربة إلى CloudWatch وS3 — فعّله؛ ستحتاج المسار التدقيقي لمراجعات ما بعد الحوادث.

اختيار الأداة المناسبة

تستخدم المؤسسات الكبيرة عمليًا أكثر من أداة: FIS لأخطاء البنية التحتية الأصيلة في AWS (تبديل RDS عند الإخفاق، محاكاة مقاطعة Spot)، وLitmus أو Chaos Mesh لأخطاء تطبيقات Kubernetes (قتل pods، تقسيم الشبكة، إجهاد CPU/ذاكرة على مستوى الحاوية). يتصدر Litmus بالنظام البيئي (ChaosHub، تكامل Argo، GitOps). يتميز Chaos Mesh بدقة أخطاء الشبكة. يتفوق FIS بصفر تكاليف تشغيلية لعملاء AWS. تبقى فلسفة Chaos Monkey — دائمة التشغيل، آلية، مستمرة — سارية بصرف النظر عن الأداة التي تُنفّذها.