عندما يتعطل موقع أو نظام أو مورد، تحتاج المؤسسة إلى معرفة ما يجب استمراره، وبأي قدرة، وخلال أي وقت. يساعد معيار ISO 22301 على تنظيم هذه القرارات ضمن نظام إدارة استمرارية الأعمال. يشرح هذا المقال كيف تتحول الأولويات إلى ترتيبات قابلة للاستخدام، وكيف تكشف التمارين الفرق بين وجود خطة مكتوبة والقدرة الفعلية على التعافي.
ما الذي ينظمه ISO 22301؟
يحدد ISO 22301:2019 متطلبات نظام إدارة استمرارية الأعمال (Business Continuity Management System — BCMS). يشمل ذلك الاستعداد للتعطل، والاستجابة له، واستمرار تقديم المنتجات والخدمات بقدرة مقبولة محددة مسبقًا. وتعرض صفحة ISO الرسمية تعديلًا صادرًا في 2024 بعنوان «تغييرات العمل المناخي». لذلك تُراجع نسخة المعيار وتعديلاته عند تحديد مرجع التطبيق، ولا يُعامل التعديل بوصفه إصدارًا مستقلًا باسم ISO 22301:2024.
ابدأ بسؤال تشغيلي واضح: أي خدمة سيؤدي توقفها إلى أثر غير مقبول؟ ثم عيّن مالكًا لها وحدد حدودها ومواقعها ومورديها. تحتاج الإدارة إلى اعتماد الأولويات وتوفير الموارد وحسم التعارض بينها. لا يكفي تكليف منسق بكتابة الخطط إذا كانت قرارات التمويل والتشغيل خارج صلاحياته.
تحليل أثر الأعمال: ما الذي نستعيده أولًا؟
يركز تحليل أثر الأعمال (Business Impact Analysis — BIA) على عواقب توقف الأنشطة بمرور الوقت. اجمع المعلومات من أصحاب العمليات، واختبرها مقابل سجلات الطلبات والمواعيد والالتزامات. قد يكون توقف قصير محتملًا في وقت هادئ، لكنه مؤثر قرب موعد تسليم حاسم. دوّن هذه الفروق بدل استخدام تقدير واحد لجميع الظروف.
حدّد متى تصبح الآثار غير مقبولة، ثم ضع أهداف الاستعادة قبل بلوغ تلك النقطة. اربط كل نشاط بالأشخاص والبيانات والتجهيزات والموافقات التي يحتاجها. لا تمنح جميع الأنشطة أولوية قصوى؛ فهذا يخفي المفاضلة التي ستواجهها المؤسسة عند نقص الموارد. يمكن بدء التحليل بخدمة واحدة، ثم توسيعه بعد مراجعة جودة المعلومات.
زمن التعافي يختلف عن نقطة استعادة البيانات
زمن التعافي المستهدف (Recovery Time Objective — RTO) يحدد الوقت المستهدف لاستعادة النشاط أو المورد إلى المستوى المتفق عليه بعد التعطل. أما نقطة الاستعادة المستهدفة (Recovery Point Objective — RPO)، في سياق البيانات، فتحدد النقطة الزمنية التي يجب استعادة البيانات إليها. إذا كان الهدف 15 دقيقة، فينبغي ألا تعود الاستعادة إلى بيانات أقدم من 15 دقيقة قبل الانقطاع.
لا يعني تشغيل الخادم أن الخدمة أصبحت جاهزة. قد يلزم التحقق من البيانات وتسجيل دخول المستخدمين وتشغيل الواجهات واختبار معاملة كاملة. ولهذا يُكتب مع هدف الوقت مستوى الخدمة المطلوب، مثل عدد الطلبات الممكن معالجتها. تحدد المؤسسة هذه الأهداف من احتياجاتها؛ لا يفرض المعيار رقمًا موحدًا بالساعات لكل المؤسسات.
من مخاطر التعطل إلى بدائل قابلة للتنفيذ
يسأل تقييم المخاطر عمّا قد يعطل الأنشطة وكيف يحدث ذلك. وقد يشمل فقدان الموقع أو غياب مهارة أساسية أو تعطل مورد مشترك. أما تحليل الأثر فيساعد على ترتيب الاستعادة وفق عواقب التوقف. استخدمهما معًا: الأول يوجه الوقاية والاستعداد للسيناريوهات، والثاني يوضح أولويات الاستمرارية.
قارن البدائل بحسب الوقت والقدرة والتكلفة والاعتماد على أطراف أخرى. هل يستطيع الموقع البديل استيعاب الفريق؟ وهل للمورد البديل مخزون متاح فعلًا؟ وهل يعتمد مزودا الاتصال على المسار نفسه؟ اطلب دليلًا يتناسب مع أهمية الافتراض، مثل تجربة تشغيل أو تحقق من قدرة متاحة. وجود عقد أو اسم بديل في جدول لا يثبت جاهزيته.
خطة يمكن استخدامها تحت الضغط
اكتب شروط التفعيل، وصاحب القرار وبديله، والإجراءات الأولى، وحدود الصلاحيات، وطريقة التصعيد. اجعل بيانات الاتصال والنسخة المعتمدة متاحتين حتى عند تعطل النظام المعتاد. يمكن اختبار قابلية الاستخدام بإعطاء الخطة لشخص مؤهل لم يكتبها، وسؤاله عن أول إجراء والجهة التي يتواصل معها.
نسّق الأدوار بين الاستجابة للطوارئ وإدارة الأزمات والتعافي التقني واستمرارية العمليات. حماية الأشخاص تبقى أولوية، ولا يبرر هدف الاستعادة تشغيلًا غير آمن. حدّد من يرسل التحديثات للعملاء والعاملين والموردين، ومتى، ومن يتحقق من مضمونها. وأدرج طريقة العودة إلى العمل المستقر وتسوية المعاملات المتراكمة؛ فاستئناف الخدمة ليس نهاية المهمة.
مثال افتراضي: عادت الخدمة، لكن هل تحقق الهدف؟
لنفترض خدمة طلبات وضعت هدفًا لاستئناف العمل خلال 4 ساعات، بقدرة لا تقل عن 20 طلبًا في الساعة. وحددت نقطة استعادة للبيانات لا تتجاوز 15 دقيقة قبل الانقطاع. هذه أرقام تعليمية مفترضة، وليست نتائج عميل أو حدودًا يحددها المعيار.
في تمرين، استأنف الفريق الخدمة بعد 3 ساعات و30 دقيقة، وأثبت معالجة 20 طلبًا في الساعة. تحقّق هدف الوقت بهامش 30 دقيقة، وكذلك هدف القدرة في ظروف التمرين. لكن أحدث بيانات قابلة للاستعادة كانت أقدم من الانقطاع بـ40 دقيقة؛ فتجاوزت نافذة البيانات المستهدفة بمقدار 25 دقيقة: 40 − 15 = 25.
النتيجة نجاح جزئي يستلزم إجراءً تصحيحيًا. يفحص الفريق سبب تقادم النسخة، ويحدد طريقة استكمال الطلبات المفقودة، ثم يعيد اختبار الاستعادة. ولا يعني نجاح التمرين ضمان النتيجة في حادث حقيقي؛ فقد تختلف الأحمال والموارد المتاحة. سجّل افتراضات الاختبار وحدوده إلى جانب النتائج، حتى لا تتحول تجربة محدودة إلى ادعاء شامل بالجاهزية.
التمارين والتحسين وحدود الشهادة
ابدأ بتمرين يناسب الخطر والقدرة الحالية: مناقشة سيناريو لاختبار القرارات، أو محاكاة للتنسيق، أو اختبار تقني للاستعادة. حدّد معيار النجاح مسبقًا، واجمع توقيتات وأدلة تشغيل، بدل الاكتفاء بقائمة الحضور. عيّن لكل فجوة مسؤولًا وموعدًا، ثم تحقّق من فعالية المعالجة في اختبار لاحق.
اربط نتائج التمارين والحوادث والتغييرات بالتدقيق الداخلي ومراجعة الإدارة وتحديث الخطط. راجع أيضًا التغييرات التي تبدو صغيرة، مثل انتقال موظف أساسي أو استبدال مزود خدمة. يمكن تطبيق النظام دون السعي إلى شهادة. وإذا اختيرت الشهادة، فإنها تتعلق بمطابقة نظام الإدارة ضمن نطاق محدد، ولا تضمن انعدام الانقطاع أو نجاح كل استجابة. وقد ينشأ طلب الشهادة من عقد أو جهة منظمة، لا من قرار المؤسسة وحده.
أسئلة عملية قبل البدء
هل تكفي النسخ الاحتياطية؟
تدعم استعادة البيانات، لكنها لا توفر وحدها الأفراد والموقع والصلاحيات والموردين. اختبر استعادة خدمة كاملة، ولا تكتفِ برسالة نجاح مهمة النسخ.
هل يجب تنفيذ كل البدائل فورًا؟
رتّب التنفيذ بحسب الأولويات والفجوات، مع قرار إداري واضح بشأن المخاطر المتبقية. لا تعرض بديلًا مخططًا أو غير مختبر بوصفه قدرة متاحة.
الخطوة الأولى: اختبر خدمة واحدة من البداية إلى النهاية
اختر خدمة ذات أولوية، واجمع مالكها مع ممثلي التقنية والموارد والموردين المعنيين. اتفقوا على وقت الاستعادة وقدرتها واحتياجات البيانات. راجعوا الاعتماديات، ثم نفّذوا تمرينًا محدودًا بأهداف واضحة. سيمنحكم الفرق بين المستهدف والنتيجة قائمة تحسين محددة، يمكن تمويلها ومتابعتها وإعادة اختبارها.
