SLA چیست و زمان پاسخ در قرارداد پشتیبانی چطور تعریف میشود
در بیشتر قراردادهای پشتیبانی که به دستمان میرسد، عبارت SLA نوشته شده است. در کمتر از نیمی از آنها، چیزی که نوشته شده واقعاً یک SLA است. تفاوت در یک چیز خلاصه میشود: SLA یعنی عددی که بشود اندازه گرفت و سرش مطالبه کرد. هر چیز دیگری اعلام حسن نیت است.
این مقاله توضیح میدهد یک SLA پشتیبانی شبکه از چه اجزایی ساخته میشود، چطور اندازهگیری میشود، و کدام بند بدون آن کل SLA تزئینی است.
SLA دقیقاً چیست
SLA یا توافقنامه سطح خدمات، بخشی از قرارداد است که میگوید ارائهدهنده خدمت، چه چیزی را در چه مدتی تعهد میکند و اگر تعهد را رعایت نکرد چه اتفاقی میافتد.
سه جزء دارد و هر سه لازم است:
- شاخص: چه چیزی اندازه گرفته میشود (مثلاً زمان پاسخ).
- هدف: عدد آن شاخص (مثلاً حداکثر ۳۰ دقیقه).
- پیامد: اگر هدف محقق نشد چه میشود.
قراردادی که جزء سوم را ندارد، SLA ندارد. شاخص و هدف بدون پیامد، فقط یک آرزوی مکتوب است.
زمان پاسخ و زمان حل؛ دو چیز کاملاً متفاوت
رایجترین ابهام قراردادها همینجاست. این سه را جدا کنید:
زمان پاسخ
فاصله بین ثبت درخواست تا لحظهای که کسی مسئولیت آن را میپذیرد و بررسی را شروع میکند. این عدد باید کوتاه و قابل تعهد باشد، چون به پیچیدگی مشکل بستگی ندارد.
زمان حضور
فاصله تا حضور فیزیکی کارشناس در محل. فقط برای مشکلاتی معنا دارد که از راه دور حل نمیشوند.
زمان حل
فاصله تا برطرف شدن مشکل. این عدد را هیچ ارائهدهنده صادقی بهصورت مطلق تعهد نمیکند، چون به علت مشکل بستگی دارد: تعویض یک کابل با بازیابی یک سرور سوخته قابل مقایسه نیست.
آنچه قابل تعهد است، زمان حل برای دستههای مشخصی از مشکلات رایج است، یا تعهد به ارائه «راهحل موقت» در بازه مشخص. اگر پیمانکاری زمان حل قطعی برای همهچیز تعهد کرد، یا متن را دقیق نخواندهاید یا او دارد چیزی میفروشد که نمیتواند بدهد.
سطحبندی؛ بدون آن SLA بیمعنی است
یک عدد واحد برای همه مشکلات، یعنی یا برای موارد بحرانی خیلی کند است یا برای موارد عادی غیرواقعبینانه. سطحبندی حل این مسئله است:
| سطح | تعریف | نمونه |
|---|---|---|
| بحرانی | کار کل سازمان یا یک سرویس درآمدزا متوقف است | قطعی کل شبکه، از کار افتادن سرور اصلی، قطعی مرکز تلفن |
| مهم | یک بخش یا سرویس مهم مختل است اما کار کل سازمان متوقف نیست | قطعی یک طبقه، کندی شدید اینترنت، اختلال در چاپ شبکه |
| عادی | مشکل یک کاربر یا موضوعی که راهحل موقت دارد | مشکل دسترسی یک نفر، درخواست تنظیم |
| درخواست | کار برنامهریزیشده، نه خرابی | ایجاد کاربر جدید، نصب تجهیز |
نکته مهم: تعریف سطح باید در قرارداد باشد، نه در ذهن طرفین. وگرنه در لحظه بحران، شما میگویید بحرانی است و پیمانکار میگوید مهم — و هیچ مرجعی برای داوری وجود ندارد.
چه کسی سطح را تعیین میکند
بهترین رویه این است که سطح اولیه را کارفرما اعلام کند و پیمانکار در صورت اختلاف، ظرف مدت کوتاهی دلیل بیاورد. اگر تعیین سطح یکطرفه در اختیار پیمانکار باشد، هر مشکلی معجزهآسا «عادی» میشود.
ساعات پوشش و اثرش بر SLA
یک زمان پاسخ عالی در ساعاتی که پوشش ندارید، بیفایده است. باید روشن باشد:
- روزها و ساعات پوشش عادی
- آیا پوشش خارج از ساعت اداری وجود دارد و با چه نرخی
- تعطیلات رسمی چه حکمی دارند
- آیا برای سطح بحرانی، پوشش گستردهتری تعریف شده
الگوی رایج و منطقی این است که سطح بحرانی پوشش گستردهتری از سطح عادی داشته باشد. اگر سرور اصلی پنجشنبه شب بخوابد، پاسخ «شنبه میآییم» برای بسیاری از کسبوکارها یعنی از دست رفتن کل آخر هفته.
چطور اندازهگیری میشود
SLA بدون سیستم ثبت، قابل اندازهگیری نیست. باید مشخص باشد:
- درخواست از چه کانالی ثبت میشود؟ تیکت، ایمیل، تلفن. اگر تلفن است، چه کسی و کجا ثبتش میکند؟
- لحظه شروع کدام است؟ زمان تماس یا زمان ثبت در سیستم؟ این تفاوت میتواند نیم ساعت باشد.
- ساعت توقف چطور محاسبه میشود؟ اگر منتظر پاسخ کارفرما بمانند، آن مدت از SLA کسر میشود یا نه؟
- گزارش را چه کسی تولید میکند؟ اگر فقط پیمانکار، باید داده خام هم در دسترس شما باشد.
بند «توقف شمارش» را جدی بگیرید. منطقی است که وقتی پیمانکار منتظر تصمیم یا دسترسی از سمت شماست زمان نشمارد — اما این باید تعریف و ثبت شود، نه اینکه در پایان ماه بهصورت شفاهی ادعا شود.
بند نقض و پیامد
این همان بندی است که بیشتر قراردادها ندارند و بدون آن، بقیه SLA تزئینی است. شکلهای رایج پیامد:
- کسر از صورتحساب: درصدی از مبلغ ماهانه بهازای هر نقض.
- اعتبار خدمات: ساعات خدمت اضافه در دوره بعد.
- حق فسخ: اگر نقض از حد مشخصی در بازه مشخصی بیشتر شد، کارفرما بدون جریمه فسخ میکند.
مورد سوم مهمتر از دو تای اول است. کسر مالی معمولاً مبلغ کوچکی است و مشکل را حل نمیکند؛ حق خروج، اهرم واقعی است.
پنج اشتباه رایج در نوشتن SLA
- عدد بدون سطحبندی. یک زمان پاسخ برای همهچیز.
- تعهد زمان حل مطلق. غیرواقعی و در عمل نادیده گرفته میشود.
- نبود تعریف برای «بحرانی». منشأ اصلی اختلاف.
- نبود کانال ثبت مشخص. بدون آن، لحظه شروع قابل اثبات نیست.
- SLA بدون گزارش. عددی که ماهانه گزارش نشود، بعد از دو ماه فراموش میشود.
SLA خوب چه شکلی است
یک SLA سالم معمولاً یک صفحه است و اینها را دارد: جدول سطحبندی با تعریف هر سطح، زمان پاسخ و حضور برای هر سطح، ساعات پوشش هر سطح، کانال ثبت رسمی، نحوه محاسبه و توقف شمارش، تعهد گزارش ماهانه، و بند نقض با پیامد مشخص.
اگر اینها را دارد، بقیه جزئیات قابل مذاکره است. اگر ندارد، بقیه جزئیات اهمیتی ندارد. فهرست کامل بندهای قرارداد را در ۹ بند ضروری قرارداد پشتیبانی شبکه آوردهایم.
چه عددی برای شما درست است
پاسخ به این سؤال از محاسبه هزینه خرابی شبکه میآید، نه از مقایسه با شرکتهای دیگر. اگر هر ساعت توقف برای شما گران است، زمان پاسخ کوتاهتر میارزد؛ اگر نه، پول اضافه میدهید بابت تعهدی که به آن نیاز ندارید.
منطقی است که برای سطح بحرانی سختگیر باشید و برای سطح عادی منعطف. SLA سختگیرانه روی همه سطوح، فقط قیمت را بالا میبرد.
SLA در مدلهای مختلف پشتیبانی
سطح تعهدی که میتوانید بخواهید، به مدل قرارداد بستگی دارد. سه مدل رایج است و هر کدام SLA متفاوتی میپذیرد:
مدل ساعتی یا موردی
پرداخت بهازای هر مراجعه یا هر ساعت کار. در این مدل عملاً SLA معناداری وجود ندارد، چون پیمانکار تعهد در دسترس بودن نداده است. مناسب شرکتهایی است که توقف شبکه برایشان هزینه بالایی ندارد و ترجیح میدهند هزینه ثابت نپردازند.
مدل قراردادی با ساعت مشخص
سقف مشخصی ساعت در ماه، با نرخ توافقشده برای مازاد. SLA در این مدل قابل تعریف است اما باید روشن باشد که وقتی سقف ساعت تمام شد، تعهد زمان پاسخ همچنان برقرار است یا نه. این نکته را حتماً بپرسید؛ در بسیاری از قراردادها مبهم رها شده است.
مدل مدیریتشده
پیمانکار مسئولیت در دسترس بودن زیرساخت را میپذیرد، نه صرفاً پاسخ به درخواست. گرانتر است اما تنها مدلی است که در آن منافع دو طرف کاملاً همجهت میشود: هرچه شبکه پایدارتر، هزینه پیمانکار کمتر. در این مدل میتوانید شاخص در دسترس بودن هم به SLA اضافه کنید.
| ساعتی | قراردادی | مدیریتشده | |
|---|---|---|---|
| زمان پاسخ تعهدی | ندارد | دارد | دارد |
| بازدید پیشگیرانه | ندارد | معمولاً دارد | دارد |
| شاخص در دسترس بودن | ندارد | معمولاً ندارد | دارد |
| همجهتی منافع | معکوس | خنثی | همجهت |
| قابل پیشبینی بودن هزینه | کم | زیاد | زیاد |
سطر «همجهتی منافع» بیش از بقیه اهمیت دارد و کمتر به آن توجه میشود. در مدل ساعتی، درآمد پیمانکار از خرابی میآید. این به معنای بدنیتی نیست، اما ساختار انگیزه را باید دید.
شاخص در دسترس بودن؛ وقتی زمان پاسخ کافی نیست
برای سازمانهایی که سرویس حیاتی دارند، تعهد زمان پاسخ کافی نیست. آنچه اهمیت دارد این است که سرویس چند درصد از زمان بالا بوده است.
اگر میخواهید این شاخص را به قرارداد اضافه کنید، چهار چیز باید روشن باشد:
- کدام سرویس؟ در دسترس بودن «شبکه» مبهم است؛ در دسترس بودن «اینترنت دفتر مرکزی» یا «سرور فایل» قابل سنجش است.
- چطور اندازهگیری میشود؟ با چه ابزاری، از چه نقطهای، با چه فاصله زمانی.
- چه چیزی مستثناست؟ توقف برنامهریزیشده، قطعی برق، خرابی اپراتور.
- پنجره نگهداری کجاست؟ بازهای که کار برنامهریزیشده در آن انجام میشود و جزو توقف حساب نمیشود.
بدون بند چهارم، پیمانکار عملاً نمیتواند نگهداری انجام دهد بدون اینکه SLA خودش را نقض کند — و نتیجهاش این است که نگهداری انجام نمیشود.
یک نکته درباره مذاکره
وسوسهانگیز است که سختگیرانهترین اعداد ممکن را بخواهید. اما SLA سختگیرانه سه اثر دارد که همهشان به نفع شما نیست: قیمت بالا میرود، پیمانکارهای خوب ممکن است اصلاً پیشنهاد ندهند، و پیمانکاری که میپذیرد ممکن است از ابتدا بداند نمیتواند عمل کند و روی این حساب کند که شما پیگیری نخواهید کرد.
رویکرد سالمتر: اعداد را از محاسبه هزینه توقف دربیاورید، برای سطح بحرانی سختگیر باشید، و در ازای انعطاف در سطوح پایینتر، بند نقض محکمتری بگیرید.
سنجش فنی SLA: از برچسب زمانی تا گزارش
SLA فقط وقتی معنا دارد که قابل اندازهگیری باشد، و اندازهگیری فقط وقتی قابل اعتماد است که دادهاش را یک سیستم ثبت کند، نه حافظه دو طرف.
برچسبهای زمانی هر درخواست
سیستم ثبت درخواست (تیکتینگ) باید این لحظهها را خودکار و غیرقابل ویرایش ثبت کند:
- ثبت: لحظهای که درخواست از هر کانالی — تلفن، ایمیل، پورتال یا هشدار مانیتورینگ — ثبت شد.
- تأیید: لحظهای که کارشناس درخواست را پذیرفت. زمان پاسخ از ثبت تا همین لحظه است.
- حضور: برای مواردی که حضور لازم است.
- راهحل موقت: سرویس برگشته اما علت ریشهای باقی است.
- حل: مشکل برطرف شده و درخواستکننده تأیید کرده است.
دو شاخص از همین داده به دست میآید: MTTA (میانگین زمان تا تأیید) و MTTR (میانگین زمان تا حل).
توقف ساعت SLA
بعضی زمانها نباید به حساب پیمانکار نوشته شود: انتظار برای پاسخ یا دسترسی از سمت شما، انتظار برای اپراتور اینترنت، یا انتظار برای رسیدن قطعهای که خارج از تعهد قرارداد است. این شرایط باید در متن قرارداد فهرست شوند؛ وگرنه «منتظر شما بودیم» به توجیه هر تأخیری تبدیل میشود. هر توقف ساعت هم باید با دلیل و زمان در تیکت ثبت شود.
میانگین کافی نیست
فرض کنید ده درخواست بحرانی داشتهاید: نه تا در ۳۰ دقیقه حل شده و یکی در ۱۰ ساعت. میانگین حدود ۸۷ دقیقه است — عددی که نه تجربه آن نه درخواست را توصیف میکند، نه تجربه آن یکی را. گزارش درست سه عدد دارد: درصد پایبندی (چند درصد در زمان هدف حل شد)، صدک نود (زمانی که ۹۰٪ درخواستها زیر آن حل شدند) و بدترین مورد با علت آن.
دسترسپذیری: از داده مانیتورینگ، نه از تیکت
وقتی SLA شامل تعهد دسترسپذیری است — مثلاً «اینترنت و سرور مالی ۹۹٫۵٪ در ماه» — مبنای محاسبه باید بررسی خودکار در فواصل کوتاه باشد (مثلاً هر دقیقه)، و دقیقههای قطعی از روی آن شمرده شود. پنجرههای نگهداری توافقشده از محاسبه خارج میشوند، به شرطی که از پیش اعلام شده باشند. ۹۹٫۵٪ در ماه سیروزه یعنی حدود ۳ ساعت و ۳۶ دقیقه توقف مجاز؛ ۹۹٫۹٪ یعنی حدود ۴۳ دقیقه. جدول کامل و روش پیادهسازی را در مانیتورینگ زیرساخت آوردهایم.
کانال ثبت درخواست
اگر درخواستها از تماس تلفنی با موبایل شخصی کارشناس ثبت میشوند، هیچکدام از این اعداد وجود ندارد. شماره یا کانال واحد پشتیبانی که هر تماس را ثبت میکند، پیششرط SLA قابل اندازهگیری است — همان منطقی که در شاخصهای مرکز تماس برای سنجش پاسخگویی آمده.
پرسشهای متداول
آیا SLA تضمین میکند مشکل حل شود؟
نه. SLA تضمین میکند در بازه مشخصی شروع به رسیدگی شود و برای دستههای مشخصی از مشکلات، در بازه مشخصی حل شود. تضمین مطلق حل هر مشکلی، از نظر فنی ممکن نیست.
اگر مشکل از سمت اپراتور اینترنت باشد چه؟
باید در متن مستثنا شده باشد، اما با یک تعهد جایگزین: پیگیری با اپراتور، اطلاعرسانی وضعیت، و در صورت وجود، فعال کردن مسیر پشتیبان. «تقصیر ما نیست» بهتنهایی پاسخ قابل قبولی نیست.
SLA برای شرکت کوچک هم لازم است؟
بله، حتی سادهترین شکلش. یک جدول سهسطحی با زمان پاسخ و بند نقض، از هیچ SLA بهتر است و مذاکرهاش هم دشوار نیست.
چند درصد پایبندی قابل قبول است؟
عددی مثل ۹۵ درصد پایبندی در دوره ماهانه، برای بیشتر شرکتها منطقی است. عدد ۱۰۰ درصد را کسی نمیتواند تعهد کند و اصرار روی آن فقط قیمت را بالا میبرد یا پیمانکار را وادار به وعده غیرواقعی میکند.
آیا SLA شامل تجهیزاتی میشود که خودمان خریدهایم؟
باید در دامنه قرارداد مشخص شود. نکته مهم این است که برای تجهیزات خارج از رده یا بدون پشتیبانی سازنده، تعهد زمان حل واقعبینانه نیست چون تأمین قطعه در کنترل پیمانکار نیست.
قدم بعدی
اگر میخواهید ببینید برای اندازه و نوع کسبوکار شما چه سطحبندی و چه اعدادی منطقی است، بازدید فنی نقطه شروع است: وضعیت فعلی را میبینیم و SLA پیشنهادی را متناسب با آن مینویسیم.
مشاهده خدمات پشتیبانی شبکه و درخواست بازدید · تلفن: 021-74903
قرارداد SLA برای مشتریانتان مینویسید؟
اگر مشاور IT هستید و مشتریتان به پیمانکاری با تعهد SLA قابل سنجش نیاز دارد، از طریق برنامه همکاری در فروش نصیر ارتباط همکار یا معرف شوید.