إطلاق الميزات تدريجيًا: Feature Flags وProgressive Delivery في SaaS

ماذا ستخرج به من هذا المقال؟

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

في هذا المقال نموذج كامل للتسليم التدريجي: عقد العلم، وقواعد التقييم، ومراحل النشر المصغّرة، وعقد النجاح، والتراجع السريع. ونختم بخطوة عملية: طبقة تقييم قابلة لإعادة الاستخدام بين PHP وTypeScript من مخطط واحد.

العلم عقد تقييم لا متغير منطقي

الخطأ الأول هو تعامل العلم كقيمة منطقية داخل الشيفرة: if ($featureEnabled) { ... }. يعمل هذا في البداية ثم يتآكل: تبدأ بعلم واحد، ثم تتضاعف، ثم تجدها في عشرات الملفات، فيصير سؤال «أي الأعلام ما زالت حيّة؟ ومن يملكها؟» بلا إجابة. المشكلة ليست في السلوك بل في غياب العقد الذي يربط العلم بمالكه وبنيته وبدورة حياته.

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

أنواع الأعلام وسلوكها وقت الأزمات

• علم إصدار (Release flag): يفصل نشر الشيفرة عن تفعيلها، ويبقى حيًا شهرًا أو شهرين ليُزال الفرع القديم لاحقًا. أكثر الأنواع استخدامًا وأكثرها إهمالًا للتنظيف.


• علم تشغيل (Operational flag): يتحكم في سلوك حرج كخفض الحِمل أو تعطيل مزود خارجي متعطل. يعيش سنوات، ومسار تقييمه في المسار الحرج ومعايَر ذاتيًا.


• علم قتل (Kill switch): علم تشغيل بشرط أن يبقى آمنًا عند تفعيله، مع مسار احتياطي محدود حتى لا يصبح هو نفسه نقطة الفشل.


• علم تجربة (Experiment flag): مرتبط بتقسيم إحصائي وله نهاية متفق عليها ونتيجة مسجلة. من تجاوز دورة تجربة كاملة فهو إهمال لا تجربة.


• علم صلاحية (Entitlement flag): مشتق من عقد المستأجر: الخطة أو الحزمة أو المنطقة. مصدره بيانات الفوترة، ولا يحمل نسب توزيع.

فصل الإصدار عن الصلاحية أهم قرار معماري مبكر. خلطهما ينتج علمًا واحدًا يسأل «من يحق له؟» و«ما النسبة؟» و«هل هو متوقف؟» في تقييم واحد، فيصبح التراجع بطيئًا وغير حاسم.

نواة التقييم: مخطط واحد بلغات متعددة

الفرق الحقيقي بين تطبيق ويب ولوحة تحكم وتطبيق جوّال ليس اللغة، بل أن منطق التقييم يجب أن يتطابق. إذا أعاد كل عميل كتابة القواعد ظهر انحراف دقيق: التطبيق يفتح الميزة عند 50% والواجهة عند 40%، ويضيع أسبوع في تشخيص لا علاقة له بالشيفرة. الحل مخطط تقييم واحد يُكتب مرة ويُترجم آليًا إلى اللغات أو يُقيَّم عند الحافة.

• محلي متزامن: نسخة من القواعد موزّعة مع التطبيق، تُقيَّم في الذاكرة في أقل من ميلي ثانية، ومناسبة للمسارات الحرجة كـ middleware. ليست مصدر الحقيقة بل نسخة منه، فيلزم قياس حداثتها.


• بعيد متزامن: استدعاء gRPC أو REST لكل طلب مع مهلة قصيرة، للاحظات التي تحتمل قفزة شبكة مثل بانر داخل التطبيق.


• بعيد غير متزامن: تدفّق أحداث (طلبات، سداد، تفعيل خطة) إلى Kafka ينتج تحديث القواعد. بطيء عمدًا لأنه يخدم الصحة النهائية حين تتغير حالة الصلاحية.

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

مثال: قاعدة تقييم في SQL

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

-- جدول توزيع واحد يخدم كل العملاء: صف لكل علم لكل مستأجر.

