نموذج الصلاحيات لشرائح العملاء: الخطط، الحدود، والأعلام

لماذا تحتاج الفرق إلى نموذج صلاحيات

إذا كنتم تبيعون أكثر من شريحة واحدة، سيظهر في النهاية نفس تذكرة الدعم: «العميل X دفع لخطة Pro، لكنه لا يستطيع الوصول إلى الميزة Y». من دون نظام واضح، لا يستطيع الدعم إصلاحه مباشرةً — تغيير وصول بسيط يصبح مهمة هندسية.

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

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

"القدرة على التعديل دون هندسة" يجب أن تكون ملموسة. عملياً:

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

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

القطع الأساسية: العملاء، الخطط، والصلاحيات

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

إليك مجموعة بسيطة من اللبنات:

• العميل (account/tenant): الشركة أو الشخص الذي يستخدم منتجك.
• الاشتراك: العلاقة التجارية (تجريبي، نشط، مُلغى)، وغالباً مرتبطة بنظام الفوترة.
• الخطة: اسم الشريحة (Free, Pro, Enterprise) الذي يحدد الوصول الافتراضي.
• الصلاحية: السلوك المسموح به فعلياً، مشتق من الخطة زائد أي تجاوزات.

تقييم الصلاحيات ليس الفوترة. الفوترة تجيب "ماذا يجب أن نفرِض ومتى؟"، والصلاحيات تجيب "ماذا يمكن لهذا العميل فعلاً الآن؟". قد يكون العميل غير مدفوع لكنه في فترة سماح، أو مدفوع لكنه محجوب مؤقتاً لأسباب امتثال. فصل هذه القرارات يسمح للمالية بتصحيح الفواتير دون تغيير وصول المنتج عن طريق الخطأ.

تعتمد عدة مجموعات على هذا الإعداد:

• المنتج يحدد ما تعنيه الخطط.
• الدعم يحتاج ضوابط آمنة لمنح أو إزالة الوصول.
• عمليات المبيعات تحتاج قواعد متسقة للصفقات والتجديدات.
• المالية تحتاج مطابقة موثوقة بين ما بيع وما تم توفيره من وصول.

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

الأعلام، الحدود، والحصص: اختر النوع الصحيح

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

• الأعلام (Boolean flags): هل الشيء مُفعّل أم مُعطّل؟ مثال: export_enabled = true.
• الحدود الرقمية (Numeric limits): ما الكمية المسموح بها دفعة واحدة؟ مثال: max_seats = 10.
• الحصص (Quotas): ما المقدار المسموح باستخدامه عبر الزمن؟ مثال: api_calls_per_month = 100000.

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

الحصص تتطلب عناية إضافية لأن الزمن مهم. تتناقص تذاكر الدعم بسرعة عندما تُدوَّن قاعدة إعادة الضبط وتُعرض في واجهة الإدارة.

النطاق هو قرار آخر يمنع الالتباس. علم مثل SAML SSO enabled عادةً يكون على مستوى الحساب. Max projects قد يكون على مستوى مساحة العمل. Can run reports قد يكون على مستوى المستخدم إذا كنتم تبيعون إضافات قائمة على الدور.

للحِصص، اختر قاعدة إعادة ضبط واحدة لكل حصة والتزم بها:

• لا أبداً (اعتمادات مدى الحياة)
• شهرياً (شهر تقويمي)
• نافذة متحركة (آخر 30 يوماً)
• لكل فترة فوترة (تطابق دورة الفاتورة)

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

مخطط قاعدة بيانات عملي للصلاحيات

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

ابدأ بأربع جداول أساسية: plans, plan_entitlements, customers, وcustomer_overrides.

• تصف plans الشرائح (Free, Pro, Enterprise).
• تصف plan_entitlements ما تتضمنه كل خطة.
• تشير customers إلى خطة.
• تغطي customer_overrides الاستثناءات لحساب واحد دون تغيير الخطة للجميع.

شكل علائقي مُدمج يعمل جيداً:

• plans: id, name, description, is_active
• plan_entitlements: id, plan_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_by
• customers: id, name, plan_id, status, created_at
• customer_overrides: id, customer_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_by

يجب أن تكون حقول الصلاحية متسقة عبر الجداول. استخدم مفتاحاً ثابتاً مثل seats, api_calls, أو sso_enabled. استخدم type لتبسيط التقييم (مثلاً: flag, limit, quota). خزّن unit صراحة (مثل users, requests, GB). للحصص، اجعل reset_policy غير غامض (مثل monthly, daily, never).

يجب أن تتصرف التجاوزات كقائمة سماح ضمن تواريخ. إذا كان لدى عميل تجاوز فعّال لـ sso_enabled=true، فعلى هذا التجاوز أن يتفوق على قيمة الخطة، لكنه صالح فقط ضمن effective_from وeffective_to. هذا يجعل عملية "منح 10 مقاعد إضافية لمدة 14 يوماً" تغيير صف واحد ينتهي تلقائياً.

