ما هو وقت تشغيل الخادم؟ وكيف يجب قياسه؟

يُعبَّر عن وقت تشغيل الخادم عادة كنسبة مئوية من الوقت كان فيه الخادم أو الخدمة قابلاً للوصول ومستجيبًا خلال فترة معيّنة — شهر، سنة. النسبة بسيطة في ذكرها وسهلة في سوء الفهم، لأنها تُخفي أمرين يهمان بقدر أهمية الرقم نفسه: كيف أُخذ القياس فعليًا، وماذا يُعدّ "توقفًا" أصلاً.

كيف يُقاس وقت التشغيل فعليًا

تعمل مراقبة وقت التشغيل بإرسال فحوصات دورية للخادم — طلب HTTP، أو ping، أو محاولة اتصال بمنفذ — على فاصل زمني ثابت، وتسجيل نجاح أو فشل كل فحص. نسبة وقت التشغيل المُبلَّغ عنها هي أساسًا (الفحوصات الناجحة ناقص الفاشلة) مقسومة على إجمالي الفحوصات، خلال فترة القياس. هذا يعني أن الفاصل الزمني بين الفحوصات يؤثر مباشرة في ما يُقاس: مراقب يفحص مرة كل 5 دقائق لا يستطيع كشف الأعطال إلا بدقة 5 دقائق — خادم يتعطل ويتعافى خلال دقيقتين قد لا يُسجَّل كفحص فاشل إطلاقًا، بينما مراقب يفحص كل 10 ثوانٍ سيلتقط ذلك التوقف القصير نفسه. يمكن أن يُبلِّغ إعدادا مراقبة يراقبان الخادم نفسه بالضبط بنسب وقت تشغيل مختلفة لمجرد اختلاف تكرار فحصهما، وهذا سبب كون طريقة القياس جزءًا مما يعنيه الرقم، لا هامشًا فرعيًا له. يهم مصدر الفحص بقدر أهمية تكراره: مراقب يفحص من موقع واحد فقط لا يرى سوى المسار بين تلك النقطة والخادم، ومشكلة شبكة إقليمية أو مشكلة توجيه أو عطل يصيب جزءًا واحدًا فقط من الإنترنت يمكن أن يجعل الخادم غير قابل للوصول لزوار حقيقيين في تلك المنطقة بينما يُبلِّغ مراقب يفحص من مكان آخر عن وقت تشغيل مثالي طوال الوقت. راجع شرح مراقبة المواقع لمعرفة كيف يغلق الفحص من مواقع متعددة تلك الثغرة تحديدًا.

ماذا تعني "التسعات" عمليًا

يُوصَف وقت التشغيل غالبًا بعدد "تسعاته"، وأسهل طريقة لرؤية الفرق العملي بينها هي تحويلها لتوقف فعلي على مدار سنة:

القفزة بين كل مستوى أكبر مما تبدو عليه كنسبة مئوية مكتوبة — الانتقال من 99% إلى 99.9% يقلّص التوقف السنوي من نحو ثلاثة أيام ونصف إلى أقل من تسع ساعات، ومن 99.9% إلى 99.99% يقلّصه أكثر إلى أقل من ساعة. كل تسعة إضافية أصعب وأكلف بشكل ملموس من سابقتها عمليًا، وهذا سبب أهمية الدقة في تحديد أي مستوى يهم فعلاً لموقع معيّن بدلاً من معاملة "تسعات أكثر" كأمر مجاني.

الأسباب الشائعة للتوقف

