SLA چیست؟ هر آنچه باید درباره قرارداد پشتیبانی نرم‌افزار بدانید

تیم آرادتیم مهندسی

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

چرا قول شفاهی کافی نیست

«هر وقت مشکلی بود زنگ بزنید، درستش می‌کنیم.» این جمله تا روزی که مشکلی پیش نیاید بی‌عیب است. مسئله از جایی شروع می‌شود که سامانه ساعت ده شب جمعه از کار می‌افتد و شما نمی‌دانید کسی جواب می‌دهد یا نه — و اگر جواب داد، نمی‌دانید تا کی قرار است درست شود.

SLA این ابهام را حذف می‌کند. کاری که می‌کند تضمین «خرابی پیش نمی‌آید» نیست؛ هیچ قراردادی نمی‌تواند این را تضمین کند. کاری که می‌کند تعریف زمان پاسخ، زمان رفع، و مسئولیت برای هر نوع خرابی است — یعنی تبدیل یک انتظار مبهم به عددی که می‌توان درباره‌اش گفت رعایت شد یا نشد.

شدت‌بندی خطا: مهم‌ترین بند قرارداد

بدون شدت‌بندی، هر تعهد زمانی بی‌معناست، چون همه خرابی‌ها یکسان نیستند. طبقه‌بندی متعارف چهار سطح دارد:

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

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

زمان پاسخ با زمان رفع یکی نیست

این تفکیک، شایع‌ترین سوءتفاهم در قراردادهای پشتیبانی است:

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

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

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

پنجره پوشش: چیزی که هزینه را تعیین می‌کند

بیشترین اثر را روی قیمت قرارداد پشتیبانی، ساعات پوشش دارد:

  • ۸×۵ — ساعات کاری، روزهای کاری. برای سامانه‌های داخلی سازمان که شب و تعطیلات کاربر ندارند، معمولاً کافی است.
  • ۱۲×۶ یا ۱۶×۶ — پوشش گسترده‌تر برای کسب‌وکارهایی که عصر و پنجشنبه فعالند.
  • ۲۴×۷ — پوشش کامل. برای فروشگاه اینترنتی، سامانه حمل‌ونقل، سلامت و هر چیزی که کاربرش شب هم فعال است، انتخاب واقعی همین است.

قاعده سنجش: ساعتی که سامانه از کار بیفتد و کسی نباشد، چقدر برای شما خرج دارد؟ اگر آن عدد از تفاوت قیمت ۸×۵ و ۲۴×۷ بیشتر است، تصمیم گرفته شده است.

پشتیبانی فقط رفع خرابی نیست

قرارداد پشتیبانی خوب چهار لایه دارد و بسیاری از قراردادها فقط لایه اول را پوشش می‌دهند:

۱. اصلاحی — رفع خرابی و باگ. همان چیزی که همه به آن فکر می‌کنند.

۲. پیشگیرانه — پایش سامانه، بررسی لاگ، فضای دیسک، پشتیبان‌گیری و آزمودن بازیابی آن. این لایه کاری است که باعث می‌شود لایه اول کمتر لازم شود. بند «پشتیبان‌گیری» بدون بند «آزمودن بازیابی» عملاً بی‌اعتبار است — نسخه پشتیبانی که بازگردانی‌اش آزموده نشده، تا روز حادثه فقط یک فرض است.

۳. تطبیقی — هم‌گام‌کردن سامانه با تغییرات بیرونی: نسخه جدید مرورگر و سیستم‌عامل، تغییر API درگاه پرداخت، تغییر مقررات مثل الزامات صورتحساب الکترونیکی. این تغییرات به شما مربوط نیستند و باز هم سامانه شما را می‌شکنند.

۴. تکاملی — تغییرات کوچک و بهبود. معمولاً به‌شکل سهمیه ماهانه نفر-ساعت در قرارداد می‌آید. اگر این سهمیه نباشد، هر تغییر کوچک تبدیل به یک مذاکره جدا می‌شود و در عمل انجام نمی‌شود.

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

  1. شدت‌بندی با مثال از سامانه من نوشته شده؟ اگر بندها عمومی‌اند، بخواهید بازنویسی شوند.
  2. زمان پاسخ و زمان رفع تفکیک شده‌اند؟ و برای رفع، تعهد راه‌حل موقت وجود دارد؟
  3. پنجره پوشش دقیقاً چیست و تعطیلات رسمی داخلش هست یا نه؟
  4. کانال اعلام مشکل چیست و آیا سابقه‌اش ثبت می‌شود؟ اعلام مشکل از طریق تماس شخصی با یک نفر، قابل پیگیری نیست.
  5. سهمیه تغییرات ماهانه چقدر است و اگر مصرف نشود منتقل می‌شود؟
  6. پشتیبان‌گیری با چه دوره‌ای، و بازیابی‌اش هر چند وقت آزموده می‌شود؟
  7. جبران عدم رعایت SLA چیست؟ بندی که تعهد دارد ولی هیچ پیامدی برای نقضش ندارد، یک توصیه است نه یک تعهد.
  8. گزارش دوره‌ای چه چیزی را نشان می‌دهد؟ حداقل: تعداد تیکت به تفکیک شدت، زمان پاسخ واقعی، و موارد نقض SLA.
  9. دسترسی‌های زیرساخت و مخزن کد نزد کیست؟ اگر فقط پیمانکار دسترسی دارد، شما در وضعیت قفل‌شدگی هستید.
  10. شرط پایان همکاری و انتقال چیست؟ چه چیزی، در چه بازه‌ای تحویل می‌شود. این بند را در روز خوب ببندید، چون در روز بد قابل مذاکره نیست.

نکته آخر

قرارداد پشتیبانی هزینه‌ای است که ارزشش را وقتی نشان می‌دهد که به آن نیاز پیدا کنید — و درست به همین دلیل، معمولاً اولین چیزی است که از بودجه حذف می‌شود. سنجه درست برای این تصمیم، درصد هزینه ساخت نیست؛ هزینه یک ساعت از‌کار‌افتادگی سامانه برای کسب‌وکار شما است. آن عدد را حساب کنید و بعد درباره قرارداد تصمیم بگیرید.

پشتیبانی ۲۴/۷ آراد روی همین چهار لایه بسته می‌شود و شدت‌بندی‌اش با مثال از سامانه خودتان نوشته می‌شود. اگر قرارداد پشتیبانی فعلی دارید و می‌خواهید بدانید کدام بندهایش خالی است، یک جلسه بررسی رایگان کافی است.

پروژه یا ایده‌ای دارید؟

متخصصین ما آماده برگزاری یک جلسه مشاوره رایگان هستند.

مشاوره رایگان

پروژه‌تان را با هم بررسی کنیم

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

چطور با شما تماس بگیریم؟

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

راه دوم برای رساندن پاسخ — اگر تلفن در دسترس نبود، ایمیل می‌زنیم.

در حال ارسال…

درخواست شما ثبت شد.

همکاران ما پیام شما را می‌بینند و با شما تماس می‌گیرند.