جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
به اشتراک بگذارید
سرور و دیتاسنتر | بلاگ وبداده
SLA چیست و چطور قرارداد سطح خدمات سرور را پیش از خرید بخوانیم؟
از درصد آپتایم تا زمان تعویض قطعه و اعتبار جبرانی؛ در این راهنما یاد میگیرید هر بند قرارداد سطح خدمات دقیقاً چه تعهدی میدهد و چه چیزی را پوشش نمیدهد.
💡 خلاصه مقاله در ۳ خط
✅ SLA یا قرارداد سطح خدمات، کیفیت سرویس را با عدد قابل اندازهگیری و پیامد مشخص تعریف میکند.
✅ درصد آپتایم بهتنهایی کافی نیست؛ تعریف قطعی، زمان تعمیر، استثناها و سقف جبران خسارت هم تعیینکنندهاند.
✅ پیش از خرید، SLA سرور را با چکلیست همین مقاله بخوانید و هر بند مبهم را مکتوب کنید.
✅ درصد آپتایم بهتنهایی کافی نیست؛ تعریف قطعی، زمان تعمیر، استثناها و سقف جبران خسارت هم تعیینکنندهاند.
✅ پیش از خرید، SLA سرور را با چکلیست همین مقاله بخوانید و هر بند مبهم را مکتوب کنید.
SLA چیست؟ SLA مخفف Service Level Agreement و به فارسی «قرارداد سطح خدمات» است. طبق تعریف IETF در RFC 3198، SLA نتیجه مکتوب مذاکره میان مشتری و ارائهدهنده سرویس است که سطح دسترسپذیری، کارایی، نحوه ارائه خدمات و دیگر ویژگیهای سرویس را مشخص میکند. به زبان ساده، SLA میگوید سرویس شما «چقدر» باید در دسترس باشد، مشکل «چه زمانی» رسیدگی میشود و اگر تعهد اجرا نشد «چه اتفاقی» میافتد.
✅ انتظار را عددی میکند: بهجای وعده کلی «پایداری بالا»، درصد آپتایم و زمان رسیدگی را مشخص میکند.
✅ مسئولیتها را تفکیک میکند: در SLA سرور روشن میشود چه کاری با ارائهدهنده است و چه کاری، مثل بکاپ داده، با شما.
✅ مبنای جبران خسارت است: بدون متن مکتوب، درخواست اعتبار جبرانی پشتوانهای ندارد.
✅ مسئولیتها را تفکیک میکند: در SLA سرور روشن میشود چه کاری با ارائهدهنده است و چه کاری، مثل بکاپ داده، با شما.
✅ مبنای جبران خسارت است: بدون متن مکتوب، درخواست اعتبار جبرانی پشتوانهای ندارد.
💡 SLA = تعهد مکتوب و قابل اندازهگیری درباره کیفیت سرویس
✅ SLA خوب هم عدد دارد، هم روش اندازهگیری و هم پیامد روشن برای نقض تعهد.
✅ سرور اختصاصی روی سختافزار HPE با مشاوره فنی شبانهروزی، تنها در وبداده.
✅ سرور اختصاصی روی سختافزار HPE با مشاوره فنی شبانهروزی، تنها در وبداده.
حتماً زمانی که این مقاله را باز کردهاید، به دنبال راهی هستید که پیش از خرید سرور، تعهدهای ارائهدهنده را درست بسنجید. در این راهنمای گامبهگام، محاسبه قطعی مجاز، زمان تعویض قطعه، جبران خسارت و یک چکلیست کامل را با مثالهای واقعی بررسی میکنیم؛ پس همراه ما باشید 😉👇
🔶 سرور اختصاصی ایران روی سختافزار HPE
اگر سروری روی سختافزار سازمانی HPE ProLiant با رم ECC و هارد NVMe میخواهید، سرور اختصاصی ایران وبداده را ببینید و سوالهای پشتیبانی را پیش از خرید از کارشناسان ما بپرسید 👇
📌 آنچه در این مقاله میخوانید
◀️ SLA چیست و قرارداد سطح خدمات سرور چه بندهایی دارد؟
◀️ جدول تفاوت SLA، SLO و SLI
◀️ آپتایم 99.9، 99.99 و 99.999 در SLA سرور یعنی چند دقیقه قطعی؟
◀️ جدول تبدیل درصد آپتایم SLA سرور به زمان قطعی
◀️ بررسی بندهای حیاتی: پاسخگویی، خرابی سختافزار سرور و جبران خسارت
◀️ مقایسه جبران خسارت در SLA سرورهای ابری AWS و Google
◀️ چکلیست بررسی SLA قبل از خرید سرور اختصاصی
◀️ SLA سرور اختصاصی در وبداده؛ پیش از خرید شفاف بپرسید
◀️ سوالات متداول درباره SLA سرور
◀️ جمعبندی؛ SLA را کامل بخوانید، نه فقط درصد آپتایم را
◀️ جدول تفاوت SLA، SLO و SLI
◀️ آپتایم 99.9، 99.99 و 99.999 در SLA سرور یعنی چند دقیقه قطعی؟
◀️ جدول تبدیل درصد آپتایم SLA سرور به زمان قطعی
◀️ بررسی بندهای حیاتی: پاسخگویی، خرابی سختافزار سرور و جبران خسارت
◀️ مقایسه جبران خسارت در SLA سرورهای ابری AWS و Google
◀️ چکلیست بررسی SLA قبل از خرید سرور اختصاصی
◀️ SLA سرور اختصاصی در وبداده؛ پیش از خرید شفاف بپرسید
◀️ سوالات متداول درباره SLA سرور
◀️ جمعبندی؛ SLA را کامل بخوانید، نه فقط درصد آپتایم را
SLA چیست و قرارداد سطح خدمات سرور چه بندهایی دارد؟
SLA بخشی از قرارداد خدمات است که کیفیت سرویس را به عدد تبدیل میکند و معمولاً کنار شرایط استفاده (Terms of Service) قرار میگیرد. موضوع آن فقط سطح کیفیت است: دسترسپذیری، سرعت پاسخگویی، زمان رفع خرابی و پیامد نقض تعهد. SLA میتواند داخلی باشد، مثلاً میان واحد IT و فروش، یا بیرونی، مثل SLA سرور که شرکت میزبانی به مشتری میدهد.
یک تشبیه کاربردی: SLA مثل بیمهنامه بدنه خودرو است. بیمهنامه نمیگوید خودروی شما هرگز تصادف نمیکند؛ میگوید اگر حادثهای رخ داد، در چه شرایطی و تا چه سقفی خسارت پرداخت میشود و چه حوادثی اصلاً پوشش ندارند. SLA سرور هم تضمین نمیکند سرور هیچوقت قطع نشود؛ بلکه مرز تعهد ارائهدهنده، روش سنجش و میزان جبران را مشخص میکند.
SLA مخفف چیست و SLO و SLI چه نقشی دارند؟
SLA مخفف Service Level Agreement است و دو اصطلاح همخانواده دارد. طبق کتاب مهندسی قابلیت اطمینان سایت (SRE) گوگل، SLI شاخصی کمّی برای سنجش کیفیت سرویس است؛ SLO مقدار هدف همان شاخص است (مثلاً آپتایم ماهانه 99.9 درصد) و SLA قراردادی است که این هدفها را همراه با پیامد برآورده نشدن آنها در بر میگیرد.
SLI (measure) ➡️ measured uptime = 99.95%
⬇️
SLO (target) ➡️ uptime >= 99.9% per month
⬇️
SLA (contract) ➡️ target missed? => service credit🔸 نکته فنی
کتاب SRE گوگل یک آزمون ساده پیشنهاد میکند: بپرسید «اگر هدف برآورده نشود، چه میشود؟». اگر پاسخ، پیامد صریحی مثل اعتبار جبرانی نباشد، با یک SLO یا وعده تبلیغاتی روبهرو هستید، نه یک SLA واقعی.
بندهای اصلی یک SLA سرور
یک قرارداد سطح خدمات کامل معمولاً بندهای زیر را دارد و نبودن هر کدام، نشانهای است که باید درباره آن سوال کنید:
- دامنه سرویس: شبکه، برق، سختافزار یا سیستمعامل.
- تعهد دسترسپذیری: درصد آپتایم و بازه سنجش آن.
- تعریف قطعی: چه وضعیتی «قطع» حساب میشود.
- زمان پاسخ و رفع مشکل: برای هر سطح اهمیت حادثه (Severity).
- تعویض قطعه: رسیدگی به خرابی سختافزار سرور.
- نگهداری برنامهریزیشده: زمان و نحوه اطلاعرسانی.
- استثناها: رویدادهایی که در آپتایم حساب نمیشوند.
- جبران خسارت: درصد اعتبار، سقف، مهلت و مدارک درخواست.
SLA اینترنت چیست و چه فرقی با SLA سرور دارد؟
در اینترنت سازمانی، مثل لینک اختصاصی، SLA فقط به «وصل بودن» محدود نمیشود. توصیهنامه ITU-T Y.1540 از اتحادیه بینالمللی مخابرات، پارامترهایی مثل تأخیر انتقال بسته، نرخ از دست رفتن بسته و دسترسپذیری سرویس IP را تعریف میکند. در مقابل، SLA سرور بیشتر بر دسترسپذیری ماشین، شبکه دیتاسنتر و زمان تعمیر سختافزار تمرکز دارد.
🚀 بیشتر بدانید: پیش از مقایسه SLAها، تفاوت پهنای باند اختصاصی و اشتراکی سرور را هم بررسی کنید.
جدول تفاوت SLA، SLO و SLI
جدول زیر تفاوت این سه مفهوم را بر اساس تعریفهای کتاب SRE گوگل، با مثالی از دنیای سرور، خلاصه میکند:
| ویژگی | SLI | SLO | SLA |
|---|---|---|---|
| ماهیت | شاخص اندازهگیری | هدف عددی | توافق همراه با پیامد |
| پرسش اصلی | الان وضعیت چطور است؟ | وضعیت خوب یعنی چه؟ | اگر هدف محقق نشد چه میشود؟ |
| نمونه در سرور | درصد دقیقههای در دسترس | آپتایم ماهانه 99.9 درصد | اعتبار جبرانی در صورت نقض |
| مخاطب اصلی | تیم فنی | تیم فنی و مدیر سرویس | مشتری، ارائهدهنده و واحد حقوقی |
آپتایم 99.9، 99.99 و 99.999 در SLA سرور یعنی چند دقیقه قطعی؟
درصد آپتایم معروفترین عدد هر SLA است، اما تا آن را به دقیقه تبدیل نکنید، حس درستی از آن به دست نمیآید. فرمول محاسبه در کادر زیر آمده است؛ اگر با مفهوم آپتایم آشنا نیستید، ابتدا مقاله آپتایم چیست را بخوانید.
Uptime % = (Total min - Downtime min) / Total min x 100
30-day month = 43,200 min
99.9% ➡️ 43,200 x 0.001 = 43.2 min downtime
99.99% ➡️ 43,200 x 0.0001 = 4.32 min downtimeهر «۹» اضافه، زمان قطعی مجاز را به یکدهم میرساند؛ یعنی تفاوت 99.9 و 99.99 درصد در عمل، تفاوت میان حدود 43 دقیقه و حدود 4 دقیقه قطعی در ماه است. رسیدن به هر ۹ بیشتر معمولاً به افزونگی در برق، شبکه و سختافزار نیاز دارد و هزینه را بالا میبرد؛ همین سطح افزونگی در زیرساخت، مبنای طبقهبندی Tier دیتاسنتر است.
۱- بازه سنجش: ماهانه یا سالانه؟
SLAهای عمومی Amazon EC2 و Google Compute Engine آپتایم را ماهانه میسنجند. این انتخاب مهم است: تعهد 99.9 درصد سالانه اجازه میدهد حدود 8.76 ساعت قطعی حتی در یک روز رخ دهد، اما همین عدد در بازه ماهانه، سقف قطعی هر ماه را حدود 43 دقیقه نگه میدارد. پس در SLA سرور همیشه بازه سنجش را بپرسید.
۲- تعریف قطعی و حداقل مدت قابل شمارش
عدد آپتایم بدون تعریف «قطعی» معنایی ندارد. SLA گوگل برای Compute Engine قطعی را از دست رفتن اتصال خارجی یا دسترسی به دیسک دائمی میداند و فقط دورههای دستکم یکدقیقهای را حساب میکند. AWS هم در سطح تکماشین، «در دسترس نبودن» را نداشتن اتصال خارجی تعریف کرده است. این سوالها را هم بپرسید:
◀️ آیا کندی شدید یا از دست رفتن بستهها هم قطعی حساب میشود؟
◀️ گزارش مانیتورینگ شما هم پذیرفته میشود یا فقط ابزار ارائهدهنده ملاک است؟
◀️ گزارش مانیتورینگ شما هم پذیرفته میشود یا فقط ابزار ارائهدهنده ملاک است؟
⚠️ دام رایج در مقایسه درصدها
دو SLA با عدد یکسان 99.9 درصد ممکن است تعهد کاملاً متفاوتی باشند؛ یکی ماهانه و با شمارش هر دقیقه قطعی، دیگری سالانه و با نادیده گرفتن قطعیهای کوتاه. برای شناخت انواع قطعی، مقاله Downtime چیست را ببینید.
جدول تبدیل درصد آپتایم SLA سرور به زمان قطعی
اعداد جدول برای ماه ۳۰ روزه و سال ۳۶۵ روزه محاسبه شدهاند و ستون آخر جایگاه هر سطح را در SLAهای عمومی نشان میدهد:
| درصد آپتایم | سقف قطعی در ماه | سقف قطعی در سال | نمونه در SLAهای عمومی |
|---|---|---|---|
| 99% | 7 ساعت و 12 دقیقه | حدود 3.65 روز | مرز پله دوم جبران در AWS و Google |
| 99.5% | 3 ساعت و 36 دقیقه | حدود 43.8 ساعت | تعهد تکماشین Amazon EC2 |
| 99.9% | 43 دقیقه و 12 ثانیه | حدود 8.76 ساعت | تعهد تکماشین Google Compute Engine |
| 99.95% | 21 دقیقه و 36 ثانیه | حدود 4.38 ساعت | تکماشین Memory Optimized در Google |
| 99.99% | حدود 4 دقیقه و 19 ثانیه | حدود 52.6 دقیقه | استقرار چندناحیهای در AWS و Google |
| 99.999% | حدود 26 ثانیه | حدود 5.3 دقیقه | نیازمند افزونگی کامل در چند لایه |
بررسی بندهای حیاتی: پاسخگویی، خرابی سختافزار سرور و جبران خسارت
در این بخش همراه تیم وبداده باشید تا بندهایی را بررسی کنیم که در روز بحران بیشترین اثر را دارند. بسیاری از خریداران در SLA سرور فقط درصد آپتایم را میخوانند، اما هنگام خرابی واقعی، زمان پاسخ و تعمیر تعیین میکند چه مدت آفلاین میمانید و سازوکار جبران خسارت مشخص میکند چه چیزی به دست میآورید.
۱- زمان پاسخگویی در برابر زمان رفع مشکل
زمان پاسخگویی (Response Time) یعنی چقدر طول میکشد تا متخصص کار روی مشکل را شروع کند؛ زمان رفع مشکل (Resolution Time) یعنی سرویس چه زمانی به حالت عادی برمیگردد. پاسخ سریع به تیکت ارزشمند است، اما بدون قطعه یدکی، سرور همچنان خاموش میماند.
دیتاشیت سرویس HPE Foundation Care این دو را دقیق تفکیک میکند: هر دو زمان از ثبت و تأیید درخواست شروع میشوند، اما «زمان پاسخ در محل» با رسیدن نماینده HPE به محل تمام میشود و «زمان تماس تا تعمیر» (Call-to-Repair) وقتی به پایان میرسد که HPE تعمیر سختافزار را تأیید کند. سطح 6-hour call-to-repair هم فقط برای حوادث بحرانی (Severity 1) بازگشت سختافزار به وضعیت عملیاتی ظرف 6 ساعت را تعهد میدهد.
◀️ پنجره پوشش: در این دیتاشیت، سطح Next Business Day فقط ساعت 8 تا 17 روزهای کاری را پوشش میدهد و سطح 24×7 شبانهروزی است.
◀️ فاصله: زمانهای پاسخ در محل فقط برای سایتهای تا 160 کیلومتری مرکز پشتیبانی HPE اعمال میشود و برای سایتهای دورتر افزایش مییابد.
◀️ فاصله: زمانهای پاسخ در محل فقط برای سایتهای تا 160 کیلومتری مرکز پشتیبانی HPE اعمال میشود و برای سایتهای دورتر افزایش مییابد.
۲- اگر سختافزار سرور اختصاصی خراب شود چه میشود؟
خرابی سختافزار سرور دیر یا زود رخ میدهد؛ دیسک، رم، منبع تغذیه یا فن ممکن است از کار بیفتند. در سرور اختصاصی اجارهای، نگهداری سختافزار معمولاً با ارائهدهنده است، پس SLA باید روشن کند چه کسی خرابی را تشخیص میدهد، قطعه یدکی از کجا میآید و تعویض در چه بازهای انجام میشود. مسیر معمول رسیدگی:
- تشخیص: هشدار مانیتورینگ یا ابزار مدیریت از راه دور، مثل iLO در سرورهای HPE، قطعه معیوب را مشخص میکند.
- ثبت تیکت: زمان پاسخگویی معمولاً از همین لحظه شمرده میشود؛ زمان ثبت را نگه دارید.
- تعویض و بازسازی: دیسکهای Hot-swap بدون خاموشی تعویض میشوند، اما بازسازی آرایه RAID ممکن است زمانبر باشد.
- بازیابی داده: اگر دادهای از بین رفته باشد، بازگرداندن آن معمولاً مسئولیت خود شماست.
📌 یادآوری مهم درباره دادهها
در دیتاشیت HPE Foundation Care، پشتیبانگیری و بازیابی سیستمعامل، نرمافزارها و داده صراحتاً در فهرست خدمات مستثنا آمده است؛ پس حتی قویترین SLA سرور هم داده شما را برنمیگرداند. RAID جلوی توقف ناشی از خرابی یک دیسک را میگیرد، اما جایگزین بکاپ مستقل سرور نیست.
۳- جریمه و جبران خسارت در SLA
جبران خسارت در بیشتر SLAهای میزبانی به شکل «اعتبار جبرانی» (Service Credit) است، نه پرداخت نقدی. در SLA سرویسهای محاسباتی AWS، اگر آپتایم ماهانه یک ماشین EC2 کمتر از 99.5 درصد شود، معادل 10 درصد هزینه ماهانه همان ماشین اعتبار داده میشود؛ این رقم زیر 99 درصد به 30 درصد و زیر 95 درصد به 100 درصد میرسد و حق بازپرداخت نقدی ایجاد نمیکند.
این جبران خودکار هم نیست. در AWS باید درخواست را تا پایان دومین چرخه صورتحساب پس از حادثه ثبت کنید. گوگل برای Compute Engine مهلت 60 روزه تعیین کرده، ارائه لاگ قطعی را لازم میداند و سقف اعتبار را مبلغ صورتحساب ماهانه همان سرویس قرار داده است. اگر درخواست ندهید، چیزی دریافت نمیکنید.
۴- استثناها و قطعیهای برنامهریزیشده
بخش استثناها (Exclusions) دامنه واقعی تعهد را مشخص میکند. AWS و Google هر دو قطعیهای ناشی از عوامل خارج از کنترل معقول خود و همچنین اقدام، نرمافزار یا تجهیزات مشتری را مشمول SLA نمیدانند. در بسیاری از قراردادهای میزبانی هم نگهداری اعلامشده در آپتایم SLA سرور حساب نمیشود:
❌ قطعی ناشی از پیکربندی اشتباه یا نرمافزار خود مشتری
❌ حوادث قهری و اختلال در شبکههای خارج از کنترل ارائهدهنده
❌ تعلیق سرویس به دلیل نقض قوانین یا شرایط قرارداد
❌ حوادث قهری و اختلال در شبکههای خارج از کنترل ارائهدهنده
❌ تعلیق سرویس به دلیل نقض قوانین یا شرایط قرارداد
📚 از منابع معتبر
کتاب Site Reliability Engineering گوگل یادآوری میکند که دسترسپذیری 100 درصد ناممکن است و اصرار بر آن، به راهحلهای گران و بیش از حد محافظهکارانه و کندی نوآوری میانجامد. پس SLA معقول، عددی واقعبینانه با پیامد روشن است.
هزینه قطعی اهمیت این بندها را نشان میدهد: Uptime Institute در گزارش تحلیل سالانه قطعیها (مه 2026) به نقل از نظرسنجی 2025 خود اعلام کرده است که 57 درصد پاسخدهندگان هزینه آخرین قطعی جدی خود را بیش از 100 هزار دلار دانستهاند و از هر ۵ پاسخدهنده، ۱ نفر هزینهای بالای 1 میلیون دلار گزارش کرده است.
مزایا و محدودیتهای SLA؛ یک نگاه واقعبینانه
✅ انتظارات عددی و قابل پیگیری از کیفیت سرویس
✅ مسیر مشخص برای گزارش و پیگیری خرابی
✅ معیاری عینی برای مقایسه ارائهدهندگان
✅ مسیر مشخص برای گزارش و پیگیری خرابی
✅ معیاری عینی برای مقایسه ارائهدهندگان
❌ اعتبار جبرانی معمولاً به هزینه همان سرویس محدود است و زیان کسبوکار را پوشش نمیدهد.
❌ SLA جلوی قطعی را نمیگیرد؛ فقط پیامد آن را تعریف میکند.
❌ ارائه مدرک قطعی اغلب بر عهده مشتری است و داده از دست رفته جبران نمیشود.
❌ SLA جلوی قطعی را نمیگیرد؛ فقط پیامد آن را تعریف میکند.
❌ ارائه مدرک قطعی اغلب بر عهده مشتری است و داده از دست رفته جبران نمیشود.
یک سناریوی نمونه از پشتیبانی سرور اختصاصی
فرض کنید مدیر یک فروشگاه اینترنتی در مانیتورینگ سرور اختصاصی خود هشدار Degraded برای آرایه RAID 1 میبیند؛ یکی از دو دیسک از کار افتاده، اما سایت هنوز بالاست. او تیکت ثبت میکند، زمان هشدار را پیوست میکند و سلامت آخرین بکاپ را بررسی میکند. پشتیبانی دیسک معیوب را تأیید و تعویض را هماهنگ میکند و آرایه بازسازی میشود. درس این سناریو: SLA سرور و RAID زمان توقف را کم میکنند، اما ثبت دقیق زمانها و بکاپ مستقل، کسبوکار را امن نگه میدارد.
مقایسه جبران خسارت در SLA سرورهای ابری AWS و Google
جدول زیر بندهای جبران خسارت دو SLA عمومی را بر اساس متن رسمی آنها مقایسه میکند؛ این اعداد نمونه آموزشیاند، نه معیار الزامی:
| بند | Amazon EC2 | Google Compute Engine |
|---|---|---|
| تعهد استقرار چندناحیهای | 99.99% | 99.99% (Premium Tier) |
| تعهد تکماشین | 99.5% | 99.9% (بیشتر خانوادهها) |
| اعتبار چندناحیهای با آپتایم 99% تا زیر حد تعهد | 10% | 10% |
| اعتبار چندناحیهای با آپتایم 95% تا زیر 99% | 30% | 25% |
| اعتبار چندناحیهای با آپتایم زیر 95% | 100% | 100% |
| مهلت درخواست | تا پایان دومین چرخه صورتحساب | 60 روز پس از احراز شرایط |
| شکل جبران | اعتبار برای صورتحسابهای آینده | اعتبار برای مصرف آینده |
چکلیست بررسی SLA قبل از خرید سرور اختصاصی
پیش از پذیرش SLA سرور، سوالهای زیر را از ارائهدهنده بپرسید و پاسخها را مکتوب بگیرید. اگر برای بندی پاسخ روشنی وجود ندارد، همین نکته بخشی از ارزیابی شماست:
✅ درصد آپتایم چقدر است و ماهانه سنجیده میشود یا سالانه؟
✅ قطعی چه تعریفی دارد و حداقل مدت قابل شمارش چقدر است؟
✅ آپتایم با چه ابزاری سنجیده میشود و به گزارشها دسترسی دارید؟
✅ زمان پاسخگویی برای هر سطح حادثه، در ساعات کاری و خارج از آن، چقدر است؟
✅ در صورت خرابی سختافزار سرور، قطعه یدکی در دسترس است و تعویض چقدر طول میکشد؟
✅ نگهداری برنامهریزیشده با چه مدت اطلاع قبلی انجام میشود؟
✅ چه رویدادهایی، از جمله حملات DDoS، مستثنا هستند؟
✅ اعتبار جبرانی چقدر است، سقفش چیست و مهلت درخواست چقدر است؟
✅ مسئولیت بکاپ و بازیابی داده با کیست؟
✅ قطعی چه تعریفی دارد و حداقل مدت قابل شمارش چقدر است؟
✅ آپتایم با چه ابزاری سنجیده میشود و به گزارشها دسترسی دارید؟
✅ زمان پاسخگویی برای هر سطح حادثه، در ساعات کاری و خارج از آن، چقدر است؟
✅ در صورت خرابی سختافزار سرور، قطعه یدکی در دسترس است و تعویض چقدر طول میکشد؟
✅ نگهداری برنامهریزیشده با چه مدت اطلاع قبلی انجام میشود؟
✅ چه رویدادهایی، از جمله حملات DDoS، مستثنا هستند؟
✅ اعتبار جبرانی چقدر است، سقفش چیست و مهلت درخواست چقدر است؟
✅ مسئولیت بکاپ و بازیابی داده با کیست؟
نکتههای انتخاب: سرور اختصاصی، مجازی یا ابری؟
SLA سرور اختصاصی معمولاً روی شبکه، برق و سختافزار تمرکز دارد، چون کل ماشین در اختیار شماست و سیستمعامل و نرمافزار را خودتان مدیریت میکنید. در سرویسهای ابری، تعهد به معماری بستگی دارد؛ همانطور که در جدول AWS و Google دیدید، تعهد تکماشین پایینتر از استقرار چندناحیهای است.
◀️ کسبوکار کوچک با یک سرور: زمان تعویض قطعه و بکاپ مستقل از خود عدد آپتایم مهمتر است.
◀️ سرویس حساس به قطعی: بهجای تکیه بر تعهد یک سرور، معماری افزونه با دو سرور یا بیشتر و یک لود بالانسر برای توزیع بار طراحی کنید.
◀️ سرویس حساس به قطعی: بهجای تکیه بر تعهد یک سرور، معماری افزونه با دو سرور یا بیشتر و یک لود بالانسر برای توزیع بار طراحی کنید.
📌 اگر سرور شما همین حالا از دسترس خارج شده، راهنمای کارهای حیاتی هنگام داون شدن سرور را دنبال کنید و زمان شروع و پایان قطعی را یادداشت کنید.
SLA سرور اختصاصی در وبداده؛ پیش از خرید شفاف بپرسید
در وبداده معتقدیم بهترین SLA سرور، قراردادی است که پیش از خرید با دقت خوانده شده باشد. پیشنهاد میکنیم سوالهای چکلیست بالا را با تیم فنی ما مطرح کنید و قوانین سرورهای اختصاصی ایران وبداده را هم پیش از پرداخت بخوانید. آنچه امروز ارائه میشود:
✅ سختافزار HPE ProLiant؛ پلن PRIME 9 با HPE DL360 Gen9 و دو پردازنده Xeon E5-2680 v4 (در مجموع 28 هسته و 56 رشته)
✅ 64GB رم Registered ECC DDR4 و 1TB هارد NVMe سری Samsung 980/990 PRO
✅ پورت 10Gbit/s روی شبکهای با آپلینک 100Gbit و محافظت Anti DDoS با ظرفیت 100Gbit/s
✅ نصب خودکار سیستمعامل و تحویل آنی پس از پرداخت، همراه با پنل مدیریت سرور
✅ تیم فنی شبانهروزی برای مشاوره پیش از خرید و بررسی پیکربندی سفارشی از طریق تیکت یا تماس
✅ 64GB رم Registered ECC DDR4 و 1TB هارد NVMe سری Samsung 980/990 PRO
✅ پورت 10Gbit/s روی شبکهای با آپلینک 100Gbit و محافظت Anti DDoS با ظرفیت 100Gbit/s
✅ نصب خودکار سیستمعامل و تحویل آنی پس از پرداخت، همراه با پنل مدیریت سرور
✅ تیم فنی شبانهروزی برای مشاوره پیش از خرید و بررسی پیکربندی سفارشی از طریق تیکت یا تماس
🚀 بیشتر بدانید: برای ثبت مستقل زمان قطعیها، آموزش مانیتورینگ سرور با Netdata و Glances را بخوانید.
سوالات متداول درباره SLA سرور
SLA مخفف چیست و معادل فارسی آن چیست؟
SLA مخفف Service Level Agreement است و در فارسی «قرارداد سطح خدمات» یا «توافقنامه سطح خدمات» ترجمه میشود. این سند کیفیتی را که ارائهدهنده متعهد میشود، مثل درصد دسترسپذیری و زمان پاسخگویی، همراه با پیامد عمل نکردن به آن مشخص میکند.
قرارداد SLA چیست و چه فرقی با قرارداد خرید سرویس دارد؟
قرارداد خرید یا شرایط استفاده، رابطه کلی دو طرف مثل قیمت و مدت را تعیین میکند. SLA بخش تخصصیتری است که فقط کیفیت سرویس را با عدد تعریف میکند: آپتایم، زمان پاسخ و تعمیر، استثناها و جبران خسارت. گاهی پیوست قرارداد اصلی است و گاهی صفحهای جداگانه؛ بدانید کدام نسخه ملاک است.
SLA اینترنت چیست و چه شاخصهایی دارد؟
SLA اینترنت تعهد اپراتور درباره کیفیت لینک است و علاوه بر دسترسپذیری، ممکن است تأخیر (Latency)، نرخ از دست رفتن بسته، تغییرات تأخیر (Jitter) و زمان رفع خرابی را هم در بر بگیرد. پارامترهای فنی این حوزه در توصیههایی مثل ITU-T Y.1540 تعریف شدهاند.
آیا ارائهدهندهای هست که آپتایم 100 درصد تضمین کند؟
به گفته کتاب SRE گوگل، دسترسپذیری 100 درصد ناممکن است. اگر ارائهدهندهای عدد 100 درصد اعلام کند، معمولاً یعنی برای قطعیهای خارج از استثناها اعتبار جبرانی میدهد، نه اینکه قطعی رخ نمیدهد. پس تعریف قطعی، استثناها و سقف جبران را بخوانید.
در صورت خرابی سختافزار سرور، دادههای من هم جبران میشود؟
معمولاً خیر. قراردادهای پشتیبانی سختافزار، تعمیر یا تعویض قطعه را پوشش میدهند، نه بازگرداندن داده؛ برای نمونه، در دیتاشیت HPE Foundation Care بازیابی داده جزو موارد مستثناست. RAID احتمال توقف را کم میکند، اما فقط بکاپ منظم و مستقل از داده در برابر خرابی، حذف اشتباه یا حمله محافظت میکند.
اعتبار جبرانی (Service Credit) بهصورت نقدی پرداخت میشود؟
در بیشتر SLAهای عمومی خیر. AWS تصریح میکند اعتبار جبرانی حق بازپرداخت نقدی ایجاد نمیکند و فقط از صورتحسابهای آینده کم میشود. Google هم اعتبار را برای مصرف آینده اعمال میکند و سقف آن را صورتحساب ماهانه همان سرویس قرار داده است. پس SLA را بیمه زیان کسبوکار ندانید.
قطعی ناشی از حمله DDoS در SLA سرور حساب میشود؟
به متن قرارداد بستگی دارد و قاعده عمومی ثابتی وجود ندارد. بسیاری از SLAها رویدادهای خارج از کنترل معقول ارائهدهنده را مستثنا میکنند و حمله ممکن است ذیل همین بند قرار بگیرد. اگر هدف حمله هستید، پیش از خرید ظرفیت محافظت DDoS و نحوه محاسبه این قطعیها را بپرسید.
SLA سرور اختصاصی با سرور ابری چه تفاوتی دارد؟
در سرور اختصاصی، کل سختافزار به شما اختصاص دارد و SLA بیشتر روی شبکه، برق و زمان تعویض قطعه تمرکز میکند. در سرویس ابری، تعهد به معماری بستگی دارد؛ در AWS و Google تعهد چندناحیهای 99.99 درصد و تعهد تکماشین پایینتر است. مدیریت سیستمعامل و داده معمولاً با خود شماست.
جمعبندی؛ SLA را کامل بخوانید، نه فقط درصد آپتایم را
حالا میدانید SLA چیست و چرا خواندن دقیق آن پیش از خرید سرور اهمیت دارد. این سند کیفیت سرویس را به عدد و پیامد تبدیل میکند، اما ارزش واقعی آن در جزئیات است: بازه سنجش آپتایم، تعریف قطعی، فاصله زمان پاسخ تا زمان تعمیر، استثناها و سقف اعتبار جبرانی.
در این راهنما دیدید که هر «۹» اضافه، قطعی مجاز را به یکدهم میرساند، جبران خسارت معمولاً اعتباری و محدود به هزینه همان سرویس است و هیچ SLA سرور داده از دست رفته را برنمیگرداند. پس بهترین راهبرد، ترکیب قرارداد شفاف، معماری مناسب با RAID و در صورت نیاز افزونگی، و بکاپ مستقل است.
توصیه نهایی ما: چکلیست این مقاله را کنار دستتان نگه دارید، هر بند مبهم را بپرسید و پاسخ را مکتوب کنید. اگر به دنبال سرور اختصاصی روی سختافزار HPE با رم ECC، هارد NVMe، پورت 10Gbit/s و محافظت DDoS هستید، کارشناسان وبداده بهصورت شبانهروزی پاسخگوی سوالهای پیش از خرید شما هستند.
در صورتی که سوالی داشتید میتوانید در بخش نظرات با ما در ارتباط باشید.
امیدوارم این مقاله از بلاگ وبداده برای شما مفید بوده باشد.
امیدوارم این مقاله از بلاگ وبداده برای شما مفید بوده باشد.
منابع: IETF RFC 3198: Terminology for Policy-Based Management؛ Google SRE Book, Chapter 4: Service Level Objectives؛ Amazon Compute Service Level Agreement (AWS)؛ Google Compute Engine Service Level Agreement؛ HPE Foundation Care Service data sheet؛ Uptime Institute: Annual Outage Analysis Report 2026
