فتح ميزة لمجموعة فرعية من المستخدمين أولاً

لديك محرك توصيات جديد جاهز. الفريق واثق. الاختبارات نجحت. مراجعة الكود انتهت. لكن هناك شيء يمنعك من تشغيل المفتاح للجميع دفعة واحدة. ماذا لو كانت المنطقية الجديدة تعمل بشكل جيد في بيئة الاختبار (Staging) ولكنها تتصرف بشكل مختلف تحت حركة المرور الحقيقية؟ ماذا لو أبطأت تحميل الصفحة للمستخدمين ذوي الاتصالات البطيئة؟ ماذا لو أوصت بشيء محرج؟

هذا التردد صحي. الطريقة الأكثر أمانًا لإطلاق ميزة هي السماح لمجموعة صغيرة من المستخدمين برؤيتها أولاً. إذا عملت، قم بتوسيع نطاقها. إذا حدث خطأ ما، فقط تلك المجموعة الصغيرة تتأثر. هذا النمط يُسمى الطرح التدريجي (Progressive Rollout)، وهو أحد أكثر استخدامات Feature Flags عملية في بيئة الإنتاج.

أبسط نهج: الطرح بناءً على النسبة المئوية

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

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

جمال هذا النهج هو أنه يمكنك عكسه فورًا. إذا ارتفع معدل الخطأ عند 25%، يمكنك خفض النسبة إلى 10% أو إيقاف تشغيل العلم بالكامل. لا حاجة للتراجع (Rollback). لا حاجة لإعادة النشر. مجرد تغيير في الإعدادات.

عندما لا تكون النسبة المئوية كافية

أحيانًا تحتاج إلى تحكم أكثر من مجرد نسبة مئوية بسيطة. قد ترغب في أن يجرب مستخدمون محددون الميزة أولاً. المختبرون الداخليون، أعضاء فريق ضمان الجودة (QA)، أو العملاء الودودون الذين وافقوا على الاختبار التجريبي. لهذا، يحتاج Feature Flag الخاص بك إلى قواعد استهداف (Targeting Rules).

قاعدة الاستهداف الأكثر شيوعًا تعتمد على معرف المستخدم (User ID). تحتفظ بقائمة من معرفات المستخدمين المسموح لهم برؤية الميزة الجديدة. الجميع يرون النسخة القديمة. هذا مفيد للاختبار التجريبي الخاضع للتحكم: تدعو مجموعة صغيرة من المستخدمين لتجربة الميزة مبكرًا، بينما لا يعلم باقي المستخدمين بوجود الميزة من الأساس.

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

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

مشكلة الاتساق (Consistency)

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

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

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

الطرح التدريجي مقابل الإصدار التجريبي (Canary Release)

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

الطرح التدريجي باستخدام Feature Flags مختلف. جميع الخوادم تشغل نفس الكود. العلم (Flag) هو الذي يحدد من يرى الميزة الجديدة. لا تحتاج إلى إدارة توجيه الخادم أو إعدادات موازن التحميل. فقط قم بتغيير قيمة العلم.

يوضح المخطط الانسيابي التالي المقارنة بين النهجين:

flowchart TD A[ابدأ: 5% من المستخدمين] --> B[راقب المقاييس] B --> C{أخطاء أو مشاكل؟} C -->|لا| D[زد إلى 10%] D --> E[راقب مرة أخرى] E --> F{مستقر؟} F -->|نعم| G[استمر إلى 25%، 50%، 100%] F -->|لا| H[تراجع إلى المستوى السابق] C -->|نعم| I[تراجع إلى 0%] I --> J[حقق وأصلح] J --> A K[Canary release: توجيه حركة المرور إلى مجموعة فرعية من الخوادم] --> L[راقب مقاييس الخادم] L --> M{سليم؟} M -->|نعم| N[زد حركة مرور Canary] M -->|لا| O[أعد توجيه حركة المرور بعيدًا]

هذا الاختلاف مهم للفرق التي تنشر على العديد من الخوادم أو تستخدم تنسيق الحاويات (Container Orchestration). باستخدام Feature Flags، لا تحتاج إلى الحفاظ على إصدارات متعددة من تطبيقك في الإنتاج. كل خادم لديه نفس الملف الثنائي (Binary). العلم هو الفرق الوحيد.

التأثير النفسي

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

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

قائمة التحقق العملية للطرح التدريجي

قبل أن تفتح ميزة لمجموعة فرعية من المستخدمين، راجع قائمة التحقق هذه:

  • هل يمكنك تحديد المستخدمين بشكل متسق؟ استخدم معرفًا ثابتًا مثل User ID أو Session ID لحسابات النسبة المئوية.
  • هل لديك مراقبة (Monitoring) معمول بها؟ اعرف المقاييس التي يجب مراقبتها: معدل الخطأ، وقت الاستجابة، المشكلات التي أبلغ عنها المستخدم.
  • هل يمكنك إيقاف تشغيل العلم فورًا؟ تأكد من أن نظام العلم يستجيب بسرعة ولا يتطلب إعادة نشر.
  • هل حددت مراحل الطرح؟ خطط للنسب المئوية: 5%، 10%، 25%، 50%، 100%. قرر المدة التي ستبقى فيها في كل مرحلة.
  • هل لديك خطة للتراجع؟ ما هي عتبة المقياس التي تؤدي إلى إيقاف العلم؟ من يتخذ هذا القرار؟

الخلاصة

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