عندما يتخذ نشرك القرار بنفسه: أتمتة قرارات التراجع والترقية

لقد نشرت للتو إصدارًا جديدًا من واجهة API الخاصة بك. بعد خمس دقائق، يقفز معدل الأخطاء من 0.1% إلى 4%. أنت في اجتماع. بحلول الوقت الذي تتفقد فيه لوحة التحكم، تكون خمس عشرة دقيقة قد مرت. المستخدمون بدأوا بالفعل في الشكوى.

تخيل الآن أن هذا يحدث ثلاث مرات في الأسبوع. في كل مرة، يجب على شخص ما ملاحظة الارتفاع، فتح أداة المراقبة، تفسير الأرقام، اتخاذ قرار بشأن ما يجب فعله، ثم تشغيل التراجع أو الإيقاف يدويًا. بالنسبة لفريق يقوم بنشرات متعددة يوميًا، تصبح حلقة القرار اليدوية هذه مرهقة. والأسوأ من ذلك، أنها غير متسقة. قد يقوم مهندس بالتراجع عند معدل خطأ 2%. قد ينتظر آخر حتى 5%. قد لا يلاحظ ثالث على الإطلاق حتى يقوم شخص ما بإرسال تنبيه له في الدردشة.

هذه هي المشكلة التي تحلها بوابات النشر (Deployment Gates). بوابة النشر هي نقطة تفتيش آلية تقرر ما إذا كان يمكن للإصدار الجديد الانتقال إلى المرحلة التالية أو يجب إيقافه. البوابة لا تخمن. إنها تتبع سياسة: مجموعة من القواعد تقول، "إذا تجاوزت هذه الإشارة ذلك الحد، قم بهذا الإجراء."

كيف تعمل بوابة النشر

فكر في البوابة كحارس عند مدخل النادي. الحارس لا يعرف من أنت.他只是 يتحقق: هل أنت على القائمة؟ هل هويتك صالحة؟ إذا كانت الإجابة بنعم، تدخل. إذا لا، تنتظر أو تغادر.

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

يوضح الرسم البياني أدناه النتائج الثلاث المحتملة بعد أن تتحقق البوابة من إشارات المراقبة.

flowchart TD A[نشر الإصدار الجديد لمجموعة فرعية] --> B[التحقق من إشارات المراقبة] B --> C{الإشارات سليمة؟} C -->|نعم| D[الترقية لمزيد من المستخدمين] C -->|لا| E{شدة المشكلة؟} E -->|طفيفة| F[إيقاف - إبقاء الإصدار قيد التشغيل، إيقاف الترقية] E -->|كبيرة| G[التراجع إلى الإصدار السابق] E -->|غير مؤكدة| H[تعليق - إبقاء الإصدار قيد التشغيل، مراجعة يدوية]

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

مكونات السياسة

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

بالنسبة للتطبيق، قد تتحقق السياسة من:

  • معدل الأخطاء مقارنة بخط الأساس لـ SLO
  • زمن الاستجابة عند المئين 95 أو 99
  • انخفاض الإنتاجية الذي يشير إلى أن الخدمة ترفض الطلبات

بالنسبة لترحيل قاعدة البيانات، قد تتحقق السياسة من:

  • تأخير النسخ المتماثل بين الأساسي والنسخ
  • عدد الاستعلامات البطيئة بعد الترحيل
  • استنفاد مجموعة الاتصالات

بالنسبة لتغييرات البنية التحتية، قد تتحقق السياسة من:

  • صحة العقد في الكتلة
  • أنماط استخدام وحدة المعالجة المركزية والذاكرة
  • عدد مرات إعادة تشغيل البودات

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

فيما يلي مثال بسيط لسياسة كرمز (Policy as Code) تنفذ المنطق الموصوف أعلاه:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: api-deployment
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  service:
    port: 8080
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: error-rate
      thresholdRange:
        max: 0.05
      interval: 2m
    - name: request-duration
      thresholdRange:
        max: 0.5
      interval: 2m
    webhooks:
    - name: rollback-on-failure
      timeout: 30s
      metadata:
        action: rollback

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

استخدام ميزانية الأخطاء كمرتكز للسياسة

تمنحك ميزانية الأخطاء رقمًا عمليًا لتضعه في سياستك. إذا حدد فريقك SLO لتوفر 99.9%، فلديك حوالي 43 دقيقة من وقت التوقف المسموح به شهريًا. هذه هي ميزانية الأخطاء الخاصة بك.

