صيانة الخوادم: خطة تشغيل للتحديثات والنسخ الاحتياطي والاستعادة الفعلية

كل مهمة تحتاج إلى دور مسؤول

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

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

إيقاع صيانة له غرض مبرر

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

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

ينتهي التحديث بفحص وظيفي

يصف NIST إدارة التصحيحات بأنها تحديد التحديثات وترتيب أولوياتها والحصول عليها وتثبيتها والتحقق منها. ويصنفها الدليل صيانة وقائية. عملياً، لا يكتمل التحديث إلا بفحص التثبيت والخدمة المطلوبة. NIST SP 800-40 Rev. 4: تخطيط إدارة التصحيحات ↗

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

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

خطط للنسخ الاحتياطي انطلاقاً من هدف الاستعادة

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

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

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

مثال: لماذا لا يتحقق هدف استعادة خلال ساعتين؟

يجب أن تعود خدمة افتراضية قابلة للاستخدام خلال ساعتين من الانقطاع. تحتوي النسخة على 200 GB بوحدات عشرية. نفترض في الاختبار معدل نقل فعلياً قدره 400 Mbit/s. يحتاج النقل وحده إلى 200 × 8,000 / 400 = 4,000 ثانية، أي نحو 67 دقيقة. جميع المدد التالية افتراضات حسابية من إعدادنا.

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

اربط التنبيهات بإجراء

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

راقب الاتجاهات إلى جانب الأخطاء: السعة الاحتياطية وعمر آخر نسخة ناجحة وارتفاع أزمنة الاستجابة وقرب انتهاء الشهادات. في التخزين، يهم التغير. يعطي حسابنا مع 500 GB فارغة ونمو 20 GB يومياً مدة نظرية 25 يوماً حتى الامتلاء؛ وتقلل احتياطيات الصيانة والذروات الفترة المفيدة. يسمح ذلك بتخطيط التوسعة قبل رفض التطبيق الكتابة.

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

حدّث مدد الدعم ومعلومات التسليم أيضاً

احتفظ بتقويم لدورة حياة نظام التشغيل وقاعدة البيانات والتطبيق والعتاد. يعتمد نطاق الدعم على المنتج والإصدار وأي عقد مشتَرى. تميز Canonical مثلاً مستويات مختلفة للصيانة والدعم في دورة Ubuntu. افحص التغطية الفعلية لتثبيتك بدلاً من عمر رقم الإصدار فقط. Canonical: دورة إصدارات Ubuntu وتغطية الدعم ↗

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

تقرير شهري يقود إلى قرارات

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

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