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

الفوضى المستمرة ونماذج النضج

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

الفوضى المستمرة ونماذج النضج

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

يغطي هذا الدرس نصفَي ممارسة الفوضى الناضجة: آليات دمجها في خطوط الأنابيب، والنموذج التنظيمي الذي يخبرك بصدق أين أنت وما الخطوة التالية.

لماذا لا تكفي التجارب الفردية؟

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

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

مفهوم أساسي: تجربة الفوضى التي تُجرى مرة واحدة لها عمر نصف يُقاس بالأسابيع. أما تجربة الفوضى التي تُجرى مع كل نشر فعمر نصفها يُقاس بالوقت اللازم لشحن الإصلاح التالي. الأتمتة هي ما يحوّل الفوضى من مشروع إلى ممارسة.

أين في خط الأنابيب تُجرى التجارب

لا تنتمي جميع التجارب إلى المرحلة ذاتها من خط الأنابيب. القاعدة هي: نطاق الانفجار يحدد مكان الوضع. التجارب التي تؤثر على حجرة (pod) واحدة أو شريحة حركة مرور اصطناعية يمكن تشغيلها في CI ضد مجموعة تجهيز. أما التجارب التي تُنهي مجموعات عقد كاملة أو تُشبع بنية تحتية حقيقية فتنتمي إلى بوابة ما قبل الإنتاج المخصصة، أو إلى الإنتاج بحارس canary.

يمتلك خط الأنابيب النموذجي في الشركات الكبرى ثلاث نقاط دمج للفوضى:

CI (تجهيز، حركة مرور اصطناعية): تجارب Litmus أو Chaos Mesh تقتل حجرة واحدة، أو تحقن ارتفاعًا في التأخير مقداره 200 ملي ثانية في اعتمادية وهمية، أو تستنزف ذاكرة حاوية sidecar. تعمل بسرعة (أقل من 5 دقائق)، وتبوّب كل دمج PR، ونطاق انفجارها هو فضاء أسماء اختبار. الفشل في SLO هنا يحجب الدمج.
بوابة ما قبل الإنتاج (تجهيز على نطاق واسع، حركة مرور معكوسة): تجارب تقتل 30% من مجموعة نسخ الخدمة، أو تقسّم مجموعة مستهلكي Kafka، أو تحقن إخفاقات DNS. تعمل بعد نجاح اختبارات التكامل، قبل الترقية للإنتاج. نطاق الانفجار بيئة واحدة. الفشل في البوابة يؤخر الإصدار.
الإنتاج (مستمر، منخفض الحدة): تجارب الحالة المستقرة تعمل بجدول زمني على نسبة صغيرة من البنية التحتية الإنتاجية. لا تحجب النشرات — بل تنبّه المناوب إذا انكسرت الحالة المستقرة.

ربط الفوضى بخط أنابيب CI/CD

يلي ذلك سير عمل GitHub Actions كامل يُشغّل تجربة Litmus ChaosEngine كبوابة ما بعد النشر في التجهيز. النمط الأساسي: انشر الخدمة، انتظر استقرارها، احقن العطل، قِس مؤشرات SLO عبر Prometheus، نظّف ثم احكم على النتيجة.

# .github/workflows/chaos-gate.yml
name: Chaos Gate

on:
  workflow_call:
    inputs:
      namespace:
        required: true
        type: string
      service:
        required: true
        type: string

