SLA چیست؟ توافق سطح خدمات در قرارداد پشتیبانی IT، آپ تایم و زمان پاسخ

SLA چیست؟ مخفف Service Level Agreement، یعنی توافقی مکتوب که مشخص می کند ارائه دهنده خدمت چه سطحی از کیفیت را متعهد شده و چطور اندازه گرفته می شود. در قرارداد پشتیبانی شبکه و سرور، SLA معمولاً فصلی است که می گوید به درخواست شما در چه مدت جواب داده می شود، مشکل در چه مدت رفع می شود و اگر سرویس از حدی بیشتر خاموش ماند چه جبرانی در کار است.

بدون SLA، عبارت هایی مثل «پشتیبانی سریع» یا «پاسخگویی شبانه روزی» فقط قول اند و هیچ کس نمی تواند بعداً ثابت کند رعایت شده یا نه. با SLA همین قول ها به عدد تبدیل می شوند.

اجزای یک SLA

• دامنه خدمات: کدام سرورها، تجهیزات و سرویس ها زیر پوشش اند.
• ساعت پوشش: ساعت اداری، 24 ساعته یا 24 ساعته فقط برای مشکل های بحرانی.
• سطح بندی درخواست ها و زمان پاسخ و رفع برای هر سطح.
• آپ تایم (در دسترس بودن) سرویس های اصلی و روش اندازه گیری آن.
• گزارش دوره ای: چه چیزی، با چه تناوبی به شما داده می شود.
• جبران در صورت رعایت نشدن SLA.
• استثناها، یعنی مواردی که قطعی حساب نمی شود.

زمان پاسخ و زمان رفع فرق دارند

این دو را اغلب با هم قاطی می کنند:

• زمان پاسخ فاصله ثبت درخواست تا شروع کار یک کارشناس روی آن است.
• زمان رفع فاصله ثبت درخواست تا برگشتن سرویس به حالت عادی یا ارائه راه حل موقت است.

قراردادی که فقط «زمان پاسخ 15 دقیقه» دارد، ممکن است همان 15 دقیقه فقط یک تیکت را بخواند و ساعت ها بعد کار شروع شود. بپرسید زمان رفع هم تعریف شده یا نه، و اگر تعریف نشده چرا. بعضی مشکل ها (مثل خرابی سخت افزار) به عوامل بیرونی وابسته اند و ارائه دهنده فقط «زمان شروع رسیدگی» را متعهد می شود، که اشکالی ندارد به شرطی که صریح نوشته شده باشد.

نمونه سطح بندی درخواست ها

عدد زمان پاسخ و رفع برای هر سطح را در قرارداد ببینید. تعداد سطح ها مهم تر از اعداد خاص است، چون قراردادی که همه درخواست ها را بحرانی می داند عملاً سطح بندی ندارد. بحرانی بودن را مشتری و پیمانکار باید با هم تعریف کنند.

آپ تایم چطور حساب می شود

آپ تایم درصد زمانی است که سرویس در یک ماه در دسترس بوده. عددهای رایج و حداکثر قطعی مجازشان در ماه 30 روزه:

فرمول: قطعی مجاز = (100 منهای درصد آپ تایم) تقسیم بر 100، ضرب در تعداد دقایق ماه. برای 99.9 درصد: 0.1 درصد از 43200 دقیقه، برابر 43.2 دقیقه. هرچه عدد به 100 نزدیک تر شود، هزینه بالاتر می رود، چون فقط با افزونگی (دو سرور، دو لینک، دو منبع تغذیه) ممکن است. قبل از خرید پلن 99.99 درصد، ببینید سرویس شما واقعاً این سطح را لازم دارد یا نه. چنین عددی روی یک سرور تنها بی معنی است.

جزئیات دیگری که باید روشن باشد: آپ تایم از کجا اندازه گرفته می شود (از داخل شبکه ارائه دهنده یا از بیرون)، آیا نگه داری برنامه ریزی شده قطعی حساب می شود، و ابزار اندازه گیری را چه کسی دارد.

استثناها

هر SLA مواردی را از شمول بیرون می گذارد. بعضی منطقی اند و بعضی باید دقت کرد:

• نگه داری برنامه ریزی شده که از قبل اعلام شده، معمولاً قابل قبول است.
• قطعی اینترنت یا برق بیرون از کنترل ارائه دهنده، منطقی است ولی باید مرزش روشن باشد.
• مشکل ناشی از تغییری که مشتری بدون هماهنگی داده.
• سخت افزار یا نرم افزاری که تحت پشتیبانی سازنده نیست و در قرارداد فهرست نشده است.
• فهرست استثناهای بلند و مبهم، که عملاً SLA را بی اثر می کند.

جبران در صورت رعایت نشدن

