هزینه پشتیبانی سایت؛ Scope، SLA و بودجه سالانه

دو پیشنهاد پشتیبانی سایت ممکن است هر دو «ماهانه» باشند، اما یکی فقط پاسخ به Ticket و دیگری مانیتورینگ، Backup قابل بازیابی، Update با Rollback، On-call و ظرفیت تغییر را بفروشد. مقایسه مبلغ بدون مقایسه Scope شبیه مقایسه قیمت بیمه بدون دیدن پوشش و فرانشیز است.

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

هزینه پشتیبانی سایت شامل چه چیزهایی است؟

در یک قرارداد سالم، هزینه به Work package وصل است، نه عبارت مبهم «پشتیبانی کامل». پنج سبد اصلی را جدا ببینید:

نگهداری، پشتیبانی، توسعه و میزبانی را جدا کنید

مرز مهم است چون «افزودن درگاه جدید» Change/Project است، «رفع اختلال Callback درگاه موجود» می‌تواند Incident باشد و «تغییر متن صفحه» Service request. هر سه را با یک سقف نامحدود قیمت‌گذاری نکنید.

Gate صفر: سایت و مسئولیت‌ها را Inventory کنید

پیش از درخواست قیمت، فهرست دارایی و Owner بسازید. Vendor نمی‌تواند برای چیزی که نمی‌بیند SLA معتبر بدهد.

برای دامنه، Account و Recovery را شخصی یا نزد پیمانکار رها نکنید. منابع Registrant در ICANN روی تمدید، انتقال، اطلاعات تماس و حفاظت دامنه تمرکز دارند؛ جزئیات عملی مالکیت، DNS و Incident نیز در راهنمای مدیریت دامنه آمده است.

Shared responsibility؛ چه کسی دقیقاً چه کاری می‌کند؟

هاست Managed، CDN، توسعه‌دهنده، آژانس، مالک محتوا و Provider درگاه مرزهای متفاوتی دارند. عبارت «امنیت با هاست است» یا «Backup با طراح است» بدون Matrix قابل اتکا نیست.

Class of service؛ همه درخواست‌ها Ticket یکسان نیستند

SLA چیست و چه چیزی نیست؟

SLA فقط «پاسخ زیر ۳۰ دقیقه» نیست. باید Scope، ساعات پوشش، Severity، کانال معتبر، زمان Acknowledge، هدف Restore، Update cadence، Exclusion، Credit/Remedy و روش گزارش را مشخص کند. زمان پاسخ با زمان حل برابر نیست.

Severity را بر اساس اثر تعریف کنید

Severity را Vendor به‌تنهایی بر اساس سختی فنی تعیین نکند؛ اثر کسب‌وکار و کاربر مهم است. یک تغییر یک‌خطی در قیمت می‌تواند Sev-۱ و یک Bug پیچیده در صفحه کم‌استفاده Sev-۳ باشد.

SLO و Error budget؛ بودجه قابلیت اطمینان

«آپ‌تایم ۱۰۰٪» وعده قابل دفاعی نیست. Indicator و Window را تعریف کنید: Availability کدام مسیر، از کدام نقطه، در چه بازه و با چه Exclusionی؟ نمونه سیاست Error budget در Google SRE نشان می‌دهد چگونه مصرف بودجه خطا می‌تواند سرعت Change را محدود کند.

طراحی دقیق SLI/SLO و Alert در راهنمای Observability سایت آمده است.

RPO و RTO؛ Backup با «روزی یک‌بار» کامل نمی‌شود

• RPO: حداکثر داده‌ای که از نظر زمان می‌توانید از دست بدهید.
• RTO: هدف زمانی بازگرداندن خدمت پس از رخداد.
• Retention: چند نقطه بازیابی و برای چه مدت نگه می‌دارید.
• Restore evidence: آخرین بازیابی موفق، زمان و Scope آن.

Backup روی همان حساب و همان Credential، یا Backup بدون آزمون Restore، پوشش ضعیفی است. WordPress در مستند Update رسمی نیز Backup پیش از به‌روزرسانی را توصیه می‌کند. طراحی کامل RPO/RTO، نسخه immutable/offsite و Runbook در راهنمای Backup و Disaster Recovery پوشش داده شده است.

Update و Patch؛ هزینه کلیک روی دکمه نیست

