پشتیبانی سایت چیست؟ بکاپ، امنیت، آپدیت و SLA

پشتیبانی سایت فقط پاسخ‌دادن به پیام «سایت باز نمی‌شود» نیست. پشتیبانی یعنی بعد از انتشار، امنیت، بکاپ، سلامت فنی، به‌روزرسانی و مسیر رسیدگی به خطاها صاحب مشخص داشته باشد. سایتی که ساخته شده اما کسی مسئول نگهداری آن نیست، با اولین خطای افزونه، قطعی درگاه یا تغییر سرویس بیرونی وارد ریسک می‌شود.

جست‌وجوهایی مثل «پشتیبانی سایت چیست»، «پشتیبانی سایت شامل چیست»، «قرارداد پشتیبانی سایت»، «بکاپ سایت» و «SLA پشتیبانی» معمولاً از کارفرمایی می‌آید که می‌خواهد بداند بعد از تحویل تنها می‌ماند یا نه. این راهنما تفاوت پشتیبانی، توسعه و میزبانی را روشن می‌کند و وارد نیت تجاری طراحی سایت نمی‌شود. برای نگهداری پروژه مشخص، ابتدا دامنه و فناوری سایت را بررسی کنید؛ یک قرارداد واحد برای WordPress، فروشگاه و SaaS منطقی نیست.

Security is a process, not a product.

پشتیبانی سایت دقیقاً چیست؟

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

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

بکاپ خوب چه ویژگی‌هایی دارد؟

داشتن یک فایل backup روی همان سروری که سایت اجرا می‌شود، برنامه بازیابی نیست. بکاپ باید در محل جدا، با زمان‌بندی مشخص و با retention مناسب نگه‌داری شود. دیتابیس، فایل‌های آپلودی، تنظیمات و در صورت نیاز secrets باید دامنه پشتیبان‌گیری را تشکیل دهند؛ البته secrets باید رمزنگاری و دسترسی‌شان محدود شود.

بکاپی که restore نشده، فقط یک فرض است. در بازه‌های مشخص یک بازیابی آزمایشی در محیط جدا انجام دهید و زمان بازگشت سرویس را ثبت کنید. برای فروشگاه، موجودی و سفارش‌ها حساس‌اند؛ برای سایت محتوایی، رسانه و دیتابیس اهمیت دارند؛ برای SaaS، نسخه و مهاجرت داده هم باید دیده شود. بکاپ را با git اشتباه نگیرید؛ هرکدام مسئله متفاوتی را حل می‌کنند.

آپدیت امنیتی را چطور انجام دهیم؟

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

امنیت فقط نصب آخرین نسخه نیست. دسترسی ادمین، MFA، سطح دسترسی فایل، SSL، secretها، لاگ و سرویس‌های ثالث هم باید مرور شوند. حسابی که دیگر استفاده نمی‌شود حذف یا غیرفعال شود. اگر سایت داده پزشکی، مالی یا اطلاعات مشتری دارد، نگهداری و دسترسی به backup اهمیت بیشتری پیدا می‌کند.

مانیتورینگ سایت شامل چه چیزهایی است؟

مانیتورینگ باید متناسب با ریسک باشد: در دسترس بودن صفحه اصلی، زمان پاسخ، خطاهای 5xx، سلامت SSL، فضای دیسک، مصرف منابع، صف کارها و در صورت نیاز مسیر ورود یا پرداخت. ابزار تحلیلی و Search Console به فهم رفتار و ایندکس کمک می‌کنند، اما جای health check و لاگ سرور را نمی‌گیرند.

هشدار خوب به اقدام وصل است. «سایت down شد» باید به فرد، کانال و runbook مشخص برسد. هشدار بیش از حد باعث بی‌توجهی می‌شود؛ آستانه‌ها را با داده واقعی تنظیم کنید. بعد از هر رخداد، علت، زمان تشخیص، زمان رفع و اقدام پیشگیرانه را ثبت کنید تا تیم فقط هر ماه همان خطا را خاموش نکند.

SLA پشتیبانی چه چیزهایی را مشخص می‌کند؟

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

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

تحویل سایت به تیم پشتیبانی

تیم پشتیبانی باید نقشه دسترسی‌ها، فناوری، محیط‌ها، روش deploy، jobهای زمان‌بندی‌شده، سرویس‌های ثالث، دامنه، DNS، SSL، بکاپ و مسیر rollback را داشته باشد. بدون این اطلاعات، هر خطا به جست‌وجوی دستی در سرور تبدیل می‌شود. مستندات کوتاه و به‌روز از فایل طولانی که کسی نمی‌خواند مفیدتر است.

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

اشتباهات رایج پشتیبانی سایت

• نگه داشتن بکاپ روی همان سرور اصلی
• آپدیت مستقیم بدون staging یا تست مسیر اصلی
• یکی گرفتن زمان پاسخ با زمان رفع کامل
• نداشتن مالک مشخص برای دامنه و دسترسی‌ها
• ثبت نکردن رخداد و علت ریشه‌ای خطا
• پشتیبانی نامحدود بدون تعریف دامنه و اولویت
• فراموش کردن سرویس‌های ثالث و webhookها

چک‌لیست قرارداد پشتیبانی سایت

1. فناوری، محیط‌ها و دامنه سایت مشخص شده است.
2. بکاپ، retention و تست بازیابی تعریف شده است.
3. مانیتورینگ، هشدار و مسئول رسیدگی مشخص است.
4. سطح شدت رخداد و زمان پاسخ در SLA آمده است.
5. آپدیت امنیتی و روش rollback روشن است.
6. توسعه فیچر و تولید محتوا از پشتیبانی جدا شده‌اند.
7. مالکیت کد، دامنه، هاست و حساب‌های سرویس منتقل شده است.

جمع‌بندی: پشتیبانی یعنی آمادگی قبل از خطا

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

اگر سایت شما بعد از تحویل به برنامه نگهداری، توسعه یا مانیتورینگ نیاز دارد، از خدمات طراحی و توسعه سایت روبینش و فرم تماس شروع کنید. برای سایت موجود، برآورد باید بعد از شناخت فناوری و وضعیت فعلی انجام شود.