آپتایم (Uptime) یکی از معیارهای مهم برای بررسی پایداری وبسایتها، نرمافزارهای آنلاین و سرورهاست. این شاخص نشان میدهد یک سرویس در چه مدت زمانی در دسترس کاربران قرار داشته است. در مقابل، داونتایم (Downtime) به زمانی گفته میشود که سرویس از دسترس خارج شده یا عملکرد مورد انتظار را ندارد.
در کسبوکارهای آنلاین، حتی چند دقیقه قطعی ممکن است باعث اختلال در ارائه خدمات، از دست رفتن سفارشها یا نارضایتی کاربران شود. به همین دلیل، آشنایی با مفهوم آپتایم، نحوه محاسبه زمان قطعی مجاز و مفاد توافقنامه سطح خدمات (SLA) به مدیران و تیمهای فنی کمک میکند زیرساخت مناسبتری انتخاب کنند.
در این مقاله، مفهوم آپتایم و داونتایم، روش محاسبه درصد دسترسپذیری، تفاوت سطوح مختلف آپتایم و راهکارهای کاهش قطعی سرویس را بررسی میکنیم.

آپتایم چیست؟
آپتایم مدتزمانی است که یک سرور، وبسایت یا سرویس آنلاین در حال فعالیت و در دسترس کاربران است. این شاخص معمولاً بهصورت درصد بیان میشود و نشان میدهد سرویس در یک بازه زمانی مشخص، چه میزان از زمان را بدون قطعی سپری کرده است.
برای مثال، آپتایم ۹۹٫۹ درصد به این معناست که سرویس در بازه مورد بررسی، در ۹۹٫۹ درصد از زمان در دسترس بوده است. بخش باقیمانده، در صورت محاسبه بر اساس زمان کل، سهم زمان قطعی را نشان میدهد.
آپتایم در سرویسهای مختلف اهمیت دارد؛ از جمله:
- وبسایتهای فروشگاهی و سامانههای پرداخت
- نرمافزارهای سازمانی و سامانههای مدیریت مشتریان
- سرورهای ابری و ماشینهای مجازی
- پایگاههای داده و سرویسهای API
- برنامههایی که بهصورت شبانهروزی در دسترس کاربران هستند
البته بالا بودن آپتایم بهتنهایی تضمین نمیکند که سرویس همیشه سریع، امن و بدون خطا باشد. برای ارزیابی کاملتر باید معیارهایی مانند زمان پاسخگویی، عملکرد برنامه و دسترسپذیری بخشهای مختلف سیستم نیز بررسی شوند.
داونتایم چیست و چه تفاوتی با آپتایم دارد؟
داونتایم (Downtime) به مدتزمانی گفته میشود که یک سرویس بهطور کامل یا جزئی از دسترس خارج شده است. برای مثال، اگر کاربران نتوانند وارد وبسایت شوند، درخواستهای برنامه با خطا مواجه شوند یا پایگاه داده پاسخگو نباشد، ممکن است بخشی از سرویس دچار قطعی شده باشد.
داونتایم میتواند به دلایل مختلفی رخ دهد؛ از خرابی سختافزار و اختلال شبکه گرفته تا خطای نرمافزاری، اتمام منابع سرور یا تغییرات نادرست در تنظیمات.
تفاوت اصلی این دو مفهوم در این است که آپتایم زمان در دسترس بودن سرویس را نشان میدهد و داونتایم مدتزمان قطعی آن را. برای محاسبه دقیق این دو شاخص باید بازه زمانی مشخصی، مانند یک ماه یا یک سال، در نظر گرفته شود. همچنین لازم است تعریف قطعی مشخص باشد؛ زیرا ممکن است سرور روشن باشد، اما برنامه یا پایگاه داده آن بهدرستی کار نکند.