jobs:
  chaos-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure kubectl
        run: |
          echo "${{ secrets.KUBECONFIG_STAGING }}" | base64 -d > /tmp/kube.yaml
          export KUBECONFIG=/tmp/kube.yaml

      - name: Wait for rollout
        run: |
          kubectl rollout status deployment/${{ inputs.service }} \
            -n ${{ inputs.namespace }} --timeout=5m

      - name: Capture pre-chaos SLO baseline
        id: baseline
        run: |
          ERROR_RATE=$(curl -sf \
            "http://prometheus.staging:9090/api/v1/query?query=\
            rate(http_requests_total{service%3D%22${{ inputs.service }}%22,status%3D~%225..%22}[2m])\
            /rate(http_requests_total{service%3D%22${{ inputs.service }}%22}[2m])" \
            | jq -r '.data.result[0].value[1] // "0"')
          echo "baseline_error_rate=$ERROR_RATE" >> "$GITHUB_OUTPUT"

      - name: Apply ChaosEngine
        run: |
          kubectl apply -f chaos/pod-kill-experiment.yaml \
            -n ${{ inputs.namespace }}

      - name: Wait for experiment to complete
        run: |
          for i in $(seq 1 30); do
            STATUS=$(kubectl get chaosengine chaos-pod-kill \
              -n ${{ inputs.namespace }} \
              -o jsonpath='{.status.engineStatus}')
            [ "$STATUS" = "completed" ] && break
            sleep 10
          done

      - name: Evaluate SLO verdict
        run: |
          ERROR_RATE=$(curl -sf \
            "http://prometheus.staging:9090/api/v1/query?query=\
            rate(http_requests_total{service%3D%22${{ inputs.service }}%22,status%3D~%225..%22}[5m])\
            /rate(http_requests_total{service%3D%22${{ inputs.service }}%22}[5m])" \
            | jq -r '.data.result[0].value[1] // "0"')
          python3 -c "
          rate = float('$ERROR_RATE')
          if rate > 0.01:
              print(f'FAIL: error rate {rate:.4f} exceeded 0.01 threshold')
              exit(1)
          print(f'PASS: error rate {rate:.4f} within SLO')
          "

      - name: Cleanup ChaosEngine
        if: always()
        run: |
          kubectl delete chaosengine chaos-pod-kill \
            -n ${{ inputs.namespace }} --ignore-not-found

يُعرّف ملف بيان التجربة المرفق بالضبط العطل المُحقَن ومدته والهدف المستهدف. الاحتفاظ بهذا الملف في التحكم بالإصدار جنبًا إلى جنب مع كود الخدمة يعني أن المطورين يستطيعون قراءة تهيئة الفوضى وتعديلها ومراجعتها تمامًا كما يفعلون مع اختبار الوحدة:

# chaos/pod-kill-experiment.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: chaos-pod-kill
spec:
  appinfo:
    appns: staging
    applabel: "app=payment-service"
    appkind: deployment
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"           # ثواني
            - name: CHAOS_INTERVAL
              value: "15"           # اقتل حجرة واحدة كل 15 ثانية
            - name: FORCE
              value: "false"        # SIGTERM لطيف، لا SIGKILL
            - name: PODS_AFFECTED_PERC
              value: "30"           # 30% من النسخ
  annotationCheck: "false"

ممارسة احترافية: التقط دائمًا خط أساس ما قبل الفوضى في نفس الخطوة التي تبدأ فيها التجربة، باستخدام نافذة استرجاع ثابتة (2 دقيقة). هذا يمنع النتائج الإيجابية الكاذبة من الارتفاعات العابرة التي كانت موجودة قبل حقن العطل. احفظ مقاييس ما قبل الفوضى وما بعدها كمصنوعات خط الأنابيب للوحة اتجاه المرونة.

جدولة تجارب الإنتاج المستمرة

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

يمتلك Gremlin وAWS Fault Injection Service جدولة أصلية. للفرق التي تعمل بالفعل مع Argo Workflows أو Kubernetes CronJobs، يُعدّ تغليف تجربة Litmus في CronJob أسلوبًا محليًا:

# k8s/chaos-cron.yaml — تنهي حجرة payment-service واحدة كل يوم عمل الساعة 10:30 صباحًا
apiVersion: batch/v1
kind: CronJob
metadata:
  name: chaos-pod-kill-daily
  namespace: chaos-system
spec:
  schedule: "30 10 * * 1-5"   # الإثنين-الجمعة 10:30 — ساعات العمل بالتصميم
  concurrencyPolicy: Forbid    # لا تشغّل تجربتين معًا أبدًا
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: litmus-admin
          containers:
            - name: chaos-runner
              image: litmuschaos/litmus-checker:latest
              args:
                - -file=/experiments/pod-kill.yaml
                - -saveName=/tmp/result
              volumeMounts:
                - name: experiment-config
                  mountPath: /experiments
          volumes:
            - name: experiment-config
              configMap:
                name: pod-kill-experiment
          restartPolicy: Never

فخ إنتاجي: جدولة تجارب الفوضى بدون مفتاح إيقاف عالمي أمر خطير. قبل تشغيل التجارب في الإنتاج، نفّذ علامة ميزة على مستوى البيئة (ConfigMap في Kubernetes، أو علامة LaunchDarkly، أو مفتاح بسيط في مخزن المعلمات) يتحقق منها مُشغّل الفوضى قبل حقن أي عطل. عند اندلاع حادثة غير ذات صلة، يحتاج مهندس المناوبة إلى إسكات جميع الفوضى بأمر واحد، لا إلى البحث عن ست CronJobs. لدى Chaos Monkey في Netflix واجهة برمجية للإيقاف المؤقت العالمي لهذا السبب بالذات.

