وقت تشغيل الاستضافة Uptime: كيفية مراقبته بدقة

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

للحصول على قياس دقيق، تحتاج إلى مراقبة خارجية مستقلة تفحص موقعك بصورة دورية، وتسجل أوقات التوقف والاستجابة، وتتحقق من المشكلة من أكثر من نقطة قبل إرسال التنبيه. كما يجب أن تعرف الفرق بين توقف الخادم، وفشل صفحة معينة، ومشكلة DNS، وخطأ شهادة HTTPS، وبطء الموقع؛ فكل حالة منها تحتاج إلى طريقة قياس مختلفة.

في هذا الدليل ستتعرف على معنى Uptime، وكيفية حسابه، وما الفرق الحقيقي بين 99% و99.9% و99.99%، وكيف تنشئ نظام مراقبة عملياً يساعدك على اكتشاف الأعطال وتوثيقها وتقييم جودة الاستضافة بدقة.

ما هو وقت تشغيل الاستضافة Uptime؟

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

فعندما يقال إن موقعاً حقق Uptime بنسبة 99.9%، فهذا يعني أنه كان متاحاً خلال 99.9% من الفترة التي تم قياسها، بينما تمثل النسبة المتبقية الوقت الذي اعتبر فيه غير متاح وفق شروط أداة المراقبة المستخدمة.

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

وقت التشغيل لا يعني أن الموقع سريع

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

لذلك من الأفضل متابعة مؤشرين منفصلين:

• التوافر: هل الموقع يعمل ويمكن الوصول إليه؟
• زمن الاستجابة: كم يستغرق الخادم حتى يستجيب لطلب المراقبة؟

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

كيف يتم حساب Uptime؟

يمكن التعبير عن وقت التشغيل بالمعادلة التالية:

وقت التشغيل = (إجمالي مدة القياس - مدة التوقف) ÷ إجمالي مدة القياس × 100

على سبيل المثال، إذا تمت مراقبة الموقع لمدة 30 يوماً، فإن إجمالي مدة المراقبة تساوي:

30 × 24 × 60 = 43,200 دقيقة

وإذا سجلت أداة المراقبة توقفاً إجمالياً لمدة 43 دقيقة تقريباً، فستكون نسبة التوافر قريبة من 99.9%.

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

ماذا تعني نسب Uptime بالأرقام الفعلية؟

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

نسبة Uptime	توقف تقريبي خلال 30 يوماً	توقف تقريبي خلال 365 يوماً
99%	حوالي 7 ساعات و12 دقيقة	حوالي 3 أيام و15 ساعة
99.5%	حوالي 3 ساعات و36 دقيقة	حوالي يوم و20 ساعة
99.9%	حوالي 43 دقيقة	حوالي 8 ساعات و46 دقيقة
99.95%	حوالي 22 دقيقة	حوالي 4 ساعات و23 دقيقة
99.99%	حوالي 4 دقائق و19 ثانية	حوالي 53 دقيقة

هذه الأرقام تساعد على فهم سبب أهمية الأجزاء الصغيرة من النسبة. الفرق بين 99.9% و99.99% ليس 0.09% فقط من الناحية العملية، بل قد يعني الانتقال من عدة ساعات من التوقف سنوياً إلى أقل من ساعة تقريباً.

لماذا لا يكفي الاعتماد على إحصاءات شركة الاستضافة؟

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

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

قد يكون الخادم نفسه متصلاً بينما يعاني موقعك من مشكلة مثل:

• توقف قاعدة البيانات.
• خطأ في إعداد الموقع.
• مشكلة في DNS.
• انتهاء شهادة HTTPS أو وجود خطأ فيها.
• فشل تطبيق الموقع رغم استجابة الخادم.
• وجود صفحة خطأ يعيدها الخادم برمز استجابة غير ناجح.
• حدوث مشكلة في شبكة توزيع المحتوى.

لهذا السبب تعد المراقبة الخارجية من جهة مستقلة أكثر فائدة عند تقييم وقت التشغيل الذي يراه المستخدم الحقيقي.

كيف تعمل أدوات مراقبة Uptime؟

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

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

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

ما أفضل مدة بين كل فحص Uptime وآخر؟

فترة الفحص أو Monitoring Interval تحدد عدد المرات التي يتم فيها اختبار الموقع. وكلما قصرت المدة، زادت قدرتك على اكتشاف الانقطاعات القصيرة بسرعة.

