بناء SaaS متعدد العملاء: دليل عملي للمؤسسين

منتج SaaS متعدد العملاء يخدم عملاء كثيرين من منتج واحد، بينما يشعر كل واحد منهم أنه له وحده. هكذا تعمل معظم البرامج التي تدفع لها اشتراكًا شهريًا، وهو القرار الذي يحدّد شكل منتجك أكثر من أي شيء آخر.

أبني وأدير منصة متعددة العملاء تستخدمها أكثر من 10 شركات تدفع. هذا هو الدليل الذي أعطيه لمؤسس يبدأ اليوم: ماذا تقرّر أولًا، وأين يقع الناس عادةً، وما الذي يمكن أن ينتظر.

اختر طريقة الفصل بين العملاء

هناك ثلاث طرق شائعة لفصل بيانات العملاء:

الطريقة	قوة الفصل	كلفة التشغيل	مناسبة لـ
جداول مشتركة مع Tenant ID	يفرضها الكود	الأقل	معظم المنتجات الجديدة
Schema لكل عميل	أقوى	متوسطة	عملاء أقل وأكبر
قاعدة بيانات لكل عميل	الأقوى	الأعلى	عقود صارمة أو تفرض مكان البيانات

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

مش متأكد أيها يناسبك؟ جاوب على هذه الأسئلة وأقول لك من أين أبدأ.

اجعل الحدّ بين العملاء مستحيل النسيان

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

• طبّق نطاق العميل على كل استعلام في مكان واحد، لا يستطيع أي مبرمج تجاوزه، بدل أن تعتمد على أن يتذكر الجميع.
• أضف طبقة ثانية. ميزات قاعدة البيانات مثل row-level security تبقى شغّالة حتى لو كان في الكود خطأ.
• اختبر الحدّ عن قصد. اكتب اختبارات تدخل كعميل وتحاول قراءة بيانات عميل آخر وتعديلها وحذفها. يجب أن تفشل بوضوح.
• راجعه في كل تغيير. أي جدول أو كاش أو مسار ملفات جديد يجب أن يجيب على سؤال واحد: لمين هذا؟

تعدد العملاء أكبر من قاعدة البيانات

قاعدة البيانات تأخذ كل الاهتمام، لكن هذه تأخذ وقتًا أكثر:

• الدومينات. العملاء يريدون عناوينهم الخاصة. يعني توجيهًا حسب الـ hostname، وإصدار شهادات، والتعامل مع إعدادات DNS الخاطئة.
• العلامة التجارية. إذا كان منتجك white-label، فكل إيميل وصفحة دخول ورسالة خطأ يجب أن تحمل علامة العميل، لا علامتك.
• الملفات والكاش والطوابير. مفتاح كاش أو مسار ملف بدون العميل فيه هو نفس خطأ استعلام بدون فلتر.
• الميزات لكل عميل. كل عميل يحتاج أشياء مختلفة. خطّط لطريقة تشغيل الميزات وإيقافها قبل أن تثبّتها في الكود.
• الفوترة. الباقات والتجارب والترقيات والدفعات الفاشلة والعملات كلها تابعة للعميل، لا للمستخدم.
• اللغات. دعم الكتابة من اليمين لليسار، مثل العربي، أرخص بكثير إذا خطّطت له باكرًا بدل إضافته لاحقًا.
• المغادرة. سيطلب العملاء تصدير بياناتهم وحذفها، ومن النسخ الاحتياطية أيضًا. قرّر كيف قبل أن يطلب أولهم.

خلِّ البنية بسيطة

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

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

متى تضيف تعقيدًا

أضف بنية جديدة لسبب ملموس، لا من باب المبدأ:

• وعدت بنسبة تشغيل لا تستطيع بنيتك الحالية الوفاء بها بصدق.
• عقد عميل يتطلب فصلًا أو منطقة جغرافية معيّنة.
• قِست حدًّا لا يحلّه استعلام أفضل أو جهاز أكبر.

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

قبل الإطلاق

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

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

إذا كنت تخطّط لـ SaaS وتحب نحكي فيه، هذا من نوع الشغل الذي آخذه.