هزینه واقعی Update از Inventory، Release note، Dependency، Backup، Staging، Regression test، Deployment، Verify و Rollback می‌آید. Auto-update می‌تواند برای جزء کم‌ریسک مناسب باشد، اما نیازمند Backup، Alert شکست و سیاست Rollback است. مستند رسمی Auto-update وردپرس نیز بر Backup و امکان بازگشت تأکید دارد.

Workflow ریسک‌محور Update وردپرس در راهنمای Staging و Rollback آمده است.

امنیت؛ کدام فعالیت داخل Retainer است؟

بودجه امنیت باید از Exposure و Residual risk بیاید؛ چارچوب آن در راهنمای بودجه امنیت سایت است. «اسکن افزونه نصب است» Evidence کافی برای امنیت نیست.

Monitoring؛ Ping سبز معادل سایت سالم نیست

سه سطح را جدا کنید: دسترس‌پذیری URL، Synthetic journey و Telemetry داخلی. Homepage ۲۰۰ ممکن است در حالی سبز باشد که Login، Search یا Payment شکسته است.

Performance و Core Web Vitals؛ پروژه یا نگهداری؟

پایش Regression و رفع تغییر کوچک می‌تواند داخل Maintenance باشد؛ بازطراحی Theme، مهاجرت Media pipeline یا Refactor JavaScript پروژه جداست. قرارداد باید Budget و Threshold بدهد، نه جمله «سرعت سایت تضمین می‌شود».

برای LCP/INP/CLS، Field data، RUM، Attribution و Regression gate به راهنمای Core Web Vitals مراجعه کنید.

SEO فنی و سلامت محتوا در قرارداد نگهداری

Maintenance window؛ سایت را بی‌دلیل از دسترس خارج نکنید

برای Change کوتاه، Blue/green، rolling، Read-only یا محدودکردن قابلیت معمولاً بهتر از خاموشی کامل است. اگر توقف کوتاه اجتناب‌ناپذیر شد، راهنمای رسمی Google Search برای تعطیلی بسیار کوتاه از پاسخ ۵۰۳، صفحه سبک و Retry-After صحبت می‌کند و بستن طولانی کل سایت را توصیه نمی‌کند.

تغییر کوچک یعنی چه؟ واحد ظرفیت بسازید

عبارت «تغییرات جزئی رایگان» محل اختلاف است. تعریف کنید چه چیزی با چه سقف Effort/Risk، بدون Discovery، Design یا Migration در Capacity ماهانه جا می‌گیرد.

مدل‌های قیمت‌گذاری پشتیبانی سایت

عوامل افزایش یا کاهش هزینه پشتیبانی

فرمول بودجه سالانه نگهداری سایت

بودجه سالانه =
تمدید دارایی‌ها و سرویس‌های ثابت
+ مصرف زیرساخت و سرویس‌های متغیر
+ عملیات پیشگیرانه و گزارش
+ ظرفیت Support و Change
+ On-call / پوشش خارج ساعات
+ Assurance دوره‌ای (امنیت، DR، Performance)
+ ذخیره ریسک و Incident
+ مالیات، کارمزد و هزینه پرداخت/ارز
+ هزینه Exit یا Transition برنامه‌ریزی‌شده

برای مقایسه، تمام Quoteها را به یک Window دوازده‌ماهه تبدیل کنید. «ماه اول رایگان»، Setup، حداقل مصرف، ساعت منقضی، Overage، تعطیلات، مالیات و تمدید ارزی را پنهان نکنید.

Budget worksheet قابل پرکردن

ذخیره ریسک را با سناریو بسازید

Reserve درصد دلخواه نیست. سناریوهای محتمل را ثبت کنید: خرابی Storage، انقضای دامنه، Plugin abandon، افزایش مصرف، اختلال درگاه، Incident امنیتی یا نیاز اضطراری به Migration.

Expected annual exposure (برای برنامه‌ریزی) =
Σ احتمال سناریو در بازه × هزینه پاسخ/بازیابی سناریو

Reserve decision ≠ expected value alone
Tail risk، cash tolerance، insurance و control strength را نیز ببینید.

هزینه اختلال را چگونه برآورد کنیم؟

Revenue کل سایت را بر دقیقه تقسیم نکنید مگر Seasonality، Margin و مسیر اثر واقعاً همان باشد. هدف عدد نمایشی نیست؛ تصمیم درباره Control و SLA است.

سه سطح خدمت نمونه—بدون قیمت ثابت

این جدول Package فروش نیست؛ نقطه شروع Requirement است. هر کسب‌وکار ممکن است ترکیب متفاوتی بخواهد.

