ثلاث أدوات للإصدارات الآمنة: حركة المرور والمجموعات وأعلام الميزات

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

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

حركة المرور: التحكم في حجم التحميل الذي يصل إلى الإصدار الجديد

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

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

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

فيما يلي مثال واقعي باستخدام VirtualService من Istio لتقسيم حركة المرور بنسبة 5% إلى الإصدار الجديد و95% إلى الإصدار القديم:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.example.com
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: myapp
        subset: v2
      weight: 5
    - destination:
        host: myapp
        subset: v1
      weight: 95

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

المجموعات: التحكم في من يحصل على الإصدار الجديد

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

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

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

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

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

الميزات: التحكم في الوظائف النشطة

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

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

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

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

دمج الأدوات الثلاث

هذه المكونات الثلاث ليست حصرية. في الممارسة العملية، تستخدم استراتيجية التسليم التدريجي الناضجة جميعها معًا.

يوضح الرسم البياني أدناه كيف تعمل الأدوات الثلاث معًا في تسلسل تسليم تدريجي نموذجي.

flowchart TD A[بدء الإصدار] --> B{التحقق من البنية التحتية؟} B -->|نعم| C[تقسيم حركة المرور] C --> D[فحص معدلات الأخطاء] D -->|جيد| E{هل تحتاج ملاحظات المستخدم؟} D -->|مرتفع| F[إيقاف الإصدار] E -->|نعم| G[إصدار المجموعة] E -->|لا| H{نشر الكود الآن، التفعيل لاحقًا؟} G --> H H -->|نعم| I[أعلام الميزات] H -->|لا| J[الإصدار الكامل] I --> K[تمكين العلم تدريجيًا] K --> L[مراقبة وضبط] L -->|آمن| J L -->|مشكلة| M[تعطيل العلم]

قد يبدو التسلسل النموذجي كالتالي:

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

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

قائمة تحقق عملية

قبل إصدارك التالي، اسأل هذه الأسئلة:

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

الخلاصة

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