Feature Flags تحتاج خطة خروج، لا مجرد مفتاح تشغيل

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

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

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

صنّف العلم قبل كتابة الفرع

ليست كل الأعلام متشابهة. ينقل Release Flag الميزة تدريجيًا من مخفية إلى متاحة على نطاق واسع. ويقارن Experiment Flag بين نسخ للإجابة عن سؤال منتج. ويعمل Operational Flag كقاطع طوارئ أو أداة لتخفيف الحمل. ويمثل Entitlement Flag حدًا تجاريًا أو صلاحية دائمة. خلط هذه الأنواع يخلق توقعات غير آمنة.

يجب أن يحمل Release Flag المؤقت مالكًا وعمرًا متوقعًا وشرط إزالة. ويحتاج Operational Flag الدائم إلى سلوك طوارئ مختبر ومراجعة دورية. أما Entitlement فيجب فرضه عند حد موثوق على الخادم؛ العلم في الواجهة ليس تفويضًا. وتحتاج التجربة إلى توزيع ثابت ودليل تعرض وقاعدة قرار، لا إلى منزلق نسب مئوية فقط.

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

امنح كل علم عقد منتج وهندسة

يجب أن يوجد العقد قبل التعرض في الإنتاج. سجّل مفتاح العلم ونوعه ومالكه ورحلة المستخدم المتأثرة والنتيجة المقصودة وحد التقييم وخصائص الاستهداف وSafe Default ومراحل الإطلاق ومقياس المنتج وGuardrails التشغيلية وصلاحية التراجع وتاريخ الانتهاء المتوقع وعمل التنظيف. اربطه بالتنفيذ وRunbook.

يكفي سجل صغير:

flag: catalog_import_validator_v2
type: temporary release
owner: catalog-experience
subject: organization_id
exposure: first validation executed by v2
outcome: valid import completed within 24h
guardrails: false_rejection_rate, api_error_rate, p95_latency
fallback: v1 validator
rollback: on-call may set 0%
cleanup_by: 2026-10-20

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

اجعل التقييم ثابتًا وقابلًا للفحص

تعرّف OpenFeature Evaluation Context يستطيع حمل خصائص الطلب أو التطبيق أو المستخدم، مع أولوية موثقة بين المستويات العامة والمعاملة والعميل والاستدعاء وHooks. استخدم هذه المرونة عمدًا. اختر Subject Key ثابتًا عند حد المنتج—مثل الحساب أو المؤسسة أو المستخدم—وحافظ عليه طوال عمر الإطلاق.

إذا وزعت Workflow مشتركًا على مستوى المؤسسة باستخدام User ID، فقد يرى زميلان حالتين متعارضتين في العملية نفسها. وإذا تغير المفتاح بين الويب والـWorker وAPI فقد تعبر العملية من نسخة إلى أخرى في منتصف التنفيذ. مرر أقل سياق ثابت مطلوب للقرار، ووثق مصدره. لا تنسخ بيانات شخصية عشوائية أو عالية Cardinality إلى كل تقييم لمجرد أن SDK يقبلها.

استخدم Detailed Evaluation عندما يهم سبب القرار واسم النسخة. تستطيع واجهة OpenFeature التفصيلية إعادة القيمة والـvariant والسبب ومعلومات الخطأ، بينما يعيد التقييم غير الطبيعي القيمة الافتراضية التي قدمها التطبيق بدل إنهائه. خزّن تشخيصًا محدودًا لاستكشاف المشكلات، لكن لا تطبع Log غير محدود لكل تقييم في مسار ساخن.

افصل التوزيع عن التعرض وعن النتيجة

التقييم ليس دليلًا على أن المستخدم عاش التجربة. قد يقيّم الكود العلم قبل العرض ثم يغادر عبر مسار آخر. وقد يقيّم Prefetch خلفي نسخة لا تظهر أبدًا. اعتبار كل تقييم Exposure يخفف العينة وقد يجعل ميزة ضعيفة تبدو محايدة.

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

ثم سجّل أحداث النتائج بصورة مستقلة. صممت Tracking API في OpenFeature لربط تقييمات الأعلام بالأفعال أو حالات التطبيق اللاحقة، وتستطيع Hooks إرسال تفاصيل التقييم إلى أدوات القياس. يسمح هذا الفصل بسؤال: هل أكمل من تعرضوا المهمة المقصودة؟ مع الاحتفاظ بدليل النسخة والتقييم. كما يمنع تحويل Business Metric إلى Side Effect لاستدعاء العلم نفسه.

صمّم سلوك الفشل قبل تعطل المزود

نظام Feature Flags تبعية أخرى. يجب أن يعرف التطبيق ما يفعل عندما يكون المزود غير متاح أو قديم البيانات أو سيئ الإعداد. تشترط OpenFeature أن تعيد استدعاءات التقييم Default يقدمه التطبيق عند التنفيذ غير الطبيعي، وتعرّف أحداثًا لحالات المزود مثل Ready وError وStale وReconciling. تكشف هذه الآليات الحالة؛ ويظل على الفريق اختيار السلوك الآمن للمنتج.

المسار القديم غالبًا، لا دائمًا، هو Safe Default لعلم إطلاق. فحص الاحتيال أو الخصوصية أو الصلاحية لا يستطيع أن يفشل مفتوحًا بصمت. قد تختفي لوحة توصيات جديدة بأمان، بينما يحتاج تنسيق كتابة جديد إلى Fail Closed أو طبقة توافق؛ لأن إعادة القارئ القديم لا تعكس بيانات كتبت بالفعل. قرر لكل علم، لا لكل SDK.

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

وسّع التعرض بناءً على الدليل لا التقويم

الإطلاق التدريجي سلسلة قرارات، لا نسب 5% و25% و50% و100% في تواريخ ثابتة. تحتاج كل مرحلة إلى نافذة ملاحظة دنيا، وعدد كافٍ من المعرضين للاستنتاج المطلوب، وGuardrails تشغيلية، وقاعدة واضحة للتوسيع أو الانتظار أو التراجع. حافظ على توزيع المجموعة بين المراحل ما لم يحتج السؤال إلى مجتمع جديد.

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

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

اجعل التراجع حالة منتج

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

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

في التغييرات عالية الأثر استخدم استجابة من جزأين: خفّض أو أوقف التعرض الجديد، ثم طابق العمل الذي دخل مسبقًا. تساعد مراقبة الأنظمة الخلفية في تتبع العمليات المتأثرة عبر الخدمات؛ ويجب أن تكون نسخة العلم وهوية التعرض دليلًا قابلًا للبحث، لا Label عالية Cardinality في Metrics.

احذف الفرع بعد حسم القرار

تتراكم الديون التقنية عندما تبقى الأعلام المؤقتة والكود بعد انتهاء الغرض. تضع Unleash العلم في حالة Potentially Stale بعد عمر متوقع، وتدعو إرشادات LaunchDarkly إلى المراقبة أثناء الإطلاق وإزالة الأعلام المؤقتة بعد استقرار الميزة. يساعد التحذير في Dashboard، لكن الكود يحتاج تغيير تنظيف مقصودًا.

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

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

راجع دورة الحياة كاملة في Test Matrix واحدة

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

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

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

إعداد: Noor Yasser