احمد المُنَجّد — مقالات

كيف تختار بين نظام جاهز ونظام مخصّص

Mon, 27 Jul 2026 00:00:00 GMT

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

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

متى يكون الجاهز هو الخيار الصحيح

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

وهناك سبب ثانٍ أقل ذكراً: النظام الجاهز يأتي بجمهور من المستخدمين يشاركونك المشكلات. حين يظهر خلل، من المرجّح أن أحداً قد أبلغ عنه قبلك.

الإشارة التي تدلّ على أن الجاهز بدأ يكلّفك

المؤشّر الذي أبحث عنه ليس شكوى من النظام. الناس يشتكون من كل نظام. المؤشّر هو عدد الأشخاص الذين يعملون حول النظام بدل أن يعملوا داخله:

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

كل واحدة من هذه التفافات صغيرة ومحتملة وحدها. مجتمعةً هي نظامك الحقيقي، وهو يعمل خارج البرنامج الذي تدفع اشتراكه.

السؤال الذي يحسم القرار

سؤال واحد يختصر أكثر النقاشات: أي جزء من عملك لو نسخه منافس حرفياً لتوقّف تميّزك عنه؟

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

الخيار الثالث الذي يُغفل غالباً

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

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

كيف تقرّر عملياً

قبل أن تطلب عرض سعر من أي طرف:

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

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

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

كيف تُوسّع منصّة SaaS دون إعادة بنائها

Mon, 27 Jul 2026 00:00:00 GMT

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

هذه المادة أصل محاضرة قدّمتها في Arabic Dev Group Malaysia.

لماذا يكون المستأجر الواحد هو المشكلة؟

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

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

أول ما يُبنى ليس حلّاً للتوسّع، بل القدرة على الإجابة عن سؤال: أي مستأجر، أي استعلام، أي مزوّد.

ما الذي يتعطّل أولاً، بالترتيب

الترتيب متكرّر بما يكفي ليكون قابلاً للتوقّع:

استعلام واحد بلا فهرس مناسب. يظهر مع نمو أكبر مستأجر، لا مع نمو عدد المستأجرين. أرخص إصلاح متاح، وأكثر ما يُشخَّص خطأً على أنه «حاجة إلى خوادم أكبر».
‏N+1 في مسار يعالج قوائم. غير محسوس بعشرين سجلّاً، وقاتل بعشرين ألفاً. لوحات التقارير هي موطنه المعتاد.
مهام خلفية تعالج كل المستأجرين تسلسلياً. تعمل جيداً حتى يصير مجموع الوقت أطول من الفترة بين تشغيلتين، فتتراكم.
اتّصالات قاعدة البيانات. كل نسخة تطبيق تحتفظ بمجموعة اتّصالات؛ مضاعفة عدد النسخ تضاعف الضغط على القاعدة، فيصير التوسّع الأفقي سبباً للبطء لا علاجاً له.
الخوادم نفسها. آخر القائمة عادةً، لا أولها.

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

ماذا تفعل بالمستأجر الكبير؟

حين يكون مستأجر واحد سبب الضغط، الخيارات ثلاثة، ولكلٍّ منها ثمن صريح:

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

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

أين يفيد التخزين المؤقّت وأين يضرّ

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

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

وبعد ذلك، الترتيب النافع:

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

متى تُفصل خدمة فعلاً؟

الفصل قرار له مُحفّزات محدّدة، لا شعور بأن النظام «صار كبيراً»:

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

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

الخلاصة

التوسّع مسألة قياس قبل أن يكون مسألة معمارية. القياس مقسوماً على المستأجر، ثم الاستعلامات والفهارس، ثم المهام الخلفية، ثم الاتّصالات — وأخيراً البنية التحتية. والترتيب المعكوس، وهو الشائع، يشتري حلولاً لمشاكل لم تُشخَّص.

هذا ما أبنيه للعملاء، وما أُشغّله بنفسي في مَكّوك.

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

معمارية تعدّد المستأجرين: القرارات التي لا يمكن التراجع عنها

Mon, 27 Jul 2026 00:00:00 GMT

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

هذه المادة أصل محاضرة قدّمتها في Arabic Dev Group Malaysia، وهي مكتوبة هنا بتوسّع أكبر ممّا يسمح به نصف ساعة.

ما الذي يعنيه «معزول» فعلاً؟

العزل ليس خياراً ثنائياً بين قاعدة بيانات لكل عميل وقاعدة واحدة مشتركة؛ بل طيف، وموضعك عليه قرار تجاري يرتدي ثياباً تقنية:

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

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

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

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

كيف يعرف النظام أي مستأجر يخاطبه؟

قبل أي منطق عمل، على كل طلب أن يُحلَّ إلى مستأجر واحد محدّد. الطرق المتاحة ثلاث، ولها آثار متباينة:

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

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

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

هل المستخدم يخصّ مستأجراً واحداً؟

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

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

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

هل يقيس النظام الاستهلاك من البداية؟

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

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

القرار الأدنى المطلوب في البداية: أن يكون لكل عملية ذات كلفة مُعرّف مستأجر مسجَّل معها. لا حاجة إلى نظام فوترة في الشهر الأول؛ الحاجة إلى ألّا تكون البيانات مفقودة حين يُبنى ذلك النظام.

ما الذي يمكن تأجيله فعلاً

ليس كل شيء في تعدّد المستأجرين قراراً مبكراً، ومعرفة ما يمكن تأجيله تحرّر وقتاً للقرارات الأربعة السابقة:

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

الخيط الجامع بين الأربعة الأولى أنها تلمس كل شيء، وبين هذه الثلاثة أنها موضعية.

الخلاصة

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

هذا ما أبنيه للعملاء، وما أُشغّله بنفسي في مَكّوك، وما أُدرّسه للفرق الهندسية.

الخدمة: تطوير منصّات البرمجيات كخدمة
المادة المرتبطة: كيف تُوسّع منصّة SaaS دون إعادة بنائها
إن كان فريقك هو من يحتاج هذه المادة: تدريب الفرق