مقایسهٔ کامل قرارداد نگهداری سایت؛ کدام برای شما مناسب است؟

اعداد بازار و بازه‌های تعرفه را در راهنمای هزینه و تعرفهٔ قرارداد نگهداری سایت باز کرده‌ایم؛ این‌جا سؤال دیگری را جواب می‌دهیم: کدام مدل قرارداد برای سایت شما درست است. این سؤال مهم‌تر از «چند؟» است، چون مدلِ اشتباه حتی با قیمت مناسب هم گران تمام می‌شود: قراردادی که پاسخ اضطراری ندارد، در ساعت حادثه هزینه می‌سازد؛ و قراردادی که فقط به یک نفر وابسته است، با رفتن او متوقف می‌شود.

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

انواع قرارداد نگهداری سایت و تفاوت اصلی‌شان

چهار مدل رایج را با تعریف روشن شروع کنیم. مدل موردی-ساعتی یعنی بدون تعهد ماهانه؛ هر تغییر یا مشکل، سفارشی جداگانه با نرخ ساعتی. مدل ماهانهٔ ثابت یعنی پوشش مشخصی از کارها — آپدیت، بکاپ، تغییرات محتوایی محدود — در ازای رقم ثابت. مدل اشتراک اتوماسیون‌شده یعنی کارهای تکراری (آپدیت امنیتی طبق سیاست، بکاپ زمان‌بندی‌شده، پایش دسترس‌پذیری) با نرم‌افزار انجام می‌شود و نیروی انسانی برای قضاوت و حوادث می‌ماند. مدل چهارم هم آن چیزی نیست که اسمی رویش نوشته شده: سایت را همان سازنده نگه می‌دارد، بدون قرارداد مکتوب — وابستگی کامل به یک فرد.

تفاوت اصلی مدل‌ها در سه متغیر است. اول پوشش: چه کارهایی داخل قرارداد است و چه کارهایی فاکتور جدا می‌خواهد. دوم سرعت: ساعت پاسخ‌گویی به حادثه — تفاوت بین SLA مکتوب و «ان‌شاءالله فردا» در ساعت سقوط سایت، تعیین‌کننده است. سوم ریسک: وابستگی به یک نفر، وابستگی به یک افزونهٔ بسته، یا پوشش مستندشده. به تجربهٔ ما اکثر نارضایتی‌ها از نداشتنِ جواب مکتوب روی همین سه سؤال می‌آید، نه از بد بودن پشتیبان.

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

مقایسهٔ چهار مدل در یک جدول

چهار مدل را در یک جدول کنار هم بگذاریم؛ ستون ریسک، همان چیزی است که در جلسات امضا کمتر گفته می‌شود:

هیچ مدلی برای همهٔ سایت‌ها بهتر نیست؛ جدول را با نوع سایت بخش چهارم بخوانید.

دو نکتهٔ خوانش جدول: اول، مدل‌ها ترکیب‌شدنی‌اند — سایت‌های بزرگ معمولاً اشتراک اتوماسیون برای پایداری و یک قرارداد موردی برای پروژه‌های خاص دارند. دوم، ریسک مدل موردی با «فهرست قیمت و صف انتظار مکتوب» و ریسک مدل ماهانه با «فهرست بستهٔ پوشش» قابل مدیریت است؛ ریسک مدل وابسته به فرد اما با مذاکره حل نمی‌شود، با مستندسازی و انتقال دسترسی‌ها حل می‌شود.

وقتی چند پیشنهاد کنار هم گذاشتید، نه از ستون قیمت شروع کنید؛ از ستون پوشش. یک برگهٔ سه‌ستونه بسازید — چه کاری پوشش داده شده، در چند ساعت پاسخ می‌دهند، گزارش چی می‌دهند — و برای هر سه ستون امتیاز بدهید. در این حالت دو پیشنهادِ قیمت نزدیک، دیگر یکسان دیده نمی‌شوند: یکی بکاپ روزانه با تست بازگردانی دارد و دیگری وعدهٔ کلی «پشتیبانی کامل». به تجربهٔ ما همین برگهٔ ساده، گفت‌وگوی خرید را از «تخفیف بده» به «پوشش را مقایسه کنیم» تغییر می‌دهد و نتیجه‌اش قراردادی است که شش ماه بعد هم قابل دفاع است.

هفت بند که قرارداد خوب باید داشته باشد

بند اول، دامنهٔ کار مکتوب است: کدام دسته از کارها داخل پوشش‌اند (آپدیت هسته و افزونه‌ها طبق سیاست، تغییرات محتوایی محدود، پایش دسترس‌پذیری) و کدام‌ها جدا فاکتور می‌شوند (طراحی، توسعه، مهاجرت). بند دوم، بکاپ خودکار با بازگردانیِ تست‌شده است؛ بکاپی که هرگز بازیابی نشده، بکاپ نیست — روایتِ خوبِ قرارداد باید بگوید هر چند وقت یک‌بار، کجا ذخیره می‌شود و آخرین تست بازگردانی کی بوده.

بند سوم، توقف اضطراری و SLA است: ساعت پاسخ به حادثه، مسیر تماس اضطراری و نفر جایگزین اگر پشتیبان در دسترس نبود. بند چهارم، snapshot و بازگردانی پیش از تغییرهای بزرگ: پیش از هر آپدیت پرمخاطره، نسخه‌ای قابل برگشت گرفته شود؛ همین یک بند، اکثر آتش‌سوزی‌های پس از آپدیت را خاموش می‌کند. بند پنجم، گزارش ماهانه است — چه شد، چه خطری دیده شد، چه چیزی عقب افتاد — چون بدون گزارش، خریدار هیچ ابزاری برای قضاوت قرارداد ندارد.

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