الفحص كل 5 دقائق

يصلح للمواقع غير الحساسة التي تريد مراقبة عامة لحالتها، لكنه قد يفوت بعض الانقطاعات القصيرة بالكامل.

فإذا تعطل موقعك لمدة دقيقتين بين فحصين متتاليين، فمن الممكن ألا تسجل الأداة التوقف من الأساس.

الفحص كل دقيقة

يعتبر خياراً عملياً لمعظم المواقع. فهو يوفر رؤية جيدة للانقطاعات من دون إرسال عدد مبالغ فيه من الطلبات إلى الموقع.

الفحص كل 30 ثانية تقريباً

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

هل الفحص كل ثانية أفضل؟

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

الأهم من اختيار أقصر مدة ممكنة هو استخدام فاصل زمني مناسب مع آلية جيدة لتأكيد الأعطال.

لماذا تؤثر مدة الفحص في دقة نسبة Uptime؟

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

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

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

استخدم المراقبة من أكثر من موقع جغرافي

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

عندما يتم تأكيد الفشل من عدة نقاط منفصلة، تصبح احتمالية وجود مشكلة حقيقية في موقعك أكبر.

لماذا تحدث الإنذارات الكاذبة؟

قد تظهر نتيجة فشل رغم أن الخادم نفسه لم يتوقف بسبب:

• مشكلة مؤقتة في نقطة المراقبة.
• تعطل مسار شبكة معين.
• تأخير مؤقت في DNS.
• حجب عنوان خدمة المراقبة بواسطة الجدار الناري.
• ارتفاع زمن الاتصال للحظات.
• تحديد معدل الطلبات بطريقة تمنع أداة المراقبة من الوصول.

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

HTTP Monitoring أفضل من Ping وحده لمراقبة المواقع

يمكن استخدام Ping لمعرفة ما إذا كان الخادم أو عنوان الشبكة يستجيب، لكنه لا يخبرك دائماً بأن الموقع نفسه يعمل بصورة صحيحة.

قد يستجيب الخادم للشبكة بينما تكون خدمة الويب متوقفة أو توجد مشكلة تمنع تحميل الموقع.

بالنسبة لموقع ويب، يفضل استخدام مراقبة HTTP أو HTTPS لأنها تختبر الوصول إلى الصفحة نفسها وتتحقق من الاستجابة التي يحصل عليها الزائر.

مراقبة رمز استجابة HTTP

أحد أبسط أنواع المراقبة هو إرسال طلب إلى الصفحة الرئيسية والتحقق من رمز الاستجابة.

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

لكن مراقبة الرمز وحده ليست كافية في جميع الحالات.

الموقع قد يعيد استجابة ناجحة رغم وجود مشكلة

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

وهنا تصبح مراقبة المحتوى أو الكلمة المفتاحية مفيدة.

استخدم Keyword Monitoring لزيادة الدقة

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

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

هذه الطريقة مفيدة لاكتشاف حالات مثل:

• ظهور صفحة خطأ داخل القالب.
• عدم اتصال التطبيق بقاعدة البيانات بصورة صحيحة.
• تحميل صفحة فارغة.
• ظهور صفحة مختلفة عن المحتوى المتوقع.

اختر كلمة مراقبة مستقرة

لا تستخدم عنوان مقال يتغير باستمرار أو نصاً قد يتم حذفه أثناء تحديث الموقع. اختر عنصراً ثابتاً حتى لا تحصل على تنبيهات غير صحيحة عند تعديل المحتوى.

راقب أكثر من الصفحة الرئيسية

خطأ شائع هو مراقبة عنوان الموقع الرئيسي فقط. قد تعمل الصفحة الرئيسية بينما توجد مشكلة في جزء مهم آخر.

إذا كان الموقع مهماً، يمكنك إنشاء فحوص مستقلة لعدة نقاط أساسية مثل:

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

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

راقب DNS بصورة منفصلة

قد يكون خادم الاستضافة سليماً تماماً ومع ذلك يصبح الموقع غير متاح بسبب مشكلة في نظام أسماء النطاقات DNS.

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

الفصل بين مراقبة DNS ومراقبة خادم الويب يساعدك أيضاً على تحديد مصدر المشكلة بسرعة عند حدوث انقطاع.