التوقف ليس حصرًا، ولا حتى غالبًا، حدث عطل في العتاد. تشمل الأسباب الشائعة نوافذ صيانة مخطَّط لها (تحديثات برمجية، استبدال عتاد) لم تُبلَّغ كتوقف لكنها تُسجَّل كذلك في نظر المراقب، وسوء ضبط نُشِر بالخطأ، ونفاد الموارد (خادم ينفد منه الذاكرة أو مساحة القرص تحت حمل غير متوقَّع)، ومشاكل على مستوى الشبكة أعلى من الخادم نفسه، وهجمات DDoS أو ارتفاعات حركة تتجاوز السعة المتاحة. ليس كل توقف خطأ الخادم نفسه أيضًا — يمكن لسوء ضبط DNS أو عطل شبكة أعلى أن يجعل خادمًا سليمًا تمامًا غير قابل للوصول، وهو ما يُبلِّغ عنه فحص المراقبة بنفس الطريقة التي يُبلِّغ بها عن عطل خادم فعلي، لأن كليهما يبدو من الخارج متماثلاً: لا استجابة. هذا جزء من سبب أهمية تحديد السبب الجذري بعد الحادث بقدر أهمية كشفه أصلاً — خادم كان سليمًا تقنيًا طوال حادثة سببها مشكلة DNS أو شبكة أعلى يحتاج إصلاحًا مختلفًا عن خادم تعطّل فعليًا، رغم أن كليهما يظهران كتوقف متماثل في تقرير المراقبة. عطل العتاد تحديدًا — قرص تالف، خطأ ذاكرة، أو مشكلة في مكوّن فعلي آخر — يميل لأن يكون الأقل شيوعًا على بنية تحتية جيدة الصيانة مقارنة بالأسباب الأخرى المذكورة هنا، ولو فقط لأنه الفئة الوحيدة التي صُمِّم العتاد الزائد وطبقات الافتراضية الحديثة خصيصًا لتقليلها، بينما تبقى أخطاء الضبط ونفاد الموارد مسألة ممارسة تشغيلية بحتة لا موثوقية عتاد.

وقت تشغيل الخادم مقابل وقت تشغيل الخدمة

"الخادم يعمل" و"الموقع يعمل" ليسا دائمًا الحقيقة نفسها، وهذا تمييز يستحق الدقة فيه. يمكن أن يكون الخادم متاحًا تمامًا ومستجيبًا لفحص اتصال أساسي — نظام التشغيل يعمل، الاتصال الشبكي سليم — بينما تعطّل أو تجمّد التطبيق المحدَّد العامل عليه (عملية خادم الويب، قاعدة البيانات، خدمة معيّنة). لا رؤية لمراقب يفحص فقط استجابة الخادم لـ ping لذلك العطل إطلاقًا، لأن الخادم سليم تمامًا من منظور شبكي بحت. هذا سبب أن مراقبة وقت التشغيل ذات المعنى تفحص الخدمة الفعلية التي تهم — استجابة HTTP ناجحة من الموقع نفسه، لا مجرد عنوان IP قابل للوصول — ولماذا يمكن قياس والإبلاغ عن كل خدمة مستقلة على خادم واحد يستضيف عدة خدمات (موقع وواجهة برمجية منفصلة، مثلاً) على حدة، لأن تعطل واحدة لا يعني بالضرورة تعطل الأخرى.

ماذا تفحص أداة المراقبة فعليًا

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

أرقام وقت التشغيل مقابل اتفاقية مستوى الخدمة

يستحق الأمر توضيح تمييز: رقم تقني عام كـ"99.9% تعادل نحو 8.76 ساعة توقف سنويًا" مجرد حساب رياضي، لا التزام من مزوّد معيّن. أي ضمانة فعلية يقدمها مزوّد استضافة بخصوص وقت التشغيل — بما في ذلك ما يُحتسَب توقفًا مؤهَّلاً، وكيف يُقاس، وأي تعويض ينطبق إن لم يُستوفَ — موجودة في اتفاقية مستوى الخدمة الخاصة بذلك المزوّد، وهي وثيقة تعاقدية خاصة بمزوّد وخطة معيّنين، لا معيارًا تقنيًا عالميًا. تعامل مع النسب أعلاه كطريقة لفهم ما يعنيه رقم معيّن بالساعات، لا كتمثيل لما تضمنه أي خطة استضافة محددة. عند مقارنة مزوّدين أو خطتين، التفصيل الذي يستحق قراءته في اتفاقية مستوى خدمة فعلية نادرًا ما يكون النسبة الرئيسية نفسها — بل تعريف ما يُحتسَب توقفًا (هل تُحتسَب الصيانة المجدولة ضمن الرقم أم تُستثنى تمامًا)، وكيف يُقاس ذلك التوقف ومن يقيسه، وأي تعويض، إن وُجد، ينطبق عند عدم الالتزام. يمكن لخطتين تعلنان نفس النسبة الرئيسية أن تختلفا جوهريًا بمجرد احتساب تلك التفاصيل.

الخلاصة العملية

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