النسخ الاحتياطي والمراقبة: ما يحتاجه نظامك بعد الإطلاق

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

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

النسخة التي لم تُختبر استعادتها ليست ضماناً

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

لذلك توصي الوكالة الأمريكية للأمن السيبراني وأمن البنية التحتية CISA، في دليلها لمواجهة برمجيات الفدية، باختبار توفر النسخ الاحتياطية وسلامتها بانتظام في سيناريو تعافٍ من الكوارث. وعملياً يعني ذلك أن تستعيد نسخة كاملة على بيئة منفصلة، وتتأكد أن النظام يعمل عليها وأن آخر الحركات موجودة فيها.

ثم هناك قرارات يتخذها صاحب العمل، لا الفريق التقني وحده:

• كم مرة تؤخذ النسخة؟ والسؤال الحقيقي وراءه: ما مقدار العمل الذي تقبل أن تخسره وتعيد إدخاله إن تعطل النظام الآن؟
• كم تُحفظ النسخ؟ يرتبط ذلك بالتزاماتك المحاسبية والقانونية، وبالمدة التي قد يمر فيها خطأ في البيانات دون أن يُكتشف.
• ما المدة المقبولة لعودة النظام؟ فالمتجر الإلكتروني في موسم البيع يختلف عن نظام تقارير شهرية.

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

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

أكثر من مكان، ووصول منفصل

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

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

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

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

ماذا تراقب

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

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

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

السجلات

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

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

تنبيه يصل إلى شخص باسمه، ودليل للأعطال

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

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

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

ويوصي دليل CISA بإعداد خطة للاستجابة للحوادث وصيانتها والتدرّب عليها بانتظام. وفي الأنظمة الإدارية يكفي في البداية دليل تشغيل بسيط ومكتوب يجيب عن أسئلة محددة:

1. كيف نعرف أن هناك عطلاً، ومن يتأكد منه؟
2. من يُبلَّغ داخل الشركة، وماذا يقال للفروع والعملاء؟
3. ما الخطوات الأولى لكل نوع من الأعطال المعروفة؟
4. متى نقرر الاستعادة من نسخة احتياطية، ومن يملك هذا القرار؟
5. كيف نوثّق ما حدث بعد انتهاء العطل، وما الذي نغيّره حتى لا يتكرر؟

من يملك النظام بعد الإطلاق

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

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

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

النظام الذي لا يملك أحد تشغيله يعمل حتى أول عطل، ثم يبدأ البحث عن المسؤول والعمل متوقف.

قائمة تحقق بعد الإطلاق

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

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

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