ساعت دو نیمه شب است. سرور اصلی سازمان از دسترس خارج شده و سیستم فروش شما قفل کرده است. اولین تماس با شرکت پشتیبانی شبکه به جایی نمیرسد. تماس دوم پیام خارج از ساعت اداری پخش میکند. حالا به قراردادی که ماه گذشته امضا کردید نگاه میکنید؛ صفحه ای که در آن قول داده بودند پشتیبانی شبکه کامل ۲۴ ساعته ارائه میشود. اما هیچ عدد و معیاری برای پاسخگویی وجود ندارد. این دقیقا همان لحظه ای است که متوجه میشوید SLA در پشتیبانی شبکه را نادیده گرفته اید.
در این متن، بندهایی را مرور میکنیم که بدون آنها یک قرارداد پشتیبانی شبکه ارزش کاغذش را ندارد. برای مدیران فنی و مهندسانی که نمیخواهند در بحران بعدی دست خالی بمانند، این راهنما کاملا عملیاتی است.
SLA در پشتیبانی شبکه دقیقا چه چیزی را کنترل میکند؟
هر قرارداد پشتیبانی شبکه بدون SLA فقط یک قول شفاهی با مهر و امضا است. SLA به شما اجازه میدهد از عبارت سرویس خوب به عدد برسید: مثلا زمان پاسخ اولیه ۱۵ دقیقه برای بحران، زمان حل موقت ۲ ساعت و زمان رفع نهایی ۴ ساعت. این اعداد سلیقه ای نیستند؛ از تحلیل هزینه هر دقیقه قطعی برای کسب و کار شما استخراج میشوند.
در توافق نامه سطح خدمات چهار متغیر اصلی کنترل میشوند: زمان پاسخ، زمان رفع، درصد در دسترس بودن و حجم مجاز خرابی. اگر یکی از این چهار مورد در قرارداد نباشد، شما در واقع یک قرارداد نظافت ساختمان امضا کرده اید نه پشتیبانی شبکه.
یک تجربه عینی: در یک شرکت تولیدی، سرور برنامه حسابداری بعد از قطع برق روشن نشد. قرارداد پشتیبانی داشتند ولی در متن آن نوشته بود در اسرع وقت. مهندس پشتیبان فردا صبح آمد. واحد حسابداری یک روز کامل خوابید. ضرر آن روز از هزینه دو سال قرارداد پشتیبانی بیشتر بود. این فقدان یک بند SLA روشن است؛ نه بدشانسی.
چرا SLA بدون ابزار پایش فقط یک شوخی کاغذی است؟
بسیاری از مدیران فکر میکنند امضای SLA کافی است. در واقعیت، توافقی که ابزار پایش نداشته باشد محکمه پسند نیست. اگر شرکت پشتیبانی مدعی شود ما ساعت ۲ بامداد تماس شما را دیدیم و در ۱۵ دقیقه پاسخ دادیم، شما با چه داده ای خلافش را ثابت میکنید؟
ابزار پایش مثل سیستم تیکتینگ، مانیتورینگ شبکه (Zabbix، PRTG، SolarWinds) و لاگهای تماس، ستون فقرات اجرای 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 چیست؟
ترکیب یک سیستم تیکتینگ مثل Jira Service Management یا RT و یک سیستم مانیتورینگ مثل Zabbix یا PRTG. انتخاب ابزار باید در خود SLA مشخص شود.
آیا SLA فقط برای شرکتهای بزرگ لازم است؟
خیر. هر کسب و کاری که به شبکه وابسته است حتی با ۱۰ کارمند اگر قطعی باعث توقف فروش یا عملیات شود به SLA نیاز دارد. مقیاس فرق دارد اصل یکسان است.