CREATE TABLE feature_rollout (

  flag_key      text        NOT NULL,

  tenant_id     bigint      NOT NULL,

  treatment     smallint    NOT NULL,  -- 0 = ضابط، 1 = تجربة، 99 = غير مؤهل

  sticky_bucket smallint    NOT NULL,  -- يُحسب مرة واحدة ولا يتغير

  assigned_at   timestamptz NOT NULL DEFAULT now(),

  PRIMARY KEY (flag_key, tenant_id)

);



-- التوزيع يتم مرة واحدة ثم يثبت، فلا يتذبذب المستخدم بين المجموعتين.

INSERT INTO feature_rollout (flag_key, tenant_id, treatment, sticky_bucket)

SELECT 'settlement.batch_v2', t.id,

       CASE WHEN hash(t.id) % 100 < :rollout_pct THEN 1 ELSE 0 END,

       hash(t.id) % 10000

FROM   tenant t

WHERE  t.status = 'active'

  AND  t.plan IN ('enterprise', 'business');



-- فعّل العلم فقط للمستأجرين المؤهلين في موجة اليوم.

UPDATE feature_rollout

SET    treatment = 1

WHERE  flag_key = 'settlement.batch_v2'

  AND  tenant_id IN (SELECT id FROM rollout_wave_2026_03_01);

انتبه إلى sticky_bucket: النسبة وحدها لا تكفي. إعادة حساب hash(id) % 100 < 10 في كل طلب تجعل نحو ثلث المستخدمين يتذبذبون بين التجربة والضابط، فتفسد كل قراءة في لوحات التحليل.

الصيغة الأساسية للتقييم

تتحول معظم القواعد إلى خمس خطوات قابلة لإعادة الاستخدام في أي لغة، وترتيبها يحدد الأولوية بين مصادر القرار:

1. الافتراضي الصريح: قيمة افتراضية مكتوبة في الكود حيث يراها مراجعة الطلب. الغياب ليس خيارًا، وفي المسارات الحساسة اجعلها off صريحًا.


2. التحديد الصريح: معرّفات تتقدم على أي نسبة، وهي مخرج الطوارئ لفريق الجودة، ويجب أن تكون مؤقتة.


3. الصلاحية: هل اشترى المستأجر الميزة أصلًا؟ إن لم يكن، توقف قبل تقييم النسبة.


4. الاستهداف: الدولة، المنطقة، القطاع، إصدار التطبيق، مستوى العميل. هنا تُعبَّر عن «أطلق أولًا لعملاء بنك في الخليج تتجاوز حساباتهم النشطة عشرة آلاف».


5. النسبة: التقسيم الإحصائي على البُعد الصحيح: مستأجر أو مستخدم أو جلسة.

قيمة هذه الصيغة أنها واحدة في PHP وTypeScript وGo: تُكتب القاعدة مرة، وتراها المراجعة البشرية والآلية بالنيّة نفسها، وتبقى أسماء الأعلام ووثائقها متطابقة عبر الأنظمة.

مراحل النشر المصغّرة

النشر التدريجي ليس مفتاحًا بل آلة حالات، وتخطّي المراحل هو السبب الثاني لحوادث الأعلام: قفزة من 0% إلى 50% لأن التقويم كان مزدحمًا.

• داخلي: الفريق فقط، في إنتاج حقيقي إن أمكن، لكشف مسارات فشل لا تكشفها أي حساب تجريبي.


• بطلب (Opt-in): مستأجرون طلبوا الميزة أو ذُكروا في ملاحظات الإصدار. هنا تأتي أول تعليقات جودة حقيقية.


• تجريبي (5–20%): عينة صغيرة غير عشوائية عمدًا، لكن متنوّعة في الحجم والقطاع والمنطقة. هنا يظهر التنوع عند حدود الأداء.


• تدرّجي (25–50%): بعد تجاوز معايير النجاح، ويتطلب اتفاقًا مكتوبًا مع المنتج: ماذا نفعل إذا لم يتحقق المؤشر خلال 48 ساعة؟


• عام (100%): الإطلاق العام، ولا يعني إزالة العلم فورًا. أبقه شهرًا أو شهرين لموظف دعم في وردية لاحقة.