كيف ينبغي أن يعمل تقييم الصلاحيات

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

استخدم ترتيب أسبقية واضح ولا تحيد عنه: تجاوز العميل > قيمة الخطة > الافتراضي النظامي. هذا يتيح للدعم منح استثناءات مؤقتة دون تغيير الخطة، ويمنح الهندسة افتراضات آمنة عندما لا يوجد تكوين.

تدفق تقييم عملي:

• حدد العميل/الحساب من الجلسة المصادقة (ليس من جسم الطلب).
• حمل الخطة النشطة للعميل وأي تجاوزات نشطة.
• لمفتاح معيّن، أعد التجاوز إذا وُجد؛ وإلا أعد قيمة الخطة؛ وإلا أعد الافتراضي النظامي.
• إذا كان المفتاح مفقوداً في كل مكان، فافترض الفشل المغلق لفحوصات الوصول (اعتبره "غير مسموح") واستخدم افتراضاً معقولاً لواجهة العرض فقط.
• إذا كان المفتاح غير معروف (غير مُسجّل في السجل)، اعتبره خطأ تكويني، افشل مغلقاً، وسجّله للمتابعة.

التخزين المؤقت مهم لأن الصلاحيات تُفحص باستمرار. خزّن الصلاحيات المحلولة لكل عميل مع TTL قصير ورقم إصدار صريح. ألغِ الصلاحية عند أي تغيير في: تعيين الخطة، تعريف الخطة، تجاوزات العميل، أو حالة العميل (تجربة، سماح، محجوب). نمط بسيط هو "التخزين حسب customer_id + entitlements_version"، حيث يرفع الدعم الإصدار حتى تظهر التغييرات بسرعة.

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

خطوة بخطوة: سير عمل صديق للدعم لتعديل الوصول

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

سير آمن للدعم

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

قبل تغيير أي شيء، تحقق من الاستخدام الفعلي مقابل الحد الحالي أو الحصة. تختفي كثير من الطلبات بمجرد رؤية أن الحساب ليس عند الحد أو أن المشكلة في مكان آخر (مثلاً، تتبع الاستخدام لم يتحدث).

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

قائمة تحقق بسيطة داخل أداة الإدارة عادةً تكفي:

• أكد هوية العميل، الخطة الحالية، وسبب الطلب.
• راجع الاستخدام الحالي مقابل الحد ذي الصلة.
• طبّق تجاوزاً مُقيَّداً واضبط انتهاء المدة.
• أضف ملاحظات مع مرجع التذكرة أو الحالة.
• تحقق من النتيجة في واجهة المنتج عبر التقمص (impersonation) أو حساب اختبار.

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

الترقيات، التخفيضات، التجارب، وفترات السماح

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

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

التخفيضات هي حيث تحدث المفاجآت. اختر سلوك تخفيض واضح واجعله مرئياً للدعم:

• فترة سماح: احتفظ بالوصول الأعلى حتى نهاية المدة المدفوعة.
• وضع القراءة فقط: السماح بعرض/تصدير البيانات لكن منع الإنشاءات الجديدة.
• إيقاف فوري: حظر الميزة فوراً (مخصص للميزات الخطرة).
• سلوك ما بعد الحد: السماح بالاستخدام لكن منع الإنشاءات عند تجاوز العميل للحصة.
• الاحتفاظ بالبيانات: احتفظ بالبيانات لكن عطّل الوصول حتى الترقي.

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

فترات السماح مفيدة أيضاً عند فشل الدفع. نافذة "المتأخر عن السداد" قصيرة (مثلاً 3 إلى 7 أيام) تعطي وقتاً لإصلاح الدفع دون فقدان الوصول أثناء يوم العمل. عامل فترة السماح كاستثناء محدد زمنياً، لا اسم خطة مخصص.

نصيحة عملية: لا تربط الصلاحيات بأسماء شرائح تسويقية متغيرة مثل "Pro" أو "Enterprise". احتفظ بمعرّفات خطة داخلية ثابتة مثل plan_basic_v2 حتى تتمكن من إعادة تسمية الشرائح دون كسر القواعد.

التدقيق وضوابط السلامة

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

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

ما الذي يجب تسجيله لكل تغيير

اجعل السجل بسيطاً حتى يُستخدم بالفعل:

• created_by و created_at
• approved_by و approved_at (اختياري)
• reason (نص قصير مثل "إضافة مدفوعة" أو "ائتمان تعويضي")
• previous_value و new_value
• expires_at

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

التراجع والاستعداد للمراجعة

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

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

