استراتيجيات النشر والتسليم التدريجي

إصدارات الكناري

18 دقيقة الدرس 4 من 28

إصدارات الكناري

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

تقع إصدارات الكناري بين أسلوب التبديل الأزرق-الأخضر (من 0% إلى 100% في خطوة واحدة) والنشر المتجدد (الذي يخلط الإصدارات عبر جميع الحاويات بشكل موحد). الخاصية المميزة هي التحويل التدريجي المتعمد للحركة مع التحليل الآلي بين كل خطوة. تستخدم شركات جوجل ونتفليكس وأمازون وأوبر إصدارات الكناري كمسار افتراضي للإنتاج للخدمات عديمة الحالة.

آليات تحويل الحركة

يتم تقسيم الحركة على مستوى موازن التحميل أو شبكة الخدمات، وليس على مستوى التطبيق. تنفيذان شائعان:

التوجيه الموزون — يرسل موازن التحميل N% من الطلبات إلى مجموعة حاويات الكناري و(100−N)% إلى المجموعة المستقرة. توفر هذه الآلية خدمات AWS Application Load Balancer ونجنكس وIstio وArgo Rollouts.
تثبيت الترويسة أو ملف تعريف الارتباط — يُوجَّه مستخدمون محددون دائماً إلى الكناري (الموظفون الداخليون، المشتركون في النسخة التجريبية، أو نسبة ثابتة بناءً على معرف المستخدم). يتيح هذا جلسات قابلة للتكرار للتصحيح لكنه لا يغطي الحركة الحقيقية العشوائية.

مثال كامل لمواصفات الكناري في Argo Rollouts مع خطوات متدرجة:

# rollout.yaml — استراتيجية الكناري في Argo Rollouts
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payment-service
  namespace: production
spec:
  replicas: 20
  selector:
    matchLabels:
      app: payment-service
  template:
    metadata:
      labels:
        app: payment-service
    spec:
      containers:
        - name: payment-service
          image: registry.example.com/payment-service:2.14.0
          ports:
            - containerPort: 8080
  strategy:
    canary:
      canaryService: payment-service-canary
      stableService: payment-service-stable
      trafficRouting:
        istio:
          virtualService:
            name: payment-service-vsvc
            routes:
              - primary
      steps:
        - setWeight: 5        # الخطوة 1 — 5% حركة، انتظار 10 دقائق
        - pause: {duration: 10m}
        - setWeight: 20       # الخطوة 2 — 20% حركة، انتظار 20 دقيقة
        - pause: {duration: 20m}
        - setWeight: 50       # الخطوة 3 — 50%، نافذة تحليل آلي
        - analysis:
            templates:
              - templateName: success-rate-check
        - setWeight: 100      # الترقية الكاملة — تعمل فقط إذا نجح التحليل

يستعلم AnalysisTemplate المرافق من نظام المقاييس (Prometheus أو Datadog أو New Relic) ليقرر إما المتابعة أو الإلغاء:

# analysis-template.yaml — التحليل الآلي للكناري
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate-check
  namespace: production
spec:
  metrics:
    - name: success-rate
      interval: 1m
      successCondition: result[0] >= 0.99      # يُشترط معدل نجاح >= 99%
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{job="payment-service",
              version="canary", status!~"5.."}[5m]))
            /
            sum(rate(http_requests_total{job="payment-service",
              version="canary"}[5m]))
    - name: p99-latency
      interval: 1m
      successCondition: result[0] < 0.250      # p99 يجب أن يبقى تحت 250 مللي ثانية
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            histogram_quantile(0.99,
              sum(rate(http_request_duration_seconds_bucket{
                job="payment-service", version="canary"}[5m])) by (le))

نوافذ التحليل — المدة المثلى للنقع

نافذة التحليل هي الفترة بين زيادة وزن الحركة وقرار الترقية التالي. الخطأ في تحديدها هو أكثر أنماط فشل الكناري شيوعاً:

قصيرة جداً — ضوضاء إحصائية. مع 5% حركة فقط ونافذة مدتها دقيقتان، قد يكون لديك أقل من 100 عينة؛ طلب واحد بطيء يمكنه رفع P99 وتشغيل إيقاف تشغيل خاطئ، أو مشكلة في معدل الأخطاء الحقيقية قد لا تظهر بعد.
طويلة جداً — عمليات نشر بطيئة. مع 50% حركة ونقع لمدة 60 دقيقة، يستغرق النشر المكوّن من 10 خطوات أكثر من 10 ساعات، مما يدفع الفرق إلى التخلي عن هذا الانضباط.

قاعدة الإبهام في الشركات الكبرى: انقع لفترة كافية لجمع 1,000 طلب على الأقل لكل خطوة على مجموعة الكناري. عند 5% وزن لخدمة تعالج 500 طلباً في الثانية، يعني ذلك ~4 ثوانٍ من البيانات — وهو لا يكفي إحصائياً. إما رفع النسبة الدنيا للحركة إلى 10-20%، أو تمديد وقت النقع. تستخدم نتفليكس عادةً نوافذ نقع مدتها ساعة واحدة لكل خطوة للخدمات ذات حركة منخفضة، و5 دقائق للخدمات التي تتجاوز 10 آلاف طلب في الثانية.

الترقية والإلغاء الآليان

قوة إصدارات الكناري تكمن في إزالة الحكم البشري من المسار الحرج. تدفق كل نافذة تحليل هو:

