تعدّد المستأجرين بلا مصطلحات تقنية: دليل المؤسّس

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

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

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

ما الذي يعنيه «متعدّد المستأجرين» فعلاً

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

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

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

لماذا يمسّ هذا القرار عملك كلّه

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

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

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

الطرق الثلاث لفصل المستأجرين

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

1. قاعدة بيانات مشتركة، جداول مشتركة

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

2. قاعدة بيانات مشتركة، حُجَر منفصلة

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

3. قاعدة بيانات منفصلة لكلّ مستأجر

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

الجزء الذي لا يجوز أن تخطئ فيه: العزل

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

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

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

متى يكون المستأجر الواحد هو القرار الصائب فعلاً

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

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

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

الأسئلة التي تطرحها قبل أن يكتب أحدٌ شِفرة

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

1. 1
   كيف ستُبقي بيانات المستأجرين منفصلة؟

   أنت تنصت لجوابٍ بنيوي — النظام يفرضه — لا «سنكون حريصين». هذا هو غير القابل للتفاوض.
2. 2
   أيّ نموذج نستعمل، ولماذا؟

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

   حتى لو بدأت بالمشاركة الكاملة، ينبغي أن يترك التصميم متّسعاً لمنح عميل كبير أو منظَّم فصلاً أقوى دون إعادة بناء.
4. 4
   ماذا يحدث حين يصبح عميل واحد ضخماً؟

   كيف يمنع النظام مستأجراً ثقيلاً من إبطاء الجميع؟ تريد أن تسمع أنّ سيناريوهات الجار المزعج أُخذت في الحسبان.
5. 5
   كيف نُصدّر أو نحذف بيانات عميل واحد بنظافة؟

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

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

مثال قصير على هيئة الواقع

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

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

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

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

أسئلة شائعة