مراقبة شهادة HTTPS مهمة أيضاً

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

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

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

ما هو Timeout في مراقبة Uptime؟

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

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

اختر قيمة مناسبة لسلوك موقعك الطبيعي، ثم راقب تغير زمن الاستجابة مع الوقت بدلاً من النظر إلى حالة Up أو Down فقط.

لماذا يجب إعادة الفحص قبل تسجيل Downtime؟

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

لذلك يمكن ضبط المراقبة بحيث يعاد الفحص عند حدوث فشل أولي قبل إطلاق التنبيه.

النظام الأكثر توازناً يمكن أن يعمل بهذه الطريقة:

1. يفشل الفحص الأول.
2. تتم إعادة الاختبار خلال مدة قصيرة.
3. يمكن إجراء الاختبار من نقطة مراقبة إضافية.
4. إذا استمر الفشل يتم تسجيل الحادث.
5. يصل التنبيه إلى صاحب الموقع.

بهذه الطريقة تقل التنبيهات الكاذبة مع الحفاظ على القدرة على اكتشاف الأعطال الحقيقية بسرعة.

لا تجعل تأكيد العطل بطيئاً أكثر من اللازم

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

المطلوب هو تحقيق توازن بين سرعة اكتشاف المشكلة وتقليل الإنذارات الكاذبة.

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

كيف تعرف وقت بداية التوقف بدقة؟

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

على سبيل المثال، عند المراقبة كل دقيقة:

• الفحص في الساعة 10:00 نجح.
• الفحص في الساعة 10:01 فشل.

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

متى ينتهي احتساب Downtime؟

ينتهي الحادث عندما تبدأ أداة المراقبة في الحصول على استجابات ناجحة مرة أخرى وفق شروط التعافي المحددة.

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

استخدام عدة نجاحات متتالية مفيد إذا كان الخادم يدخل في حالة من التوقف والعمل المتكرر خلال فترة قصيرة.

ما هو Flapping ولماذا يربك قياس Uptime؟

يحدث Flapping عندما يتغير الموقع باستمرار بين حالة العمل والتوقف خلال فترة قصيرة.

على سبيل المثال:

• الموقع يعمل.
• بعد دقيقة يتوقف.
• ثم يعود للعمل.
• بعد فترة قصيرة يتوقف مرة أخرى.

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

وجود فترة تأكيد للتعافي يساعد على منع إغلاق الحادث بمجرد نجاح فحص واحد مؤقت.

راقب زمن الاستجابة بجانب Uptime

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

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

• زيادة الحمل على الخادم.
• ضغط على قاعدة البيانات.
• وصول الحساب إلى حدود الموارد.
• مشكلة في الشبكة.
• عملية داخل الموقع تستهلك قدرة معالجة كبيرة.

متابعة الاتجاه العام أهم من التركيز على ارتفاع منفرد في استجابة واحدة.

هل يمكن الاعتماد على أداة Uptime واحدة؟

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

الفكرة ليست إنشاء عدد كبير من الحسابات، وإنما امتلاك وسيلة للتأكد عند وجود اختلاف بين بيانات شركة الاستضافة وبيانات المراقبة الأساسية.

متى تكون الأداة الثانية مفيدة؟

• عند اختبار استضافة جديدة قبل نقل موقع مهم إليها.
• عندما تسجل أداة واحدة انقطاعات متكررة غير واضحة.
• عند وجود خلاف حول مدة التوقف المسجلة.
• عندما تريد مقارنة النتائج من شبكات ومناطق مختلفة.

هل يجب مراقبة الخادم أم الموقع؟

إذا كان هدفك معرفة تجربة الزائر، فابدأ بمراقبة الموقع نفسه من الخارج. أما إذا كنت تدير الخادم أيضاً، فمن المفيد إضافة مراقبة داخلية لموارده.

المراقبة الخارجية

تجيب عن السؤال: هل يستطيع المستخدم الوصول إلى الموقع؟

المراقبة الداخلية

يمكن أن تتابع مؤشرات مثل:

• استخدام المعالج.
• استهلاك الذاكرة.
• المساحة المتبقية على التخزين.
• حمل الخادم.
• حالة قاعدة البيانات.
• عدد العمليات.

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

