ما هو uptime والـSLA وكيف تختار استضافة موثوقة

حين تبحث عن استضافة، يلوّح كل مزوّد تقريبًا بشعار «99.9% uptime» وكأنه مرادفٌ للكمال. لكنّ هذا الرقم — رغم أهميته — يُساء فهمه أكثر من أي مقياس آخر في عالم الاستضافة. فالفارق بين نسبتين تبدوان متطابقتين تقريبًا (99.9% و99.99%) يعني عمليًا الفرق بين ساعات من التوقّف وبين دقائق معدودة. والأخطر أن «الضمان» نفسه — الـSLA — كثيرًا ما يكون أضعف بكثير ممّا يوحي ظاهره، لأنه يُقاس بطرق تستثني أكبر أسباب التوقّف الحقيقية. في هذا الدليل الموسوعي نفكّك المفهوم من جذوره: ما الـuptime ولماذا يُترجَم مباشرةً إلى مال وسمعة وترتيب في محركات البحث، ماذا تعني كل نسبة بالأرقام الدقيقة، ما الذي يضمنه الـSLA وما الذي يخفيه في بنوده، كيف تطالب بتعويضك حين يُخلَف الوعد، وكيف تقيس توفّرك بنفسك حتى لا تبقى رهينة لتقارير المضيف. الهدف أن تخرج قادرًا على تمييز الموثوق فعلًا من اللامع شكلًا.

ما هو الـuptime ولماذا يهمّ فعلًا؟

الـuptime — أو نسبة التوفّر — هو النسبة المئوية من الوقت التي يكون فيها خادمك (وموقعك معه) متاحًا ويستجيب للطلبات. نقيضه هو الـdowntime أو وقت التوقّف: كل لحظة لا يستطيع فيها الزائر الوصول إلى موقعك، سواء بسبب تعطّل الخادم، أو خطأ في الشبكة، أو انهيار قاعدة البيانات، أو أي خلل يحول بين زائرك وصفحتك.

تُحسب النسبة بمعادلة بسيطة على مدى فترة قياس محدّدة:

نسبة التوفّر (%) = (إجمالي الوقت − وقت التوقّف) ÷ إجمالي الوقت × 100

مثال: في شهر = 43,200 دقيقة. إذا توقّف الموقع 30 دقيقة:
(43,200 − 30) ÷ 43,200 × 100 = 99.93%

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

• المال المباشر: كل دقيقة توقّف لمتجر إلكتروني هي طلباتٌ ضائعة وعربات تسوّق مهجورة لا تعود. لو كان متجرك يحقّق 1000 ريال في الساعة، فإن توقّفًا لثلاث ساعات في يوم ذروة هو خسارة 3000 ريال مبيعات لن تستردّها أبدًا، فضلًا عن تكلفة الإعلانات التي دفعتها لتوجيه زوّار وجدوا الباب مغلقًا.
• السمعة والثقة: الزائر الذي يصطدم بموقع معطّل نادرًا ما يعود ويحاول لاحقًا؛ غالبًا يذهب مباشرةً إلى منافسك. والأسوأ أن الانطباع الأول عن «موقع لا يعمل» يلتصق بعلامتك التجارية. الموثوقية المتوقَّعة جزء من هويّتك، وتآكلها يصعب إصلاحه.
• السيو وترتيب البحث: عندما تزور عناكب جوجل موقعك وتجده معطّلًا تكرارًا، يبدأ في خفض وتيرة الزحف، وقد يُسقط صفحات من الفهرس إن طال التوقّف. التوقّفات المتكرّرة تضرّ ترتيبك تدريجيًا، وزمن الاستجابة البطيء المصاحب للخوادم المرهقة يضرّ تجربة المستخدم وإشارات الترتيب معًا.

