عبدالله بن سنكر يشرح: كيف تبني نظام SaaS متعدد العملاء؟

عندك فكرة نظام تبيعه باشتراك شهري لعشرات الشركات. السؤال اللي يجي بعد الحماس: كيف يشتغل نظام واحد لكل هؤلاء، وكل شركة تحس إنه نظامها لحالها، ولا تشوف بيانات غيرها؟ عبدالله بن سنكر بنى «ياء»، نظاماً سحابياً عربياً لمكاتب المحاماة فيه القضايا والجلسات والفواتير وبوابة للموكّلين. وهنا يشرح لك المعمار بلغة صاحب المشروع، بدون ما تحتاج تكون مبرمجاً.

الفكرة: عمارة وحدة وشقق كثيرة

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

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

رحلة طلب واحد داخل النظام

خلنا نتابع محامية تفتح قائمة جلسات الأسبوع. وش يصير بين الضغطة والنتيجة؟

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

الخطوة الرابعة هي قلب الموضوع. أخطر ثغرة في أي SaaS إن مبرمجاً ينسى شرط المستأجر في استعلام واحد، فيشوف عميل بيانات عميل ثاني، ولو صار هذا مرة وحدة فالضرر مو تقني بس، هو ثقة العميل كلها. عشان كذا ما يُترك هذا الشرط لذاكرة المبرمج: يُفرض في طبقة واحدة مشتركة يمر منها كل طلب، أو في قاعدة البيانات نفسها عبر سياسات الأمان على مستوى الصفوف (Row Level Security) في قواعد مثل PostgreSQL، بحيث حتى لو نسي الكود، القاعدة ما تنسى.

طرفان في نظام واحد: المكتب وموكّلوه

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

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

أجزاء ينساها أغلب الناس

قاعدة البيانات مو المكان الوحيد اللي يحتاج عزل. هذي أجزاء تحتاج نفس الانتباه:

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

متى تحتاج عزلاً أقوى؟

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

وش تسأل المطوّر قبل ما توقّع

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

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