تُتخذ معظم قرارات استضافة Odoo مرة واحدة، عند الاشتراك، ثم لا يعود إليها أحد. يحصي أحدهم عدد الموظفين، ويختار الباقة التي يطابق عدد مستخدميها هذا الرقم، وينتهي الأمر. هذه نقطة بداية معقولة، لكنها إجابة ضعيفة على المدى الطويل، لأن استهلاك Odoo للموارد يرتبط بما يفعله الناس أكثر بكثير من ارتباطه بعدد من يملكون حساباً.
فيما يلي ما يحدد فعلياً حجم نظام Odoo، وكيف تفكر فيه دون تخمين.
عدد الحسابات شيء، والمستخدمون المتزامنون شيء آخر
الشركة التي لديها 60 حساباً في Odoo نادراً ما يكون فيها 60 شخصاً يرسلون طلبات في اللحظة نفسها. مندوب المبيعات يفتح سجلاً، يقرأه، يكتب لدقيقتين، ثم يحفظ. المحاسبون يعملون على دفعات حول إقفال الفترة. الرقم الذي يُجهد الخادم هو النشاط المتزامن، وهو في الإدارات الخلفية جزء صغير من إجمالي الحسابات في أي لحظة.
والاستثناءات هنا أهم من القاعدة. سلسلة تجزئة تشغّل Point of Sale لديها كاشيرات يستخدمون النظام بلا انقطاع طوال ساعات العمل. أرضية تصنيع بأجهزة باركود تولّد تدفقاً ثابتاً من عمليات كتابة صغيرة. متجر إلكتروني يضع زواراً مجهولين على النظام نفسه الذي يعمل عليه موظفوك. إن انطبق أي من ذلك عليك، فعدد الموظفين لا يخبرك شيئاً تقريباً، وشكل الحركة يخبرك بكل شيء.
ما الذي يستهلك المعالج والذاكرة
يخدم Odoo الطلبات عبر مجموعة من عمليات worker، وكل worker يعالج طلباً واحداً في كل مرة ويحتفظ بذاكرته الخاصة. هذا يترك لك رافعتين عمليتين، عدد الـ workers وحجم الذاكرة لكل واحد منها، وأنواعاً من الأحمال تسحب عليهما بطرق مختلفة:
- الاستخدام التفاعلي: رخيص لكل طلب، لكنه يصل باستمرار، وهو أول ما يلاحظه المستخدمون حين لا يوجد worker متاح للرد عليهم.
- توليد التقارير: ملف PDF بمئات السطور، أو جدول محوري يغطي سنة كاملة، قد يشغل worker لمدة أطول بكثير من فتح صفحة عادية.
- الاستيراد والتعديلات الجماعية: شخص واحد يستورد عشرات الآلاف من السطور يحجز worker طوال العملية وينافس بقية الفريق عليه.
- الإجراءات المجدولة: المهام الدورية والفواتير المتكررة وإعادة التزويد والتكاملات تعمل وفق ساعتها الخاصة، وأثقلها يعمل غالباً ليلاً حيث لا يراه أحد، إلى أن يتقاطع مع نافذة النسخ الاحتياطي.
- حركة الـ API: نظام خارجي يستعلم من نظامك بشكل دوري هو مستخدم لا ينام ولا يأخذ استراحة غداء ولا يملّ من إعادة المحاولة.
نمو قاعدة البيانات يأتي من أماكن لا يخطط لها أحد
حجم الحركات المحاسبية والتشغيلية هو المحرك الواضح. أما المحركات الصامتة فهي الأكثر أثراً مع الوقت:
- المرفقات: الفواتير الممسوحة ضوئياً وصور المنتجات ومرفقات البريد الواردة تتجاوز حجم بيانات العمل نفسها في كثير من الأنظمة.
- سجل المحادثات: كل رسالة وملاحظة وتغيير في حقل متتبَّع يُخزَّن. وفي أنواع السجلات كثيرة الحركة يتراكم هذا أسرع من تراكم السجلات ذاتها.
- نقاط البيع والمخزون: سطور الطلبات وحركات المخزون صغيرة منفردة وضخمة مجتمعة.
المساحة التخزينية عادةً أرخص مورد يمكن زيادته، فالحجم بحد ذاته ليس المشكلة. المشكلة في نتائجه. قاعدة بيانات تضاعف حجمها ثلاث مرات بهدوء تغيّر مدة النسخ الاحتياطي، ومدة الاسترجاع، ومدة ترقية الإصدار. وهذه بالذات هي الأرقام التي تؤلم في اليوم الذي تحتاجها فيه.
كيف تعرف أن الحجم أصغر مما يجب
نقص الحجم نادراً ما يعلن عن نفسه كتوقف كامل. يظهر على شكل صفحات تستغرق عدة ثوانٍ بعد الظهر بينما تبدو سريعة في الثامنة صباحاً، وتقارير نهاية الشهر التي تنتهي مهلتها بينما التقرير نفسه يعمل بلا مشكلة في منتصف الشهر، وعمليات استيراد يضطر الفريق لتأجيلها إلى ما بعد الدوام، وتكاملات تبدأ بالفشل في أكثر أوقاتك ازدحاماً. حين تكون الشكوى «النظام بطيء بعد الغداء»، فأنت غالباً أمام نمط سعة لا أمام خلل برمجي.
كيف تعرف أن الحجم أكبر مما يجب
الإفراط في الحجم أهدأ، لكنه يحاسبك كل شهر. إن بقي نظامك على الباقة نفسها لمدة سنتين، ولم يتغير حجم حركتك كثيراً، ولم يشتكِ أحد من البطء، فأنت على الأرجح تدفع مقابل هامش لا تصل إليه. هذه مقايضة مشروعة إن كانت تشتري لك الطمأنينة في ذروة معروفة، وهي هدر إن كانت الذروة لا تأتي أصلاً.
طريقة عملية لتقدير الحجم
- ابدأ من ذروة النشاط المتزامن، لا من عدد الموظفين. اسأل متى يكون النظام في أشد ازدحامه، وكم شخصاً يعمل عليه فعلياً في تلك اللحظة.
- سمِّ عملياتك الثقيلة صراحة: إقفال نهاية الشهر، تشغيل الرواتب، عمليات الاستيراد الكبيرة، التكاملات المجدولة. هذه هي التي تحدد المتطلب، لا اليوم المتوسط.
- قدّر النمو خلال 12 شهراً القادمة لا خلال 5 سنوات. أي تقدير يتجاوز سنة هو تخمين ستعيد النظر فيه على أي حال.
- افصل ما يحتاج سعة عمّا يحتاج إصلاحاً. التقرير البطيء غالباً مشكلة في التقرير نفسه، وشراء باقة أكبر لن يعالجه.
تقدير الحجم قرار يُراجَع، لا قرار يُتخذ مرة
الخطأ الأشيع هو التعامل مع اختيار الباقة كقرار دائم. الشركات تفتح فرعاً، أو تطلق متجراً، أو تستوعب استحواذاً، أو تضيف وحدة تغيّر شكل الحمل بالكامل. العادة المفيدة هي النظر في سلوك النظام الفعلي وفق إيقاع ثابت، ومرة كل ربع سنة تكفي معظم الشركات، ثم التعديل بقرار واعٍ بدل انتظار تصعيد المستخدمين.
في Plemo، تأتي استضافة Odoo المُدارة مع نسخ احتياطي آلي، واسترجاع إلى نقطة زمنية محددة، ومراقبة، وبيئات staging، عبر باقات Starter وProfessional وEnterprise، بحيث يصبح تغيير الباقة خطوة تشغيلية لا مشروع ترحيل. وأياً كان من يستضيفك، يبقى المبدأ نفسه: قدّر الحجم للذروة التي تستطيع تسميتها فعلاً، وتعامل مع الرقم كقرار له موعد مراجعة.
وإن كان نظامك يعمل بالفعل ولست متأكداً إن كان البطء مشكلة سعة أم مشكلة في الإعداد، فاحسم هذا السؤال قبل أن تدفع مقابل موارد إضافية. فحص صحة نظام ERP موجود لهذا التمييز بالذات.