لهذا فإن سؤال «كم نسبة التوفّر؟» ليس سؤالًا تقنيًا تتركه للمبرمجين، بل قرارٌ تجاري في صميم اختيار مضيفك. وكلما زادت حساسية مشروعك للتوقّف — متجر، منصّة حجوزات، خدمة SaaS — ارتفع الثمن الذي تدفعه مقابل كل عُشر نقطة مئوية ضائعة.

النسب وما تعنيه فعليًا بالتوقّف

هنا يكمن أكثر سوء فهم شائع. كثيرون يظنّون أن 99% و99.9% متقاربتان لأن الفرق «عُشر بالمئة فقط». الحقيقة أن كل «تسعة» إضافية تقلّص التوقّف المسموح به إلى نحو عُشره. هذه هي قاعدة «التسعات» (The Nines) التي يبنى عليها قطاع الاستضافة بأكمله.

الجدول التالي يترجم كل نسبة شائعة إلى وقت توقّف مسموح به فعلي عبر فترات مختلفة. هذا هو الجدول الأهمّ في الدليل كلّه — احفظه أو ضعه في المفضّلة:

تأمّل الفجوة: الانتقال من 99% إلى 99.9% يوفّر عليك أكثر من 3.5 يوم توقّف سنويًا. والانتقال من 99.9% إلى 99.99% يقلّص الـ8.76 ساعة إلى أقل من ساعة واحدة. هذه ليست تحسينات تجميلية بل قفزات في طبيعة الخدمة كلّها، وكلٌّ منها يتطلّب بنية تحتية أكثر تعقيدًا وكلفة.

ماذا تعني كل نسبة عمليًا؟

نصيحة عملية: لا تنخدع بسباق التسعات. معظم المواقع التجارية الصغيرة والمتوسطة تُخدَم تمامًا بـ99.9% من مضيف موثوق، ودفع علاوة كبيرة مقابل 99.99% قد لا يكون مبرّرًا إلا إذا كانت كل ساعة توقّف تكلّفك مبالغ ضخمة. المهمّ أن تطابق النسبة مع حساسية مشروعك للتوقّف، لا أن تطارد الرقم الأكبر لذاته.

جاهز لإطلاق موقعك على استضافة سريعة؟

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

اكتشف خطط الاستضافة

ما هو الـSLA (اتفاق مستوى الخدمة)؟

الـSLA — اختصار Service Level Agreement أو اتفاق مستوى الخدمة — هو الوثيقة التعاقدية التي يلتزم فيها المضيف بمستوى خدمة محدّد قابل للقياس، ويتعهّد بتعويضك إن لم يفِ به. الفرق الجوهري الذي يجب أن يرسخ في ذهنك:

نسبة التوفّر المعلَنة في الإعلان هي وعدٌ تسويقي؛ أما نسبة التوفّر المكتوبة في الـSLA فهي التزامٌ تعاقدي له عواقب إن خُرق. حين يقول مضيف «99.9% uptime» في صفحة هبوط فهذا طموح، وحين يكتبها في SLA فهذا ضمان قابل للمطالبة.

ولأن الـSLA عقد، فإن تفاصيله الدقيقة هي ما يحدّد قيمته الفعلية. وثيقة SLA جيّدة تتكوّن من عدّة مكوّنات أساسية يجب أن تقرأها كلّها قبل التوقيع، لا أن تكتفي بالرقم اللامع في العنوان:

النقطة الأخطر هنا هي نطاق القياس. كثير من اتفاقيات الـSLA تضمن «توفّر الشبكة» (Network Uptime) أو «توفّر مرفق البيانات»، وهو ما يعني أن أجهزة المضيف موصولة بالإنترنت وتستجيب — لكنه لا يضمن بالضرورة أن موقعك أنت يعمل. فإذا انهارت قاعدة بياناتك أو تعطّل تطبيقك بينما الشبكة سليمة، قد لا يُحتسب ذلك خرقًا للـSLA أصلًا. اقرأ هذا التعريف بدقّة، لأنه الفرق بين ضمانٍ حقيقي وضمانٍ شكلي.

مثال على بند SLA نموذجي:

