متطلبات نظام HSE On-Premise: الخوادم والتشغيل والتحديثات

ما الذي يتغير فعلًا عندما يعمل النظام على خوادمك؟

في السحابة المُدارة يشتري المشتري خدمة تعمل. في On-Premise يشتري برنامجًا يحتاج بيئة تعمل، وكل ما كان مخفيًا داخل الاشتراك يصبح بندًا له مالك. صفحة الأمن والاستضافة تلخص ذلك في سطر: On-Premise «تثبيت على خوادم المنشأة ضمن شبكتها، تحت سياسات تقنية المعلومات لديها»، والتحديثات «مجدولة بالتنسيق».

عمليًا تنتقل إلى فريقك أربع مسؤوليات كانت على المورد: البنية والخوادم، والنسخ الاحتياطي وتنفيذه، ونافذة التحديث التي تُجدول بالتنسيق مع المورد، وإتاحة النظام للمستخدمين خارج المكاتب. ويبقى على المورد البرنامج نفسه: الإصدارات، والإرشادات، والدعم من المستوى الثاني. لهذا تُكتب متطلبات On-Premise في ثلاث طبقات منفصلة: ما تطلبه وثيقةً من المورد، وما تجهزه أنت، وما تتفقان عليه في مصفوفة مسؤوليات. خلط الطبقات الثلاث في بند واحد («يلتزم المورد بتوفير بيئة تشغيل مناسبة») من أكثر ما يولّد الخلاف بعد التوقيع.

وإن لم يُحسم القرار بعد بين الخيارات الثلاثة، فهذه المقالة سابقة لأوانها؛ ابدأ من مقارنة Cloud وOn-Premise لنظام HSE ثم عد إلى هنا.

متطلبات نظام HSE On-Premise في البنية: ما تطلبه وما تجهزه

لا تكتب في الكراسة مواصفات خوادم من عندك. اطلب من المورد وثيقة بنية ومتطلبات خوادم لحجم منشأتك المحدد، ثم راجعها مقابل معايير مركز بياناتك. صفحة الأمن والاستضافة تذكر أن المورد يقدم لفريق تقنية المعلومات «وصف البنية والمكونات ومتطلبات الخوادم لنسخة On-Premise»، فاجعل هذه الوثيقة مخرجًا إلزاميًا في العرض الفني لا وعدًا لما بعد الترسية.

لاحظ أن العمود الأخير ليس تفصيلًا. كل سؤال فيه يمثل موقفًا تكرر في مشاريع On-Premise: محرك قاعدة بيانات لا تملك الجهة رخصته، أو مرفقات تُنسخ في مكان وقاعدة البيانات في مكان آخر فلا تتطابقان عند الاستعادة، أو إشعارات تتوقف لأن الجدار الناري يمنع الخروج إلى بوابة الرسائل.

كيف تقدّر حجم التخزين ونموه لنظام سلامة؟

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

لذلك لا تكتفِ بطلب «مساحة تخزين مناسبة». أعطِ المورد أرقام نشاطك المتوقع، واطلب منه تقدير النمو السنوي، ثم أضف إليه نسخ الاحتياط ومدة الاحتفاظ.

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

الشبكة ووصول الجوال: البند الذي يُكتشف متأخرًا

أصعب متطلبات On-Premise لنظام السلامة ليس الخادم بل الطريق إليه. المستخدم الحقيقي للنظام مشرف في موقع بعيد، أو عامل مقاول في ساحة مشروع، أو فني يفتش طفايات في فرع آخر. صفحة المقارنة تقولها صراحة: في On-Premise «يجب أن تكون المنصة متاحة للأجهزة الميدانية عبر الإنترنت أو شبكة المنشأة بحسب سياسة تقنية المعلومات».

أمامك عادة ثلاثة نماذج، ولكل منها متطلبات مختلفة تُكتب في الكراسة:

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

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

الهوية والتكاملات داخل الشبكة

ميزة On-Premise هنا حقيقية: التكامل مع الأنظمة الداخلية يكون «مباشرًا داخل الشبكة» كما في جدول المقارنة، دون فتح واجهات أنظمتك إلى الخارج. لكن «مباشر» لا يعني «تلقائيًا». كل تكامل يحتاج حسابات خدمة وقواعد اتصال وملكية واضحة.

• Active Directory وSSO: حدد خدمة الهوية المستخدمة لديك وطريقة الربط، وحساب الخدمة وصلاحياته الدنيا. صفحة المستخدمين والصلاحيات تذكر إنشاء المستخدم وتعطيله تلقائيًا من Active Directory حسب حالته في دليل المنشأة.
• الموارد البشرية: اتجاه البيانات، ودورية المزامنة، والحقول المطلوبة (الموظف، الوظيفة، الإدارة، المدير، حالة التعيين).
• ERP والصيانة ونظام الدخول: ما يتيحه كل نظام من واجهات بإصداره الحالي، لأن نطاق كل تكامل يُحدد بحسب النظام الآخر وواجهاته.
• أدوات BI: هل تقرأ من واجهات API أم من نسخة تقارير منفصلة، حتى لا تثقل الاستعلامات قاعدة الإنتاج.
• البريد الداخلي: خادم الترحيل وعنوان المرسل والقيود على المرفقات.