خط أنابيب الترقية الآلية للكناري: تتقسم الحركة بين المجموعتين المستقرة والكناري؛ يستعلم محرك التحليل عن المقاييس ويقرر إما الترقية (زيادة الوزن) أو الإلغاء (التراجع عن الكناري).

عندما يصوّت محرك التحليل بـالإلغاء، تعيد Argo Rollouts وزن الكناري إلى 0% وتُعلّم عملية النشر بحالة Degraded. لم تُمَس النسخة المستقرة قط، لذلك لن يواجه المستخدمون أي انقطاع. هذه هي الميزة الحاسمة مقارنةً بالنشر المتجدد: فشل الكناري يظل معزولاً.

اختيار المقاييس الصحيحة

المقاييس التي تحللها تحدد ما إذا كانت بوابة الكناري ذات معنى أم مجرد إجراء شكلي. كحد أدنى، تتبع:

معدل الأخطاء — معدل HTTP 5xx، نسبة أخطاء gRPC، أو عدد الاستثناءات على مستوى التطبيق. هذه هي الإشارة الأهم على الإطلاق.
مئينيات الزمن الاستجابي — p50 وp95 وp99. قد يكون للإصدار الجديد نفس معدل الأخطاء لكن p99 أعلى بنسبة 40%، مما يُدهور اتفاقيات مستوى الخدمة بصمت.
الإشباع — نمو CPU والذاكرة لكل طلب. لا تظهر تسريبات الذاكرة إلا بعد تشغيل الكناري لمدة 30+ دقيقة.
مؤشرات الأداء الرئيسية للأعمال — معدل إضافة المنتجات للسلة، التحويل عند الدفع، نسبة النقر في نتائج البحث. المقاييس التقنية قد تبدو سليمة بينما يُدمر تراجع في واجهة المستخدم معدلات التحويل.

مقارنة الخط الأساسي تهمّ: لا تكتفِ بالتحقق من أن معدل أخطاء الكناري أقل من 1%. قارنه بـالخط الأساسي المستقر خلال نفس النافذة باستخدام نسبة مثل canary_error_rate / stable_error_rate < 1.1. يُصفّي هذا الارتفاعات المحيطية للحركة (هجمات DDoS، الطفرات المفاجئة) التي قد تُشغّل إيقافات تشغيل خاطئة.

أنماط الفشل في الإنتاج

أنماط الكناري السلبية الشائعة التي يجب تجنبها:

كسر تقارب الجلسة للتقسيم — إذا كان موازن التحميل يستخدم جلسات لاصقة، فسيُقفل المستخدمون الأوائل على الكناري إلى الأبد، مما يُدمر نسب الحركة. عطّل الجلسات اللاصقة لمجموعات الكناري، أو استخدم التوجيه المستند إلى الترويسات بدلاً من ذلك.
تغييرات مخطط قاعدة البيانات مع الكناري — إذا أسقطت هجرتك عموداً لا تزال حاويات النسخة المستقرة تقرأه، ستحصل فوراً على أخطاء 500 من الحاويات المستقرة. استخدم دائماً نمط Expand-Contract (الدرس 8) قبل أي كناري يمس المخطط.
تحليل تسمية الإصدار الخاطئ — إذا لم تتضمن مقاييس Prometheus الخاصة بك وسم version، يخلط استعلام التحليل بين بيانات المستقر والكناري، مما يجعل البوابة بلا معنى. ضع وسمات على كل شيء على مستوى شبكة الخدمات أو التطبيق.
شرط نجاح متشدد للغاية — اشتراط معدل نجاح 99.99% عند 5% حركة يُنتج إيقافات تشغيل خاطئة كثيرة تدفع المهندسين إلى تجاوز التحليل. دوّن العتبات بناءً على خطك الأساسي التاريخي، لا على المثالية النظرية.

الكناري على النطاق الواسع — ما تفعله شركات التقنية الكبرى فعلاً

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

الكناريات المحدودة بالمنطقة — انشر أولاً في منطقة AWS واحدة (مثل us-west-2)، راقب لمدة 30 دقيقة، ثم رقِّ عالمياً. نطاق الضرر على مستوى المنطقة أصغر بكثير من النشر العالمي.
حركة الظل (المرايا) — أرسل نسخة من جميع طلبات الإنتاج إلى حاوية الكناري دون إعادة استجابتها إلى المستخدمين. تُعالج الكناري الحمل الحقيقي بأمان، مما يتيح لك اكتشاف الذعر وأخطاء نفاد الذاكرة قبل توجيه أي حركة حقيقية إليها. يدعم Istio هذا عبر حقل mirror في VirtualService.
التراجع الآلي بناءً على معدل استهلاك ميزانية SLO — بدلاً من عتبة معدل خطأ ثابتة، شغّل الإلغاء عندما يدخل معدل الاستهلاك (من تنبيه ميزانية الخطأ متعدد النوافذ) منطقة الاحتراق السريع. يربط هذا بوابة الكناري مباشرةً بالتزاماتك في اتفاقيات مستوى الخدمة.

سير عمل كناري GitOps: تجمع الفرق الأكثر نضجاً بين Argo Rollouts وArgo CD. يُحدّث الدمج في main وسم الصورة في ملف قيم Helm؛ يكتشف Argo CD الانجراف ويزامن؛ تُشغّل Argo Rollouts خطوات الكناري آلياً. لا يلمس أي إنسان المجموعة. تظهر حالة النشر كبيئة GitHub Deployment، مما يوفر سجل تدقيق كامل لكل إيداع.