"يضمن المزوّد توفّر الخدمة بنسبة 99.9% محسوبة شهريًا،
باستثناء الصيانة المجدولة المعلَن عنها مسبقًا (≤ 4 ساعات شهريًا)،
وحالات القوة القاهرة، والأعطال الناتجة عن إعدادات العميل.
عند الخرق، يحصل العميل على رصيد خدمة بنسبة 5% من فاتورة
الشهر عن كل ساعة توقّف تتجاوز الحدّ المضمون، بحدّ أقصى 50%."

لاحظ في هذا المثال كم استثناءً يقلّص قيمة «99.9%» المعلنة، وكيف يضع التعويض سقفًا (50%) لا يتجاوزه مهما طال التوقّف. هذا نمطٌ شائع جدًا، وهو ما يجعل قراءة البنود لا الاكتفاء بالعنوان أمرًا ضروريًا.

ما الذي يستثنيه الـSLA عادةً؟

هنا يكمن سرّ الفجوة بين «التوفّر المعلَن» و«التوفّر الذي تعيشه فعلًا». فالنسبة التي يضمنها العقد تُحسب بعد طرح فئات كاملة من التوقّف. بعبارة أخرى: قد يتوقّف موقعك ساعات فعلية، ويظلّ المضيف «ملتزمًا بالـSLA» لأن تلك الساعات تقع ضمن الاستثناءات. هذه أبرزها:

أخطر هذه الاستثناءات هو الصيانة المجدولة، لأنه استثناء «شرعي» يتكرّر باستمرار. تخيّل مضيفًا يجري صيانة 4 ساعات شهريًا (48 ساعة سنويًا) لا تُحتسب توقّفًا في الـSLA. حتى لو حقّق «99.9%» على الورق بعد استبعادها، فإن توفّرك الفعلي الذي تعيشه أنت وزوّارك أقل بكثير. لهذا يجب أن تسأل دائمًا: هل تقع الصيانة في ساعات الذروة أم في أوقات هادئة؟ وكم مدّتها وتكرارها؟ ومضيف محترف يجري صيانته في نوافذ منخفضة الحركة ويُعلمك مسبقًا.

لماذا يخدع «المتوسّط»؟

مشكلة أخرى أعمق: نسبة التوفّر رقمٌ متوسّط يخفي توزيع التوقّف. تأمّل سيناريوهين كلاهما «99.9%» على الورق:

• السيناريو أ: التوقّف موزّع كثوانٍ متفرّقة عبر السنة، لا يلاحظها أحد تقريبًا.
• السيناريو ب: التوقّف متركّز في انقطاع واحد لمدّة 8.76 ساعة في يوم إطلاق حملتك الكبرى.

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

التعويضات (service credits): كيف تُطالب وما حدودها

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

جدول تعويضات نموذجي (يختلف بين المزوّدين، لكنه يوضّح النمط السائد):

ثلاث حقائق يجب أن تعرفها عن هذه التعويضات قبل أن تعوّل عليها:

• سقفها منخفض: غالبًا لا يتجاوز التعويض 100% من فاتورة الشهر، أي ثمن الاستضافة لا أكثر. إن كانت فاتورتك 50 ريالًا شهريًا وخسرت آلاف الريالات مبيعات، فأقصى ما تستردّه هو 50 ريالًا. الـservice credit ليس تأمينًا على عملك.
• عبء الإثبات عليك: في معظم العقود، أنت من يجب أن يرصد التوقّف ويقدّم المطالبة خلال مهلة محدّدة (غالبًا 30 يومًا). إن لم تطالب، لا تحصل على شيء تلقائيًا. هذا وحده سبب كافٍ لتشغيل مراقبة مستقلّة (سنشرحها لاحقًا).
• استثناءات تبتلع المطالبة: ما يقع ضمن الصيانة المجدولة أو القوة القاهرة لا يُحتسب، فقد يُرفَض جزء كبير من مطالبتك استنادًا إلى البنود.