هل 100% Uptime رقم واقعي؟

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

كما تعتمد النتيجة على طول فترة القياس. الوصول إلى 100% خلال أيام قليلة أسهل بكثير من المحافظة على نسبة مرتفعة خلال فترة طويلة.

لهذا السبب يجب عدم تقييم الاستضافة من رقم قصير المدى وحده.

ما المدة المناسبة لتقييم استقرار الاستضافة؟

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

يفضل الاحتفاظ بتاريخ المراقبة لعدة أشهر على الأقل ومقارنة الأداء بين الفترات.

بهذه الطريقة تستطيع معرفة ما إذا كان الانقطاع حادثاً منفرداً أم نمطاً متكرراً.

الفرق بين Uptime الشهري والسنوي

يمكن لخادم أن يحقق نتيجة ممتازة في شهر معين بينما تكون نتيجته طويلة المدى أقل بسبب مشكلة كبيرة حدثت في فترة أخرى.

ولهذا من المفيد متابعة أكثر من نافذة زمنية:

• آخر 24 ساعة لمعرفة الحالة الحالية.
• آخر عدة أيام لرؤية المشكلات الحديثة.
• آخر 30 يوماً لمتابعة الاستقرار الشهري.
• فترة طويلة لتقييم جودة الخدمة بصورة أشمل.

لا تعتمد على نافذة واحدة فقط عند اتخاذ قرار بشأن الاستمرار مع شركة الاستضافة أو الانتقال منها.

هل الصيانة المجدولة تدخل في حساب Uptime؟

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

لذلك يجب التمييز بين أمرين:

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

قد تختلف النسبتان حتى لو كانت كل منهما محسوبة بصورة صحيحة وفق تعريفها الخاص.

ما هو SLA وما علاقته بـ Uptime؟

اتفاق مستوى الخدمة أو SLA هو التزام تعاقدي قد تحدد فيه شركة الاستضافة مستوى معيناً من التوافر وشروط التعامل مع عدم تحقيقه.

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

• طريقة حساب النسبة.
• مدة القياس.
• الأحداث المستثناة.
• طريقة طلب التعويض إن وجد.
• المهلة المتاحة لتقديم الطلب.
• نوع الرصيد أو التعويض الذي يمكن الحصول عليه.

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

لماذا تختلف نتيجة Uptime بين خدمتين للمراقبة؟

وجود اختلاف بسيط بين أداتين لا يعني بالضرورة أن إحداهما خاطئة. قد يكون الاختلاف ناتجاً عن إعدادات القياس نفسها.

أسباب اختلاف النتائج تشمل:

• اختلاف مدة الفحص.
• اختلاف مواقع المراقبة.
• اختلاف قيمة Timeout.
• عدد محاولات إعادة الفحص.
• طريقة التعامل مع رموز HTTP.
• اختلاف تعريف وقت بداية ونهاية الحادث.
• وجود فحوص للمحتوى في خدمة دون الأخرى.

عند مقارنة أداتين حاول توحيد الإعدادات قدر الإمكان.

إعداد عملي لمراقبة موقع عادي

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

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

إعداد مراقبة لمتجر أو موقع مهم

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

يمكن أن تشمل المراقبة:

• الصفحة الرئيسية.
• صفحة منتج أو خدمة أساسية.
• عملية اتصال بقاعدة البيانات.
• واجهة API مهمة.
• DNS.
• شهادة HTTPS.
• زمن استجابة الخادم.
• الخدمات الخارجية الأساسية التي يعتمد عليها الموقع.

ومن المفيد أيضاً تصنيف التنبيهات حسب أهميتها حتى لا تصبح كل مشكلة صغيرة تنبيهاً عاجلاً.

ضع صفحة مراقبة بسيطة لا تستهلك موارد كثيرة

في بعض البيئات يمكن إنشاء عنوان مخصص لفحص صحة التطبيق بدلاً من الاعتماد دائماً على الصفحة الرئيسية الثقيلة.

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

هذه الطريقة مفيدة خصوصاً عندما تكون الصفحة الرئيسية تحتوي على عدد كبير من العمليات التي لا تحتاج إلى تنفيذها مع كل فحص.

لا تجعل أداة المراقبة نفسها سبباً في الإنذارات

