برای کاهش تاثیر اختلال اینترنت روی سایت چه زیرساختی انتخاب کنیم؟

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

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

بنابراین برای کاهش تاثیر اختلال اینترنت باید تمام زنجیره فنی سایت بررسی شود؛ از دستگاه کاربر و شبکه ارائه دهنده اینترنت گرفته تا DNS، CDN، سرور اصلی، دیتابیس، درگاه پرداخت، سرویس پیامک و نسخه های پشتیبان.

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

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

منظور از اختلال اینترنت چیست؟

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

برای طراحی زیرساخت مناسب باید مشخص کنیم قصد داریم در برابر چه نوع اختلالی مقاومت کنیم.

اختلال شبکه کاربران

ممکن است کاربران یک اپراتور یا ارائه دهنده اینترنت نتوانند به بعضی مسیرها متصل شوند، در حالی که سایت برای کاربران شبکه های دیگر در دسترس است.

اختلال مسیرهای بین المللی

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

اختلال دیتاسنتر یا سرور اصلی

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

اختلال DNS

اگر DNS دامنه پاسخ ندهد، مرورگر نمی تواند آدرس دامنه را به IP سرور تبدیل کند. در این شرایط ممکن است سرور کاملا سالم باشد اما کاربران نتوانند سایت را باز کنند.

اختلال سرویس های جانبی

درگاه پرداخت، پیامک، ایمیل، نقشه، فونت، CDN، سرویس لایسنس، API، سیستم آمارگیری یا فضای ویدیو ممکن است جدا از سایت دچار مشکل شوند.

حمله یا مصرف غیرعادی منابع

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

چرا فقط انتخاب هاست ایران یا خارج کافی نیست؟

یک صفحه وردپرسی ممکن است برای نمایش کامل به چندین سرویس وابسته باشد. HTML اصلی از سرور وردپرس دریافت می شود، اما تصاویر، فونت ها، اسکریپت ها، نقشه، ویدیو و اطلاعات داینامیک می توانند از دامنه های دیگری بارگذاری شوند.

یک فروشگاه اینترنتی نیز برای تکمیل سفارش به سرویس های بیشتری نیاز دارد:

• سرور وردپرس و ووکامرس
• پایگاه داده سفارش ها
• درگاه پرداخت
• وب سرویس حمل و نقل
• سامانه پیامک
• سرویس ارسال ایمیل
• سیستم حسابداری یا انبار
• API تامین کننده محصولات
• DNS و CDN

در دسترس بودن صفحه اصلی به معنی سالم بودن تمام فرایند خرید نیست. ممکن است محصولات نمایش داده شوند اما پرداخت، ارسال پیامک یا ثبت اطلاعات در سیستم جانبی انجام نشود.

به همین دلیل باید دسترسی سایت را در سه سطح جداگانه بررسی کرد:

• نمایش سایت: آیا صفحات عمومی باز می شوند؟
• عملکرد سایت: آیا فرم، ورود، جستجو و سبد خرید کار می کنند؟
• تکمیل عملیات تجاری: آیا پرداخت، ایمیل، پیامک و همگام سازی اطلاعات انجام می شوند؟

نقشه وابستگی های سایت را تهیه کنید

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

بخش زیرساخت	نمونه کاربرد	تاثیر اختلال
DNS	تبدیل دامنه به IP	ممکن است کل سایت با دامنه باز نشود
سرور اصلی	اجرای وردپرس و PHP	صفحات داینامیک از دسترس خارج می شوند
دیتابیس	محتوا، کاربر و سفارش	ورود، خرید و مدیریت اطلاعات مختل می شود
CDN	تصاویر و فایل های ثابت	ظاهر سایت ناقص یا کند می شود
درگاه پرداخت	تکمیل سفارش	کاربر نمی تواند پرداخت کند
سرویس پیامک	کد ورود و اطلاع رسانی سفارش	ورود یا تایید شماره ممکن است متوقف شود
سرویس ایمیل	بازیابی رمز و اعلان سفارش	پیام های ضروری ارسال نمی شوند
API خارجی	نرخ ارز، CRM یا هوش مصنوعی	بخشی از سایت یا پردازش ها متوقف می شوند
فونت و اسکریپت خارجی	ظاهر و عملکرد رابط کاربری	صفحه ناقص یا کند نمایش داده می شود
بکاپ	بازیابی پس از خرابی	امکان بازگرداندن سایت محدود می شود