کدام مدل برای کدام سایت مناسب است؟

انتخاب مدل با سه سؤال شروع می‌شود: در ماه چند تغییر واقعی روی سایت می‌دهید؟ اگر سایت دو ساعت پایین بماند، درآمد و اعتماد چه ضربه‌ای می‌خورد؟ و تیم داخلی‌تان چند ساعت در ماه ظرفیت فنی دارد؟ سایت معرفی‌محورِ کم‌تغییر با این دو جواب اول، مدل موردی می‌خواهد؛ سایت شرکتی با انتشار منظم، ماهانهٔ ثابت با فهرست مکتوب؛ فروشگاه اینترنتی و سایت پربازدید که سقوطش یعنی فروشِ سوخته، اشتراک اتوماسیون‌شده با SLA جدی.

پیشنهادها چارچوب تصمیم‌اند، نه قاعده؛ با سه سؤال ابتدای همین بخش تطبیق دهید.

در ممیزی‌هایمان الگوی پرتکرارِ خراب این است: سایت‌های فروشگاهی با قرارداد موردی — یعنی حساس‌ترین سایت‌ها با کم‌تعهدترین مدل. عکسش هم می‌آید: سایت معرفی‌محورِ بی‌تغییر با ماهانهٔ گران که عملاً فقط بکاپ می‌گیرد. هر دو از ندیدنِ جدول بالا می‌آید؛ مدل را از رفتار سایت انتخاب کنید، نه از عادت یا معرفی دوستان.

اتوماسیون در نگهداری؛ چه چیزی خودکار می‌شود و چه چیزی نه

بخش بزرگی از کارهای نگهداری امروز خودکارشدنی است و صادق بودن دربارهٔ مرزش مهم است. خودکارِ معقول: بکاپ زمان‌بندی‌شده، آپدیت‌های امنیتی طبق سیاست تعریف‌شده، پایش دسترس‌پذیری، snapshot و بازگردانی، و گزارش‌های دوره‌ای. انسانیِ باقی‌مانده: قضاوت سازگاری هر آپدیت با قالب و افزونه‌های خاص سایت، تصمیم معماری و حذف/ادغام صفحات، مدیریت حادثهٔ پیچیده و اولویت‌بندی کارها. قراردادی که می‌گوید «همه‌چیز خودکار می‌شود» یا «همه‌چیز دستی است»، در هر دو حالت از واقعیت فاصله دارد.

همین الگو در سوئیت ویژن‌پرایم اجرا شده است: انتشار خودکار سطح‌بندی‌شده با توقف اضطراری، snapshot و بازگردانی — یعنی ریسک تغییر کنترل‌شده می‌ماند و هر تغییر قابل برگشت است. پلن پیشرو — ۷٫۹ میلیون تومان/ماه (انتشار خودکار + اپراتور) لایهٔ اتوماسیون را با پوشش انسانی اپراتور ترکیب می‌کند؛ همان دو لایه‌ای که در این بخش توضیح دادیم. اگر می‌خواهید قبل از تصمیم، چرخهٔ کار را با چشم ببینید، دموی رایگان پلتفرم همین حالا در دسترس است.

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

اشتباه‌های رایج در خرید و مدیریت قرارداد

پنج اشتباه رایج را جمع کنیم. اول، خرید بر اساس ساعت به‌جای نتیجه: ساعتی ارزان با تأخیر یک‌روزه، گران‌تر از ساعتی گران با پاسخ دو‌ساعته تمام می‌شود. دوم، تست‌نکردن بازگردانی: بکاپِ بی‌تست در روز حادثه شما را نجات نمی‌دهد. سوم، نبودِ شرط خروج و تحویل که رابطه را یک‌طرفه قفل می‌کند. چهارم، واگذاری کامل دسترسی‌ها: حساب ادمین و دامنه باید مال شما بماند. پنجم، امضای قراردادی بدون تعریف گزارش — بعد از سه ماه هیچ‌کس نمی‌داند پول رفته کجا.

یک توصیهٔ اجرایی برای پایان مذاکره: قبل از امضا، از پشتیبان بخواهید یک سناریوی جدولی را روی کاغذ حل کند — «سایت فردا صبح پایین است؛ چه می‌کنید، در چند ساعت، با چه ابزاری؟». جواب این سؤال، صد برابرِ وعده‌های شفاهی گویاست؛ پاسخ منظم و مکتوب، قرارداد واقعی است.

جمع‌بندی

جمع کنیم: قرارداد نگهداری سایت را از رفتار سایت انتخاب کنید — تغییرات ماهانه، حساسیت درآمدی و ظرفیت فنی تیم شما؛ بین چهار مدل، جدول بخش دوم را معیار بگذارید؛ هفت بند (دامنهٔ کار، بکاپ تست‌شده، SLA و توقف اضطراری، snapshot و بازگردانی، گزارش، مالکیت دسترسی، شرط خروج) را قبل از امضا مکتوب کنید و لایهٔ اتوماسیون را از لایهٔ انسانی جدا ببینید. زمینهٔ کامل‌تر خوشه در هاب نگهداری، مهاجرت و خطاها است. به تجربهٔ ما سایت‌هایی که همین هفت بند را دارند، حوادثشان کوتاه‌تر و کم‌هزینه‌تر تمام می‌شود؛ چون پاسخ از قبل طراحی شده، نه در لحظهٔ اضطراب. برای دیدن وضعیت فعلی سایت‌تان، ممیزی رایگان دامنه را شروع کنید و شواهد را در کیس‌های ثبت‌شدهٔ سوئیت ببینید.

رصد ما، رشد شما.