آپتایم هاست؛ تضمین ۹۹٫۹ درصد دقیقاً یعنی چه؟
سرور روشن الزاماً به معنی فروشگاه سالم نیست. این راهنما کمک می‌کند درصد دسترس‌پذیری و تعهد جبران را با نیاز واقعی سایت مقایسه کنید.
آپتایم هاست معمولاً با یک درصد بزرگ معرفی می‌شود؛ عددی که در نگاه اول خیال شما را راحت می‌کند. اما آیا روشن بودن سرور همان در دسترس بودن فروشگاه است؟ و اگر سایت قطع شود، تضمین اعلام‌شده دقیقاً چه چیزی را جبران می‌کند؟
درصد دسترس‌پذیری بدون روش اندازه‌گیری و محدوده تعهد، اطلاعات کاملی نمی‌دهد. باید بدانید چه سرویسی، از کجا، در چه بازه‌ای و با چه استثناهایی سنجیده می‌شود. این مقاله کمک می‌کند یک عبارت تبلیغاتی را به معیار قابل بررسی تبدیل کنید.
آپتایم هاست چه چیزی را اندازه می‌گیرد؟
در ساده‌ترین بیان، نسبت زمانی است که سرویس طبق تعریف مشخص در دسترس بوده است. اما همان تعریف اهمیت دارد: پاسخ شبکه، پاسخ وب‌سرور و انجام موفق خرید سه سطح متفاوت‌اند. ممکن است صفحه اصلی باز شود ولی اتصال پایگاه داده یا پرداخت مشکل داشته باشد.
اگر پایش فقط یک فایل ساده را بررسی کند، سلامت کامل برنامه مشخص نمی‌شود. برعکس، خطای یک افزونه ممکن است به معنی قطع کل زیرساخت میزبان نباشد. برای نسبت دادن مسئولیت، باید لایه مشکل را جدا کرد.
عدد ۹۹٫۹ درصد در عمل یعنی چه؟
در یک ماه فرضی سی‌روزه، ۴۳۲۰۰ دقیقه وجود دارد. یک‌دهم درصد این زمان، ۴۳٫۲ دقیقه است. بنابراین دسترس‌پذیری ۹۹٫۹ درصد در چنین بازه‌ای، از نظر محاسبه خام با حدود ۴۳ دقیقه عدم دسترسی سازگار است.
این فقط مثال ریاضی است، نه تفسیر قرارداد یک شرکت. ممکن است معیار روی بازه دیگر، سرویس خاص یا با استثناهایی محاسبه شود. همیشه تعریف قرارداد را بخوانید؛ نباید از محاسبه نمونه، نتیجه قطعی درباره تعهد فروشنده گرفت.
| چیزی که می‌بینید | سؤال تکمیلی |
|---|---|
| درصد بالا | در چه بازه‌ای محاسبه شده؟ |
| تضمین SLA | چه مواردی داخل تعهد هستند؟ |
| جبران خسارت | وجه نقد است یا اعتبار سرویس؟ |
| نمودار سبز | از کدام نقطه و با چه فاصله‌ای بررسی شده؟ |
| سرور روشن | عملیات اصلی سایت هم موفق است؟ |
SLA با سابقه واقعی فرق دارد
SLA توافق سطح خدمت است و شرایط تعهد را مشخص می‌کند. سابقه عملکرد نشان می‌دهد در یک دوره چه اتفاقی افتاده است. داشتن تعهد خوب، اثبات نمی‌کند که هیچ اختلالی رخ نمی‌دهد؛ همان‌طور که سابقه خوب، آینده را تضمین نمی‌کند.
در نمونه قراردادهای زیرساخت، جبران میتواند به شکل اعتبار خدمت و مشروط به ثبت درخواست و ارائه مدارک باشد. جزئیات هر شرکت متفاوت است. عبارت «تضمین» را معادل پرداخت همه فروش ازدست‌رفته یا هزینه کسب‌وکار فرض نکنید.
از کجا پایش کنیم؟
اگر فقط از داخل همان سرور بررسی انجام شود، ممکن است اختلال مسیر کاربر دیده نشود. پایش بیرونی از چند نقطه میتواند دید بهتری بدهد، اما باید محل‌های مهم برای مخاطب شما را هم در نظر گرفت. نتیجه یک نقطه در جهان، تجربه تمام کاربران را نمایندگی نمی‌کند.
فاصله بررسی نیز مهم است. اختلال کوتاه میان دو آزمون ممکن است ثبت نشود. از طرف دیگر، یک خطای گذرا در شبکه پایش نباید بی‌بررسی به قطعی قطعی سایت تبدیل شود. روش تأیید و ثبت رخداد را مشخص کنید.
فروشگاه چه چیزهایی را باید کنترل کند؟
نمایش محصول، جست‌وجو، ورود و روند خرید اهمیت دارند. لازم نیست هر دقیقه پرداخت واقعی انجام شود، اما می‌توان آزمون‌های مجاز و کنترل‌شده برای بخش‌های مهم طراحی کرد. این کار باید بدون ایجاد سفارش یا پیام تکراری برای مشتری انجام شود.
همچنین هشدار باید به فرد مسئول برسد و اقدام بعدی روشن باشد. پایشی که فقط نمودار تولید می‌کند ولی کسی هشدار را نمی‌بیند، زمان واکنش را کم نمی‌کند. بین تشخیص اختلال و رسیدگی به آن فاصله نگذارید.
نکته: آپتایم هاست را با سلامت کامل کسب‌وکار یکی ندانید. برای مسیرهای حیاتی سایت، معیار جدا و قابل آزمایش داشته باشید.
هنگام اختلال چه مدرکی نگه داریم؟
- زمان شروع و پایان با منطقه زمانی مشخص.
- نشانی یا عملیات تحت تأثیر.
- متن خطا و نتیجه آزمون از مسیر دیگر.
- گزارش پایش و پاسخ پشتیبانی.
- زمان بازگشت و نتیجه آزمون نهایی.
این اطلاعات هم برای عیب‌یابی و هم برای بررسی تعهد سرویس مفید است. ثبت منظم رخدادها کمک می‌کند اختلال تکرارشونده از یک اتفاق جدا تشخیص داده شود. تصمیم مهاجرت را بهتر است بر الگوی مستند بنا کنید، نه فقط احساس نارضایتی لحظه‌ای.
یک مثال عملی برای تصمیم‌گیری
یک فروشگاه فرضی نمودار میزبانی سبز دارد، اما کاربران از خطای ثبت سفارش گزارش میدهند. در این مثال، مسئله‌ای که باید حل شود این است: پایش فعلی فقط صفحه اصلی را می‌سنجد و سلامت خرید مشخص نیست. قرار نیست از روی یک نشانه، نتیجه قطعی بگیریم. بهتر است ابتدا معلوم کنیم چه چیزی قابل مشاهده است و چه چیزی فقط حدس ماست. این تفکیک جلوی خرید عجولانه یا تغییر تنظیماتی را می‌گیرد که به مشکل ارتباطی ندارند.
اولین مدرک مفید در این سناریو، گزارش خطای مسیر سفارش و زمان‌های آن در کنار نمودار زیرساخت است. اگر این اطلاعات در دسترس نیست، قدم بعدی تهیه همان مدرک است؛ نه انتخاب گران‌ترین گزینه. گاهی یک گزارش کوتاه نشان می‌دهد مسئله در کدام بخش قرار دارد و گاهی لازم است بررسی دقیق‌تری انجام شود. در هر دو حالت، ثبت وضعیت اولیه کمک می‌کند نتیجه اقدام را با چیزی واقعی مقایسه کنید.
اقدام پیشنهادی نخست این است: آزمون کنترل‌شده مسیر خرید را به بررسی صفحه اصلی اضافه کنید. این اقدام باید با وضعیت سرویس و اختیار شما سازگار باشد. اگر دسترسی لازم را ندارید، از فرد مسئول بخواهید نتیجه را همراه با توضیح کوتاه ارائه کند. نیازی نیست صاحب کسب‌وکار همه جزئیات فنی را خودش اجرا کند؛ اما باید بداند چه کاری انجام شده و قرار است چه اثری داشته باشد.
اشتباه وسوسه‌کننده در این مثال، اعلام سالم بودن همه‌چیز فقط به دلیل روشن بودن سرور است. ممکن است چنین کاری ظاهراً سریع‌تر باشد، اما اگر علت را برطرف نکند، هزینه یا ابهام تازه‌ای به وجود می‌آورد. راه بهتر این است که برای هر تغییر، یک دلیل مشخص داشته باشید و پس از آن همان نشانه اولیه را دوباره بررسی کنید. هم‌زمان عوض کردن چند عامل، تشخیص اثر هرکدام را دشوار می‌کند.
پیش از اقدام، معیار نتیجه را مشخص کنید
برای موضوع آپتایم هاست، نتیجه مورد انتظار در این سناریو چنین است: تشخیص اختلال عملیات مهم و رسیدن هشدار معتبر به فرد مسئول. این جمله را در درخواست خود بنویسید تا معیار تحویل برای دو طرف یکسان باشد. عبارت‌هایی مثل «بررسی شد» یا «انجام شد» به‌تنهایی نشان نمی‌دهند نیاز شما برطرف شده است. باید نتیجه‌ای وجود داشته باشد که بتوان آن را مشاهده یا تأیید کرد.
مسئول مناسب پیگیری، مدیر فنی سایت و پشتیبانی میزبان برای لایه زیرساخت است. اگر افراد مختلفی درگیرند، یک نفر هماهنگی را بر عهده بگیرد و پاسخ‌ها را کنار هم قرار دهد. مسئول مالی، طراح و پشتیبانی ممکن است هرکدام بخشی از اطلاعات را داشته باشند؛ تصمیم خوب از ترکیب این اطلاعات به دست می‌آید. نبودن مسئول مشخص، حتی یک کار ساده را طولانی می‌کند.
این پرسش را مطرح کنید: «کدام بخش واقعاً از دسترس خارج شده و آیا در محدوده SLA قرار می‌گیرد؟» پاسخ خوب باید محدودیت‌ها و اقدام بعدی را روشن کند. اگر جواب فقط یک عبارت تبلیغاتی یا توصیه کلی بود، جزئیات مربوط به وضعیت خودتان را بخواهید. هدف گرفتن قول ناممکن نیست؛ باید بتوانید بفهمید چه چیزی در تعهد ارائه‌دهنده است و کدام بخش به تنظیمات یا تصمیم شما وابسته است.
چک‌لیست پیگیری و تحویل
- شرح کوتاهی از نیاز و شرایط فعلی بنویسید؛ نام سرویس، دامنه مرتبط و زمان مشاهده مسئله را در صورت نیاز ثبت کنید.
- مدرک مربوط را جمع کنید و اطلاعات محرمانه مثل رمز، کلید یا داده مشتری را از نسخه ارسالی عمومی حذف کنید.
- اقدام پیشنهادی را به یک نتیجه قابل بررسی وصل کنید و مشخص کنید چه کسی آن را انجام می‌دهد.
- اگر تغییر بر سرویس فعال اثر دارد، زمان انجام و روش حفظ وضعیت قبلی را پیشاپیش هماهنگ کنید.
- پس از اقدام، بررسی اصلی را انجام دهید: هم مسیر عمومی و هم عملیات مهم پس از رفع مشکل موفق باشند.
- نتیجه و موارد باقی‌مانده را ثبت کنید؛ پایان یک درخواست پشتیبانی لزوماً به معنی پایان همه بررسی‌های لازم نیست.
در مورد برگشت از تغییر، تغییر روش پایش باید با حفظ گزارش‌های قبلی انجام شود تا سابقه از بین نرود. پیش از اقدام درباره همین موضوع توافق کنید. داشتن راه بازگشت فقط به معنی نگه داشتن یک تصویر از پنل نیست؛ لازم است مشخص باشد چه اطلاعات یا اختیاراتی برای برگشت لازم است. اگر اقدام برگشت‌پذیر نیست، تصمیم باید با آگاهی از همین محدودیت گرفته شود.
برای تصمیم تجاری، زمان اختلال را کنار ساعت‌های پرفروش ببینید. دو رخداد با مدت برابر ممکن است اثر اقتصادی متفاوتی داشته باشند. این محاسبه داخلی کسب‌وکار را از فرمول قراردادی جبران جدا نگه دارید؛ یکی لزوماً معادل دیگری نیست.
هشدار زیاد هم میتواند مسئله‌ساز شود
اگر هر خطای لحظه‌ای پیام اضطراری بسازد، احتمال نادیده گرفتن هشدار واقعی بیشتر می‌شود. روش تأیید رخداد، شدت آن و فرد دریافت‌کننده را مشخص کنید. هشدار قطع کامل با کندی کوتاه یک صفحه نباید الزاماً واکنش یکسان بخواهد.
پس از هر اختلال مهم، یک یادداشت کوتاه بنویسید: علت چه بود، چه کسی متوجه شد و چه چیزی زمان رفع را طولانی کرد؟ هدف مقصرسازی نیست؛ باید معلوم شود کدام تغییر از تکرار یا تأخیر در تشخیص جلوگیری می‌کند. نمودار درصد به‌تنهایی این درس‌ها را ثبت نمی‌کند.
برای مطالعه بیشتر
مطالب مرتبط را در راهنمای هاست سی‌پنل و صفحه سوالات متداول دنبال کنید.
مراجع فنی این مقاله: نمونه SLA زیرساخت AWS و ابزارهای سنجش در cPanel.
سوالات متداول
آیا ۹۹٫۹ درصد یعنی سایت هیچ‌وقت قطع نمی‌شود؟
خیر. حتی محاسبه خام این درصد هم مقداری عدم دسترسی را شامل می‌شود؛ تعریف قرارداد نیز مهم است.
آیا SLA همه زیان فروش را جبران می‌کند؟
چنین فرضی نکنید. نوع و سقف جبران را از متن قرارداد بخوانید.
آیا پاسخ صفحه اصلی کافی است؟
برای سلامت کامل فروشگاه نه؛ عملیات مهم هم باید بررسی شوند.
چرا دو ابزار آپتایم متفاوت نشان میدهند؟
نقطه پایش، فاصله آزمون و تعریف خطا میتواند متفاوت باشد.
چه زمانی باید میزبان را عوض کنیم؟
وقتی الگوی مستند اختلال، پاسخگویی و نیاز شما نشان دهد گزینه فعلی مناسب نیست؛ نه صرفاً با یک عدد منفرد.