پس از تهیه این فهرست، سرویس ها را بر اساس اهمیت تقسیم بندی کنید:

• حیاتی: بدون آن ها فعالیت اصلی سایت ممکن نیست.
• مهم: اختلال آن ها بخشی از تجربه کاربر را خراب می کند.
• غیرحیاتی: نبود موقت آن ها مانع فعالیت اصلی نمی شود.

سرور اصلی را بر اساس کاربران و وابستگی ها انتخاب کنید

برای سایتی که کاربران، درگاه پرداخت، سامانه پیامک و خدمات اصلی آن داخل ایران هستند، سرور ایران می تواند مسیر مناسبی ایجاد کند. برای سایت بین المللی یا پروژه وابسته به سرویس های خارجی، سرور اروپا یا خارج نیز قابل بررسی است.

اما انتخاب محل سرور باید همراه با این سوال ها انجام شود:

• بیشتر کاربران در چه کشور یا شبکه ای هستند؟
• کدام سرویس های خارجی برای سایت حیاتی هستند؟
• ارتباط سرور با درگاه پرداخت و پیامک چگونه است؟
• آیا کاربران خارج از ایران بخش مهمی از مخاطبان هستند؟
• نسخه های پشتیبان در چه موقعیتی نگهداری می شوند؟
• آیا امکان انتقال یا راه اندازی سرور جایگزین وجود دارد؟

هیچ شرکت یا موقعیت سروری نمی تواند دسترسی سایت را در تمام انواع اختلال تضمین کند. ادعاهایی مانند «دسترسی صد درصد در زمان قطعی اینترنت» باید با احتیاط بررسی شوند.

DNS چه نقشی در پایداری سایت دارد؟

DNS یکی از اولین بخش هایی است که کاربر برای باز کردن سایت به آن نیاز دارد. اگر Name Serverهای دامنه پاسخ ندهند، کاربر حتی به مرحله اتصال به هاست نمی رسد.

برای کاهش ریسک DNS این موارد را بررسی کنید:

• استفاده از حداقل دو Name Server مستقل
• قرار داشتن Name Serverها روی زیرساخت پایدار
• امکان تغییر سریع رکوردهای DNS
• فعال بودن مانیتورینگ DNS
• مدیریت مقدار TTL پیش از تغییرات زیرساخت
• در اختیار داشتن دسترسی مالک دامنه و پنل DNS
• وابسته نبودن کامل دامنه، هاست و DNS به یک حساب غیرقابل دسترس

TTL چیست و چرا اهمیت دارد؟

TTL مشخص می کند پاسخ DNS تا چه مدت در حافظه کش باقی بماند. اگر TTL بسیار بالا باشد، تغییر IP سایت ممکن است دیرتر به کاربران برسد. اگر بسیار پایین باشد، تعداد درخواست های DNS افزایش پیدا می کند.

قبل از مهاجرت برنامه ریزی شده یا فعال کردن سرور جایگزین می توان TTL را از قبل کاهش داد. کاهش TTL درست در لحظه خرابی همیشه نتیجه فوری ایجاد نمی کند؛ زیرا پاسخ قبلی ممکن است همچنان در کش کاربران و ارائه دهندگان اینترنت باقی مانده باشد.

DNS جایگزین به تنهایی کافی نیست

داشتن دو DNS مستقل می تواند ریسک خرابی سرویس نام دامنه را کاهش دهد، اما اگر هر دو رکورد به همان سرور از دسترس خارج شده اشاره کنند، سایت همچنان قابل استفاده نخواهد بود.

DNS مقاوم باید در کنار سرور سالم، مانیتورینگ و برنامه بازیابی استفاده شود.

CDN چگونه می تواند تاثیر اختلال را کاهش دهد؟

CDN نسخه ای از فایل های قابل کش سایت را در چند نقطه شبکه نگهداری می کند. تصاویر، CSS، JavaScript و بعضی صفحات عمومی می توانند از نزدیک ترین نقطه قابل دسترس به کاربر تحویل داده شوند.

مزایای احتمالی CDN عبارتند از:

• کاهش فشار روی سرور اصلی
• تحویل سریع تر فایل های ثابت
• مقاومت بهتر در برابر افزایش ناگهانی ترافیک
• فیلتر کردن بخشی از ترافیک مخرب
• امکان نمایش نسخه کش شده بعضی صفحات
• پنهان کردن IP سرور اصلی در تنظیمات مناسب