صفحة التكاملات وAPI تصف منهجية تبدأ بالحصر ثم الأولوية ثم التصميم ثم الاختبار في بيئة تجريبية ثم التشغيل مع «سجل لكل عملية مزامنة وتنبيه عند الفشل». في On-Premise اطلب أن يصل هذا التنبيه إلى أداة المراقبة لديك لا إلى بريد شخص واحد. وتفصيل متطلبات كل تكامل وصياغتها في الكراسة يأتي في متطلبات التكامل لنظام EHS.

ويستحق بند الذكاء الاصطناعي سطرًا مستقلًا: صفحة الذكاء الاصطناعي تنص على أن إمكاناته وطريقة تشغيله في نسخ On-Premise والسحابة الخاصة «تُحدد ضمن نطاق المشروع ومتطلبات المنشأة لأمن البيانات». فإن كان المساعد الذكي جزءًا من قرارك، فاكتبه متطلبًا صريحًا واطلب وصف تشغيله في بيئتك وما يحتاجه من موارد واتصال.

مصفوفة المسؤوليات بين المورد وتقنية المعلومات

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

أما مستويات الخدمة وتصنيف الأعطال والتدريب بعد الإطلاق فتفصّلها SLA نظام HSE والدعم والتدريب؛ ويكفي في ملحق On-Premise أن تربط كل صف في المصفوفة ببند في اتفاقية الخدمة.

التحديثات والإصلاحات: كيف تكتب سياسة لا تُجمّد النظام

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

اطلب من المورد سياسة إصدارات مكتوبة تجيب عن: كم مرة تصدر التحديثات؟ ما الفرق بين التحديث الوظيفي والإصلاح الأمني العاجل؟ كم إصدارًا سابقًا يبقى مدعومًا؟ هل يحتاج التحديث إيقافًا للخدمة وكم يقدّر؟ ثم ابنِ عليها دورة تحديث ثابتة:

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

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

النسخ الاحتياطي والاستعادة: ما يُنسخ وكيف يُثبت

في On-Premise ينفذ فريقك النسخ عادة، كما تذكر صفحة الأمن والاستضافة: «تدير المنشأة البنية التحتية والنسخ وفق سياستها، ونقدم الإرشادات والإجراءات والدعم». الخطأ الشائع أن تطبق سياسة النسخ العامة دون أن تعرف ما الذي يكوّن نسخة صالحة من هذا النظام بالذات.

• قاعدة البيانات والمرفقات تُنسخان في التوقيت نفسه أو بطريقة تضمن تطابقهما عند الاستعادة؛ وإلا ظهرت سجلات بلا صورها أو صور بلا سجلاتها.
• ملفات الإعداد والمفاتيح والشهادات جزء من النسخة، ويُحفظ ما هو حساس منها بضوابط منفصلة.
• هدف نقطة الاستعادة (RPO) وهدف زمن الاستعادة (RTO) يُتفق عليهما كتابيًا مع فريق السلامة. صفحة الأمن تذكر «خطة تعافٍ بأهداف استعادة يُتفق عليها»، فلا تقبل صياغة عامة.
• نسخة خارج الموقع أو في موقع تعافٍ، مشفرة، ضمن ما تسمح به سياسة البيانات.
• اختبار استعادة دوري على بيئة منفصلة بمحضر: ما الذي استُعيد، وكم استغرق، وهل عملت التكاملات بعده.

عند تحديد RTO فكر بالسؤال الميداني لا التقني: إذا توقف النظام صباح يوم عمل، كيف تُصدر التصاريح؟ إن كانت الإجابة «نعود للورق»، فاكتب إجراء الطوارئ الورقي وطريقة إدخال ما صدر خلال التوقف بعد عودة النظام. هذه ليست مسؤولية المورد، لكنها جزء من متطلبات تشغيل نظام سلامة على خوادمك.

المراقبة والسجلات: ما الذي تراقبه تقنية المعلومات

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

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

وصول المورد عن بعد للدعم: كيف تتيحه دون أن تفتح الباب

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

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

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

وإن كانت جهتك من الجهات التي تنطبق عليها الضوابط الأساسية للأمن السيبراني (ECC-2:2024) من الهيئة الوطنية للأمن السيبراني، فراجع مع فريق الأمن السيبراني لديك ما تشترطه على الأطراف الخارجية والوصول عن بعد، وانقل ذلك إلى الكراسة متطلبات صريحة بدل الإحالة العامة. وصياغة بقية المتطلبات الأمنية من الهوية إلى اختبار الاختراق تفصلها متطلبات أمن منصة HSE.

سيناريو: مرفق مياه يُعد متطلبات On-Premise

قائمة ما ترفقه بكراسة الشروط وما تطلبه في العرض الفني

اجمع ما سبق في ملحق تقني واحد بعنوان «متطلبات النشر على خوادم المنشأة»، وضعه ضمن المتطلبات غير الوظيفية في قالب كراسة متطلبات نظام HSE. ما تقدمه أنت للموردين:

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

وما تطلبه من كل مورد في عرضه الفني، مكتوبًا لا شفهيًا:

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

هذه البنود هي ما يجعل ردود الموردين قابلة للمقارنة، وطريقة صياغتها بحيث لا يجيب المورد بـ«نعم ندعم» تشرحها كتابة RFP لنظام HSE. وعندما يكتمل الملحق يمكنك إرساله مع طلب عرض السعر لتحصل على عرض On-Premise مبني على بيئتك الفعلية.

الأسئلة الشائعة

اقرأ أيضًا