قرارداد پشتیبانی سایت نباید فقط یک جمله درباره «رفع مشکلات سایت» داشته باشد. چنین عبارتی مشخص نمی‌کند چه کاری، در چه زمانی، با چه هزینه‌ای و توسط چه کسی انجام می‌شود. وقتی سایت قطع می‌شود یا اطلاعاتی از بین می‌رود، همین ابهام‌ها به اختلاف تبدیل می‌شوند.
یک قرارداد مناسب باید دامنه خدمات، سطح سرویس یا SLA، مسئولیت امنیت و بکاپ، نحوه دسترسی، مالکیت کد و داده، مبلغ و تعدیل قیمت، شرایط فسخ و روش تحویل را روشن کند. در ایران لازم است موضوعاتی مانند ریال یا تومان، مالیات و صورتحساب، تعطیلات رسمی، محدودیت سرویس‌های خارجی و اختلال اینترنت نیز صریح نوشته شوند. این مقاله همه بخش‌های مهم را مرحله‌به‌مرحله توضیح می‌دهد.
این متن راهنمای عمومی تنظیم قرارداد است و جای مشاوره اختصاصی وکیل، مشاور مالیاتی یا متخصص بیمه را نمی‌گیرد. متن نهایی باید با وضعیت طرفین، نوع سایت، داده‌ها و شیوه همکاری تطبیق داده شود.
۱. مشخصات و اختیار طرفین
نام و نام خانوادگی یا نام کامل شرکت، کد ملی یا شناسه ملی، شماره ثبت، نشانی، کدپستی، شماره تماس و اطلاعات نماینده باید دقیق ثبت شود. اگر یکی از طرفین شخص حقوقی است، سمت و حدود اختیار امضاکننده بر اساس آخرین روزنامه رسمی یا مدرک معتبر بررسی شود. مشخص کنید ابلاغ‌های قراردادی به کدام نشانی، ایمیل یا سامانه ارسال می‌شوند و تغییر اطلاعات چگونه اعلام خواهد شد.
وجود مهر بهتنهایی جای احراز اختیار امضا را نمی‌گیرد. همچنین اگر مدیر سایت، واحد فناوری یا آژانس دیگری درخواست‌ها را ثبت می‌کند، نام افراد مجاز برای تأیید کار و هزینه اضافه در پیوست قرارداد بیاید.
۲. موضوع قرارداد و تعریف دقیق سایت
در موضوع قرارداد، دامنه‌ها، زیردامنه‌ها، پنل‌ها، اپلیکیشن‌های وابسته و محیط‌های آزمایشی را نام ببرید. فناوری اصلی، محل میزبانی، مخزن کد و سرویس‌های مهم متصل مانند درگاه پرداخت، پیامک، ایمیل، حسابداری یا CRM نیز در پیوست فنی ثبت شوند.
عبارت موضوع باید میان «نگهداری»، «رفع باگ»، «پشتیبانی کاربران»، «تغییر محتوا» و «توسعه قابلیت جدید» تفاوت بگذارد. صفحه خدمات پشتیبانی سایت کمک می‌کند دامنه معمول خدمات را پیش از عقد قرارداد بهتر بشناسید.
۳. وضعیت اولیه و صورت‌جلسه تحویل
پشتیبان نباید بدون ثبت وضعیت موجود، مسئول همه مشکلات قبلی شناخته شود. در شروع همکاری یک ارزیابی اولیه انجام دهید و نسخه‌های نرم‌افزار، خطاهای شناخته‌شده، کیفیت بکاپ، دسترسیها، بدهی فنی و مشکلات امنیتی قابل مشاهده را ثبت کنید. مواردی که باید پیش از شروع نگهداری اصلاح شوند، به‌صورت پروژه جدا یا برنامه زمان‌بندی‌شده بیایند.
صورت‌جلسه تحویل باید مشخص کند چه دسترسیها و مستنداتی تحویل شده و چه مواردی هنوز ناقص‌اند. اگر کارفرما به کد منبع، پنل هاست یا حساب سرویس بیرونی دسترسی ندارد، اثر این محدودیت بر تعهد پشتیبان نوشته شود.
۴. دامنه خدمات دوره‌ای
خدمات ثابت را با تناوب و خروجی قابل بررسی تعریف کنید. نمونه‌ها عبارت‌اند از:
- مانیتورینگ دسترسی سایت، SSL، فضای دیسک و خطاهای حیاتی
- بکاپ‌گیری از فایل‌ها و پایگاه داده و آزمون دوره‌ای بازیابی
- به‌روزرسانی هسته، قالب، افزونه‌ها، کتابخانه‌ها و وابستگی‌ها
- بررسی امنیت، حساب‌های کاربری، لاگ‌ها و رفتارهای مشکوک
- رفع خطاهای فنی در قابلیت‌های موجود
- بررسی سرعت، کش، دیتابیس و منابع سرور
- کنترل فرم‌ها، پرداخت، ایمیل و اتصال‌های کلیدی
- گزارش ماهانه رخدادها، تغییرات و وضعیت سلامت سایت
برای هر مورد بنویسید چند بار، با چه ابزار یا معیار کلی و با چه گزارشی انجام می‌شود. «بررسی امنیت» بدون تعریف حداقل فعالیت‌ها قابل سنجش نیست.
۵. موارد خارج از قرارداد
فهرست استثناها به اندازه فهرست خدمات اهمیت دارد. طراحی مجدد، ساخت ماژول تازه، ورود انبوه محتوا، تولید متن و تصویر، خرید هاست یا لایسنس، مهاجرت سرور، بازسازی پس از هک قدیمی و رفع خطای سرویس ثالث معمولاً نیازمند توافق جدا هستند.
مشخص کنید پشتیبان برای سرویس ثالث فقط پیگیری و عیب‌یابی می‌کند یا نتیجه آن سرویس را نیز تضمین می‌کند. تیم پشتیبانی معمولاً نمی‌تواند عملکرد اپراتور اینترنت، دیتاسنتر، بانک یا API خارج از کنترل خود را تضمین کند.
۶. روش ثبت، تأیید و اولویت‌بندی درخواست
کانال رسمی درخواست باید مشخص باشد، مانند سامانه تیکت، ایمیل یا پیام‌رسان توافق‌شده. تماس تلفنی می‌تواند برای هشدار فوری استفاده شود، اما جزئیات و تأیید نهایی بهتر است در کانال قابل ثبت قرار گیرد. ساعت ثبت تیکت، اطلاعات ضروری، فرد مجاز درخواست‌کننده و شیوه اعلام پایان کار را بنویسید.
درخواست‌ها را دست‌کم به چهار سطح تقسیم کنید:
| سطح | نمونه | نوع برخورد |
|---|---|---|
| بحرانی | قطع کامل، اختلال گسترده پرداخت یا رخداد امنیتی فعال | واکنش فوری طبق SLA و تمرکز بر بازیابی سرویس |
| زیاد | خرابی یک قابلیت اصلی بدون راه‌حل جایگزین مناسب | اولویت بالا و اطلاع‌رسانی منظم |
| متوسط | اختلال محدود با راه‌حل موقت | رسیدگی در برنامه کاری |
| کم | ایراد ظاهری جزئی یا درخواست غیرفوری | قرار گرفتن در صف عادی |
تعریف سطح نباید فقط در اختیار درخواست‌کننده یا فقط در اختیار پشتیبان باشد. معیار و مسیر حل اختلاف درباره اولویت را از قبل تعیین کنید.
۷. SLA و تفاوت زمان پاسخ با زمان رفع
زمان پاسخ یعنی فاصله ثبت درخواست تا شروع بررسی و اعلام دریافت. زمان بازیابی یعنی مدت هدف برای برگرداندن قابلیت اصلی، حتی اگر راه‌حل موقت باشد. زمان رفع نهایی ممکن است بیشتر باشد، به‌خصوص وقتی مشکل به سرویس ثالث یا تغییر کد پیچیده وابسته است.
در SLA باید ساعات پوشش، روزهای کاری، تعطیلات رسمی ایران، منطقه زمانی تهران، روش محاسبه توقف ساعت و تناوب گزارش وضعیت مشخص شود. اگر پوشش شبانه‌روزی لازم است، آن را صریح و همراه با کانال اضطراری بنویسید. عبارت «پشتیبانی ۲۴ ساعته» بدون تعریف زمان واکنش و نیروی On-call مبهم است.
۸. مانیتورینگ، دسترس‌پذیری و پنجره نگهداری
اگر درصد Uptime تعهد می‌شود، ابزار اندازه‌گیری، نقاط پایش، دوره محاسبه و موارد مستثنا را مشخص کنید. قطعی برنامه‌ریزی‌شده، اختلال سراسری اینترنت، خرابی سرویس ثالث و اقدام بدون هماهنگی کارفرما ممکن است شرایط متفاوتی داشته باشند. استثناها نباید آن‌قدر گسترده باشند که تعهد دسترس‌پذیری بی‌معنا شود.
زمان اجرای به‌روزرسانی یا نگهداری برنامه‌ریزی‌شده، مدت اطلاع قبلی، روش تأیید و برنامه بازگشت باید روشن باشد. برای فروشگاه یا سامانه پرتراکنش، زمان کم‌ترافیک انتخاب شود.
۹. بکاپ، RPO و RTO
قرارداد باید نوع داده، تناوب بکاپ، محل نگهداری، رمزنگاری، مدت حفظ نسخه‌ها و مسئول پرداخت فضای ذخیره‌سازی را تعیین کند. نگهداری همه نسخه‌ها روی همان سرور اصلی ریسک مناسبی نیست.
RPO بیشترین داده قابل قبول برای از دست رفتن و RTO زمان هدف برای بازگرداندن سرویس است. این دو مقدار باید متناسب با فعالیت سایت باشند. مسئول آزمون بازیابی، تناوب آزمون و نحوه گزارش نتیجه نیز نوشته شود. هیچ پشتیبانی نباید موفق بودن بازیابی را فقط از روی ساخته شدن فایل بکاپ فرض کند.
۱۰. امنیت، محرمانگی و دسترسی به داده
پشتیبان ممکن است به اطلاعات مشتریان، سفارش‌ها، رمزها، کد و اسرار تجاری دسترسی پیدا کند. نوع داده محرمانه، موارد مجاز استفاده، مدت تعهد، افراد دارای دسترسی و شرایط افشای قانونی را تعریف کنید. تعهد محرمانگی بهتر است پس از پایان قرارداد نیز برای مدت متناسب ادامه داشته باشد.
حساب مشترک نسازید. هر فرد حساب جدا، حداقل سطح دسترسی و در صورت امکان احراز هویت دومرحله‌ای داشته باشد. نحوه نگهداری و انتقال رمز، ثبت لاگ، لغو دسترسی فرد جداشده و اطلاع رخداد امنیتی باید مشخص شود. دسترسی پشتیبان باید با اجازه و در محدوده قرارداد باشد؛ قانون جرایم رایانه‌ای برای دسترسی غیرمجاز به داده یا سامانه حفاظت‌شده حکم دارد.
همچنین بنویسید آیا پیمانکار می‌تواند از نیروی فرعی استفاده کند، شرایط دسترسی او چیست و مسئولیت اعمال او با چه کسی است. داده واقعی نباید بدون مجوز برای تست یا نمایش نمونه‌کار استفاده شود.
۱۱. مالکیت دامنه، هاست، کد و تغییرات نرم‌افزاری
دامنه و حساب‌های اصلی بهتر است به نام و تحت کنترل کارفرما باشند و پشتیبان دسترسی لازم را دریافت کند. مالکیت کد موجود، کد نوشته‌شده در دوره پشتیبانی، اسکریپت‌های عمومی پیمانکار، لایسنس افزونه‌ها و حق استفاده پس از پایان قرارداد باید جداگانه تعیین شود.
قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای درباره حقوق مادی و معنوی نرم‌افزار قواعدی دارد و برای نرم‌افزار ناشی از استخدام یا قرارداد نیز مقرراتی پیش‌بینی کرده است. با این حال، اتکا به برداشت شفاهی کافی نیست. حق تغییر، توسعه، بهره‌برداری، تحویل Source Code و استفاده مجدد از اجزای عمومی را در قرارداد روشن کنید.
۱۲. مدیریت تغییر و توسعه خارج از محدوده
هر درخواست تازه باید از مسیر Change Request عبور کند. شرح تغییر، اثر بر زمان و هزینه، ریسک، معیار پذیرش و شخص تأییدکننده ثبت شود. تا قبل از تأیید کتبی، پیمانکار ملزم به اجرای کار اضافه نباشد.
برای تغییرات کوچک می‌توان ظرفیت ماهانه تعریف کرد. مشخص کنید ساعت استفاده‌نشده منتقل می‌شود یا نه، حداقل واحد محاسبه چیست و گزارش مصرف چگونه ارائه می‌شود. راهنمای محاسبه هزینه پشتیبانی سایت مدل‌های قیمت‌گذاری و عوامل مؤثر بر مبلغ را با جزئیات توضیح می‌دهد.
۱۳. مبلغ، واحد پول و تعدیل قیمت در ایران
مبلغ را هم به عدد و هم به حروف بنویسید و دقیقاً مشخص کنید ریال است یا تومان. برنامه پرداخت، مهلت صدور و تسویه صورتحساب، پیش‌پرداخت، هزینه ساعت اضافه و پیامد تأخیر باید روشن باشد. پرداخت هزینه سرویس‌های خارجی و اثر تغییر نرخ ارز نیز نیازمند بند جداگانه است.
در قرارداد بلندمدت، روش تعدیل مبلغ را تعریف کنید. تاریخ بازنگری، شاخص یا درصد مورد توافق، سقف و کف تغییر و حق خاتمه در صورت نرسیدن به توافق می‌تواند ابهام را کم کند. عبارت کلی «با توجه به تورم افزایش می‌یابد» برای محاسبه دقیق کافی نیست.
۱۴. مالیات، ارزش افزوده و صورتحساب
مشخص کنید مبلغ شامل مالیات و عوارض قانونی است یا این موارد جداگانه افزوده می‌شوند. مسئول صدور صورتحساب، اطلاعات اقتصادی مورد نیاز و تکلیف ثبت در سامانه مؤدیان نیز متناسب با وضعیت طرفین نوشته شود. قانون مالیات بر ارزش افزوده و قانون پایانه‌های فروشگاهی و سامانه مؤدیان ممکن است بر شیوه صورتحساب خدمات اثر بگذارند.
از درج درصد یا تکلیف ثابت بدون بررسی وضعیت روز خودداری کنید. شخصیت حقیقی یا حقوقی طرفین، مشمول بودن، نوع خدمت و مقررات جاری مهم‌اند. این بخش را پیش از امضا با حسابدار یا مشاور مالیاتی بررسی کنید. اگر کسورات قانونی یا بیمه‌ای در مورد قرارداد شما مطرح است، مسئولیت ارائه مدارک و نحوه کسر و آزادسازی مبلغ را صریح بنویسید.
۱۵. تعهدات کارفرما
- تحویل به‌موقع دسترسی، مستندات و اطلاعات درست
- معرفی نماینده مجاز و پاسخ در زمان لازم برای تأیید تغییر
- پرداخت به‌موقع هزینه قرارداد و سرویس‌های ثالث
- خودداری از تغییر مستقیم سایت بدون اطلاع پشتیبان
- استفاده قانونی از محتوا، نرم‌افزار و داده‌ها
- اعلام فوری رخداد، پیام مشکوک یا تغییر نیروی دارای دسترسی
اگر تأخیر کارفرما مانع انجام تعهد می‌شود، اثر آن بر SLA و زمان تحویل باید مشخص باشد.
۱۶. تعهدات پیمانکار
- اجرای خدمات در محدوده و سطح توافق‌شده
- استفاده از نیروی دارای صلاحیت و رعایت حداقل دسترسی
- ثبت تغییرات و نگهداری مستندات لازم
- اطلاع سریع رخداد امنیتی یا خطر از دست رفتن داده
- دریافت تأیید پیش از تغییر پرریسک یا هزینه‌زا
- ارائه گزارش دوره‌ای و همکاری در تحویل پایان قرارداد
۱۷. معیار پذیرش و گزارش‌دهی
رفع یک باگ زمانی پایان‌یافته است که معیار پذیرش آن برآورده و نتیجه در محیط مناسب آزموده شود. مشخص کنید چه کسی تأیید می‌کند و اگر در مدت معین پاسخی نداد چه اتفاقی می‌افتد. گزارش ماهانه می‌تواند شامل Uptime، رخدادها، زمان پاسخ، بکاپ‌ها، به‌روزرسانی‌ها، ساعات مصرف‌شده و پیشنهادهای ماه بعد باشد.
گزارش باید قابل فهم و قابل ردگیری باشد. ارائه فهرست فعالیت بدون نتیجه، برای ارزیابی SLA کافی نیست.
۱۸. مسئولیت، خسارت و Service Credit
حدود مسئولیت باید متناسب و قابل اجرا باشد. سقف مسئولیت، خسارت مستقیم و غیرمستقیم، تقصیر طرفین، استفاده نادرست از سایت و رخداد ناشی از سرویس ثالث را با مشاور حقوقی تنظیم کنید. بند سلب همه مسئولیت ممکن است تعادل قرارداد را از بین ببرد.
برای نقض SLA می‌توان Service Credit یا جبران خدماتی تعریف کرد، مانند اعتبار در صورتحساب بعدی. روش محاسبه، سقف و فرایند مطالبه باید روشن باشد. جریمه قراردادی نباید جای برنامه واقعی بازیابی را بگیرد.
۱۹. فورس ماژور و شرایط خاص زیرساختی ایران
حوادث خارج از کنترل مانند بلای طبیعی، دستور الزام‌آور حاکمیتی، اختلال گسترده زیرساخت یا قطع سراسری ممکن است اجرای تعهد را مختل کنند. قرارداد باید تعریف رخداد، وظیفه اطلاع‌رسانی، تلاش برای کاهش اثر، تعلیق موقت و حق خاتمه در تداوم طولانی را مشخص کند.
هر اختلال اینترنت یا برق نباید خودکار فورس ماژور تلقی شود. اگر استفاده از زیرساخت جایگزین، UPS، چند مسیر ارتباطی یا سرور پشتیبان جزو تعهد بوده، باید همان تعهد سنجیده شود. محدودیت دسترسی به سرویس‌های خارجی، تحریم، تغییر مقررات و مشکل پرداخت ارزی را نیز با سناریوی جایگزین و تقسیم مسئولیت بنویسید.
۲۰. مدت، تمدید، تعلیق و فسخ
تاریخ شروع و پایان، دوره آزمایشی، تمدید خودکار یا با توافق و مهلت اعلام عدم تمدید مشخص باشد. موارد فسخ مانند عدم پرداخت، نقض محرمانگی، تکرار نقض SLA یا خودداری از تحویل دسترسی تعریف شوند. برای تخلف قابل اصلاح، بهتر است مهلت رفع نقض نیز در نظر گرفته شود.
تعلیق سرویس به دلیل بدهی باید با اخطار، مهلت و استثنای رخدادهای امنیتی تنظیم شود. قطع ناگهانی دسترسی می‌تواند به کسب‌وکار آسیب بزند و خودش منشأ اختلاف شود.
۲۱. برنامه خروج و تحویل پایان همکاری
قرارداد خوب از ابتدا برای پایان همکاری آماده است. فهرست اقلام تحویلی شامل کد، بکاپ، مستندات، رمزها، حساب‌ها، تنظیمات DNS، گزارش رخدادهای باز و لایسنسها باشد. قالب، زمان و هزینه همکاری انتقالی به تیم بعدی را تعیین کنید.
پس از تأیید تحویل، دسترسی پیمانکار لغو و نسخه‌های داده نزد او طبق تعهد قراردادی حذف یا بازگردانده شود. مواردی که به دلیل تکلیف قانونی باید نگهداری شوند، جدا مشخص شوند.
۲۲. حل اختلاف و قانون حاکم
ابتدا مسیر مذاکره و مدت آن را بنویسید. سپس مرجع نهایی را مشخص کنید. اگر داوری انتخاب می‌شود، داور یا روش دقیق انتخاب، محل داوری، هزینه و نحوه جایگزینی داور روشن باشد. نوشتن فقط عبارت «اختلاف از طریق داوری حل می‌شود» ممکن است در زمان اختلاف سؤال‌های تازه بسازد.
اگر دادگاه انتخاب می‌شود، صلاحیت محلی با نظر وکیل بررسی شود. قانون حاکم، نسخه معتبر قرارداد و ترتیب اولویت میان متن اصلی و پیوست‌ها نیز ذکر شود.
۲۳. امضای الکترونیکی و نگهداری سوابق
قانون تجارت الکترونیکی ایران برای داده‌پیام و امضای الکترونیکی قواعدی دارد و ارزش اثباتی سابقه مطمئن را به رسمیت می‌شناسد. اگر قرارداد از راه الکترونیکی امضا می‌شود، هویت امضاکنندگان، نسخه نهایی، زمان امضا و روش نگهداری امن سوابق مشخص باشد.
تأیید تغییرات مهم، صورت‌جلسه‌ها و درخواست‌های هزینه‌زا را نیز در کانالی نگه دارید که تاریخ، فرستنده و محتوای پیام قابل اثبات باشد. پیام‌های پراکنده و قابل حذف، مدیریت اختلاف را دشوار می‌کنند.
پیوست‌های ضروری قرارداد
- پیوست فنی شامل دامنه‌ها، فناوری‌ها، سرویس‌ها و وضعیت اولیه
- جدول دامنه خدمات و موارد خارج از قرارداد
- جدول SLA، اولویت رخداد و مسیر Escalation
- سیاست بکاپ و بازیابی شامل RPO و RTO
- فهرست دسترسیها و افراد مجاز
- تعرفه کار اضافه و فرایند Change Request
- قالب گزارش ماهانه و معیارهای پذیرش
- چکلیست تحویل شروع و پایان همکاری
نشانه‌های خطر پیش از امضا
- استفاده از عباراتی مانند «پشتیبانی کامل» بدون فهرست خدمات
- تضمین Uptime یا امنیت بدون معیار و استثنای روشن
- نبود مسئول مشخص برای بکاپ و آزمون بازیابی
- دسترسی دائمی و نامحدود بدون ثبت و کنترل
- نامشخص بودن مالکیت دامنه، کد و حساب‌های اصلی
- مبلغ بدون تعیین ریال یا تومان و وضعیت مالیات
- فسخ بدون برنامه تحویل و انتقال
- داوری بدون تعیین داور یا روش انتخاب او
جمع‌بندی
قرارداد پشتیبانی سایت زمانی مفید است که انتظارات را به تعهدهای قابل سنجش تبدیل کند. مشخصات طرفین، وضعیت اولیه، دامنه خدمات، SLA، بکاپ، امنیت، مالکیت، مبلغ، مالیات، تغییرات، مسئولیت و پایان همکاری باید روشن باشند. در شرایط ایران، واحد پول، تعدیل قیمت، تعطیلات، صورتحساب الکترونیکی، سرویس خارجی و اختلال زیرساختی اهمیت ویژه دارند.
پیش از امضا، متن را هم‌زمان از سه زاویه فنی، مالی و حقوقی بررسی کنید. پیوست دقیق معمولاً از متن کلی ارزشمندتر است، چون نشان می‌دهد در یک رخداد واقعی چه کسی باید چه کاری را در چه زمانی انجام دهد.