CDN چه مشکلاتی را حل نمی کند؟

CDN نمی تواند تمام بخش های وردپرس را هنگام خاموش بودن سرور اصلی فعال نگه دارد. صفحات زیر معمولا داینامیک هستند:

• سبد خرید
• تسویه حساب
• حساب کاربری
• پیشخوان وردپرس
• جستجوی پیشرفته
• فیلترهای داینامیک
• فرم های ثبت اطلاعات
• پنل دانشجو یا کاربر

ممکن است CDN بتواند نسخه کش شده صفحه معرفی یا مقاله را نمایش دهد، اما ثبت سفارش و ورود کاربران همچنان به سرور اصلی و دیتابیس نیاز دارند.

همچنین اگر کاربران به خود شبکه CDN دسترسی مناسبی نداشته باشند، فعال بودن CDN نمی تواند مشکل مسیر آن ها را برطرف کند.

قوانین کش را برای ووکامرس درست تنظیم کنید

در فروشگاه ووکامرسی نباید صفحات سبد خرید، تسویه حساب و حساب کاربری مانند صفحات عمومی کش شوند. کوکی های ووکامرس و پاسخ های شخصی سازی شده نیز باید در تنظیمات کش در نظر گرفته شوند.

تنظیم اشتباه CDN ممکن است باعث نمایش سبد خرید یک کاربر به کاربر دیگر، نمایش قیمت قدیمی یا ایجاد خطا در فرایند پرداخت شود.

نسخه اضطراری یا Static سایت چیست؟

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

نسخه اضطراری می تواند شامل این موارد باشد:

• نام و معرفی کوتاه کسب و کار
• شماره تماس و راه ارتباطی
• پیام مربوط به اختلال موقت
• وضعیت سفارش ها یا خدمات
• آدرس شعب یا مراکز پشتیبانی
• زمان احتمالی بررسی بعدی بدون وعده قطعی

این صفحه نباید به منابع خارجی غیرضروری وابسته باشد. فونت، CSS و تصاویر اصلی آن بهتر است همراه خود صفحه میزبانی شوند.

نسخه ثابت امکان ورود، ثبت سفارش یا دریافت اطلاعات داینامیک را ندارد، اما می تواند ارتباط اولیه با کاربران را حفظ کند.

سرور جایگزین و Failover چگونه کار می کند؟

در معماری Failover، یک سرور یا زیرساخت ثانویه برای زمان خرابی سرویس اصلی آماده می شود. سیستم مانیتورینگ سلامت سرور اصلی را بررسی می کند و در صورت تشخیص مشکل، ترافیک به مقصد سالم هدایت می شود.

دو مدل رایج وجود دارد:

Active-Passive

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

Active-Active

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

چالش اصلی Failover وردپرس چیست؟

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

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

به همین دلیل راه اندازی Failover کامل برای وردپرس و ووکامرس بسیار پیچیده تر از قرار دادن یک نسخه کپی از فایل ها روی سرور دوم است.

آیا داشتن دو هاست در ایران و خارج کافی است؟

خرید دو هاست بدون برنامه همگام سازی و تغییر مسیر، زیرساخت مقاوم ایجاد نمی کند. باید مشخص شود:

• فایل ها چگونه میان دو سرور همگام می شوند؟
• دیتابیس هر چند وقت یک بار کپی می شود؟
• کدام سرور اجازه ثبت اطلاعات دارد؟
• تغییر DNS یا مسیر ترافیک چگونه انجام می شود؟
• چه کسی خرابی را تشخیص می دهد؟
• بازگشت از سرور دوم به سرور اصلی چگونه انجام می شود؟
• از ایجاد سفارش یا اطلاعات تکراری چگونه جلوگیری می شود؟

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

وابستگی سایت به APIهای خارجی را کاهش دهید

وردپرس و افزونه ها می توانند از طریق درخواست HTTP به سرویس های خارجی متصل شوند. این ارتباط در قابلیت هایی مانند نرخ ارز، نقشه، CRM، لایسنس، هوش مصنوعی، همگام سازی محصولات و ارسال اطلاعات فرم استفاده می شود.

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

راهکارهای کاهش تاثیر API خارجی

