استضافة المواقع للشركات: البنية لكل مرحلة

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

01ثلاثة أرقام قبل أي خطة

قبل أن تقارن الخطط، اكتب هذه الأرقام على ورقة واحدة واتفق عليها مع الإدارة:

• هدف التوافر: نسبة الوقت الذي يجب أن يبقى فيه موقعك متاحاً خلال الشهر، كـ 99.9% أو 99.99%. ترد عادة في اتفاقية مستوى الخدمة التي تعقدها مع مزوّدك، أو التي تَعِد بها عملاءك.
• زمن الاستعادة (RTO): هدف زمن الاستعادة أطول مدة مقبولة بين لحظة العطل ولحظة عودة الخدمة: أربع ساعات لموقع تعريفي، وربع ساعة لمنصة يعمل عليها عملاؤك طوال اليوم.
• نقطة الاستعادة (RPO): هدف نقطة الاستعادة أقصى قدر من البيانات تتحمل خسارته، مقيساً بالزمن. نسخة احتياطية كل ليلة تعني أنك قد تخسر حتى 24 ساعة من الطلبات والتعديلات.

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

02ماذا تعني نسب التوافر بالدقائق

النسب تبدو متقاربة، لكن الفرق بينها كبير حين تحوّلها إلى دقائق. هذا التوقف المسموح في شهر من 30 يوماً (43,200 دقيقة) وفي سنة كاملة:

وتذكّر أن موقعك سلسلة من المكونات: DNS، ثم خادم التطبيق، ثم قاعدة البيانات، وربما بوابة دفع خارجية. إن كان تعطّل أي مكوّن يُسقط الموقع كله، فتوافر الموقع حاصل ضرب نسبها. خادم بضمان 99.97% وقاعدة بيانات على خادم آخر بالضمان نفسه وDNS بنسبة 99.99% تعطيك نحو 99.93%، أي قرابة 30 دقيقة في الشهر، لا 13. ضع نسب مكوناتك في هذا السطر واحسب بنفسك:

# توافر سلسلة من ثلاثة مكونات: الخادم وقاعدة البيانات وDNSawk 'BEGIN { a = 0.9997 * 0.9997 * 0.9999; printf "%.2f%%  %.1f min/month\n", a * 100, (1 - a) * 43200 }'

ما لا تقوله نسبة الضمان

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

خوادم CoreVPS مثلاً بضمان تشغيل 99.97%، أي نحو 13 دقيقة في شهر من 30 يوماً. هذا رقم البنية التحتية؛ أما توافر تطبيقك فيُبنى فوقه بما تقرره أنت.

03المرحلة الأولى: شركة صغيرة

موقع تعريفي أو متجر بعشرات الطلبات يومياً، وبريد لبضعة موظفين، ولا مهندس متفرغ للخوادم. هنا يكفي هدف 99.9%، وRTO من بضع ساعات، وRPO من يوم واحد في الغالب. والخطر الحقيقي في هذه المرحلة ليس العطل التقني، بل غياب نسخة تستعيد منها، وكلمة مرور واحدة يعرفها موظف غادر.

• استضافة cPanel مشتركة: المزوّد يدير الخادم وتحديثاته، وأنت تدير موقعك من لوحة التحكم. خطط cPanel Start وPower وInfinity من إليفانتي تتسع لنحو 35,000 و75,000 و150,000 زيارة شهرياً، مع شهادة SSL تتجدد تلقائياً، ونسخ احتياطية تُحفظ 15 و30 و45 يوماً بحسب الخطة.
• بريد مُدار مستقل: خطط cPanel تضم حسابات بريد غير محدودة تكفي البداية. لكن إن كان البريد قناة البيع الأولى عندك، ففصله على خدمة مخصصة، كالبريد الإلكتروني للأعمال من Acrux Mail، يعني أن عطلاً في الموقع لا يوقف مراسلاتك، والعكس.
• النطاق باسم الشركة: سجّل النطاق باسم الشركة وببريد إداري لا يرتبط بشخص واحد، وفعّل المصادقة الثنائية في منطقة العملاء.
• نسخة خارج المزوّد: نزّل نسخة كاملة من حسابك مرة في الشهر واحفظها في تخزين تملكه الشركة. نسخ المزوّد تحميك من الأعطال، ونسختك تحميك من فقدان الحساب نفسه.
• مراقبة خارجية: اشترك في خدمة فحص توافر تطلب صفحتك الرئيسية كل دقيقة إلى خمس دقائق وتنبّهك بالبريد أو الهاتف. أن تعرف بالتوقف قبل عملائك يختصر نصف زمن الاستعادة.

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

04المرحلة الثانية: شركة متوسطة

متجر يبيع كل ساعة، أو تطبيق SaaS بمئات المستخدمين، أو وكالة تستضيف مواقع عملائها، ومعه مطوّر أو مدير أنظمة واحد على الأقل. الهدف هنا نحو 99.95%، وRTO بين ساعة وأربع ساعات، وRPO ساعة أو أقل. خطوات الانتقال من الاستضافة المشتركة إلى خادم VPS نشرحها في مقال مستقل على المدونة؛ وهنا نركّز على شكل البنية بعده:

• خادم للتطبيق وآخر لقاعدة البيانات: فصل قاعدة البيانات على خادم VPS ثانٍ يمنع استعلاماً ثقيلاً من خنق خادم الويب، ويتيح لك ترقية كل منهما وحده، ويُبقي قاعدة البيانات خارج الإنترنت العام: لا يصلها إلا خادم التطبيق عبر جدار الحماية.
• شبكة توصيل المحتوى: شبكة CDN أمام الموقع تخدم الصور والملفات الثابتة من نقاط قريبة من الزوار، فتخفف الحمل عن خادمك وتقصّر زمن التحميل في المدن البعيدة عن مركز البيانات.
• مراقبة وتنبيهات: فحص التوافر وحده لا يكفي: راقب المعالج والذاكرة وامتلاء القرص وزمن الاستجابة p95، واضبط التنبيه قبل أن يمتلئ القرص لا بعده. خوادم CoreVPS تضم Grafana وPrometheus وZabbix بين تطبيقاتها الجاهزة عند الإنشاء.
• بيئة اختبار (Staging): نسخة مصغرة من الإنتاج تجرّب عليها التحديثات قبل نشرها. أغلب التوقفات في هذه المرحلة يسببها تحديث، لا عطل في العتاد.
• نسخ احتياطي بطبقتين: نسخة كاملة من الخادم كل ليلة، ونسخة لقاعدة البيانات كل ساعة على الأقل، وكلتاهما خارج الخادم. كل خطة CoreVPS تأتي بمساحة نسخ احتياطي خارجية بين 10 و100 GB بحسب الخطة.

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

# تفترض الأوامر أن بيانات الدخول إلى MySQL محفوظة في ~/.my.cnf# على خادم الإنتاج: نسخة متسقة لجداول InnoDB دون قفلهاmysqldump --single-transaction --routines --triggers souq_db | gzip > /backup/souq_db-$(date +%F-%H%M).sql.gz# انقل النسخ إلى خادم نسخ في مركز بيانات آخرrsync -az /backup/ [email protected]:/srv/backups/souq/# على خادم الاختبار: اجلب النسخ، واستعد أحدثها، وقِس الزمنrsync -az [email protected]:/srv/backups/souq/ /restore/mysql -e "CREATE DATABASE IF NOT EXISTS souq_staging"time (gunzip -c "$(ls -t /restore/souq_db-*.sql.gz | head -1)" | mysql souq_staging)

إن استغرقت الاستعادة 40 دقيقة، فلا تَعِد إدارتك بـ RTO من ربع ساعة. وRPO هنا يساوي الفاصل بين نسختين؛ فإن احتجت أقل من ساعة فالحل في سجلات المعاملات والاستعادة إلى لحظة محددة، وهو ما نفصّله في مقالنا عن استضافة قواعد البيانات.

05المرحلة الثالثة: شركة كبيرة

منصة يعمل عليها آلاف المستخدمين في الوقت نفسه، وعقود تَعِد عملاءك بنسبة توافر وتعويضات، وجهات رقابية تسأل أين بياناتك ومن يصل إليها. الهدف 99.99%، أي 4 دقائق في الشهر، وRTO دون 15 دقيقة، وRPO بالثواني. هذا لا يحققه خادم أقوى، بل بنية ليس فيها مكوّن واحد يُسقط الخدمة إن تعطل:

• عدة خوادم تطبيق خلف موازن حمل: موازنة الحمل توزّع الطلبات على خادمين أو أكثر، وتُخرج الخادم المعطل من الدوران تلقائياً، فتنشر التحديثات خادماً بعد خادم دون توقف. والموازن نفسه يحتاج نسخة ثانية تتسلّم عنوانه إن تعطل.
• قاعدة بيانات بنسخ متماثل: النسخ المتماثل يُبقي خادماً احتياطياً يتلقى كل تغيير من الخادم الرئيسي. التماثل غير المتزامن أسرع، لكنه قد يُفقدك ثواني من الكتابات عند التحويل؛ والمتزامن يجعل RPO صفراً مقابل زمن كتابة أطول. اختر بحسب ما وعدت به.
• نسخ احتياطية في منطقة ثانية: التماثل ينسخ الأخطاء أيضاً: جدول حُذف بالخطأ يُحذف من النسختين في ثانية. لذلك تبقى النسخ المستقلة ضرورية، وتُحفظ في مركز بيانات آخر. مع CoreVPS مثلاً تشغّل الإنتاج في ألمانيا وتحفظ النسخ وموقع التعافي في فنلندا، فتبقى البيانات داخل الاتحاد الأوروبي.
• الامتثال: اعرف القوانين التي تخضع لها بياناتك: GDPR إن خدمت مقيمين في الاتحاد الأوروبي، وPCI DSS إن مرت بيانات البطاقات عبر خوادمك؛ وأبسط طريق للخروج من نطاق PCI أن تترك البطاقة لبوابة الدفع ولا تخزنها أبداً. وفعّل سجلات تدقيق لكل وصول إداري، ومصادقة متعددة العوامل، وتشفير النسخ.
• تمارين التعافي: خطة التعافي التي لم تُجرَّب ورقة. أوقف الخادم الرئيسي عمداً في بيئة الاختبار مرتين في السنة على الأقل، وقِس كم دقيقة احتاج التحويل.

06جدول القرار حسب المرحلة

وهذه أخطاء شائعة في كل مرحلة، وما يكمن خلفها:

المشكلةوعدنا عملاءنا بـ 99.99% لأن خادمنا بضمان 99.97%

الحلتوافر موقعك حاصل ضرب مكوناته، فهو أقل من أضعف حلقة فيها. لا تَعِد بأكثر مما قسته فعلاً على مدى ثلاثة أشهر.

المشكلةالنسخ الاحتياطية موجودة، لكن الاستعادة استغرقت يوماً كاملاً

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

المشكلةالنسخ محفوظة على الخادم نفسه

الحلعطل القرص أو اختراق الخادم يأخذ النسخ معه. انقلها إلى تخزين منفصل، ويُفضَّل أن يكون في مركز بيانات آخر.

المشكلةالموقع يبطؤ فنشتري خادماً أكبر كل بضعة أشهر

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

07قبل أن تقرر

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

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