خطوات المطالبة العملية بالتعويض:

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

الخلاصة: تعامل مع الـservice credit كآلية مساءلة رمزية تُبقي المضيف على أهبّة، لا كتعويض عن خسائرك. الحماية الحقيقية من التوقّف هي اختيار مضيف موثوق ابتداءً وبنية متينة، لا الاتكال على استرداد بضعة ريالات بعد الكارثة.

كيف تقيس التوفّر بنفسك؟

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

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

نصائح لإعداد مراقبة فعّالة:

• اضبط فترة فحص قصيرة قدر الإمكان (دقيقة واحدة إن أمكن). الفحص كل 5 دقائق قد يفوّت انقطاعات قصيرة ويقلّل دقّة سجلّك مقابل مطالبات الـSLA.
• راقب صفحة حقيقية لا الجذر فقط: افحص صفحة تستدعي قاعدة البيانات (مثل صفحة منتج) لا الصفحة الرئيسية الثابتة فحسب، حتى تكتشف أعطال التطبيق لا الشبكة فقط.
• فعّل تنبيهات فورية متعدّدة القنوات كي تعرف بالتوقّف قبل زوّارك وعملائك.
• احتفظ بتقارير التوفّر التاريخية: هي دليلك عند المطالبة بتعويض، وهي أيضًا أداتك لتقييم مضيفك بعد أشهر بالأرقام لا بالانطباع.

للفحص اليدوي السريع عند الشكّ، يمكنك التحقّق من استجابة الموقع وكوده مباشرةً:

# يطبع رمز حالة HTTP وزمن الاستجابة الكلي بالثواني
curl -o /dev/null -s -w "code=%{http_code} time=%{time_total}s\n" https://example.com

# فحص اتصال أساسي بالخادم
ping -c 4 example.com

رمز 200 يعني استجابة سليمة؛ رموز 5xx تشير إلى أعطال في الخادم. لكن تذكّر: الفحص اليدوي لحظي فقط، والمراقبة الدائمة هي التي تبني سجلّك الموثوق على المدى الطويل.

جاهز لإطلاق موقعك على استضافة سريعة؟

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

اكتشف خطط الاستضافة

uptime مقابل availability مقابل reliability

تُستخدم هذه المصطلحات الثلاثة بالتبادل خطأً، لكنّ التمييز بينها يجعلك قارئًا أذكى لوعود المضيفين. فمضيف قد يحقّق uptime عاليًا لكن reliability ضعيفًا، والفرق مهمّ:

الفرق العملي مهمّ: قد يكون الخادم «مشغّلًا» (uptime مرتفع) بينما تطبيقك بطيء جدًا أو يردّ بأخطاء، فالـavailability الفعلية منخفضة. وقد يحقّق نظامٌ توفّرًا جيدًا بالمتوسّط لكنه «غير موثوق» لأنه يتعطّل بشكل متكرّر ولو لدقائق قصيرة في كل مرّة. مهندسو الموثوقية يقيسون الأخيرة بمقياسين شهيرين: MTBF (متوسّط الزمن بين الأعطال — كلما زاد كان أفضل) وMTTR (متوسّط زمن الإصلاح — كلما قلّ كان أفضل). مضيف موثوق فعلًا يطيل الزمن بين الأعطال ويقصّر زمن التعافي، لا يكتفي برقم متوسّط لامع.

حين تقرأ وعود مضيف، اسأل نفسك: هل يتحدّث عن «تشغيل الخادم» فقط (uptime)، أم عن أن موقعك سيعمل ويستجيب فعلًا لمستخدميك (availability)، أم عن صلابته تحت الضغط على المدى (reliability)؟ كلما اقترب الوعد من الـreliability، كان أصدق تعبيرًا عن تجربتك الحقيقية.

ما الذي يحقّق توفّرًا عاليًا فعلًا؟