زمان قطعی مجاز چیست؟
زمان قطعی مجاز (Allowed Downtime) حداکثر زمانی است که یک سرویس میتواند در یک بازه مشخص از دسترس خارج شود و همچنان درصد آپتایم هدف را حفظ کند.
برای مثال، اگر هدف یک سرویس دستیابی به آپتایم ۹۹٫۹ درصد در یک ماه ۳۰روزه باشد، زمان قطعی متناظر با این درصد برابر با ۴۳ دقیقه و ۱۲ ثانیه است.
هرچه درصد آپتایم هدف بالاتر باشد، زمان قطعی مجاز کمتر میشود. به همین دلیل، تفاوت میان آپتایم ۹۹ درصد و ۹۹٫۹۹ درصد در عمل میتواند برای سرویسهای حساس بسیار مهم باشد.
فرمول محاسبه زمان قطعی مجاز
برای محاسبه زمان قطعی مجاز از فرمول زیر استفاده میشود:
زمان قطعی مجاز = زمان کل × (۱۰۰ − درصد آپتایم هدف) ÷ ۱۰۰
برای مثال، اگر بخواهیم زمان قطعی مجاز یک سرویس با آپتایم هدف ۹۹٫۹ درصد را در یک ماه ۳۰روزه محاسبه کنیم:
- زمان کل ماه: ۷۲۰ ساعت
- درصد قطعی مجاز: ۰٫۱ درصد
- زمان قطعی مجاز: ۷۲۰ × ۰٫۰۰۱ = ۰٫۷۲ ساعت
۰٫۷۲ ساعت برابر با ۴۳ دقیقه و ۱۲ ثانیه است.
برای محاسبه درصد آپتایم واقعی نیز میتوان از فرمول زیر استفاده کرد:
درصد آپتایم = (زمان کل − زمان قطعی) ÷ زمان کل × ۱۰۰
برای نمونه، اگر یک سرویس در طول یک ماه ۶۰ دقیقه قطعی داشته باشد، باید مدت قطعی را از کل زمان ماه کم کرد و نتیجه را بر زمان کل تقسیم کرد تا درصد آپتایم به دست آید.
مقایسه درصدهای آپتایم و زمان قطعی مجاز
درصد آپتایم بهتنهایی ممکن است تفاوت سطح دسترسپذیری سرویسها را بهخوبی نشان ندهد. تبدیل این درصد به زمان قطعی مجاز کمک میکند اثر آن در بازههای روزانه، ماهانه و سالانه بهتر درک شود.
| آپتایم هدف | زمان قطعی مجاز در ماه ۳۰روزه | زمان قطعی مجاز در سال ۳۶۵روزه |
|---|---|---|
| ۹۹٪ | ۷ ساعت و ۱۲ دقیقه | ۳ روز و ۱۵ ساعت و ۳۶ دقیقه |
| ۹۹٫۵٪ | ۳ ساعت و ۳۶ دقیقه | ۱ روز و ۱۹ ساعت و ۴۸ دقیقه |
| ۹۹٫۹٪ | ۴۳ دقیقه و ۱۲ ثانیه | ۸ ساعت و ۴۵ دقیقه و ۳۶ ثانیه |
| ۹۹٫۹۵٪ | ۲۱ دقیقه و ۳۶ ثانیه | ۴ ساعت و ۲۲ دقیقه و ۴۸ ثانیه |
| ۹۹٫۹۹٪ | حدود ۴ دقیقه و ۱۹ ثانیه | حدود ۵۲ دقیقه و ۳۴ ثانیه |
| ۹۹٫۹۹۹٪ | حدود ۲۶ ثانیه | حدود ۵ دقیقه و ۱۵ ثانیه |
این اعداد بر اساس زمان تقویمی و با فرض محاسبه پیوسته به دست آمدهاند. در عمل، نحوه محاسبه آپتایم و زمان قطعی مجاز ممکن است با توجه به شرایط قرارداد SLA، بازه اندازهگیری و استثناهای تعریفشده متفاوت باشد.
آیا آپتایم ۹۹٫۹ درصد کافی است؟
پاسخ به نوع سرویس و میزان وابستگی کاربران به آن بستگی دارد. برای یک وبسایت کمترافیک، این سطح ممکن است قابل قبول باشد؛ اما برای سامانه پرداخت، نرمافزار سازمانی یا سرویسی که بهصورت شبانهروزی استفاده میشود، باید پیامدهای قطعی با دقت بیشتری بررسی شوند.
برای انتخاب سطح مناسب آپتایم، بهتر است به این موارد توجه کنید:
- میزان خسارت مالی ناشی از قطعی
- تعداد کاربران و ساعات اوج استفاده
- اهمیت دسترسی مداوم به اطلاعات
- هزینه فراهم کردن زیرساخت پایدارتر
- تعهدات قراردادی در برابر مشتریان
همچنین نباید فرض کرد که دستیابی به آپتایم بالاتر همیشه فقط با انتخاب سرور گرانتر امکانپذیر است. معماری نرمافزار، افزونگی، مانیتورینگ و نحوه مدیریت تغییرات نیز نقش مهمی دارند. اگر برای میزبانی وبسایت یا اجرای نرمافزار آنلاین به زیرساخت نیاز دارید، میتوانید پلنهای سرور مجازی آوابرید را بررسی کنید و منابع موردنیاز خود را با مشخصات سرویسها مقایسه کنید.
SLA چیست و چه ارتباطی با آپتایم دارد؟
SLA یا Service Level Agreement به معنای توافقنامه سطح خدمات است. این توافقنامه شرایط ارائه یک سرویس و تعهدات ارائهدهنده و مشتری را مشخص میکند.
در سرویسهای زیرساختی، SLA ممکن است شامل مواردی مانند درصد دسترسپذیری هدف، روش محاسبه آپتایم، بازه اندازهگیری، استثناهای قطعی و شرایط دریافت خسارت یا اعتبار خدماتی باشد.
برای مثال، ممکن است در SLA یک سرویس، سطح مشخصی از دسترسپذیری برای یک دوره ماهانه تعریف شود. در این حالت، باید بررسی کرد که قطعی چگونه محاسبه میشود و چه شرایطی از محاسبه خارج است. برای آشنایی با نمونهای واقعی، میتوانید توافقنامه سطح خدمات Amazon EC2 را مطالعه کنید. این سند شرایط دسترسپذیری و اعتبار خدماتی مربوط به سرویس EC2 را توضیح میدهد؛ تعهدات آن مختص همان سرویس است و نباید به سایر ارائهدهندگان تعمیم داده شود.
پیش از انتخاب یک سرویس ابری یا سرور، بهتر است موارد زیر را در SLA بررسی کنید:
- درصد آپتایم تعهدشده
- بازه زمانی محاسبه دسترسپذیری
- تعریف دقیق قطعی سرویس
- استثناها، مانند تعمیرات برنامهریزیشده
- روش ثبت و پیگیری اختلال
- شرایط جبران خسارت یا ارائه اعتبار خدماتی
درصد آپتایم اعلامشده در تبلیغات لزوماً به معنای تعهد قراردادی نیست. برای اطلاع از تعهد واقعی ارائهدهنده، باید متن SLA و شرایط رسمی سرویس بررسی شود. همچنین در خدماتی مانند کولوکیشن، مسئولیت تأسیسات دیتاسنتر با مسئولیت نگهداری سیستمعامل و نرمافزار یکسان نیست. برای آشنایی بیشتر با این مدل زیرساختی، مقاله کولوکیشن چیست و چه کاربردی دارد؟ را بخوانید.

