عندما يقرر خط الأنابيب الخاص بك: أتمتة قرارات التوصيل التدريجي

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

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

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

كيف تعمل البوابات الآلية

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

إليك مثال ملموس. يبدأ خط الأنابيب الخاص بك بتوجيه 5% من حركة المرور إلى الإصدار الجديد. ينتظر لمدة خمس دقائق لتجميع البيانات. ثم يتحقق من ثلاثة أشياء:

  • هل معدل الخطأ للإصدار الجديد أقل من 0.1%؟
  • هل زمن الاستجابة ضمن 10% من خط الأساس للإصدار القديم؟
  • هل لا توجد زيادات كبيرة في استجابات 5xx؟

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

يُوضح المخطط الانسيابي التالي منطق اتخاذ القرار عند كل بوابة في خط الأنابيب:

flowchart TD A([البدء: 5% حركة مرور]) --> B[انتظار 5 دقائق للبيانات] B --> C{فحص المقاييس} C -->|جميعها ناجحة| D[المتابعة إلى 20%] C -->|حد التحذير| E[توقف - إخطار الفريق] C -->|حد حرج| F[التراجع إلى الإصدار القديم] D --> G[انتظار 5 دقائق] G --> H{فحص المقاييس} H -->|جميعها ناجحة| I[المتابعة إلى 50%] H -->|تحذير| J[توقف - إخطار الفريق] H -->|حرج| K[التراجع] I --> L[انتظار 5 دقائق] L --> M{فحص المقاييس} M -->|جميعها ناجحة| N[المتابعة إلى 100%] M -->|تحذير| O[توقف - إخطار الفريق] M -->|حرج| P[التراجع]

إليك ما قد يبدو عليه تكوين تلك البوابة في خط أنابيب قائم على YAML:

gates:
  - name: canary-5pct
    traffic: 5%
    wait: 5m
    checks:
      - metric: error_rate
        query: "sum(rate(http_requests_total{version='new', status=~'5..'}[5m])) / sum(rate(http_requests_total{version='new'}[5m]))"
        warning: 0.005
        critical: 0.02
        action_warning: hold
        action_critical: rollback
      - metric: latency_p99
        query: "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{version='new'}[5m])) by (le))"
        baseline: "histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{version='old'}[5m])) by (le))"
        warning: 1.10
        critical: 1.25
        action_warning: hold
        action_critical: rollback

يتحقق هذا التكوين من مقياسين بعد خمس دقائق عند 5% من حركة المرور. إذا تجاوز معدل الخطأ 0.5% (تحذير)، يتوقف خط الأنابيب. إذا تجاوز 2% (حرج)، فإنه يتراجع. تتم مقارنة زمن الاستجابة بخط الأساس للإصدار القديم، مع حدود مماثلة.

ثلاثة إجراءات محتملة: المتابعة أو التوقف أو التراجع

بمجرد أن يخترق مقياس ما حدًا معينًا، يكون أمام خط الأنابيب ثلاثة خيارات.

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

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

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

وضع الحدود: التحذير مقابل الحرج

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

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

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

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

ما يحتاجه خط الأنابيب لاتخاذ القرارات

يتطلب اتخاذ القرار الآلي ثلاثة أشياء تعمل معًا.

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

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

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

الأتمتة لا تحل محل البشر

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

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

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

قائمة مرجعية عملية سريعة

قبل تنفيذ بوابات القرار الآلية، تحقق من هذه الأساسيات:

  • هل يمكن لخط الأنابيب الخاص بك الاستعلام عن المقاييس من نظام المراقبة في الوقت الفعلي؟
  • هل لديك مقاييس خط الأساس من إصدارك المستقر الحالي؟
  • هل قمت بتعريف حدود التحذير والحرج لمعدل الخطأ وزمن الاستجابة واستجابات 5xx؟
  • هل يحتوي خط الأنابيب الخاص بك على آلية لإيقاف التقدم دون التراجع؟
  • هل تم تكوين الإخطارات للوصول إلى الأشخاص المناسبين عند حدوث توقف أو تراجع؟
  • هل اختبرت التراجع الآلي في بيئة اختبارية؟

ما التالي

بمجرد أن يتمكن خط الأنابيب الخاص بك من تحديد موعد المتابعة أو التوقف أو التراجع، فإن الخطوة التالية هي اختيار كيفية توزيع حركة المرور. هناك طريقتان شائعتان هما الإصدارات التجريبية (Canary releases) والطرح التدريجي (Staged rollouts). لكل منهما خصائص مختلفة لتوسيع نطاق الإصدار الجديد. يعتمد الاختيار الصحيح على بنية تطبيقك وكيفية تعامل بنيتك التحتية مع توجيه حركة المرور.

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