النسبة العالية ليست شعارًا تكتبه، بل نتيجة هندسة. مبدأ التوفّر العالي كلّه يقوم على فكرة واحدة: إزالة نقاط الفشل المفردة (Single Points of Failure). أي مكوّن إن تعطّل أسقط الخدمة كلّها هو نقطة فشل مفردة، والهدف أن يكون لكل مكوّن بديلٌ جاهز يلتقط الحِمل فورًا. هذا ما يحقّقه عبر عدّة طبقات:

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

هنا يظهر سبب ارتباط التوفّر العالي بنماذج معيّنة من الاستضافة. الاستضافة المشتركة عادةً تعتمد بنية أبسط ونقاط فشل أكثر، بينما الاستضافة السحابية والمُدارة جيّدًا تُبنى أصلًا على التكرار وتوزيع الحِمل. لو كنت تقارن بين هذه النماذج وتأثيرها على الموثوقية، فدليل مشتركة vs VPS vs مُدارة يفصّل ذلك، كما يشرح دليل الاستضافة السحابية كيف تحقّق هذه البنية توفّرًا أعلى عبر الأسطول الموزّع. ببساطة: حين يَعِد مضيفٌ بـ99.99%، اسأله عن البنية التي تجعل هذا الرقم ممكنًا — فالوعد بلا بنية مجرّد حبر.

كيف تقرأ وعود المضيفين وتختار موثوقًا فعلًا؟

الآن وقد فهمت الأرقام والبنود والبنية، إليك العدسة الناقدة التي تقرأ بها أي عرض استضافة. القاعدة الذهبية: افصل الوعد التسويقي عن الالتزام التعاقدي، ثم اطلب الدليل.

قائمة تحقّق عملية لاختيار مضيف موثوق:

إشارة جودة كبرى كثيرًا ما تُهمَل: صفحة الحالة العلنية (Status Page). المضيف الذي ينشر حالة خدمته وحوادثه السابقة بشفافية يثق بموثوقيته ولا يخشى المساءلة؛ أما الذي يخفي كل شيء فاسأل لماذا. وهذا جزء من معايير أوسع لاختيار المضيف فصّلناها في دليل معايير اختيار شركة استضافة موثوقة، فالموثوقية ركن واحد من عدّة أركان يجب أن تجتمع.

أسئلة تطرحها على المضيف قبل الشراء

اطرح هذه الأسئلة المباشرة قبل الدفع — وطريقة إجابتهم نفسها مؤشّر على شفافيتهم:

أخطاء شائعة ونصائح خبير

أخطاء يقع فيها كثيرون عند تقييم الموثوقية:

• مطاردة التسعات بلا داعٍ: دفع علاوة كبيرة مقابل 99.99% لمدوّنة شخصية إهدار؛ طابق النسبة مع كلفة التوقّف الفعلية على مشروعك.
• تصديق العنوان وتجاهل البنود: «99.9%» في الإعلان قد تتبخّر في الاستثناءات. اقرأ الـSLA كاملًا أو لا تعتدّ به.
• الاكتفاء بقياس المضيف: بلا مراقبة مستقلّة، لن تعرف توقّفك الحقيقي ولن تملك دليلًا للمطالبة.
• الخلط بين توفّر الشبكة وتوفّر الموقع: ضمان «اتصال الخادم بالإنترنت» لا يعني أن موقعك يعمل.
• تجاهل توزيع التوقّف: «99.9%» قد تخفي انقطاعًا واحدًا طويلًا في أسوأ وقت. اسأل عن أطول انقطاع متواصل.
• إهمال الصيانة المجدولة: هي توقّف حقيقي لك حتى لو لم يُحتسب في العقد.

نصائح خبير تختصر سنوات تجربة:

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

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

ما الفرق بين uptime وSLA؟ الـuptime مقياسٌ يصف نسبة الوقت الذي يكون فيه موقعك متاحًا فعلًا. أما الـSLA فهو العقد الذي يَعِد بنسبة uptime محدّدة ويلتزم بتعويض إن لم يفِ بها. باختصار: الـuptime هو الواقع المقاس، والـSLA هو الوعد المكتوب بشأنه.