آپتایم چگونه اندازهگیری میشود؟
برای اندازهگیری آپتایم باید دسترسپذیری سرویس در طول یک بازه زمانی مشخص پایش شود. این کار معمولاً با ابزارهای مانیتورینگ انجام میشود که در فواصل زمانی منظم وضعیت سرویس را بررسی میکنند.
روش اندازهگیری به نوع سرویس بستگی دارد. برای مثال، بررسی روشن بودن سرور بهتنهایی کافی نیست؛ زیرا ممکن است سیستمعامل فعال باشد، اما وبسایت یا پایگاه داده پاسخگو نباشد.
۱. بررسی دسترسپذیری شبکه: ابزار مانیتورینگ میتواند پاسخگویی سرور را از طریق روشهایی مانند Ping بررسی کند. بااینحال، پاسخگو بودن سرور لزوماً به معنای سالم بودن برنامه نیست.
۲. بررسی درخواست HTTP یا HTTPS: در این روش، ابزار مانیتورینگ یک درخواست به وبسایت یا API ارسال میکند و وضعیت پاسخ را میسنجد. میتوان علاوه بر کد پاسخ، زمان پاسخگویی یا محتوای مورد انتظار را نیز بررسی کرد.
۳. بررسی سلامت برنامه و پایگاه داده: برای سرویسهای حساس، لازم است وضعیت اجزای اصلی مانند API، پایگاه داده و سرویسهای وابسته نیز پایش شود.
۴. بررسی گزارشهای سیستم: لاگهای سرور، برنامه و پایگاه داده میتوانند علت خطاها و قطعیها را مشخص کنند و به تحلیل دقیقتر اختلال کمک کنند.
بهترین روش، ترکیب چند بررسی متناسب با معماری سرویس است. همچنین باید توجه داشت که نتیجه یک ابزار مانیتورینگ ممکن است با روش محاسبه آپتایم در SLA یکسان نباشد.
چه عواملی باعث کاهش آپتایم میشوند؟
قطعی سرویس معمولاً نتیجه یک عامل واحد نیست و ممکن است از مشکلات زیرساختی، نرمافزاری یا عملیاتی ناشی شود.
خرابی سختافزار یا کمبود منابع: کمبود CPU، RAM یا فضای ذخیرهسازی میتواند باعث کندی یا از دسترس خارج شدن سرویس شود. خرابی تجهیزات نیز ممکن است عملکرد سرور را مختل کند.
اختلال شبکه: مشکلات ارتباطی، قطعی مسیرهای شبکه یا تنظیمات نادرست میتوانند دسترسی کاربران به سرویس را تحت تأثیر قرار دهند.
خطاهای نرمافزاری: باگهای برنامه، ناسازگاری نسخهها و تغییرات آزمایشنشده ممکن است باعث توقف سرویس شوند.
مشکلات پایگاه داده: افزایش تعداد اتصالها، کند شدن پرسوجوها، کمبود منابع یا خطاهای پایگاه داده میتواند کل برنامه را با اختلال مواجه کند.
خطای انسانی: حذف یا تغییر اشتباه تنظیمات، انتشار نسخه ناسالم یا اعمال تغییرات بدون بررسی کافی از دلایل احتمالی قطعی هستند.
حملات و ترافیک غیرعادی: افزایش ناگهانی درخواستها یا حملات منع سرویس توزیعشده (DDoS) ممکن است منابع سیستم را تحت فشار قرار دهد.
شناخت این عوامل به تیم فنی کمک میکند نقاط ضعف سرویس را شناسایی کند و برای پیشگیری از اختلال برنامهریزی داشته باشد.