تخيل الآن أن نشرًا جديدًا يستهلك 10 دقائق من تلك الميزانية في الساعة الأولى. هذه إشارة قوية على أن هناك خطأ ما. يمكن للسياسة أن تقول: "إذا استهلك الإصدار الجديد أكثر من 5% من ميزانية الأخطاء الشهرية في أول 30 دقيقة، قم بالتراجع تلقائيًا."

هذا النهج يزيل التخمين. وافق الفريق على SLO. السياسة تفرضه. لا أحد يحتاج إلى الجدال حول ما إذا كانت 10 دقائق كثيرة جدًا. الرقم محدد بالفعل.

ليست كل القرارات تحتاج إلى تراجع

الخطأ الشائع هو جعل كل سياسة تنتهي بتراجع. هذا عدواني جدًا للعديد من المواقف. النهج الأفضل هو السياسات متعددة المستويات.

مثال:

  • إذا زاد معدل الأخطاء بنسبة 0.5% لكنه بقي تحت حد SLO، قم بتشغيل إيقاف (Hold). يبقى الإصدار الجديد قيد التشغيل لكن لا يتم ترقيته لمزيد من المستخدمين. يحقق الفريق دون ضغط.
  • إذا تجاوز معدل الأخطاء حد SLO، قم بتشغيل تراجع (Rollback). يعود النظام إلى الإصدار السابق فورًا.
  • إذا زاد زمن الاستجابة لكن معدل الأخطاء مستقر، قم بتشغيل تعليق (Pause). لا تتم أي ترقية أخرى، لكن الإصدار الحالي يستمر في العمل. يقرر الفريق يدويًا ما إذا كان سيواصل أو يتراجع.

هذا النهج متعدد المستويات يمنح الفريق مساحة للتعامل مع مستويات مختلفة من الشدة دون رد فعل مفرط أو غير كاف.

ما تحتاجه لجعل هذا يعمل

تتطلب بوابات النشر تكاملًا بين نظام المراقبة ومنصة النشر الخاصة بك. يجب أن تكون الإشارات من المراقبة قابلة للقراءة من قبل خط الأنابيب أو المنصة التي تدير النشرات.

أدوات مثل Argo Rollouts و Flagger و Spinnaker تدعم هذا النمط بالفعل. يمكنها سحب المقاييس من Prometheus أو Datadog أو New Relic أو أي مصدر مقاييس آخر. تقوم بتكوين السياسة، وتنفذ الأداة القرار.

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

  • ما هي الإشارات المهمة لكل نوع من النشر
  • ما هي الحدود التي تشير إلى مشكلة حقيقية مقابل ضوضاء
  • مدى سرعة رد فعلك لمستويات الشدة المختلفة للفشل

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

هل من الآمن ترك النظام يقرر؟

هذا السؤال يظهر في كل مرة. الجواب هو: يعتمد على مدى جودة تعريفك للسياسة.

السياسة الجيدة لا تحل محل الحكم البشري تمامًا. إنها تتولى القرارات المتوقعة بالفعل. إذا كان الفريق يعلم أن معدل الأخطاء فوق 2% لمدة خمس دقائق يؤدي دائمًا إلى تراجع، فلماذا الانتظار حتى يقوم إنسان بذلك؟ قم بأتمتة هذا القرار.

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

الهدف ليس إزالة البشر من الحلقة. الهدف هو إزالة البشر من القرارات المملة والمتكررة والمتوقعة حتى يتمكنوا من التركيز على تلك التي تحتاج فعليًا إلى سياق وحكم.

قائمة مراجعة سريعة للبدء

قبل بناء أول بوابة نشر لك، تأكد من توفر ما يلي:

  • إشارة مراقبة واحدة تثق بها (ابدأ بمعدل الأخطاء أو زمن الاستجابة)
  • حد واضح بناءً على SLO أو ميزانية الأخطاء الخاصة بك
  • منصة نشر تدعم البوابات (Argo Rollouts أو Flagger أو Spinnaker أو ما شابه)
  • آلية تجاوز للتدخل اليدوي
  • إيقاع مراجعة للتحقق من فعالية السياسة كل أسبوعين

لا تحاول بناء سياسة مثالية في اليوم الأول. ابدأ ببوابة واحدة، إشارة واحدة، إجراء واحد. تعلم من النتائج. توسع من هناك.

القيمة الحقيقية هي الاتساق

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

عندما تكون قرارات النشر الخاصة بك مؤتمتة بواسطة السياسة، يمكن لفريقك النشر بشكل متكرر دون إرهاق. النظام يتعامل مع أحكام القرار الروتينية. فريقك يتعامل مع الاستثناءات والتحسينات. هذا هو الفرق بين فريق ينشر بشكل متكرر وفريق ينشر بشكل مستدام.