متطلبات استضافة نظام ERP مخصص على سيرفر سعودي: الموارد والأمان والنفاذ الوطني

الإجابة المباشرة: ماذا يحتاج نظام ERP مخصص على سيرفر سعودي

نظام ERP مخصص لشركة متوسطة، من 20 إلى 100 مستخدم متزامن، يحتاج كحد أدنى عملي 4 إلى 8 vCPU، ومن 8 إلى 16 GB RAM، وقرص SSD من 40 إلى 100 GB، مع فصل قاعدة البيانات عن طبقة التطبيق متى تجاوز الحمل عدداً كبيراً من المستخدمين النشطين. لكن الأرقام وحدها لا تحسم القرار، فالأهم في استضافة ERP هو أين توضع البيانات وكيف تُؤمَّن ومن يصل إليها، وهل يتكامل النظام مع النفاذ الوطني والجهات الحكومية. هذه العوامل تفرض سيرفراً داخل السعودية، لأن التكامل الحكومي كثيراً ما يرفض النداءات القادمة من عناوين IP خارجية، ولأن زمن الاستجابة من سيرفر في الرياض يقارب 8ms مقابل 100 إلى 120ms من سيرفر أوروبي، وهذا الفرق يظهر مباشرة في كل استعلام قاعدة بيانات يمر عليه المستخدم عشرات المرات في الجلسة الواحدة.

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

حساب الموارد: كم vCPU وRAM وSSD يحتاج نظامك فعلاً

القاعدة الهندسية أن تبدأ من الحمل لا من التخمين. المستخدم المتزامن في ERP ليس المستخدم المسجَّل، بل من يرسل طلباً فعلياً في اللحظة نفسها، وعادة يمثّل من 10% إلى 20% من إجمالي المستخدمين. شركة فيها 200 موظف على النظام قد يكون ذروة تزامنها الحقيقي 30 إلى 40 مستخدماً فقط، وهذا ما تُبنى عليه الموارد.

لكل مستخدم متزامن نشط في ERP نموذجي احسب من 150 إلى 250 MB من RAM لطبقة التطبيق، ونواة معالجة تخدم من 8 إلى 12 مستخدماً متزامناً في الأحمال العادية. بهذا المنطق:

• حتى 20 مستخدماً متزامناً: باقة نمو بـ 2 vCPU و4 GB RAM قد تكفي بداية، لكن الأأمن 4 vCPU و8 GB إذا كانت التقارير ثقيلة.
• من 20 إلى 50 مستخدماً: باقة أعمال بـ 4 vCPU و8 GB RAM هي نقطة الانطلاق المنطقية.
• من 50 إلى 100 مستخدم: باقة مؤسسة بـ 8 vCPU و16 GB RAM مع فصل قاعدة البيانات على مثيل مستقل.

أما التخزين فلا تنظر إلى حجم البيانات الحالي فقط، بل إلى نموّه. قاعدة بيانات ERP تنمو بمعدل 20% إلى 40% سنوياً في شركة نشطة، لذا خصّص ضعف حجمك الحالي على الأقل، واحرص أن يكون القرص SSD حصراً، لأن الفرق بين SSD وقرص دوّار في زمن الوصول العشوائي يفوق 20 ضعفاً، وهذا بالضبط نمط وصول ERP: استعلامات صغيرة كثيرة متفرقة. في كلاود كل الباقات على SSD افتراضياً، وتقدر تزيد التخزين بخطوة 100 GB مسعّرة بوضوح متى احتجت.

قاعدة البيانات: أهم قرار في استضافة ERP

قاعدة البيانات هي عنق الزجاجة في 80% من مشاكل أداء ERP التي نراها عند الترحيل. النظام قد يكون مكتوباً بإتقان، لكن استعلاماً واحداً بلا فهرس مناسب يكفي ليجرّ السيرفر كله. لذلك عزل قاعدة البيانات وضبطها ليس رفاهية.

الفصل بين طبقة التطبيق وقاعدة البيانات

ما دام عدد المستخدمين المتزامنين تحت 25، يمكن تشغيل التطبيق وقاعدة البيانات على نفس المثيل بأمان. فوق ذلك، افصلهما على مثيلين، لأنهما يتنافسان على الذاكرة والمعالج بأنماط مختلفة: التطبيق يريد معالجة، وقاعدة البيانات تريد ذاكرة وI/O. الفصل يرفع الأداء بنسبة تصل إلى 30% تحت الحمل، ويسمح بتوسيع كل طبقة مستقلة عن الأخرى.

ضبط MySQL أو PostgreSQL

أياً كان محرّكك، هذه المعايير تصنع الفرق:

• ذاكرة التخزين المؤقت: في MySQL اضبط innodb_buffer_pool_size على 60% إلى 70% من ذاكرة السيرفر المخصصة لقاعدة البيانات، فهذه الذاكرة هي التي تُبقي الفهارس والبيانات الساخنة قريبة دون قراءة القرص.
• الفهارس: راجع الاستعلامات البطيئة عبر سجل slow query log بحدّ ثانية واحدة، وأنشئ فهارس على الأعمدة المستخدمة في الشروط والربط. فهرس واحد صحيح قد يختصر استعلاماً من 4 ثوانٍ إلى أقل من 50ms.
• الاتصالات: اضبط max_connections بحسب الحمل الحقيقي لا بمبالغة، لأن كل اتصال يحجز ذاكرة، والرقم المتضخّم يستهلك RAM بلا فائدة.

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

الأمان: طبقات لا خيار واحد

أمان ERP يُبنى طبقات، لأن أي طبقة وحيدة تسقط يوماً ما. البيانات هنا حساسة: رواتب، عقود، فواتير، بيانات عملاء تخضع لأنظمة حماية البيانات السعودية. الحد الأدنى الجاد يشمل:

• عزل الشبكة: قاعدة البيانات لا تكون معرّضة على الإنترنت العام إطلاقاً، بل خلف جدار ناري لا يقبل إلا اتصالات طبقة التطبيق. أغلق كل منفذ لا تستخدمه، وابقِ منفذ قاعدة البيانات 3306 أو 5432 مغلقاً خارجياً بالكامل.
• التشفير: شهادة SSL على كل اتصال، وتشفير القرص للبيانات الساكنة. كلاود يوفّر شهادات Let's Encrypt مجاناً، وهذا يغطي التشفير أثناء النقل دون تكلفة.
• التحكم بالوصول: لا تستخدم مستخدم root لقاعدة البيانات في التطبيق، بل مستخدماً بأقل صلاحية تكفي. فعّل المصادقة الثنائية على لوحة التحكم والوصول SSH، واحصر SSH بمفاتيح لا كلمات مرور.
• التحديثات: رقعة أمنية واحدة متأخرة تكفي لاختراق. 60% من الاختراقات تستغل ثغرات معروفة لها تحديث منشور أصلاً، لذا رقّع نظام التشغيل ومحرّك قاعدة البيانات دورياً.

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

تكامل النفاذ الوطني ولماذا يفرض سيرفراً سعودياً

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

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

النسخ الاحتياطي واستمرارية العمل: RPO وRTO

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

• RPO منخفض: لنظام ERP نشط، استهدف RPO أقل من ساعة عبر نسخ قاعدة بيانات متكرر خلال اليوم، لا نسخة يومية واحدة تفقد معها عمل يوم كامل عند أي عطل.
• تعدد المستويات: نسخة يومية للاستعادة السريعة، وأسبوعية وشهرية للرجوع الأبعد. كلاود يوفّر النسخ اليومي والأسبوعي والشهري على كل باقات الاستضافة المُدارة دون تكلفة إضافية.
• اختبار الاستعادة: نسخة احتياطية لم تُختبر استعادتها ليست نسخة، بل افتراض. اختبر الاستعادة كل ربع سنة على الأقل حتى تعرف RTO الحقيقي قبل أن تحتاجه في يوم عطل.

واحتفظ بنسخة خارج السيرفر نفسه، لأن نسخة على نفس القرص تسقط مع القرص. القاعدة المعروفة 3-2-1 تعني ثلاث نسخ على وسيطين مختلفين ونسخة خارج الموقع، وهي الحد الذي يحمي فعلاً.

قائمة تحقق قبل ترحيل ERP إلى سيرفر سعودي

قبل نقل نظامك المخصص، راجع هذه البنود لتتجنّب أكثر المشاكل شيوعاً في الترحيل:

• الموارد: حسبتَ الحمل من المستخدمين المتزامنين الحقيقيين، وخصّصت هامش نمو 30% على الأقل.
• قاعدة البيانات: فصلتها عند تجاوز 25 مستخدماً متزامناً، وراجعت الفهارس والاستعلامات البطيئة قبل الترحيل لا بعده.
• الأمان: أغلقت منفذ قاعدة البيانات خارجياً، وفعّلت SSL والمصادقة الثنائية ومستخدم قاعدة بيانات محدود الصلاحية.
• النفاذ الوطني: تأكدت أن IP السيرفر سعودي ومسجّل حيث تتطلبه التكاملات الحكومية.
• النسخ الاحتياطي: حدّدت RPO وRTO، وفعّلت نسخاً متعدد المستويات، واختبرت استعادة كاملة مرة واحدة على الأقل.

كلاود لا يرحّل الأنظمة المخصصة نيابة عن مطوّرك، لكنه يوفّر البنية السعودية الصحيحة ودعماً هندسياً لفريقك عبر جلسات توجيه أثناء الترحيل. أنت تختار الموارد بحرية عبر مكوّن VPS، وتفعّل السيرفر خلال ثوانٍ بعد الدفع، وتبني عليه نظامك بأداء 8ms من الرياض وامتثال داخل حدود المملكة.