پشتیبانی و نگهداری سایت؛ برنامه‌ای که بعد از انتشار لازم دارید

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

سه نوع کار را از هم جدا کنید

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

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

پشتیبان باید قابل بازیابی باشد

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

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

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

سناریوی فرضی: فروشگاهی روزانه سفارش می‌گیرد و یک نفر مسئول بسته‌بندی است. برای این کسب‌وکار، بررسی دسترس‌بودن صفحه اصلی به‌تنهایی کافی نیست. برنامه زیر نقطه شروع مذاکره است و باید با حجم عملیات تغییر کند.

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

تغییر را مستقیم روی نسخه زنده امتحان نکنید

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

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

قبل از انتخاب پشتیبان این موارد را تحویل بگیرید

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

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