نمونه ایرانی: فروشگاه WooCommerce با درگاه و پیامک

فرض کنید فروشگاه ایرانی سفارش روزانه، یک درگاه، SMS، حسابداری Export و کمپین‌های پیک دارد. قیمت باید حداقل این Workload را ببیند:

اگر دو Vendor مبلغ متفاوت می‌دهند، Compare باید روی همین Scope، ساعات پوشش و Evidence باشد؛ نه روی نام Package.

ملاحظات قیمت‌گذاری در ایران

• در Quote صریح بنویسید مبلغ به ریال است یا تومان؛ نمایش جداگانه مالیات و کارمزد را بخواهید.
• تاریخ اعتبار پیشنهاد، دوره تعدیل دستمزد و مبنای سرویس ارزی را مشخص کنید؛ «نرخ روز» بدون Source و زمان Settlement مبهم است.
• Eligibility، Terms، روش پرداخت و امکان تمدید سرویس خارجی را دوره‌ای بررسی کنید؛ با هویت یا پرداخت جعلی محدودیت را دور نزنید.
• مالک Domain، Hosting، CDN، Repo، Analytics و License سازمان باشد یا دست‌کم انتقال‌پذیری قراردادی و آزموده داشته باشد.
• اختلال اپراتور/ISP، SMS، Email و Gateway را در Synthetic و Runbook بگنجانید.
• Backup را از Provider/Account/Region اصلی جدا و هزینه Restore/egress را پیشاپیش بررسی کنید.
• تقویم شمسی/میلادی، تعطیلات و ساعات On-call تهران را در SLA صریح کنید.

چطور سه پیشنهاد قیمت را منصفانه مقایسه کنیم؟

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

1. Scope دقیق هر ماه و Exclusionها چیست؟
2. پاسخ، Restore و Resolution چگونه اندازه‌گیری می‌شوند؟
3. چه کسی On-call است و تعطیلات/خارج ساعت چگونه قیمت دارد؟
4. آخرین Restore test و نمونه گزارش Incident چیست؟
5. Update با چه Staging، Test و Rollback انجام می‌شود؟
6. ساعت/ظرفیت استفاده‌نشده، Overage و کار اضطراری چه قاعده‌ای دارند؟
7. Credentialها کجا نگهداری و دسترسی Vendor چگونه ثبت/لغو می‌شود؟
8. دامنه، حساب، Repo، داده، License و Artifact متعلق به چه کسی است؟
9. در پایان قرارداد انتقال دانش و تحویل چه خروجی‌هایی دارد؟
10. قیمت، مالیات، ریال/تومان، ارز و تعدیل چگونه نوشته می‌شود؟

گزارش ماهانه باید Evidence بدهد

WordPress Site Health برای وضعیت Update، Runtime و پیکربندی سیگنال مفیدی است، اما جای Synthetic، Restore test، Security assessment یا Business journey را نمی‌گیرد.

تقویم نگهداری ریسک‌محور

Frequency نسخه واحد ندارد؛ فروشگاه پرتراکنش با سایت بروشوری متفاوت است. Trigger رخداد/Release گاهی مهم‌تر از تقویم است.

Exit plan؛ پشتیبانی خوب قابلیت خروج دارد

طراحی ارزان اگر Repository، Test، Documentation و Ownership را حذف کند، هزینه را فقط به دوره نگهداری منتقل کرده است. این Trade-off در راهنمای کاهش هزینه طراحی بدون افت کیفیت باز شده است.

چهار Runbook مالی و عملیاتی

۱. تمدید در خطر

Expiry/Owner/Payment را تأیید کنید؛ مسیر پرداخت قانونی جایگزین و Grace period واقعی Provider را بررسی کنید؛ Auto-renew را به‌تنهایی Evidence ندانید؛ پس از تمدید Expiry و DNS/TLS را مستقل Verify کنید.

۲. Incident خارج از Scope

ابتدا اثر را مهار کنید؛ سپس مرز Scope و نرخ اضطراری را شفاف اعلام کنید. بحران را برای مذاکره مبهم رها نکنید؛ Approval و سقف هزینه کوتاه‌مدت بگیرید و پس از Restore Change/contract gap را اصلاح کنید.

۳. مصرف یا صورتحساب غیرعادی