• برای درخواست ها Timeout مشخص در نظر بگیرید.
• نتیجه اطلاعات غیرحیاتی را کش کنید.
• از اجرای هم زمان درخواست غیرضروری در زمان باز شدن صفحه خودداری کنید.
• برای عملیات مهم صف و تلاش مجدد ایجاد کنید.
• خطای سرویس خارجی را بدون متوقف کردن کل سایت مدیریت کنید.
• مقدار آخر معتبر را در صورت امکان نگهداری کنید.
• وضعیت اتصال API را مانیتور کنید.
• برای سرویس حیاتی، راهکار جایگزین داشته باشید.

قابلیت سایت را به شکل Graceful Degradation طراحی کنید

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

در یک افزونه اختصاصی وردپرس نیز باید خطاهای شبکه، پاسخ نامعتبر و Timeout به صورت کنترل شده مدیریت شوند.

فونت، JavaScript و فایل های خارجی را بررسی کنید

بعضی سایت ها فونت، کتابخانه JavaScript، آیکن، CSS و تصویر را مستقیما از دامنه های خارجی بارگذاری می کنند. اگر آن دامنه در دسترس نباشد، ظاهر یا عملکرد صفحه ناقص می شود.

برای فایل های ضروری می توانید این راهکارها را بررسی کنید:

• میزبانی فونت های مجاز روی هاست خود سایت
• حذف کتابخانه های خارجی غیرضروری
• استفاده از نسخه محلی فایل های مورد نیاز
• تعریف فونت جایگزین سیستمی
• جلوگیری از وابستگی عملکرد اصلی به ابزار آمارگیری
• لود غیرهم زمان اسکریپت های غیرحیاتی

قبل از میزبانی محلی هر فایل باید مجوز استفاده و شرایط لایسنس آن بررسی شود.

نقشه، ویدیو و ابزارهای Embed شده

نقشه، ویدیو، فرم و ویجت خارجی معمولا با iframe یا JavaScript داخل سایت نمایش داده می شوند. قطع سرویس خارجی ممکن است فضای خالی، خطا یا تاخیر طولانی ایجاد کند.

برای بخش های مهم، یک حالت جایگزین طراحی کنید:

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

درگاه پرداخت در زمان اختلال اینترنت

نمایش فروشگاه بدون امکان پرداخت برای بسیاری از کسب و کارها کافی نیست. ارتباط با درگاه پرداخت باید از سمت کاربران و سرور سایت قابل دسترس باشد.

هنگام طراحی فرایند پرداخت این موارد را در نظر بگیرید:

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

اگر امکان استفاده قانونی و قراردادی از چند درگاه وجود دارد، داشتن مسیر پرداخت جایگزین می تواند ریسک وابستگی به یک ارائه دهنده را کاهش دهد.

سامانه پیامک و ورود با کد یک بار مصرف

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

برای کاهش این وابستگی می توان بر اساس سطح امنیت پروژه راهکارهای زیر را بررسی کرد:

• امکان ورود با رمز عبور در کنار کد پیامکی
• ارسال کد از بیش از یک مسیر مورد تایید
• محدودیت و کنترل تلاش های ورود
• نمایش پیام واضح هنگام اختلال سرویس
• امکان بازیابی حساب از روش امن دیگر
• صف بندی پیام های غیرحیاتی برای ارسال بعدی

نباید برای حفظ دسترسی، امنیت ورود کاربران کاهش پیدا کند. مسیر جایگزین باید همچنان احراز هویت مناسبی داشته باشد.

ایمیل های تراکنشی را از ایمیل عمومی جدا کنید

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

موارد زیر را بررسی کنید:

• تنظیم صحیح SPF، DKIM و DMARC
• امکان اتصال هاست به SMTP
• ثبت لاگ ایمیل های ارسال شده
• صف بندی و تلاش مجدد در صورت خطا
• جدا کردن خبرنامه از ایمیل تراکنشی
• داشتن راه ارتباطی جایگزین برای پیام های حیاتی

WP-Cron و پردازش های زمان بندی شده

وردپرس برای اجرای بسیاری از وظایف زمان بندی شده از WP-Cron استفاده می کند. ارسال ایمیل، انتشار نوشته، پردازش صف، تمدید اشتراک و بعضی عملیات ووکامرس می توانند به اجرای Cron وابسته باشند.

WP-Cron در حالت عادی با بازدید سایت فعال می شود. اگر سایت بازدید نداشته باشد یا درخواست داخلی وردپرس با مشکل روبرو شود، بعضی وظایف ممکن است با تاخیر اجرا شوند.