نموذج نضج الفوضى

نموذج نضج الفوضى (الذي أشاعه Gremlin واعتمده معظم فرق SRE) يمنح المنظمات الهندسية طريقة منظمة لفهم مكانها في رحلة الفوضى وما هي الخطوة التالية الملموسة. يمتلك أربعة مستويات:

نموذج نضج الفوضى ذو المستويات الأربعة: من إطفاء الحرائق التفاعلي إلى التجريب المستمر المدفوع بمؤشرات SLO في الإنتاج.

المستوى الأول — تفاعلي: تُجري الفرقة تجارب الفوضى فقط بعد حادثة، لفهم ما حدث. لا يوجد تعريف للحالة المستقرة، ولا فرضية، ولا أتمتة. هذا هو المكان الذي تبدأ منه معظم المنظمات. الشرط المسبق للخروج من المستوى الأول هو وجود رؤية شغّالة.

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

المستوى الثالث — مندمج في خط الأنابيب: تعمل على الأقل مجموعة من التجارب تلقائيًا في خط التوصيل. تحجب بوابة الفوضى في CI النشرات السيئة قبل وصولها للإنتاج. التجارب منوّعة مع كود الخدمة. الشرط المسبق هو سلسلة أدوات فوضى ومؤشرات SLO محددة يمكنها أن تخدم كأحكام نجاح/فشل آلية.

المستوى الرابع — مستمر ومدفوع بمؤشرات SLO: التجارب تعمل بجدول زمني في الإنتاج. للبرنامج مفتاح إيقاف عالمي. تغذي النتائج لوحة اتجاه مرونة تراجعها القيادة الهندسية أسبوعيًا. تدفع نتائج التجارب خارطة الطريق: إذا أظهرت ثلاثة أسابيع متتالية من اختبارات قتل الحجرة ارتفاع وقت التعافي، يصبح ذلك تذكرة sprint. Netflix وGoogle SRE وAmazon في المستوى الرابع عبر معظم خدماتهم الحرجة. هذه هي الحالة المستهدفة.

قياس صحة برنامج الفوضى

يُنتج برنامج الفوضى الناضج مقاييسه الخاصة — لا مجرد المقاييس من التجارب. تتبع هذه المقاييس لإثبات صحة البرنامج للقيادة ولاكتشاف تراجع البرنامج ذاته:

تغطية التجارب: نسبة الخدمات التي تمتلك بوابة فوضى آلية واحدة على الأقل في خط أنابيبها. الهدف 100% للخدمات ذات SLO.
متوسط وقت الاكتشاف (chaos MTtD): مدى سرعة ظهور انتهاك SLO الناجم عن التجربة في تنبيه. يقيس جودة الرؤية. الهدف أقل من 60 ثانية.
معدل تأكيد الفرضيات: نسبة التجارب التي تصرّف فيها النظام كما هو متوقع. معدل تأكيد أقل من 70% يعني أن نظامك أقل مرونة مما تعتقد. معدل أعلى من 95% يعني أنك لا تُجري تجارب صعبة بما يكفي.
معدل التراجع: نسبة النشرات التي فشلت في بوابة الفوضى. تتبعه عبر الزمن — معدل تراجع متصاعد مؤشر قيادي على تدهور ثقافة المرونة.
وقت المعالجة: المدة من فشل بوابة الفوضى إلى دمج الإصلاح. هذا مقياس عناء المرونة.

ممارسة احترافية: ابنِ لوحة Grafana تُسمى "صحة برنامج الفوضى" تضم هذه المقاييس الخمسة كلوحات، تُحدَّث تلقائيًا من نظام CI/CD ومُشغّل الفوضى. اعرضها في مراجعة SRE الأسبوعية. حين تستطيع القيادة رؤية الاتجاه، تصبح الفوضى استثمارًا هندسيًا من الدرجة الأولى لا تجربة اختيارية. في Google، تُقاس فرق SRE بتغطية الفوضى كجزء من بطاقة أداء الموثوقية.

الانتقال من مستوى إلى آخر: خارطة طريق عملية

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

الدرس الأخير في هذا البرنامج التعليمي (الدرس العاشر) يطبق كل ما تعلمناه في السلسلة كاملة — بما فيها الفوضى المستمرة — على تصميم برنامج فوضى متكامل من الصفر لبنية خدمات مصغرة واقعية.