هل 99.9% uptime نسبة جيّدة؟ نعم، هي المعيار الصناعي الافتراضي وتكفي معظم المواقع التعريفية والمدوّنات والشركات الصغيرة، إذ تعني نحو 8.76 ساعة توقّف سنويًا فقط. لكن للمتاجر النشطة والخدمات الحرجة قد تحتاج 99.99% لتقليص التوقّف إلى أقل من ساعة سنويًا.

كم يعني uptime 99.9% من توقّف فعلي؟ نحو 8.76 ساعة سنويًا، أي ما يقارب 43.83 دقيقة شهريًا، أو نحو 10 دقائق أسبوعيًا. أما 99.99% فتعني نحو 52.6 دقيقة سنويًا فقط، و99.999% نحو 5.26 دقيقة سنويًا.

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

ما هي service credits وهل تعوّض خسائري؟ هي رصيد خدمة (نسبة من فاتورتك) تحصل عليه عند خرق الـSLA. لكنها لا تعوّض خسائرك التجارية الحقيقية؛ سقفها غالبًا 100% من فاتورة الشهر، أي ثمن الاستضافة لا أرباحك الضائعة. اعتبرها آلية مساءلة رمزية لا تأمينًا.

كيف أطالب بالتعويض عند توقّف الموقع؟ وثّق التوقّف بدليل مستقل من أداة مراقبة خارجية (طوابع زمنية)، تأكّد أنه يستوفي تعريف «التوقّف» ولا يقع ضمن استثناء، ثم قدّم مطالبة رسمية عبر تذكرة دعم خلال المهلة المحدّدة (غالبًا 30 يومًا). احتفظ بكل المراسلات والسجلّات كتابةً.

كيف أقيس uptime موقعي بنفسي؟ استخدم أداة مراقبة خارجية مستقلّة مثل UptimeRobot أو Pingdom تفحص موقعك دوريًا من خارج بنية المضيف وتنبّهك عند التوقّف وتسجّل تقارير تاريخية. للفحص اللحظي السريع يمكنك استخدام curl أو ping، لكن المراقبة الدائمة هي ما يبني دليلك الموثوق.

ما الفرق بين توفّر الشبكة وتوفّر الموقع؟ توفّر الشبكة يعني أن أجهزة المضيف موصولة بالإنترنت وتستجيب، بينما توفّر الموقع يعني أن موقعك أنت يعمل فعلًا ويحمّل صفحاته. قد تكون الشبكة سليمة بينما تطبيقك أو قاعدة بياناتك معطّلة، فلا يُحتسب ذلك خرقًا إن كان الـSLA يضمن الشبكة فقط — وهذا فرق حاسم اقرأه بدقّة.

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

هل أحتاج فعلًا إلى 99.999% (خمس تسعات)؟ نادرًا. خمس التسعات تعني نحو 5 دقائق توقّف سنويًا فقط، لكنها تتطلّب بنية موزّعة معقّدة ومكلفة، وتُبرَّر للبنوك والمنصّات الحرجة التي لا تحتمل أي توقّف. لمعظم المتاجر والمواقع، 99.9% أو 99.95% خيار متوازن بين الكلفة والموثوقية.

ما الذي يجعل استضافة موثوقة فعلًا؟ ليست النسبة المعلنة وحدها، بل البنية التي تدعمها: تكرار يزيل نقاط الفشل المفردة، توزيع حِمل، تعدّد مراكز بيانات، خطّة تعافٍ من الكوارث، ودعم سريع وقت الأزمات. أضف إليها شفافية (SLA واضح وصفحة حالة علنية) وسجلًّا حقيقيًا من مراجعات المستخدمين.

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

جاهز لإطلاق موقعك على استضافة سريعة؟

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

اكتشف خطط الاستضافة