آپتایم سرور معمولاً مدت کارکرد پیوستهٔ سرور را نشان می‌دهد، اما در تبلیغات میزبانی گاهی به درصد دسترس‌پذیری سرویس گفته می‌شود. این دو یکسان نیستند: ممکن است سیستم‌عامل روشن باشد ولی سایت به دلیل خطای دیتابیس یا برنامه کار نکند.
آپتایم سرور را از تجربهٔ کاربر جدا کنیم
برای ارزیابی سایت باید تعریف کنید چه چیزی «در دسترس» محسوب می‌شود. پاسخ شبکه، بازشدن صفحهٔ اصلی، ورود کاربر و تکمیل سفارش معیارهای متفاوتی‌اند. یک پاسخ HTTP موفق هم اگر صفحهٔ خطا درون آن نمایش داده شود، لزوماً موفقیت واقعی کاربر نیست.
بازهٔ اندازه‌گیری را مشخص کنید: روز، ماه، سال یا پنجرهٔ متحرک. عدد بدون دوره و تعریف خرابی، برای مقایسهٔ سرویس‌ها کافی نیست.
فرمول درصد دسترس‌پذیری زمانی
اگر کل بازه و زمان قطعی با واحد یکسان اندازه‌گیری شوند، می‌توان از این فرمول استفاده کرد:
درصد دسترس‌پذیری = ۱۰۰ × (کل زمان − زمان قطعی) ÷ کل زمان
برای مثال، در ماه ۳۰روزه ۴۳۲۰۰ دقیقه وجود دارد. اگر سایت در این بازه ۶۰ دقیقه در دسترس نباشد، دسترس‌پذیری حدود ۹۹٫۸۶ درصد است. در محاسبهٔ واقعی، مرز بازه و روش گردکردن اعداد را ثابت نگه دارید.
درصدهای رایج چه مقدار قطعی دارند؟
جدول زیر برای ماه دقیقاً ۳۰روزه است و فرض می‌کند همهٔ قطعی‌ها در محاسبه لحاظ می‌شوند. ماه تقویمی متفاوت یا استثناهای SLA نتیجه را تغییر می‌دهد.
| دسترس‌پذیری | زمان قطعی متناظر در ۳۰ روز |
|---|---|
| ۹۹٪ | ۴۳۲ دقیقه، برابر ۷ ساعت و ۱۲ دقیقه |
| ۹۹٫۹٪ | ۴۳٫۲ دقیقه |
| ۹۹٫۹۵٪ | ۲۱٫۶ دقیقه |
| ۹۹٫۹۹٪ | ۴٫۳۲ دقیقه |
جدول دسترس‌پذیری Google SRE نیز رابطهٔ درصد و زمان عدم دسترسی را نشان می‌دهد. اختلاف یک رقم اعشار می‌تواند زمان مجاز خرابی را بسیار تغییر دهد.
پایش درست سایت چه ویژگی‌هایی دارد؟
- از بیرون همان سرور و ترجیحاً چند محل متناسب با کاربران انجام شود.
- DNS، گواهی HTTPS، پاسخ HTTP و محتوای مورد انتظار بررسی شود.
- فاصلهٔ آزمون، timeout و شرط اعلام خرابی مشخص باشد.
- هشدار به فرد مسئول برسد و مسیر پیگیری معلوم باشد.
آزمون هر پنج دقیقه ممکن است قطعی کوتاه میان دو آزمون را نبیند. همچنین خرابی یک مسیر اینترنتی را نباید بدون بررسی به خاموش‌شدن کل سرور نسبت داد. پایش بخش‌های حساس برنامه را با دادهٔ آزمایشی و بدون ایجاد سفارش واقعی طراحی کنید.
دسترس‌پذیری بر پایهٔ درخواست
برای سرویس توزیع‌شده، درصد درخواست‌های موفق می‌تواند از زمان روشن یا خاموش بودن دقیق‌تر باشد. راهنمای Google SRE این تفاوت را برای خرابی جزئی توضیح می‌دهد. باید مشخص کنید کدام درخواست‌ها معتبرند و چه پاسخی موفق محسوب می‌شود.
سرعت نیز شاخص جداگانه‌ای است. سرویسی ممکن است پاسخ بدهد ولی آن‌قدر کند باشد که کاربر نتواند کارش را انجام دهد؛ زمان پاسخ و خطا را کنار دسترس‌پذیری ببینید.
SLA با نتیجهٔ واقعی چه تفاوتی دارد؟
SLA تعهد قراردادی با تعریف، استثناها و شرایط جبران است. پایش شما نتیجهٔ مشاهده‌شده را گزارش می‌کند. پیش از مقایسه، مشخص کنید قطعی برنامه‌ریزی‌شده، خرابی برنامهٔ مشتری یا اختلال شبکه چگونه حساب می‌شود و درخواست جبران چه مهلتی دارد.
برای بهبود، علت رخدادها را ثبت کنید: کمبود منابع، تغییر ناموفق، وابستگی بیرونی یا خطای امنیتی. اصلاح بر اساس علت، همراه با امکان بازگشت و بازیابی، از تکیه بر ادعای کلی «آپتایم صددرصد» مفیدتر است.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