مصرف را به Resource/Tenant/Feature وصل کنید؛ Leak/attack/campaign/plan change را جدا کنید؛ سقف و Alert را اعمال کنید؛ قبل از کوچک‌کردن ظرفیت، SLO و Peak را بسنجید.

۴. انتقال پیمانکار

Access freeze و Inventory snapshot بگیرید؛ حساب/Repo/Backup/Runbook/Risk را با Acceptance تحویل دهید؛ Credential را Rotate کنید؛ استقرار و Restore را با تیم جدید تمرین و فقط بعد Vendor قبلی را revoke کنید.

برنامه ۳۰روزه ساخت بودجه و قرارداد

چک‌لیست نهایی هزینه پشتیبانی سایت

• دارایی، Owner، Expiry، Account و Business journey فهرست شده‌اند.
• Hosting، Maintenance، Support، Development، Content و SEO مرز دارند.
• Incident، Request، Problem، Change و Project جدا هستند.
• Severity بر اثر کاربر/کسب‌وکار تعریف شده است.
• ساعات پوشش، Acknowledge/Response/Restore/Resolution و Update cadence روشن‌اند.
• SLO/SLI، RPO/RTO/Retention و آخرین Restore evidence ثبت شده‌اند.
• Update شامل Backup/Staging/Test/Verify/Rollback است.
• Monitoring مسیر حیاتی را می‌سنجد، نه فقط Ping Homepage.
• ظرفیت Change، Overage، انقضای ساعت و کار اضطراری قاعده دارند.
• بودجه سالانه، Reserve، Tax، FX، ریال/تومان و تاریخ اعتبار معلوم‌اند.
• گزارش ماهانه Evidence و Owner اقدام بعدی دارد.
• Account/Domain/Repo/Data/License و Exit در مالکیت/کنترل سازمان‌اند.

جمع‌بندی: قیمت را به تعهد و مدرک وصل کنید

پشتیبانی ارزان اگر Backup بازیابی‌نشده، پاسخ بدون Restore، Update بدون Rollback و دسترسی بدون Exit داشته باشد، ممکن است گران‌ترین گزینه باشد. در مقابل، Retainer بزرگ هم بدون Scope و Evidence ارزش را ثابت نمی‌کند.

با یک Brief واحد از Vendorها قیمت بگیرید: Inventory، مسیر حیاتی، Coverage، Severity، RPO/RTO، ظرفیت تغییر و Report. اگر برای ساخت همین Baseline و مقایسه پیشنهادها کمک می‌خواهید، درخواست مشاوره مایندیو را با نوع سایت، Stack، ترافیک، ساعات پوشش و سه مشکل پرتکرار ثبت کنید.

پرسش‌های متداول

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

عدد معتبر بدون Scope ممکن نیست. نوع سایت، Business criticality، Stack، Integration، ساعات پوشش، SLA، RPO/RTO، ظرفیت تغییر و On-call قیمت را می‌سازند. همه Quoteها را با مالیات، ارز، Overage و Reserve به هزینه دوازده‌ماهه تبدیل کنید.

آیا هاست و دامنه داخل هزینه پشتیبانی سایت هستند؟

فقط اگر قرارداد صریح بگوید. حتی در Managed service بهتر است مالک قانونی Account و Domain سازمان باشد و Vendor نقش اجرایی داشته باشد. مبلغ تمدید، مصرف، مالیات و روش پرداخت را جدا نمایش دهید.

تفاوت زمان پاسخ و زمان رفع مشکل چیست؟

زمان پاسخ یعنی Ticket دیده، Severity تعیین و اقدام شروع شده است. Restore یعنی خدمت با Workaround یا Rollback برگشته و Resolution یعنی اصلاح پایدار Verify شده است. قرارداد باید هر سه را جدا کند.

آیا Backup روزانه برای پشتیبانی کافی است؟

نه لزوماً. تناوب باید از RPO بیاید و ارزش Backup با Restore test، Retention، جداسازی Provider/Account، Encryption، Access و RTO اثبات شود. فروشگاه پرتراکنش ممکن است RPO بسیار کوتاه‌تری از سایت معرفی بخواهد.

چطور شرکت پشتیبانی سایت را انتخاب کنیم؟

سه پیشنهاد را با Brief یکسان و Matrix سالانه مقایسه کنید: Coverage/SLA، Included capacity، Backup/Restore، Monitoring، Update/Rollback، Security boundary، Report، Ownership و Exit. نمونه گزارش و Evidence واقعی مهم‌تر از نام Package است.