مثال: عميل على "Pro" يحتاج 30 مقعداً إضافياً لأسبوع حدث واحد. يضع الدعم seats_override=60 مع expires_at يوم الجمعة القادم، يضيف سبباً "حدث" ويحصل على موافقة المدير. بعد الانتهاء، يعود النظام تلقائياً إلى 30، ولا حاجة لتذكر إيقافه يدوياً.

أخطاء شائعة تجعل الصلاحيات مؤلمة

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

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

فخ آخر هو خلط حالة الفوترة مع الوصول. "مدفوع" ليس مطابقاً لـ "مسموح". للفوترة محاولات، استردادات، تجارب وفواتير تستقر لاحقاً. حافظ على الأحداث الفوترة منفصلة، وترجمها إلى صلاحيات بقواعد واضحة (بما في ذلك فترات السماح) حتى لا تُقفل الحسابات أو تُفتح للأبد عن طريق الحواف.

تجنّب الاعتماد على سلسلة "tier" واحدة مثل "basic" أو "pro" كمصدر الحقيقة الوحيد. الشرائح تتغير، والاستثناءات تحدث. خزّن أعلاماً وحدوداً صريحة حتى يتمكن الدعم من منح قدرة واحدة دون منح كل ما يأتي مع تسمية الشريحة.

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

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

قائمة تحقق سريعة قبل الإطلاق

قبل نشر نموذج الصلاحيات، قم بتدقيق نهائي مع من سيستخدمه يومياً: الدعم، نجاح العملاء، ومن يرد على الحوادث.

تأكد أن كل ميزة مرتبطة بمفتاح صلاحية ثابت ومالك واضح. تجنب المكررات مثل reports_enabled مقابل reporting_enabled. ضمّن لكل خطة افتراضيات صريحة للمفاتيح التي تُطلقها. إذا كان مفتاح مفقوداً، اخفق بأمان (غالباً رفض الوصول) ونبه داخلياً ليُصلح بدلاً من منح الوصول بصمت.

للعمليات، تأكد أن سير العمل قابل للاستخدام فعلاً:

• يستطيع الدعم عرض الوصول الفعّال (افتراضات الخطة زائد التجاوز) دون SQL.
• تُسجَّل التجاوزات بمن غيّر ماذا، ولماذا، ومتى تنتهي.
• للحصص قاعدة إعادة ضبط مرئية وطريقة واضحة لعرض الاستخدام الحالي.

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

سيناريو مثال: شرائح مع استثناء مؤقت

تخيل أنكم تعرضون ثلاث شرائح، وكل شريحة تحدد بضعة صلاحيات واضحة تظهر في المنتج وتُطبّق في الخلفية.

• Free: مشروع واحد، 3 مستخدمين، 200 تصدير/شهر، حد معدل API أساسي، سجلات مدققة لمدة 7 أيام.
• Team: 10 مشاريع، 25 مستخدماً، 2,000 تصدير/شهر، حد معدل API أعلى، سجلات مدققة لمدة 30 يوماً.
• Business: مشاريع غير محدودة، 200 مستخدم، 10,000 تصدير/شهر، أعلى حد معدل API، سجلات مدققة لمدة 180 يوماً، SSO مفعّل.

الآن عميل Team يقول: "لدينا دفعة نهاية ربع ونحتاج 8,000 تصدير هذا الشهر. هل تستطيعون المساعدة لمدة 30 يوماً؟" هذا بالضبط المكان الذي يكون فيه التجاوز المؤقت أفضل من نقلهم إلى خطة جديدة.

يفتح الدعم سجل العميل، يضيف تجاوزاً مثل export_monthly_limit = 8000، ويضبط expires_at بعد 30 يوماً من اليوم. يضيف ملاحظة: "موافق من Alex (Sales)، استثناء 30 يوماً لتقارير Q4."

من وجهة نظر العميل، يجب أن يحدث شيئان:

• تعكس الواجهة الحد الجديد (مثلاً عدّاد الاستخدام وعبارة "التصديرات المتبقية" تتحدّث).
• تستمر التصديرات في العمل حتى يصلوا إلى 8,000 للشهر.

إذا تجاوزوا، يرون رسالة واضحة مثل: "تم الوصول إلى حد التصدير (8,000/شهر). اتصل بالدعم أو قم بالترقية لزيادة الحد." بعد انتهاء تاريخ الانقضاء، يتوقف التجاوز تلقائياً، ويعود العميل إلى حد شريحة Team دون حاجة لأحد أن يتذكر إيقافه.

الخطوات التالية: نفّذ وكرّر دون إبطاء الدعم

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

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

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

إذا أردت بناء لوحة الإدارة والمنطق بسرعة دون كتابة شيفرة يدوياً، فـ AppMaster (appmaster.io) خيار عملي لهذا النوع من العمل: يمكنك نمذجة الخطط والتجاوزات كبيانات، تنفيذ الفحوصات كعمليات عمل، وإطلاق واجهة دعم تبقى متسقة عبر الخلفية والتطبيقات.