چگونه آپتایم سرور و سرویس را افزایش دهیم؟
برای افزایش آپتایم، تنها انتخاب یک سرور قدرتمند کافی نیست. پایداری سرویس به ترکیبی از طراحی مناسب، نگهداری منظم و واکنش سریع به مشکلات وابسته است.
۱. مانیتورینگ مداوم راهاندازی کنید. وضعیت سرور، مصرف CPU و RAM، فضای دیسک، شبکه، برنامه و پایگاه داده را بررسی کنید. تعریف هشدار برای شرایط غیرعادی باعث میشود تیم فنی در مراحل اولیه اختلال مطلع شود.
۲. منابع را متناسب با نیاز انتخاب کنید. اگر منابع سرور با بار کاری برنامه تناسب نداشته باشند، افزایش ترافیک ممکن است باعث کندی یا قطعی شود. بررسی روند مصرف منابع به تصمیمگیری درباره ارتقای ظرفیت کمک میکند.
۳. برای سرویسهای حساس افزونگی در نظر بگیرید. استفاده از اجزای جایگزین و معماری مناسب میتواند اثر خرابی یک جزء را کاهش دهد. البته افزونگی بهتنهایی کافی نیست و باید سازوکار جابهجایی به جزء جایگزین نیز آزمایش شود.
۴. انتشار نسخههای جدید را کنترل کنید. تغییرات نرمافزاری را پیش از انتشار در محیط آزمایشی بررسی کنید و برای بازگشت به نسخه قبلی برنامه داشته باشید. این کار احتمال قطعی ناشی از بهروزرسانی ناموفق را کاهش میدهد.
۵. از اطلاعات نسخه پشتیبان تهیه کنید. تهیه منظم بکاپ برای بازیابی اطلاعات ضروری است، اما وجود نسخه پشتیبان بهتنهایی مانع قطعی سرویس نمیشود. برای آشنایی با یکی از روشهای رایج محافظت از دادهها، راهنمای قانون ۳-۲-۱ پشتیبانگیری را مطالعه کنید. فرایند بازیابی نیز باید آزمایش شود تا در زمان بحران بتوان اطلاعات و سرویس را در مدت قابل قبول برگرداند.
۶. برای بازیابی سرویس برنامه داشته باشید. مشخص بودن مسئولیتها، مراحل عیبیابی و روش بازگرداندن سرویس، زمان واکنش به اختلال را کاهش میدهد. برای سرویسهای مهم، اهداف بازیابی مانند RTO و RPO نیز باید متناسب با نیاز کسبوکار تعریف شوند.
در نهایت، افزایش آپتایم به شناسایی زودهنگام مشکلات، کاهش احتمال خرابی و کوتاه کردن زمان بازیابی وابسته است.
پرسشهای متداول درباره آپتایم
آپتایم ۹۹٫۹ درصد یعنی چه؟
آپتایم ۹۹٫۹ درصد یعنی سرویس در بازه محاسبهشده، ۹۹٫۹ درصد از زمان در دسترس بوده است. اگر بازه یک ماه ۳۰روزه باشد، زمان قطعی متناظر با این درصد حدود ۴۳ دقیقه و ۱۲ ثانیه خواهد بود.
تفاوت آپتایم و داونتایم چیست؟
آپتایم مدتزمان در دسترس بودن سرویس است؛ داونتایم نیز زمانی را نشان میدهد که سرویس قطع شده یا در دسترس نبوده است. این دو معیار در کنار هم برای ارزیابی دسترسپذیری استفاده میشوند.
زمان قطعی مجاز چگونه محاسبه میشود؟
برای محاسبه زمان قطعی مجاز، زمان کل بازه را در سهم قطعی مجاز ضرب میکنیم. برای نمونه، در آپتایم هدف ۹۹٫۹ درصد، سهم قطعی مجاز ۰٫۱ درصد از زمان کل است.
آیا آپتایم بالا به معنای عملکرد سریعتر است؟
خیر. آپتایم و سرعت دو معیار متفاوتاند. یک سرویس ممکن است در دسترس باشد، اما پاسخگویی کندی داشته باشد. برای ارزیابی عملکرد باید زمان پاسخ، نرخ خطا و سایر شاخصهای فنی نیز بررسی شوند.
آیا آپتایم سرور با آپتایم وبسایت یکسان است؟
لزوماً خیر. ممکن است سرور روشن و در دسترس باشد، اما به دلیل خطای برنامه، مشکل پایگاه داده یا اختلال در یکی از سرویسهای وابسته، وبسایت درست کار نکند. به همین دلیل، بهتر است دسترسپذیری اجزای مهم سیستم جداگانه پایش شود.
SLA چه تفاوتی با آپتایم دارد؟
آپتایم شاخصی برای بیان میزان دسترسپذیری سرویس است؛ SLA توافقنامهای است که تعهدات ارائهدهنده خدمات و شرایط اندازهگیری و ارزیابی آنها را مشخص میکند. درصد آپتایم ممکن است یکی از بندهای SLA باشد.
جمعبندی
آپتایم یکی از معیارهای اصلی سنجش دسترسپذیری سرور، وبسایت و سرویسهای آنلاین است. درک ارتباط میان آپتایم، داونتایم و زمان قطعی مجاز کمک میکند سطح پایداری موردنیاز یک سرویس بهتر تعیین شود.
بااینحال، انتخاب زیرساخت نباید فقط بر اساس یک درصد انجام شود. بررسی SLA، مانیتورینگ مداوم، انتخاب منابع متناسب، مدیریت تغییرات و داشتن برنامه بازیابی از اقداماتی هستند که میتوانند احتمال اختلال و مدتزمان قطعی را کاهش دهند.
برای کسبوکارهایی که به دسترسی پایدار به نرمافزارها و اطلاعات خود نیاز دارند، ارزیابی همزمان زیرساخت، معماری برنامه و فرایندهای نگهداری، پایه تصمیمگیری دقیقتر درباره پایداری سرویس است.