قد تقوم بعض أنظمة الحماية بحجب عدد كبير من الطلبات المتكررة القادمة من خدمة Uptime، خصوصاً إذا اعتبرتها حركة آلية غير طبيعية.

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

لا تقم بإلغاء أنظمة الحماية بالكامل. الأفضل هو إعداد قواعد مناسبة تسمح بالفحوص الموثوقة من دون فتح الموقع أمام طلبات غير مرغوبة.

كيف تتعامل مع تنبيهات Uptime؟

قيمة المراقبة الحقيقية ليست في تسجيل المشكلة فقط، بل في تحويل التنبيه إلى إجراء واضح.

عندما يصلك تنبيه، تحقق بالترتيب من النقاط التالية:

1. افتح الموقع من اتصال مستقل.
2. تحقق مما إذا كانت المشكلة تشمل الموقع كله أم صفحة محددة.
3. راجع صفحة حالة شركة الاستضافة إن كانت متاحة.
4. تحقق من DNS إذا كان اسم النطاق لا يستجيب.
5. راجع حالة شهادة HTTPS.
6. افحص سجلات التطبيق أو الخادم إذا كانت متاحة لك.
7. تحقق من استخدام الموارد.
8. تواصل مع فريق الدعم إذا كانت المشكلة مرتبطة بالبنية المستضيفة.
9. سجل سبب المشكلة بعد انتهائها حتى تستطيع اكتشاف تكرارها مستقبلاً.

كيف تميز بين مشكلة الاستضافة ومشكلة الموقع؟

ليس كل Downtime دليلاً على أن شركة الاستضافة سيئة. الموقع نفسه قد يتسبب في التوقف.

علامات قد تشير إلى مشكلة في الموقع

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

علامات قد تشير إلى مشكلة في بيئة الاستضافة

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

توثيق كل حادث يساعدك مع الوقت على معرفة النمط بدلاً من الحكم من توقف واحد فقط.

ما هو الفرق بين Downtime وحالة الأداء المتدهور؟

التوقف يعني أن الخدمة لا تحقق شروط التوافر المحددة، أما تدهور الأداء فيعني أن الموقع ما زال يعمل لكنه أبطأ أو أقل استقراراً من المعتاد.

تدهور الأداء مهم لأنه قد يكون المرحلة التي تسبق التوقف الكامل.

ولهذا يفضل إعداد تنبيه مستقل عند تجاوز زمن الاستجابة حداً مرتفعاً لفترة معينة بدلاً من انتظار توقف الموقع تماماً.

راقب الاتجاهات وليس النسبة فقط

قد يكون Uptime الإجمالي ممتازاً بينما توجد مشكلة تتكرر كل أسبوع تقريباً لمدة قصيرة.

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

• توقيت متكرر للانقطاعات.
• أيام معينة تحدث فيها المشكلة.
• زيادة تدريجية في زمن الاستجابة.
• أخطاء متشابهة تتكرر في كل حادث.
• ارتباط التوقف بعمليات النسخ الاحتياطي أو المهام الدورية.

هذه المعلومات قد تكون أكثر قيمة من رقم Uptime النهائي نفسه.

هل يؤثر Uptime على محركات البحث؟

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

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

الأهم هو منع الأعطال المتكررة وتحسين سرعة اكتشافها واستعادتها.

أهم المقاييس التي يجب تسجيلها بجانب Uptime

للحصول على صورة حقيقية عن جودة الاستضافة، لا تجعل لوحة المراقبة تحتوي على نسبة التوافر فقط.

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

كيف تقارن بين شركتي استضافة باستخدام Uptime؟

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

استخدم:

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

بعد ذلك لا تقارن Uptime فقط، بل قارن أيضاً عدد الانقطاعات وزمن الاستجابة وطول كل حادث.

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

أخطاء شائعة عند مراقبة Uptime

مراقبة الصفحة الرئيسية فقط

قد تبقى الصفحة الرئيسية سليمة بينما تتوقف وظيفة مهمة داخل الموقع.

استخدام فاصل مراقبة طويل جداً

قد يؤدي ذلك إلى عدم تسجيل الانقطاعات القصيرة.

اعتبار كل فشل توقفاً حقيقياً

فشل اتصال واحد قد يكون مشكلة عابرة في شبكة المراقبة وليس في استضافتك.

الاعتماد على Ping فقط