معمول است که SLA برای نقض آن جبران مشخص کند، مثل تخفیف در صورت حساب بعدی یا تمدید رایگان سرویس. چند نکته:

• جبران معمولاً سقف دارد و خسارت واقعی کسب و کار را جبران نمی کند. SLA ابزار فشار و شفافیت است و جای بیمه را نمی گیرد.
• برای دریافت جبران، مشتری اغلب باید در مدت مشخصی درخواست بدهد. این مهلت را در قرارداد ببینید.
• اگر خسارت قطعی برای شما سنگین است، به جای تکیه بر جریمه، راه حل فنی (افزونگی، بکاپ، سرویس پشتیبان) را مطالبه کنید.

قبل از امضا چه بپرسیم

• اعداد زمان پاسخ و رفع کجا نوشته شده و برای کدام ساعت هاست؟
• تیکت ها چطور ثبت می شوند و آیا سابقه شان برای مشتری قابل دیدن است؟
• گزارش ماهانه شامل چه چیزی است؟
• اگر تیم ارائه دهنده قطعی ای را کشف کند ولی ما خبر نداشته باشیم، چه می شود؟ مانیتورینگ فعال جزء خدمت است یا نه؟ درباره این موضوع در مانیتورینگ سرور چیست بیشتر نوشته ایم.
• بند خروج چیست؟ در پایان همکاری، رمزها و مستندات چطور تحویل داده می شوند؟

SLA، SLO و SLI

این سه اصطلاح اغلب با هم می آیند و فرق دارند:

معمولاً SLO داخلی سخت گیرانه تر از SLA است تا قبل از رسیدن به نقض قرارداد، تیم هشدار بگیرد.

نمونه یک بند SLA

برای اینکه ببینید یک بند خوب چه شکلی است، این مثال را بخوانید:

سطح بحرانی: توقف کامل سرویس اصلی یا از دست رفتن اطلاعات.
پوشش: 24 ساعت و 7 روز هفته.
زمان پاسخ: حداکثر 30 دقیقه از ثبت تیکت یا تماس.
زمان رفع یا راه حل موقت: هدف 4 ساعت، با گزارش وضعیت هر 60 دقیقه.
مسئول: مهندس آنکال طبق جدول پیوست.

در این بند معلوم است چه چیزی بحرانی حساب می شود، چه کسی جواب می دهد و مشتری هر چند وقت خبر می گیرد. دو جزئی که بیشتر قراردادها ندارند: «گزارش وضعیت در حین حادثه» و «مسئول مشخص». این ها تعهد را از قول به عمل تبدیل می کنند. اعداد این مثال فقط نمونه اند و باید با نیاز و ظرفیت واقعی تعیین شوند.

SLA داخلی بین واحد IT و بقیه شرکت

SLA فقط بین دو شرکت نیست. واحد IT شرکت هم می تواند با بقیه واحدها توافق داخلی داشته باشد: درخواست ساخت کاربر جدید ظرف یک روز کاری، تعویض کامپیوتر خراب ظرف دو روز و غیره. این توافق انتظار ها را روشن می کند و وقتی IT زیر فشار است، اولویت ها بر اساس یک قاعده مشترک تعیین می شود.

چطور رعایت SLA را بسنجیم

• تیکت ها در سیستمی ثبت شوند که زمان ثبت، شروع کار و پایان را نگه می دارد.
• آپ تایم را مانیتورینگ از بیرون اندازه بگیرد و به گزارش ارائه دهنده از داخل شبکه خودش اکتفا نکند.
• در گزارش ماهانه، هر قطعی با علت و راه حل آمده باشد. مقایسه با ماه قبل نشان می دهد مشکل ها تکراری اند یا نه.
• سالی یک بار SLA را بازبینی کنید. شرکت رشد کرده، سرویس ها عوض شده اند و عددهای سال قبل ممکن است دیگر معنی نداشته باشند.

چارچوب فرایندی پشت قراردادهای خدمات در ITIL چیست آمده است.

منابع و مستندات رسمی

• فصل SLO و SLI در کتاب SRE گوگل
• فصل پذیرش ریسک و هدف دسترس پذیری در کتاب SRE گوگل
• نمونه رسمی SLA های سرویس های AWS

تأثیر سطح SLA بر مبلغ قرارداد را در تعرفه خدمات پشتیبانی شبکه بخوانید.

اگر می خواهید بدانید قراردادی که جلوی شماست چه بندهایی دارد، فهرست نمونه را در نمونه قرارداد پشتیبانی شبکه ببینید، و برای تفاوت پشتیبانی با مجموعه خدمات IT، خدمات IT چیست را بخوانید. قرارداد پشتیبانی ما با SLA روشن، سطح بندی و گزارش دوره ای در صفحه قرارداد پشتیبانی شبکه و سرور آمده است.

نحوه تهیه مقاله ها