برای سایت های مهم می توان WP-Cron داخلی را غیرفعال و یک Cron واقعی روی سرور تنظیم کرد. این کار باید توسط فرد فنی و با فاصله زمانی متناسب انجام شود.

همچنین باید صف های ووکامرس، Action Scheduler و وظایف ناموفق به صورت دوره ای بررسی شوند.

بکاپ مستقل مهم تر از نام شرکت هاستینگ است

بکاپ فقط زمانی ارزش دارد که سالم، به روز و قابل بازیابی باشد. نگهداری تمام نسخه ها روی همان سرور اصلی ریسک بالایی ایجاد می کند.

یک برنامه مناسب بکاپ باید این بخش ها را پوشش دهد:

• فایل های وردپرس
• پوشه رسانه و فایل های آپلودی
• دیتابیس
• تنظیمات سرور و DNS
• اطلاعات ایمیل در صورت میزبانی روی همان سرویس
• کلیدها و تنظیمات سرویس های خارجی
• نسخه قالب و پلاگین اختصاصی

RPO چیست؟

RPO مشخص می کند از دست رفتن چه مقدار از آخرین اطلاعات برای کسب و کار قابل قبول است. اگر RPO یک ساعت باشد، بکاپ هفتگی پاسخگوی پروژه نیست.

RTO چیست؟

RTO مدت زمانی است که برای بازگرداندن سایت پس از خرابی قابل قبول است. داشتن بکاپ بدون سرور جایگزین، دسترسی ها و دستورالعمل بازیابی ممکن است RTO را بسیار طولانی کند.

بکاپ را آزمایش کنید

دانلود موفق فایل بکاپ به معنی قابل بازیابی بودن آن نیست. باید به صورت دوره ای نسخه ای از سایت در محیط آزمایشی بازیابی و بررسی شود.

برای سایت فروشگاهی، فاصله زمانی بکاپ دیتابیس باید کوتاه تر از سایت شرکتی باشد؛ زیرا سفارش ها و اطلاعات کاربران دائما تغییر می کنند.

مانیتورینگ از چند موقعیت انجام دهید

اگر مانیتور فقط از یک کشور یا یک شبکه سایت را بررسی کند، ممکن است اختلال کاربران دیگر را تشخیص ندهد.

برای سایت مهم، مانیتورینگ می تواند این موارد را شامل شود:

• دسترسی HTTP و HTTPS
• زمان پاسخ سرور
• اعتبار گواهی SSL
• پاسخ DNS
• صفحه ورود یا API حیاتی
• فرایند آزمایشی خرید
• وضعیت Cron و صف پردازش
• مصرف CPU، RAM و فضای دیسک
• خطاهای PHP و دیتابیس

هشدارها باید به مسیری ارسال شوند که در زمان اختلال قابل دسترس باشد. وابسته بودن تمام هشدارها به یک پیام رسان یا سرویس، ریسک دیگری ایجاد می کند.

صفحه وضعیت خدمات ایجاد کنید

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

بهتر است صفحه وضعیت روی زیرساختی مستقل از سایت اصلی قرار بگیرد. اگر صفحه وضعیت روی همان سرور خراب میزبانی شود، هنگام نیاز قابل استفاده نخواهد بود.

اطلاعات صفحه وضعیت باید واضح و بدون ادعای غیرقابل اثبات باشد:

• کدام سرویس دچار اختلال است؟
• مشکل از چه زمانی شروع شده است؟
• چه بخش هایی همچنان فعال هستند؟
• راه ارتباطی جایگزین چیست؟
• آخرین به روز رسانی چه زمانی انجام شده است؟

تاثیر قطعی سایت بر سئو

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

اگر سایت به صورت موقت در دسترس نیست، سرور باید وضعیت مناسب HTTP برگرداند. برای توقف موقت، پاسخ 503 Service Unavailable همراه با Retry-After می تواند به خزنده ها اعلام کند که مشکل موقتی است.

نمایش صفحه خطا با کد 200 ممکن است باعث شود موتور جستجو همان صفحه را به عنوان محتوای اصلی دریافت کند. پاسخ 404 نیز بیان می کند که صفحه پیدا نشده است و برای خرابی موقت انتخاب درستی نیست.

استفاده طولانی مدت از 503 نیز راه حل دائمی نیست. پس از بازگشت سایت، باید پاسخ صفحات دوباره 200 و محتوای اصلی قابل دریافت باشد.

