لا تستضف مواقع عملائك كلها في حساب واحد

استضافة عشرة مواقع لعملاء مش نفس مشكلة استضافة موقع واحد عشر مرات. الفرق مش في المساحة ولا في عدد الدومينات اللي ووردبريس لتضيف له ميزة جديدة، مثل متجر أو نموذج تواصل أو تحسين للسيو، دون كتابة كود. اختر الإضافات الموثوقة المحدّثة، ولا…">الإضافات والقوالب والمستخدمين والإعدادات، وما يظهر فيها يختلف حسب دور المستخدم.">لوحة التحكم بتقبلها. الفرق إن فيه سؤال واحد بيحدد حجم الكارثة: لما باسورد يتسرب، أو إضافة تتخترق، أو موقع يستهلك كل الموارد، مين من عملائك هيقع معاه؟

ابدأ من سؤال نطاق العطل

نطاق العطل (Failure Domain) هو مجموعة الأنظمة التي يمكن أن يعطّلها حدث واحد. إذا كانت كل مواقع عملائك تستخدم بيانات دخول واحدة، ومالك ملفات واحداً، ومهمة نسخ احتياطي واحدة، وحدود PHP مشتركة، فإن الحساب نفسه هو نطاق العطل.

هذا التصميم يولّد ارتباطات خطيرة:

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

السؤال المعماري الأول إذن ليس “كام موقع يسع الحساب؟” بل “مين يقدر يقع مع مين، وليه؟”.

امنح كل عميل حدود هوية واضحة

يجب أن تمتلك كل بيئة عميل حساب لوحة تحكم خاصاً، ومستخدم نظام مستقلاً حيث توفّره المنصة، وبيانات والسيرفر عبر اتصال SSH مشفّر، وهي البديل الآمن لـ FTP العادي الذي يرسل كلمة المرور نصًا واضحًا يمكن التقاطه بسهولة في…">SFTP وقواعد بيانات ومفاتيح تطبيق منفصلة. مشاركة بيانات دخول المدير يجب أن تكون استثناءً نادراً لا طريقة عمل.

الحد الأدنى المعقول:

• حساب استضافة منفصل لكل عميل.
• هوية مدير ووردبريس فريدة لكل شخص يعمل على الموقع، لا حساب admin مشترك.
• مستخدم قاعدة بيانات وكلمة مرور مستقلين لكل موقع.
• بيانات SFTP أو نشر منفصلة.
• عدم إعادة استخدام كلمات المرور بين الإنتاج وبيئة الاختبار والبريد ومسجّل الدومين.
• المصادقة الثنائية (MFA) أينما دعمتها لوحة التحكم.
• قائمة مرجعية لسحب الصلاحيات عند خروج موظف أو متعاون.

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

تنبيه: أكثر ثغرة شائعة في وكالات المنطقة ليست تقنية: حساب واحد باسم الوكالة يعرف بياناته أربعة أشخاص، اثنان منهم تركا الفريق. ابدأ من هنا قبل أي ترحيل.

تعامل مع طاقة PHP كمسألة طوابير

يوصَف أداء ووردبريس عادة بأنه مشكلة معالج أو مشكلة كاش. تحت الضغط المتزامن هو في الغالب مشكلة طوابير.

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

تابع هذه المؤشرات لكل موقع على حدة:

• عدد عمّال PHP المتزامنين.
• معدل الطلبات ونسبة إصابة الكاش.
• زمن الاستجابة عند الشرائح 50 و95 و99.
• المعاملات البطيئة في PHP.
• زمن استعلامات قاعدة البيانات وضغط الاتصالات.
• خنق المعالج وضغط الذاكرة وانتظار القرص.
• مدة مهام ووردبريس المجدولة (الشيفرة الخبيثة تلقائيًا بعد كل تنظيف.">WP-Cron) وتكرارها.
• مهلات الخدمات الخارجية.

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

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

ضع ميزانية موارد لكل موقع

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

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

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

يجب أن تنتج حدود الموارد مساراً للتصعيد لا مفاجأة. قرّر مسبقاً: هل سيُحسَّن الموقع المحتنق، أم يُرفَّع إلى باقة أعلى، أم يُنقل إلى VPS مستقل، أم يُعاد تصميمه لتقليل العمل المتزامن؟

لا تخلط بين Multisite والعزل

الشبكة متعددة المواقع (Multisite) ميزة تطبيقية لإدارة شبكة مواقع مترابطة، وليست بديلاً عن عزل عملاء لا تربطهم علاقة.

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

استخدم الشبكة حين تكون الحوكمة المشتركة مقصودة. واستخدم بيئات منفصلة حين تكون الملكية والمسؤولية التشغيلية منفصلتين.

اجعل الاستعادة هي وحدة قياس جودة النسخ الاحتياطي

النسخة الاحتياطية لا تثبت صلاحيتها بعلامة خضراء في لوحة التحكم. تثبت حين يستعيد الفريق البيانات المطلوبة خلال الزمن الموعود.

حدّد رقمين لكل عميل:

• نقطة الاستعادة المستهدفة (RPO): كم من البيانات الحديثة يمكن خسارته.
• زمن الاستعادة المستهدف (RTO): كم يمكن أن تبقى الخدمة متوقفة.

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

شغّل اختبارات استعادة مجدولة على بيئة منفصلة، واجعل الاختبار يتجاوز الصفحة الرئيسية:

1. استعد قاعدة البيانات والملفات.
2. استبدل الروابط والمفاتيح الخاصة بالبيئة بشكل آمن.
3. تأكد من نجاح دخول المدير.
4. اختبر النماذج وصفحة الدفع والبحث والمسارات التي تتطلب تسجيل دخول.
5. افحص الوسائط والملفات المولّدة.
6. تحقق من المهام المجدولة والتكاملات الخارجية.
7. سجّل الزمن المستغرق وكل خطوة يدوية احتجتها.

النتيجة تتحول إلى دليل لتخطيط السعة. إذا كانت استعادة مكتبة وسائط متنامية تتجاوز الآن زمن الاستعادة المتفق عليه، فقد اكتشفت المشكلة قبل الحادث لا بعده.

افصل بيئة الاختبار عن الإنتاج

يجب أن تقلّل بيئة الاختبار مخاطر النشر دون أن تتحول إلى باب خلفي للإنتاج.

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

مسار النشر المنضبط صغير وقابل للتكرار: قوالب وإضافات وإعدادات تحت التحكم في الإصدارات (Git)، وترحيلات موثّقة لقاعدة البيانات، ونسخة احتياطية قبل النشر، وفحص صحة بعده، وقرار تراجع بمهلة زمنية واضحة.

تنبيه: لا تجعل الإنتاج هو المكان الأول الذي تكتشف فيه أن تحديث إضافة غيّر بنية قاعدة البيانات أو متطلب إصدار PHP أو سلوك الكاش.

أخرج الدومين والبريد والشهادات من دائرة الانفجار

تفشل استعادة المواقع كثيراً لأن الفريق ركّز على ملفات ووردبريس وقاعدة البيانات فقط.

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

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

اختر نموذج التشغيل بوعي

تختار الوكالات عادة بين ثلاثة نماذج:

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

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

سيرفر افتراضي خاص (VPS): تحكم أوسع في المكدّس والمراقبة والشبكة والأتمتة، مقابل مسؤولية أكبر: تحديثات النظام والتأمين والنسخ الاحتياطي ومراقبة الخدمات وتخطيط السعة واختبار الاستعادة.

النموذج الأغلى ليس بالضرورة الأأمن. الاختيار الصحيح هو أقل المنصات تعقيداً مع تحقيق أهداف العزل والمراقبة والاستعادة المطلوبة.

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

ابنِ خطة خروج لكل عميل

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

حزمة التسليم النظيفة تتضمن: أرشيف ملفات حديثاً، وتصديراً متسقاً لقاعدة البيانات، وسجلات DNS مع قيم TTL، ومتطلبات إصدار PHP والإضافات البرمجية، والمهام المجدولة، والاعتماديات الخارجية، وملكية التراخيص، ودليل استعادة أو ترحيل، وتأكيداً بحذف بيانات الدخول الخاصة بالوكالة.

إذا كان الموقع لا يمكن تصديره واستعادته دون معرفة شفهية في رأس أحد أفراد الفريق، فالبيئة لم تنضج تشغيلياً بعد.

تسلسل ترحيل عملي

الوكالة التي تغادر حساباً مشتركاً كبيراً يجب أن تتجنب تحويلاً واحداً يشمل المحفظة كلها. رحّل على دفعات مضبوطة:

1. اجرد كل موقع ودومين وقاعدة بيانات وصندوق بريد ومهمة وتكامل.
2. رتّب العملاء حسب الأثر التجاري والتعقيد التقني والمخاطر الحالية.
3. أنشئ حسابات وجهة منفصلة ببيانات دخول فريدة.
4. اختبر استعادة النسخة الاحتياطية قبل تغيير DNS.
5. اخفض قيمة TTL قبل موعد التحويل بوقت كافٍ فقط.
6. زامن الملفات وقاعدة البيانات بطريقة تحويل موثّقة.
7. تحقق من المسارات الديناميكية لا من الصفحات المخزّنة فقط.
8. راقب الأخطاء وزمن الاستجابة والبريد والمهام الخلفية بعد التحويل.
9. أبقِ البيئة القديمة للقراءة فقط خلال نافذة تراجع متفق عليها.
10. ألغِ بيانات الدخول القديمة واحذف البيانات المتبقية بأمان.

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

قِس النتيجة

تنجح المعمارية الجديدة حين تصغر الحوادث ويسرع التشخيص وتصبح الاستعادة متوقعة. مؤشرات مفيدة على مستوى المحفظة:

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

الخلاصة

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

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

مرجع المقال (بالإنجليزية): Stop Hosting Client WordPress Sites in One Shared Account
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.

الأسئلة الشائعة

هل أحتاج حساب استضافة منفصلاً لكل عميل فعلاً؟

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

هل تصلح شبكة Multisite لفصل مواقع العملاء؟

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

كيف أعرف أن النسخة الاحتياطية تعمل فعلاً؟

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

ما الفرق بين استضافة الريسيلر والـ VPS للوكالة؟

الريسيلر يمنحك حسابات منفصلة لكل عميل مع لوحة إدارة واحدة دون مسؤولية نظام التشغيل. أما الـ VPS فيمنحك تحكماً أوسع في المكدّس مقابل تحمّلك لتحديثات النظام والتأمين والمراقبة والاستعادة. اختر أقل المنصات تعقيداً وتحقق مع ذلك أهداف العزل والاستعادة المطلوبة.

ما المقصود بميزانية الموارد لكل موقع؟

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