استضافة Odoo في السعودية: المواصفات الصحيحة لكل حجم شركة
المواصفة الصحيحة لـ Odoo تُحسب بقاعدة عدد الـ workers = (عدد الأنوية × 2) + 1، مع نحو 150 ميجابايت رام لكل worker. تعرف على الباقة المناسبة لـ 10 و25 و50 مستخدماً متزامناً على سيرفر سعودي بزمن استجابة 8ms.
مواصفة استضافة Odoo الصحيحة تُحسب ولا تُخمّن. القاعدة العملية أن عدد عمليات المعالجة المتوازية (workers) يساوي عدد الأنوية مضروباً في اثنين زائد واحد، أي على سيرفر بأربعة أنوية تحصل على تسعة workers، وكل worker يحتاج نحو 150 ميجابايت رام في الاستخدام العادي وقد يصل إلى 250 ميجابايت في التقارير الثقيلة. كل worker يخدم في المتوسط من ست إلى ثماني جلسات مستخدم متزامنة فعلية، لأن المستخدم لا يرسل طلباً في كل ثانية بل يقرأ ويكتب بفواصل. بناءً على ذلك، شركة بعشرة مستخدمين متزامنين تكفيها باقة نمو (2vCPU/4GB)، وخمسة وعشرون مستخدماً يحتاجون باقة أعمال (4vCPU/8GB) مع زيادة رام، وخمسون مستخدماً متزامناً يبدأون من باقة مؤسسة (8vCPU/16GB) وقاعدة بيانات PostgreSQL مضبوطة جيداً. الاستضافة داخل السعودية تعطي زمن استجابة نحو 8ms من الرياض بدل 80 إلى 120ms من سيرفرات أوروبا، وهذا فرق محسوس في نظام تفتح فيه عشرات الشاشات يومياً. أضف إلى ذلك أن الفوترة الإلكترونية السعودية ومتطلبات هيئة الزكاة والضريبة والجمارك تجعل بقاء البيانات المالية على تراب سعودي قراراً عملياً لا رفاهية.
لماذا Odoo منتشر في السوق السعودي
Odoo نظام تخطيط موارد مؤسسية مفتوح المصدر يجمع المحاسبة والمبيعات والمخزون والموارد البشرية ونقاط البيع في منصة واحدة، وهذا يناسب الشركة السعودية المتوسطة التي لا تريد شراء خمسة أنظمة منفصلة. النسخة المجتمعية مجانية الترخيص، فتدفع ثمن السيرفر والإدارة فقط لا رسوم مستخدم شهرية، وهذا وحده يوفّر آلاف الريالات سنوياً مقارنة بأنظمة الاشتراك السحابي المغلقة. الأهم أن استضافته على خادم سحابي خاص بك تمنحك تحكماً كاملاً في الوحدات المثبتة، وفي جدولة النسخ الاحتياطي، وفي تكامل النظام مع الفوترة الإلكترونية ومنصات الدفع المحلية عبر واجهات برمجية مباشرة.
الشركات التي تشغّل Odoo عادة تملك مطوراً أو شريكاً تقنياً يدير الوحدات المخصصة، وهذا هو جمهور كلاود بالضبط: شركات بأنظمة مخصصة تحتاج بنية تحتية سعودية مستقرة لا استضافة ووردبريس رخيصة. الفرق بين تشغيل Odoo على سيرفر مضبوط وآخر عشوائي يظهر في نهاية الشهر وقت إقفال الحسابات، حين تفتح التقارير المجمّعة والقيود المحاسبية دفعة واحدة.
كيف تُحسب الموارد بالأرقام
ابدأ من عدد المستخدمين المتزامنين الحقيقي لا إجمالي عدد الموظفين. شركة فيها أربعون موظفاً قد يكون متزامنها الفعلي وقت الذروة اثني عشر مستخدماً فقط. بعد تقدير المتزامن، طبّق الخطوات التالية:
- عدد الـ workers = (عدد الأنوية × 2) + 1. مثال: 4 أنوية تعطي 9 workers.
- الرام للـ workers = عدد الـ workers × 200 ميجابايت كمتوسط آمن يشمل الطلبات الثقيلة.
- رام PostgreSQL = خصّص من 25% إلى 30% من إجمالي الرام لقاعدة البيانات عبر shared_buffers.
- رام نظام التشغيل والخدمات = احجز نحو 1 جيجابايت هامش أمان.
القاعدة الذهبية: worker واحد يخدم من ست إلى ثماني جلسات نشطة. إذا كان لديك عشرون مستخدماً متزامناً، فأنت تحتاج بين ثلاثة وأربعة workers فعّالة، وهذا يترجم إلى سيرفر بأربعة أنوية يعطيك تسعة workers مع فائض مريح لتقارير الإقفال. لا تنسَ فصل worker مخصص للمهام المجدولة (cron) عن workers الطلبات، لأن مهمة مجدولة ثقيلة قد تجمّد الواجهة إن تشاركت نفس المورد.
الباقة المناسبة لكل حجم شركة
الجدول التالي يربط عدد المستخدمين المتزامنين بباقات كلاود مباشرة، مع الإضافات التي ننصح بها من صفحة الخادم السحابي:
| الحجم | مستخدمون متزامنون | الباقة الأساسية | workers | إضافات مقترحة | التكلفة السنوية التقريبية |
|---|---|---|---|---|---|
| صغيرة | حتى 10 | نمو 2vCPU/4GB | 5 | +2GB RAM (600 ريال) لأمان الإقفال | نحو 7,500 ريال |
| متوسطة | حتى 25 | أعمال 4vCPU/8GB | 9 | +2GB RAM (600) + نسخ احتياطي يومي 30 يوماً (2,000) | نحو 14,100 ريال |
| كبيرة | حتى 50 | مؤسسة 8vCPU/16GB | 17 | +100GB SSD (500) + نسخ يومي 30 يوماً (2,000) | نحو 20,500 ريال |
هذه الأرقام مبنية على تسعير كلاود السنوي شامل ضريبة القيمة المضافة 15%. باقة نمو تبدأ من 6,900 ريال، وأعمال من 11,500، ومؤسسة من 18,000، مع تفعيل تلقائي للخادم خلال ثوانٍ بعد الدفع عبر Virtualizor. للاطلاع على كل التسعير راجع صفحة الأسعار والباقات.
لماذا نرفع الرام قبل الأنوية
Odoo نظام يستهلك الذاكرة أكثر من المعالج في أغلب الأحمال، لأن التقارير المحاسبية تحمّل مجموعات بيانات كبيرة في الذاكرة. لهذا نضيف رام قبل أن نفكر في أنوية إضافية، والإضافة عندنا +2GB رام بـ600 ريال سنوياً و+1 vCPU بـ500 ريال، فتوسّع المورد الذي تحتاجه فقط بدل شراء باقة أكبر بالكامل.
ضبط PostgreSQL الأساسي
قاعدة البيانات هي قلب أداء Odoo، وضبطها البسيط يصنع فرقاً كبيراً. على سيرفر بثمانية جيجابايت رام، ابدأ بهذه القيم كنقطة انطلاق ثم راقب وعدّل:
- shared_buffers = 2GB (نحو 25% من الرام).
- effective_cache_size = 5GB (نحو 60% من الرام).
- work_mem = من 16 إلى 32 ميجابايت لكل عملية فرز.
- maintenance_work_mem = 512 ميجابايت لعمليات الفهرسة والصيانة.
- max_connections = اضبطها قريبة من عدد الـ workers زائد هامش، ولا ترفعها عشوائياً لأن كل اتصال يستهلك ذاكرة.
شغّل عملية VACUUM ANALYZE مجدولة أسبوعياً على الأقل حتى تبقى خطط الاستعلام دقيقة، وفعّل فهارس على الحقول التي تبحث بها كثيراً في الفواتير وأوامر البيع. مع نمو قاعدة البيانات فوق عشرين جيجابايت، تصبح مساحة SSD السريعة أهم من عدد الأنوية، والإضافة عندنا +100GB SSD بـ500 ريال سنوياً.
الفوترة الإلكترونية والسيادة المحلية
نظام Odoo المستضاف داخل السعودية يتكامل مع منظومة الفوترة الإلكترونية لهيئة الزكاة والضريبة والجمارك عبر واجهاتها البرمجية، وبقاء البيانات المالية على سيرفر سعودي يبسّط أي تدقيق ويحفظ سرية أرقامك. زمن الاستجابة نحو 8ms من الرياض يعني أن كل استدعاء واجهة برمجية للفوترة يعود بسرعة، ووقت التشغيل المرتفع يضمن أن نظامك يعمل وقت إصدار الفواتير لا وقت راحة السيرفر. النسخ الاحتياطي اليومي والأسبوعي والشهري يحميك من أي خطأ بشري أو تحديث فاشل قبل الإقفال الشهري.
متى ترقّي: علامات الحمل بالأرقام
لا تنتظر شكوى المستخدمين لتعرف أن السيرفر امتلأ، راقب أربع إشارات رقمية تخبرك متى تضيف مورداً. الإشارة الأولى استهلاك المعالج: إذا بقي فوق 80% لأكثر من عشر دقائق في أوقات الذروة بشكل متكرر، فأنت بحاجة أنوية أو workers إضافية. الإشارة الثانية استهلاك الرام: إذا بدأ نظام التشغيل باستخدام مساحة swap على القرص، فالأداء ينهار فوراً لأن القرص أبطأ من الرام بمئات المرات، وهذه علامة رفع رام عاجلة. الإشارة الثالثة زمن استجابة الصفحات: إذا تجاوز فتح شاشة عادية ثانيتين بشكل ثابت، فابحث عن السبب في قاعدة البيانات أو الـ workers. الإشارة الرابعة طول طابور الطلبات: إذا صار المستخدمون ينتظرون دور طلبهم لأن كل الـ workers مشغولة، فقد وصلت حد الطاقة الفعلي.
القاعدة العملية أن تضيف المورد الذي بلغ حده أولاً لا أن ترقّي الباقة كاملة. إذا كانت الرام هي المختنقة، أضف +2GB بـ600 ريال، وإذا كان المعالج، أضف +1 vCPU بـ500 ريال، وإذا امتلأ القرص مع نمو قاعدة البيانات، أضف +100GB SSD بـ500 ريال. هذا التوسّع الجزئي أرخص بكثير من القفز لباقة أكبر بالكامل، والتفعيل لحظي بدفع الفرق فقط عبر لوحة التحكم. راقب هذه المؤشرات أسبوعياً في الأشهر الأولى بعد الإطلاق، فمنحنى النمو يختلف من شركة لأخرى بحسب توسّع فريقها.
خطوات عملية للبدء
ابدأ بحساب عدد مستخدميك المتزامنين وقت الذروة لا إجمالي الموظفين، ثم اختر الباقة من الجدول أعلاه. إن كنت بين حجمين، اختر الأصغر وأضف رام عند الحاجة لأن التوسّع عندنا لحظي بدفع الفرق. فعّل النسخ الاحتياطي اليومي بثلاثين يوم احتفاظ قبل أول إقفال شهري، واضبط PostgreSQL بالقيم أعلاه. للأنظمة الأكبر أو الربط الحكومي، ابدأ من صفحة الخادم السحابي واطلب اجتماع توجيه تقني لمطوّرك، فكلاود لا يهاجر نظامك لكنه يدعم فريقك في الضبط والربط. الخلاصة: احسب، اختر باقة نمو أو أعمال أو مؤسسة حسب المتزامن، وارفع الرام قبل الأنوية.