در زمان اختلال چه مواردی را در Search Console بررسی کنیم؟

• گزارش Page Indexing
• Server Errorها
• آمار Crawl Stats
• وضعیت نقشه سایت
• URL Inspection صفحات مهم
• افت ناگهانی صفحات Crawl شده

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

امنیت را برای افزایش دسترسی قربانی نکنید

در زمان اختلال ممکن است وسوسه شوید تمام فایروال ها، بررسی ها و محدودیت ها را غیرفعال کنید. این کار می تواند سایت را در برابر حمله آسیب پذیرتر کند.

به جای خاموش کردن کامل امنیت:

• قوانین اشتباه را شناسایی کنید.
• IPهای معتبر را با روش کنترل شده مجاز کنید.
• گزارش درخواست های مسدود شده را بررسی کنید.
• از غیرفعال کردن SSL خودداری کنید.
• دسترسی مدیریت را محدود نگه دارید.
• احراز هویت دو مرحله ای را حذف نکنید.
• از قرار دادن IP اصلی سرور در منابع عمومی خودداری کنید.

دسترسی بدون امنیت مناسب می تواند خسارت بیشتری از یک قطعی کوتاه ایجاد کند.

زیرساخت مناسب سایت شرکتی

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

• هاست معتبر متناسب با محل کاربران
• DNS پایدار
• CDN برای فایل های ثابت در صورت نیاز
• فونت و فایل های اصلی روی همان زیرساخت سایت
• بکاپ مستقل روزانه یا چندروزه
• صفحه اضطراری ثابت
• مانیتورینگ سایت و SSL
• فرم دارای ذخیره محلی اطلاعات پیش از ارسال خارجی

برای پروژه طراحی سایت شرکتی با وردپرس بهتر است وابستگی های خارجی از ابتدای طراحی مشخص شوند.

زیرساخت مناسب فروشگاه ووکامرسی

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

• هاست یا سرور با CPU و RAM کافی
• بکاپ پرتکرار دیتابیس
• تست بازیابی سفارش ها
• کش صحیح صفحات عمومی
• خارج کردن سبد خرید و تسویه حساب از کش
• ثبت وضعیت سفارش پیش از انتقال به درگاه
• مدیریت Callback و تراکنش تکراری
• صف بندی ایمیل و پیامک
• مانیتورینگ Action Scheduler
• راه ارتباطی جایگزین برای مشتریان

برای طراحی سایت فروشگاهی با وردپرس، تست زیرساخت باید بخشی از فرایند پیش از راه اندازی باشد.

زیرساخت مناسب سایت خبری

سایت خبری ممکن است در مدت کوتاهی با افزایش شدید بازدید روبرو شود. برای این نوع سایت موارد زیر اهمیت دارند:

• کش کامل صفحات عمومی
• CDN برای تصاویر و فایل های ثابت
• بهینه سازی تصاویر
• منابع کافی برای مدیریت افزایش ناگهانی ترافیک
• صفحه اضطراری یا نسخه فقط خواندنی
• بکاپ منظم محتوا و رسانه
• مانیتورینگ از چند شبکه
• کاهش اسکریپت ها و Embedهای غیرضروری

زیرساخت مناسب سایت آموزشی و عضویتی

سایت آموزشی دارای کاربران وارد شده و اطلاعات داینامیک است. نمایش نسخه کش شده عمومی نمی تواند تمام نیاز آن را پوشش دهد.

• منابع کافی برای کاربران هم زمان
• ذخیره ویدیو روی سرویس تخصصی
• بکاپ پرتکرار پیشرفت کاربران و آزمون ها
• صف بندی ایمیل و اعلان ها
• ورود جایگزین امن در صورت اختلال پیامک
• مانیتورینگ Cron و پردازش دوره ها
• پیام مناسب هنگام خارج بودن سرویس ویدیو

سه سطح پیشنهادی برای طراحی زیرساخت

سطح پایه برای سایت کم اهمیت

• هاست معتبر
• DNS پایدار
• SSL
• بکاپ مستقل هفتگی یا چندروزه
• مانیتورینگ ساده دسترسی
• کاهش منابع خارجی غیرضروری

سطح متعادل برای سایت تجاری

