انتقال سایت به سرور جدید بدون قطعی: چک‌لیستی که خودم استفاده می‌کنم
چک‌لیست عملی مهاجرت سایت و اپلیکیشن به سرور جدید بدون قطعی و بدون از دست رفتن داده: کاهش TTL، همگام‌سازی دیتابیس، توقف کوتاه نوشتن، گواهی SSL، درگاه پرداخت وابسته به IP، DNS کش‌شده و برنامه بازگشت.
در چند ماه اخیر چند سرویس را بین سرورها جابه‌جا کرده‌ام؛ از جمله همین سایت و فروشگاه عینک‌سازی که درگاه پرداخت و پیامک فعال دارد. انتقال سرور معمولاً از بیرون ساده به نظر می‌رسد: فایل‌ها را کپی کن و DNS را عوض کن. اما قطعی‌ها و داده‌های گم‌شده تقریباً همیشه از جزئیاتی می‌آیند که در این دو جمله نیست. این چک‌لیستی است که خودم استفاده می‌کنم، به ترتیب زمانی، با دلیل هر مرحله.
یک تا دو روز قبل: TTL را پایین بیاورید
TTL مدت زمانی است که سرورهای DNS و مرورگرها پاسخ را به خاطر می‌سپارند. اگر TTL رکورد دامنه یک روز است و DNS را عوض کنید، تا یک روز بخشی از کاربران هنوز به سرور قدیم می‌روند. یک تا دو روز قبل از انتقال، TTL را به چند دقیقه کاهش دهید تا وقتی تغییر اصلی را انجام دادید، سریع پخش شود. بعد از پایدار شدن سرور جدید، TTL را دوباره بالا ببرید.
حتی با TTL پایین، بعضی شبکه‌ها و روترها پاسخ قدیمی را بیشتر از TTL نگه می‌دارند. برای همین سرور قدیم را بلافاصله خاموش نکنید (پایین‌تر توضیح داده‌ام).
محیط جدید را کامل و جدا آماده کنید
قبل از هر تغییری در DNS، سرور جدید باید کاملاً کار کند: همان نسخه زبان و runtime، همان متغیرهای محیطی، همان فونت‌ها و ابزارهای سیستمی (کتابخانه پردازش تصویر یا فونت فارسی برای ساخت تصویر، چیزهایی است که معمولاً فراموش می‌شود)، کرون‌جاب‌ها، سرویس‌های پس‌زمینه و قوانین فایروال.
برای آزمایش سرور جدید با دامنه واقعی، لازم نیست DNS را عوض کنید. فایل hosts سیستم خودتان را موقتاً طوری تنظیم کنید که دامنه به IP جدید اشاره کند، یا از curl با پارامتر resolve استفاده کنید. همه مسیرهای مهم را امتحان کنید: صفحه اصلی، ورود، ثبت سفارش، آپلود فایل، پنل مدیریت.
# درخواست به سرور جدید با همان دامنه، بدون تغییر DNS
curl -sS --resolve example.com:443:203.0.113.20 https://example.com/health -o /dev/null -w "%{http_code}\n"وابستگی‌های بیرونی به IP
این بخشی است که بیشتر از همه غافلگیر می‌کند: سرویس‌هایی که به IP سرور شما گره خورده‌اند. درگاه‌های پرداخت بانکی معمولاً فقط از IP ثبت‌شده درخواست را می‌پذیرند؛ بعضی سرویس‌های پیامک، APIهای سازمانی و فایروال‌های شرکای تجاری هم همین‌طور.
در انتقال فروشگاه عینک‌سازی، ترمینال درگاه بانکی فقط IP سرور قدیم را قبول می‌کرد و تغییر IP در بانک زمان می‌برد. راه موقت این بود که درخواست‌های درگاه از سرور جدید از طریق سرور قدیم عبور کنند (به‌صورت رمزشده و فقط برای همان مقصد)، تا وقتی IP جدید ثبت شود. اگر این را از قبل نمی‌دانستیم، پرداخت‌ها بعد از انتقال شکست می‌خوردند. فهرست همه سرویس‌های بیرونی و وابستگی‌شان به IP را قبل از انتقال تهیه کنید و برای هر کدام برنامه داشته باشید.
نکات کلیدی
- درگاه پرداخت: IP ثبت‌شده در بانک.
- پیامک و APIهای سازمانی: لیست سفید IP.
- ایمیل: رکوردهای SPF که IP سرور را دارند.
- اتصال سرور به سرور: فایروال‌هایی که IP قدیم را مجاز کرده‌اند.
دیتابیس: کپی اولیه، بعد همگام‌سازی نهایی
داده‌ها مهم‌ترین بخش انتقال‌اند. روش امن دو مرحله‌ای است. اول یک کپی کامل از دیتابیس می‌گیرید و روی سرور جدید بازیابی می‌کنید؛ این کار ممکن است طول بکشد، ولی سایت در این مدت عادی کار می‌کند. همه آزمایش‌ها روی همین کپی انجام می‌شود.
در زمان انتقال اصلی، نوشتن در سرور قدیم را برای چند دقیقه متوقف می‌کنید (حالت تعمیر برای ثبت سفارش و فرم‌ها، یا توقف سرویس)، یک کپی نهایی می‌گیرید و روی سرور جدید بازیابی می‌کنید. این کپی دوم، تغییرات بعد از کپی اول را هم دارد. بعد از بازیابی، تعداد ردیف‌های جدول‌های مهم (سفارش‌ها، کاربران، پرداخت‌ها) را در دو طرف مقایسه کنید. فایل‌های آپلودشده کاربران را هم با rsync همین‌طور دو مرحله‌ای منتقل کنید.
اگر حتی همین چند دقیقه توقف نوشتن قابل قبول نیست، باید از replication دیتابیس استفاده کرد؛ پیچیده‌تر است و برای بیشتر کسب‌وکارهای کوچک و متوسط لازم نیست.
گواهی SSL روی سرور جدید
اگر گواهی با روش HTTP (webroot) صادر می‌شود، تا وقتی DNS به سرور جدید اشاره نکند، صدور گواهی جدید روی آن ممکن نیست. دو راه دارید: گواهی فعلی را از سرور قدیم کپی کنید تا سرور جدید از لحظه اول HTTPS معتبر داشته باشد و بعد از انتقال تمدید خودکار را روی سرور جدید راه بیندازید، یا از روش DNS برای صدور استفاده کنید.
بعد از انتقال، مطمئن شوید تمدید خودکار واقعاً روی سرور جدید کار می‌کند (یک تمدید آزمایشی بگیرید). گواهی‌ای که سه ماه بعد بی‌صدا منقضی شود، یکی از رایج‌ترین قطعی‌های بعد از مهاجرت است؛ اگر سایت پشت CDN باشد، ممکن است حتی متوجهش نشوید. ماجرای واقعی‌اش را اینجا نوشته‌ام.
لحظه انتقال و ساعت‌های بعدش
ترتیب کار در لحظه انتقال: توقف نوشتن در سرور قدیم، کپی نهایی داده، بازیابی و بررسی در سرور جدید، تغییر DNS (یا تغییر مبدأ در CDN، که سریع‌تر از DNS اعمال می‌شود)، و آزمایش مسیرهای مهم از چند شبکه مختلف.
سرور قدیم را بلافاصله خاموش نکنید. به‌جای آن، روی سرور قدیم هر درخواستی را که هنوز می‌رسد به سرور جدید هدایت کنید (proxy، نه فقط نمایش خطا) و لاگ را ببینید. تا وقتی درخواست از DNS قدیمی به آن می‌رسد، نگهش دارید. تجربه‌ام نشان داده بعضی روترهای خانگی و شبکه‌ها پاسخ قدیمی را روزها نگه می‌دارند؛ در ماجرای یک ریدایرکت ۳۰۱ ماندگار نوشته‌ام که بی‌توجهی به همین موضوع چطور بازدیدکنندگان را به سایت اشتباه فرستاد.
برنامه بازگشت
قبل از شروع، بنویسید اگر چیزی خراب شد چطور برمی‌گردید و تا چه نقطه‌ای برگشت ممکن است. تا وقتی نوشتن در سرور جدید شروع نشده، برگشت ساده است: DNS را برگردانید و نوشتن در سرور قدیم را باز کنید. بعد از اینکه سفارش یا داده تازه در سرور جدید ثبت شد، برگشت یعنی آن داده‌ها هم باید منتقل شوند. پس تصمیم «ادامه یا برگشت» را در همان ساعت اول، بر اساس آزمایش‌های از قبل تعریف‌شده، بگیرید.
چک‌لیست خلاصه
نکات کلیدی
- یک تا دو روز قبل: کاهش TTL.
- محیط جدید کامل: runtime، متغیرها، ابزارهای سیستمی، کرون، سرویس‌های پس‌زمینه، فایروال.
- آزمایش با فایل hosts یا curl --resolve قبل از تغییر DNS.
- فهرست وابستگی‌های IP: درگاه، پیامک، SPF، فایروال شرکا.
- دیتابیس دو مرحله‌ای: کپی اولیه، توقف کوتاه نوشتن، کپی نهایی، مقایسه تعداد ردیف‌ها.
- گواهی SSL از لحظه اول، و تمدید خودکار آزمایش‌شده.
- سرور قدیم به‌صورت proxy به جدید، تا وقتی درخواست می‌رسد.
- برنامه بازگشت نوشته‌شده.
- بکاپ خودکار روی سرور جدید از همان روز اول.
جمع‌بندی
انتقال بدون قطعی بیشتر برنامه‌ریزی است تا مهارت فنی: TTL را زود کم کنید، محیط جدید را قبل از تغییر DNS کامل آزمایش کنید، وابستگی‌های IP مثل درگاه پرداخت را از قبل حل کنید، داده را دو مرحله‌ای با یک توقف کوتاه منتقل کنید، و سرور قدیم را تا وقتی ترافیک دارد به‌عنوان پل نگه دارید. اگر می‌خواهید سایت یا اپلیکیشن کسب‌وکارتان را بدون ریسک به سرور جدید ببرید، در سرور و زیرساخت این کار را انجام می‌دهم؛ نمونه زیرساختی که نگهداری می‌کنم را هم در زیرساخت سرورها و IoT ببینید.