• إزالة (Retire): احذف الفرع والعلم ووثّق القرار. هذه المرحلة التي لا يخطّط لها أحد.

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

عقد النجاح: من القياس إلى قرار الفتح

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

• مؤشرات السلامة (توقف فوري): معدل الخطأ في المسار المتأثر، ونسبة 5xx على المسارات الجديدة، وفشل المهام الخلفية، وشكاوى الدعم خلال 24 ساعة. لكل مؤشر عتبة إيقاف آلي مكتوبة مسبقًا. مثال معقول: ارتفاع معدل الخطأ 0.5 نقطة مئوية فوق خط الأساس لثلاث دقائق متتالية. الأرقام أمثلة، والمهم أنها مكتوبة قبل الإطلاق ومملوكة لفريق واحد.


• مؤشرات الأداء (بوابة تقنية): زمن المعالجة، واستهلاك الموارد، وحجم الاستعلامات الجديدة، والتكلفة لكل عملية. ميزة تحسّن تجربة المستخدم 10% وتضاعف التكلفة 30% ليست نجاحًا تلقائيًا، بل تحتاج قرارًا صريحًا بنسبة التكلفة.


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

الربط بين القياس والقرار يحتاج سجل تعرض (exposure log) يربط كل تقييم بقيمة الميزة وبالسياق الكامل: المستأجر، والمستخدم، وإصدار التطبيق. بدونه تفسر كل لوحة تحليل نفسها بطريقتها. وهذا السجل هو أيضًا أساس التحليل الإحصائي السليم للتجارب: لا تقارن تجربة وضابطًا بمجموعتين مختلفتين في الحجم.

التراجع السريع: جهّز علم القتل قبل أن تحتاجه

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

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


• الوضع الآمن: إيقاف السلوك مع إبقاء الميزة ظاهرة في الواجهة وفي منافذ API. مفيد حين تكون التجربة الجديدة سيئة فعلًا.


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

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

أخطاء شائعة

قائمة تحقق

• اكتب عقد العلم قبل كتابة الكود: اسم نوعي، ومالك فريق، وغرض مكتوب، وقيمة افتراضية صريحة، وتاريخ إزالة، في كتالوج قابل للبحث.


• اعتمد مخطط تقييم واحد عبر اللغات: نفس الخطوات الخمس في PHP وTypeScript، وراجع تطابق القواعد آليًا في التكامل المستمر.


• ثبّت التخصيص: احسب المجموعة مرة واحدة لكل مستأجر واحفظها؛ لا تعِد حساب تجزئة النسبة في كل طلب.


• اكتب عقد النجاح بالأرقام قبل الانتقال: عتبة إيقاف للسلامة، وعتبة أداء، وهدف تبني، ومهلة قرار لكل مرحلة.


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


• اجعل البيانات متوافقة في الاتجاهين: حتى يبقى النشر القابل للتراجع واقعيًا لا نظريًا عند فشل بناء لاحق.

الأسئلة الشائعة

هل أحتاج خدمة Feature Flags مدفوعة أم يكفي جدول وعلم بيئة؟

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

كيف أتعامل مع مستأجر يطلب ميزة لم تُطلق بعد؟

هذا هو مخرج التحديد الصريح (Allowlist)، وهو مشروع بشرطين: أن يُسجَّل في الكتالوج كحالة مؤقتة بتاريخ انتهاء، وأن يبقى تحت المراقبة. إن طلبه أكثر من handful من المستأجرين، فهذه إشارة أن المرحلة التالية أقرب مما خططت، لا سبب للتوسيع التعسفي. كثير من الفرق تكتشف أن قائمتها نمت بصمت حتى صارت «كل من طلب»، وهذا إطلاق عام غير معلن.

هل يمكن أن تكون قيمة العلم نفسها مصدر خطر؟

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

الخلاصة

الخطوة التالية

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

كيف تستخدم هذا المقال في عمل حقيقي؟

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

flowchart LR

    A["هوية المستأجر"]

    B["التحقق من الصلاحيات"]

    C["منطق الأعمال"]

    D["حفظ آمن للبيانات"]

    E["مراقبة وقياس"]

    A --> B

    B --> C

    C --> D

    D --> E