• هاست قدرتمند یا مدیریت شده
• DNS و CDN مناسب
• بکاپ روزانه فایل و دیتابیس
• مانیتورینگ چندبخشی
• صفحه اضطراری
• صف بندی API، ایمیل و پیامک
• تست دوره ای بازیابی
• برنامه مکتوب مدیریت اختلال

سطح پیشرفته برای سرویس حیاتی

• چند سرور یا چند منطقه میزبانی
• Load Balancer و Health Check
• Failover خودکار یا کنترل شده
• همگام سازی دقیق اطلاعات
• بکاپ پرتکرار و خارج از زیرساخت اصلی
• مانیتورینگ از چند کشور و شبکه
• صفحه وضعیت مستقل
• Runbook و تیم پاسخگویی مشخص
• آزمایش دوره ای سناریوی خرابی

سطح پیشرفته هزینه و پیچیدگی بیشتری دارد و برای هر سایت وردپرسی ضروری نیست. هزینه زیرساخت باید با خسارت احتمالی قطعی مقایسه شود.

Runbook اختلال چیست؟

Runbook یک دستورالعمل مکتوب است که مشخص می کند هنگام خرابی چه اقداماتی، با چه ترتیبی و توسط چه کسی انجام شوند.

یک Runbook ساده می تواند شامل این مراحل باشد:

• بررسی سایت از چند شبکه و موقعیت
• کنترل DNS و SSL
• بررسی وضعیت سرور و منابع
• کنترل دیتابیس و لاگ خطاها
• بررسی سرویس های جانبی
• تشخیص بخش دچار اختلال
• فعال کردن صفحه اضطراری در صورت نیاز
• انتقال ترافیک به سرور جایگزین
• اطلاع رسانی به کاربران
• ثبت زمان و اقدامات انجام شده
• بازگرداندن سرویس اصلی
• بررسی صحت اطلاعات پس از بازیابی

اطلاعات ورود، کلیدها و رمزهای حساس نباید به صورت ناامن داخل Runbook قرار بگیرند. از سیستم مدیریت رمز و سطح دسترسی مناسب استفاده کنید.

زیرساخت را قبل از بحران آزمایش کنید

برنامه ای که هیچ وقت آزمایش نشده است، در زمان خرابی قابل اعتماد نیست. آزمایش های پیشنهادی عبارتند از:

• قطع موقت دسترسی سرور آزمایشی
• بررسی عملکرد صفحه اضطراری
• تغییر آزمایشی DNS روی یک زیردامنه
• بازیابی بکاپ در محیط جداگانه
• شبیه سازی قطع API خارجی
• بررسی سایت بدون فونت و اسکریپت خارجی
• آزمایش خطای درگاه پرداخت
• بررسی صف ایمیل و پیامک ناموفق
• تست ورود بدون سرویس پیامک
• بررسی هشدارهای مانیتورینگ

این آزمایش ها باید ابتدا در محیط Staging یا شرایط کنترل شده انجام شوند تا سایت اصلی دچار اختلال نشود.

اشتباهات رایج درباره زیرساخت زمان اختلال اینترنت

هاست ایران همیشه در دسترس می ماند

هاست ایران می تواند در بعضی شرایط برای کاربران داخلی مناسب باشد، اما خرابی دیتاسنتر، DNS، شبکه داخلی یا سرویس های جانبی همچنان ممکن است سایت را مختل کند.

هاست خارج همیشه امن تر و پایدارتر است

کیفیت هاست به شرکت، دیتاسنتر، منابع و مدیریت زیرساخت وابسته است. همچنین دسترسی کاربران داخلی به سرور خارجی به مسیرهای بین المللی نیاز دارد.

CDN کل سایت را هنگام خرابی فعال نگه می دارد

CDN بیشتر برای محتوای قابل کش مفید است و نمی تواند تمام عملیات داینامیک وردپرس و ووکامرس را بدون سرور اصلی اجرا کند.

داشتن بکاپ یعنی سایت سریع برمی گردد

برای بازیابی سریع، علاوه بر بکاپ سالم به سرور مقصد، دسترسی DNS، دستورالعمل بازیابی و فرد مسئول نیاز دارید.

خرید دو هاست به معنی Failover است

بدون همگام سازی، مانیتورینگ و مسیر تغییر ترافیک، هاست دوم فقط یک نسخه جداگانه و احتمالا قدیمی است.

نمایش سایت یعنی همه خدمات سالم هستند

ممکن است صفحات باز شوند اما درگاه، پیامک، ایمیل یا APIهای سایت کار نکنند.

