خطة استمرارية الأعمال للشركات المتوسطة: ماذا لو توقف كل شيء غداً

خطة استمرارية الأعمال تجيب عن سؤال واحد: إذا توقف نظام أو مكتب أو شخص أساسي غداً، كيف تستمر الشركة في خدمة عملائها وتحصيل إيراداتها حتى يعود كل شيء؟ أما التعافي من الكوارث فجزء تقني داخلها، يركز على إعادة الأنظمة والبيانات. الشركة المتوسطة لا تحتاج وثيقة من 80 صفحة، بل تحتاج خمس خطوات عملية: تحليل أثر توقف كل نظام بالريال لكل ساعة، وترتيب الأنظمة حسب الأولوية مع زمن استعادة مستهدف RTO ونقطة استعادة RPO لكل نظام، وتحديد مكان آمن للنسخ الاحتياطية وكلمات المرور يمكن الوصول إليه حتى لو تعطل المكتب والبريد، وقائمة اتصال وأدوار واضحة يعرف فيها كل شخص ماذا يفعل في أول 60 دقيقة، وتمرين سنوي مدته ساعتان يكشف الثغرات قبل الحادثة الحقيقية. الشركات التي تطبق هذه الخطوات تعود للعمل عادة خلال ساعات، بينما التي تعتمد على الارتجال قد تحتاج من 3 إلى 10 أيام لإعادة نظام ERP واحد، وتخسر خلالها بيانات لا تُستعاد. هذا المقال يمر على كل خطوة بأمثلة وأرقام قابلة للتطبيق هذا الأسبوع.

الفرق بين استمرارية الأعمال والتعافي من الكوارث

الخلط بين المفهومين يجعل الخطط ناقصة. التعافي من الكوارث (DR) يجيب: كيف أعيد السيرفر وقاعدة البيانات؟ أما استمرارية الأعمال (BCP) فتجيب: كيف يستمر قسم المبيعات في استلام الطلبات بينما السيرفر يُستعاد؟ مثال عملي: إذا توقف نظام الفوترة، فخطة التعافي تعيده خلال 4 ساعات، وخطة الاستمرارية تحدد أن الفريق يصدر فواتير يدوية بنموذج معتمد مسبقاً خلال هذه الساعات، ثم تُدخل في النظام بعد عودته. بدون الجزء الثاني، تتوقف الإيرادات كلها حتى لو كانت الاستعادة التقنية سريعة.

تحليل الأثر: كم يكلف توقف كل نظام بالساعة

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

النظام	كلفة ساعة التوقف (ريال)	RTO المستهدف	RPO المستهدف
ERP والفوترة	12,000	4 ساعات	ساعة واحدة
البريد المؤسسي	3,000	8 ساعات	24 ساعة
بوابة العملاء	5,000	4 ساعات	4 ساعات
نظام الموارد البشرية	500	3 أيام	24 ساعة
الموقع التعريفي	200	يومان	أسبوع

الأرقام تفرض الأولويات تلقائياً. ساعة توقف واحدة للـERP في هذا المثال تساوي 24 ساعة توقف لنظام الموارد البشرية، فلا معنى لأن تكون نسختهما الاحتياطية بنفس التكرار أو أن يُستعادا بنفس الترتيب.

ترجم RPO إلى إعدادات فعلية

RPO بساعة واحدة يعني أن النسخ اليومي وحده لا يكفي. لقاعدة MySQL مثلاً فعّل سجل binlog وانقله كل ساعة لموقع منفصل:

# /etc/mysql/conf.d/binlog.cnf
[mysqld]
log_bin = /var/lib/mysql/binlog
binlog_expire_logs_seconds = 604800

# crontab: نقل السجلات كل ساعة لموقع منفصل
0 * * * * rsync -a /var/lib/mysql/binlog.* backup@offsite:/srv/binlogs/

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

أين تُحفظ النسخ وكلمات المرور وقت الأزمة

أكثر خطأ مؤلم نراه: النسخة الاحتياطية موجودة، لكنها على نفس السيرفر المتعطل، أو كلمة مرور لوحة التحكم محفوظة في بريد لا يعمل. طبّق قاعدة 3-2-1: ثلاث نسخ من البيانات، على نوعين مختلفين من التخزين، ونسخة واحدة على الأقل خارج الموقع الأساسي. على الخادم السحابي تضيف نسخاً يومياً بمدة احتفاظ 7 أيام بـ800 ريال سنوياً أو 30 يوماً بـ2,000 ريال، وتحتفظ بنسخة منطقية إضافية تصدّرها بنفسك إلى موقع آخر. في الاستضافة السحابية المُدارة يأتي النسخ اليومي والأسبوعي مضمّناً في كل الباقات من 2,900 ريال سنوياً.

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

• بيانات دخول لوحة المزود ومفاتيح SSH.
• بيانات مسجل النطاق ولوحة DNS.
• أرقام دعم المزودين ورقم العقد.
• مكان آخر نسخة احتياطية وخطوات استعادتها.

أربعة سيناريوهات يجب أن تغطيها الخطة

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

1. هجوم فدية يشفّر البيانات

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

2. تعذر الوصول للمكتب

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

3. غياب الشخص الأساسي

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

4. تعطل خدمة خارجية

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

قائمة الاتصال والأدوار

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

الدور	المسؤولية
قائد الحادثة	يعلن الحادثة، ويقرر تفعيل الخطة، ويجمع الفريق
المسؤول التقني	يتواصل مع المزود ويقود الاستعادة حسب الأولويات
مسؤول الأعمال	يفعّل الإجراءات البديلة مثل الفواتير اليدوية
مسؤول التواصل	يبلغ العملاء والإدارة برسائل جاهزة مسبقاً

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

التمرين السنوي: ساعتان تكشفان الثغرات

الخطة التي لم تُمرَّن تفشل عادة في أول ثلاثين دقيقة. مرة في السنة، اجمع الفريق ساعتين، واطرح سيناريو محدداً مثل: "الساعة 9 صباح الأحد، السيرفر الأساسي لا يستجيب، والمسؤول التقني في إجازة". ثم راقب ماذا يحدث فعلاً، وسجّل كل لحظة توقف فيها أحد ليسأل "أين كلمة المرور؟" أو "من يتصل بالمزود؟".

اجعل جزءاً من التمرين عملياً: استعد نسخة قاعدة البيانات على سيرفر اختبار، وقِس الزمن. سيرفر بباقة أساس (1 vCPU و2GB RAM) بـ3,450 ريالاً سنوياً يكفي غالباً لاختبار استعادة نظام صغير، وهو مبلغ صغير مقارنة بكلفة ساعة توقف واحدة للـERP في المثال أعلاه. أمر الاستعادة والتحقق يكون بهذا الشكل:

gunzip < erp_2026-10-01.sql.gz | mysql erp_restore_test
mysql -e "SELECT COUNT(*) FROM erp_restore_test.invoices;"

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

المزود المحلي وموقع البيانات

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

ابدأ هذا الأسبوع

1. اجرد أنظمتك واحسب كلفة ساعة التوقف لكل نظام بالجدول أعلاه.
2. حدد RTO وRPO لكل نظام، وتأكد أن إعدادات النسخ تحققهما فعلاً.
3. انقل نسخة واحدة على الأقل خارج السيرفر الأساسي.
4. جهّز مدير كلمات المرور والظرف المختوم.
5. عيّن الأدوار الأربعة بأسماء وبدلاء، واكتب رسائل العملاء الجاهزة.
6. حدد موعد التمرين السنوي في التقويم الآن.

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