استجابة الخادم للشبكة لا تعني أن الموقع نفسه يعمل بصورة سليمة.

تجاهل زمن الاستجابة

قد يظل الموقع في حالة Up رغم تراجع أدائه بصورة كبيرة.

عدم مراقبة HTTPS وDNS

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

الحكم على الاستضافة خلال فترة قصيرة

البيانات قصيرة المدى لا تمثل دائماً مستوى الاستقرار الحقيقي للخدمة.

نصائح عملية للحصول على قياس Uptime أكثر دقة

• استخدم خدمة مراقبة خارجية مستقلة عن شركة الاستضافة.
• اضبط الفحص على مدة قصيرة مناسبة لأهمية الموقع.
• استخدم HTTP أو HTTPS لمراقبة موقع الويب بدلاً من Ping فقط.
• أضف فحص كلمة ثابتة إذا كانت سلامة محتوى الصفحة مهمة.
• استخدم أكثر من نقطة جغرافية لتأكيد الأعطال عندما يكون ذلك متاحاً.
• فعّل إعادة المحاولة قبل اعتبار الفشل حادثاً مؤكداً.
• راقب DNS وشهادة HTTPS بصورة مستقلة.
• احتفظ بسجل طويل للحوادث.
• راقب زمن الاستجابة وليس Up وDown فقط.
• سجل سبب كل عطل بعد معالجته.
• قارن بياناتك مع شروط SLA الخاصة بالمزود عند الحاجة.
• استخدم أكثر من مصدر قياس للمواقع ذات الأهمية العالية.

إعداد مقترح لمراقبة Uptime بدقة

يمكنك استخدام الإعداد التالي كنقطة بداية ثم تعديله وفق طبيعة موقعك:

الإعداد	الاختيار المقترح
نوع المراقبة	HTTPS
فترة الفحص	حوالي دقيقة للمواقع المهمة
تأكيد الفشل	إعادة فحص قبل إرسال التنبيه
مواقع المراقبة	أكثر من منطقة إن أمكن
فحص المحتوى	كلمة ثابتة في الصفحات الأساسية
Timeout	قيمة مناسبة لأداء الموقع الطبيعي
HTTPS	مراقبة صلاحية الشهادة والأخطاء
DNS	مراقبة مستقلة للمواقع المهمة
التنبيهات	قناة أساسية وأخرى احتياطية للمواقع الحساسة
السجل	الاحتفاظ بتاريخ طويل للحوادث والأداء

متى يصبح Uptime سبباً لتغيير شركة الاستضافة؟

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

فكر بجدية في خيارات أخرى عندما تلاحظ:

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

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

الخلاصة

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

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

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

الأسئلة الشائعة حول وقت تشغيل الاستضافة Uptime

ما معنى Uptime في الاستضافة؟

هو النسبة التي توضح مقدار الوقت الذي كان فيه الموقع أو الخادم متاحاً ويستجيب بصورة صحيحة خلال فترة القياس.

هل Uptime بنسبة 99.9% جيد؟

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

كيف أراقب Uptime لموقعي؟

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

هل مراقبة Ping كافية لمعرفة أن الموقع يعمل؟

لا. Ping قد يؤكد أن الخادم يستجيب للشبكة، لكنه لا يضمن أن صفحة الموقع أو التطبيق يعمل بصورة صحيحة. يفضل استخدام مراقبة HTTP أو HTTPS للمواقع.

كم مرة يجب فحص الموقع؟

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

لماذا ترسل أداة Uptime تنبيهاً رغم أن الموقع يعمل؟

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

هل Uptime بنسبة 100% تعني أن الاستضافة لن تتوقف؟

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

ما الفرق بين Uptime وSLA؟

Uptime هو قياس لوقت التوافر، بينما SLA هو اتفاق يحدد التزامات مقدم الخدمة وطريقة حساب مستوى التوافر والاستثناءات والإجراءات التي تنطبق عند عدم تحقيق المستوى المتفق عليه.

هل بطء الموقع يعتبر Downtime؟

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

هل يمكن لأداتين إعطاء نسب Uptime مختلفة؟

نعم. قد تختلف النتائج بسبب اختلاف مدة الفحص ومواقع المراقبة ومهلة الانتظار وعدد محاولات إعادة الفحص وطريقة تحديد بداية ونهاية الانقطاع.

تعديل المقال