چک لیست کاهش تاثیر اختلال اینترنت

• نوع اختلال هایی که برای کسب و کار مهم هستند مشخص شده است.
• نقشه تمام وابستگی های داخلی و خارجی سایت تهیه شده است.
• موقعیت سرور بر اساس کاربران و سرویس ها انتخاب شده است.
• DNS دامنه مانیتور می شود.
• دسترسی مالک دامنه و پنل DNS در اختیار مجموعه است.
• قوانین CDN و کش ووکامرس درست تنظیم شده اند.
• فایل های خارجی غیرضروری حذف یا محلی شده اند.
• APIها Timeout، کش و مدیریت خطا دارند.
• درگاه پرداخت و Callbackها در برابر تکرار مقاوم هستند.
• برای اختلال پیامک یا ایمیل مسیر جایگزین وجود دارد.
• WP-Cron و صف های ووکامرس مانیتور می شوند.
• بکاپ در زیرساختی جدا از سرور اصلی نگهداری می شود.
• RPO و RTO پروژه مشخص شده اند.
• بازیابی بکاپ به صورت دوره ای آزمایش می شود.
• صفحه اضطراری یا وضعیت خدمات آماده است.
• مانیتورینگ از چند موقعیت انجام می شود.
• Runbook مدیریت اختلال نوشته شده است.
• سناریوهای خرابی در محیط کنترل شده آزمایش شده اند.

جمع بندی؛ چه زیرساختی در زمان اختلال اینترنت بهتر است؟

زیرساخت مناسب فقط یک هاست ایران، هاست اروپا یا CDN نیست. پایداری سایت از کنار هم قرار گرفتن چند بخش ایجاد می شود: سرور مناسب، DNS قابل اعتماد، کش درست، بکاپ مستقل، مدیریت APIها، مانیتورینگ و برنامه بازیابی.

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

سایت های حیاتی نیز می توانند از چند سرور، Load Balancer، Failover و معماری چند منطقه ای استفاده کنند؛ اما این ساختار باید به صورت اصولی طراحی و آزمایش شود.

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

در مقاله بررسی میهن وب هاست برای وردپرس بعضی قابلیت های شبکه و سرویس های ایران و آلمان این شرکت را بررسی کرده ایم. وجود چنین قابلیت هایی باید در کنار سایر معیارهای زیرساخت سنجیده شود.

اگر سایت فعلی روی زیرساخت نامناسب قرار دارد، مقاله تغییر هاست وردپرس بدون قطعی مراحل آماده سازی و انتقال امن سایت را توضیح می دهد.

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

سوالات متداول درباره زیرساخت سایت در زمان اختلال اینترنت

هاست ایران در زمان قطعی اینترنت همیشه در دسترس است؟

خیر. محل سرور فقط یکی از عوامل است. دیتاسنتر، DNS، شبکه کاربران، CDN و سرویس های جانبی نیز می توانند باعث اختلال شوند.

هاست خارج برای سایت وردپرسی بهتر است؟

برای سایت بین المللی یا پروژه وابسته به APIهای خارجی می تواند مناسب باشد. برای کاربران داخلی باید کیفیت مسیر ارتباط با سرور خارج نیز بررسی شود.

آیا CDN هنگام قطعی سرور سایت را نمایش می دهد؟

ممکن است نسخه کش شده بعضی صفحات و فایل های ثابت نمایش داده شود، اما قابلیت های داینامیک مانند ورود، سبد خرید و ثبت سفارش معمولا به سرور اصلی نیاز دارند.

آیا داشتن دو سرور باعث می شود سایت قطع نشود؟

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

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

به تعداد سفارش ها و RPO کسب و کار بستگی دارد. فروشگاه پرتراکنش ممکن است به بکاپ دیتابیس با فاصله کمتر یا سیستم تکثیر اطلاعات نیاز داشته باشد.

در زمان قطعی سایت چه کد HTTP نمایش دهیم؟

برای اختلال موقت، پاسخ 503 Service Unavailable همراه با Retry-After انتخاب مناسب تری از نمایش خطا با کد 200 یا استفاده از 404 است.

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

ابتدا تمام وابستگی های سایت را شناسایی کنید، سپس بکاپ مستقل و قابل بازیابی، مانیتورینگ و یک دستورالعمل مشخص برای زمان خرابی ایجاد کنید.