مهاجرت هاست بدون Downtime؛ DNS، داده و Rollback

خطر اصلی مهاجرت هاست، کپی‌نشدن فایل نیست؛ دو نسخه هم‌زمانِ «درست» است. بخشی از کاربران هنوز به مبدأ می‌رسند، بخشی به مقصد؛ در هر دو سفارش ثبت می‌شود و صبح تیم می‌فهمد هیچ Databaseای به‌تنهایی حقیقت کامل نیست. کاهش TTL این Split را کوتاه‌تر می‌کند، اما مشکل Writer، Session، Upload، Queue و Reconciliation را حل نمی‌کند.

«بدون Downtime» را وعده مطلق نگیرید. آن را به SLO قابل‌سنجش تبدیل کنید: Journeyهای خواندن و نوشتن در Cutover چه Availability و Error budgetی دارند، حداکثر داده ازدست‌رفته چیست و Rollback در چه زمانی انجام می‌شود؟ برای سایت Static، WordPress محتوایی، فروشگاه پرتراکنش و وب‌اپ چندسرویسی یک Runbook واحد وجود ندارد. این راهنما روش انتخاب Strategy، همگام‌سازی، DNS، آزمون، Cutover و پایش را می‌دهد.

مهاجرت بدون قطعی یعنی چه؟

اعداد بالا فقط نمونه‌اند. Criticality و هزینه کسب‌وکار تعیینشان می‌کند. انتخاب مقصد باید پیش‌تر با Workload و Recovery سنجیده شود؛ چارچوب آن در راهنمای انتخاب هاست آمده است.

دامنه مهاجرت را دقیق کنید

«هاست» ممکن است فقط Origin وب باشد یا همراه DNS، Email، Database، Object storage، CDN/WAF، Cron و سرویس‌های جانبی منتقل شود. هر تغییر هم‌زمان دامنه Failure را بزرگ می‌کند. اگر URL عمومی ثابت است، پروژه Infrastructure move است؛ تغییر Domain/Path پروژه جداگانه URL migration و Redirect می‌خواهد.

اگر URL تغییر می‌کند، آن را با برنامه Redirect و مهاجرت URL ادغام کنید؛ تغییر هاست با URL ثابت به ۳۰۱ یا Change of Address نیاز ندارد.

Inventory: چیزهایی که معمولاً جا می‌مانند

Inventory را از Configuration، DNS export، Repository، Provider API، Access log و مصاحبه تیم بسازید. «کسی فکر می‌کند یک Cron هست» کافی نیست؛ Owner و Evidence لازم است.

component = {
  "name": "order-worker",
  "source": "old-host systemd",
  "target": "new-host container",
  "state": "queue + database",
  "owner": "platform",
  "test": "payment-to-paid-order fixture",
  "cutover_order": 7,
  "rollback": "stop target, drain to source",
  "evidence": "dashboard/run-184"
}

Baseline و Knockout مقصد

قبل از Build مقصد، Baseline مبدأ را ثبت کنید: Traffic معمول/Burst، CPU/RAM/IO، Storage growth، Query latency، p95/p99 Journey، Error، Cache hit، Queue lag، Cron duration و Backup/Restore. مقصد باید نه فقط میانگین امروز، بلکه Peak و Failure mode را پاسخ دهد.

• Runtime، PHP/Node/Java، extension، database و collation سازگار؛
• Disk/IOPS، inode، connection، worker، process و upload limit روشن؛
• Firewall/CDN/Origin و IP allowlist قابل تنظیم؛
• Backup مستقل، PITR یا روش جایگزین و Restore آزموده‌شده؛
• Observability، shell/API، Support escalation و Export قابل‌استفاده؛
• دسترسی و پرداخت پایدار برای تیم ایرانی و برنامه Exit.

اگر Provider اجازه Load test، Export یا دسترسی اضطراری لازم را نمی‌دهد، Pilot را متوقف کنید. SLA بازاری جای اندازه‌گیری Journey و مانور Recovery را نمی‌گیرد.

Strategy را براساس State انتخاب کنید

DNS برای Traffic steering دقیق ساخته نشده است: Resolver cache و Client reuse باعث می‌شود همه کاربران هم‌زمان جابه‌جا نشوند. اگر Canary درصدی و Rollback ثانیه‌ای لازم دارید، Load balancer/CDN/Reverse proxy که هر دو Origin را می‌شناسد معمولاً کنترل‌پذیرتر است.

اصل Single Writer؛ راه جلوگیری از Split-brain

در Cutover باید معلوم باشد چه سیستمی Authority نوشتن Order، Payment، Inventory، Form، Upload و Session است. دو Database مستقل را هم‌زمان Writer نکنید مگر Conflict resolution و Reconciliation واقعاً پیاده شده باشد.

سه الگوی رایج

1. Write freeze کوتاه: Read ادامه دارد، Write به Queue یا پیام نگهداری می‌رود؛ Delta نهایی Sync و سپس مقصد Writer می‌شود.
2. Replication/CDC: مبدأ Writer، مقصد Replica؛ Lag به صفر/بودجه می‌رسد، Write متوقف، Promote و Application جابه‌جا می‌شود.
3. Shared authoritative service: نسخه قدیم و جدید موقتاً به Database/Object مشترک و سازگار می‌نویسند؛ Schema backward-compatible لازم است.

Dual-write از Request به دو مقصد، بین دو Commit پنجره شکست دارد. اگر استفاده می‌شود، Idempotency، durable outbox، retry، order و Reconciliation باید طراحی شده باشند.

Backup با Migration copy فرق دارد

کپی مهاجرت ممکن است ناقص یا آلوده باشد. یک Backup مستقل و خارج از کنترل همان Workflow بگیرید؛ سپس در محیط جدا Restore و Journey را اجرا کنید. RPO/RTO فقط با مانور اثبات می‌شود.

• Database dump/snapshot با consistency مناسب؛
• Files/uploads/object versions و checksum؛
• Config/Infrastructure/DNS export بدون Secret خام در Data room؛
• Certificate/keys با روش امن یا صدور مجدد؛
• Restore log، زمان، خطا و Business validation.

Full copy، Delta و Integrity

برای کاهش پنجره Cutover، انتقال بزرگ را زودتر انجام دهید و در آخر فقط Delta را بفرستید. روش به Storage و Database بستگی دارد؛ مهم، سازگاری Snapshot و قابلیت Resume است.

T-7d   full database/files copy
T-3d   repeatable restore + application test
T-1d   incremental files + replication health
T-30m  announce, freeze/queue writes, final delta
T-10m  row/count/sum/checksum + business reconciliation
T0     promote one writer, shift traffic
T+     monitor both origins, reconcile late events

برابر بودن Row count کافی نیست؛ Duplicate payment یا Order با وضعیت ناسازگار ممکن است تعداد را حفظ کند. Business invariant را تست کنید.

مقصد را با Host و TLS واقعی تست کنید

بازکردن IP مقصد در Browser تست کامل نیست: Virtual host، SNI، HTTPS، Cookie domain، CSP، CORS، absolute URL و CDN behavior فرق می‌کند. با DNS override محلی یا `curl –resolve` همان Hostname و Certificate path را به IP مقصد وصل کنید.

curl --resolve example.com:443:203.0.113.40 \
  -I https://example.com/critical-path/

# Hostname/SNI واقعی، بدون تغییر DNS عمومی

Test pack پیش از Cutover

• Home، top landing، article، search، login/logout و admin؛
• Product→cart→checkout→sandbox payment→webhook→order؛
• Form→validation→submit→CRM/email؛
• Upload/download، resize، private file و object URL؛
• Cron/queue/retry/DLQ و background jobs؛
• ۴۰۴/۴۱۰/redirect/5xx، robots.txt، sitemap و canonical؛
• TLS chain/SNI/HSTS، security headers، CSP و WAF؛
• backup/restore، node/restart و dependency failure.

Artifact، Migration و Config باید همان نسخه‌ای باشد که Cutover می‌شود. Pipeline تکرارپذیر و Rollback در راهنمای CI/CD امن تشریح شده است.

DNS: TTL دقیقاً چه کاری می‌کند؟

TTL می‌گوید Resolver پاسخ را چه مدت Cache کند؛ دکمه «انتشار فوری» نیست. اگر رکورد قبلاً با TTL ۲۴ساعته Cache شده، کاهش TTL در دقیقه آخر آن Cache را پاک نمی‌کند. باید دست‌کم به‌اندازه TTL قبلی—با حاشیه عملیاتی—پیش از Cutover کاهش یابد.

1. Authoritative source و همه Recordها را Export کنید.
2. TTL رکوردهای تغییرپذیر را پیش از پنجره کاهش دهید.
3. A و AAAA، CDN proxy mode و Origin auth را هماهنگ کنید.
4. از Resolverهای شبکه‌های هدف پاسخ و TTL باقی‌مانده را بسنجید.
5. پس از ثبات و پایان Rollback window، TTL را به مقدار عملیاتی برگردانید.

به‌جای تصور مبهم «DNS propagation تا ۴۸ ساعت»، Queryهای Authoritative و Recursive را از شبکه‌های واقعی ثبت کنید. جزئیات Zone، TTL، DNSSEC و Runbook در راهنمای مدیریت DNS آمده است.

A/AAAA switch یا تغییر Nameserver؟

اگر فقط Origin وب عوض می‌شود، معمولاً تغییر A/AAAA یا Target پشت CDN دامنه کوچک‌تری دارد. تغییر Nameserver مدیریت کل Zone را جابه‌جا می‌کند؛ MX، SPF، DKIM، DMARC، verification، subdomain و SRV هم در خطرند.

چک‌لیست Nameserver migration

• Zone مقصد را پیش از Delegation کامل و از چند Type مقایسه کنید.
• SOA/NS و Delegation فرزند/Glue را بررسی کنید.
• DNSSEC/DS را با روش Provider و Registry هماهنگ کنید؛ DS قدیمی با کلید جدید می‌تواند SERVFAIL بسازد.
• MX/SPF/DKIM/DMARC و Verificationهای SaaS را فراموش نکنید.
• Authoritative قدیم را تا عبور Cache و مشاهده Query نگه دارید.

برای نمونه، راهنمای Cloudflare درباره تغییر Nameserver هشدار می‌دهد که در Setup معمول، DNSSEC فعال/DS نامتناسب هنگام تعویض Nameserver می‌تواند دامنه را غیرقابل دسترس کند؛ فرایند دقیق را باید از Provider و Registry خود بگیرید.

Email را پروژه مستقل فرض کنید

تغییر Nameserver یا Host ممکن است Email را ناخواسته جابه‌جا کند. Mailbox، Alias، Forwarder، Catch-all، MX priority، SPF، DKIM selector/key، DMARC، MTA-STS/TLS-RPT در Scope شماست.

• Mailbox را Pre-sync و Delta نهایی را پس از Cutover اجرا کنید.
• ارسال/دریافت داخلی و خارجی، Reply، Attachment و Spam placement را تست کنید.
• هر دو Provider را برای پنجره عبور آماده نگه دارید.
• SPF را با دو رکورد جدا نسازید؛ Policy نهایی معتبر و محدود باشد.
• Queue و bounce log را پس از تغییر پایش کنید.

Runbook Cutover دقیقه‌به‌دقیقه

هر سطر باید Command/Link، Expected output و مسئول جایگزین داشته باشد. «اگر مشکل شد برمی‌گردیم» Rollback plan نیست.

Rollback بعد از Write جدید چگونه ممکن است؟

اگر مقصد پس از Cutover سفارش گرفته، برگرداندن DNS به مبدأ بدون Reverse sync داده را گم می‌کند. Rollback را در سه سطح طراحی کنید:

1. Traffic rollback: وقتی Data authority مشترک/سازگار است، مسیر را به Application قدیم برگردانید.
2. Application rollback: Artifact قبلی روی مقصد، با Schema backward-compatible.
3. Data rollback/reconcile: Writeهای مقصد را freeze، Export/replicate و قبل از Promote مبدأ تطبیق دهید.

برای Migrationهای غیرقابل برگشت، Roll-forward ممکن است امن‌تر باشد. این تصمیم، Deadline و Authority باید قبل از Cutover ثبت شوند.

Observability در پنجره مهاجرت

Dashboard را پیش از تغییر بسازید، نه هنگام Incident. از بیرون و داخل هر دو محیط پایش کنید:

• DNS answer/TTL/Resolver و TLS handshake/certificate؛
• Uptime synthetic از چند شبکه و Journey؛
• RPS، 2xx/3xx/4xx/5xx، p95/p99 و saturation؛
• Database connection/query/lock/replication lag؛
• Queue lag/retry/DLQ و Cron last success؛
• Order/payment/inventory/form/email reconciliation؛
• Old vs new origin access log و Bot/user split؛

پایش بیرونی Uptime در دسترس‌بودن مقصد کمک می‌کند و راهنمای Observability Telemetry را تا Outcome و SLO امتداد می‌دهد.

SEO در مهاجرت هاست با URL ثابت

راهنمای رسمی گوگل برای تغییر Hosting بدون تغییر URL پیشنهاد می‌کند زیرساخت جدید را آماده و تست کنید، TTL را پیش‌تر کاهش دهید، DNS را عوض کنید، Log هر دو محیط را پایش و مبدأ را وقتی Traffic به صفر رسید خاموش کنید. افت موقت Crawl rate پس از تغییر می‌تواند طبیعی باشد؛ Error/Slowdown جدی مهم است.

SEO parity gate

• URL، Status، body، canonical، robots و sitemap همان Semantics قبلی؛
• Test noindex/robots block و Basic auth از مقصد عمومی حذف شده؛
• Search Console verification file/meta/DNS پابرجاست؛
• Googlebot در Firewall/WAF/CDN به‌اشتباه مسدود نمی‌شود؛
• Redirect chain یا Host/IP leakage تازه ساخته نشده؛
• Log، Crawl stats، Indexing و 5xx پس از Cutover پایش می‌شوند.

قطعی کوتاه را «سیگنال منفی بزرگ فوری» ننامید؛ مدت، تکرار و پاسخ مهم‌اند. اگر ناچار به توقف کوتاه کل سایت هستید، راهنمای گوگل برای توقف موقت استفاده کوتاه از ۵۰۳ و `Retry-After`، حفظ robots.txt قابل Crawl و پرهیز از ۲۰۰ جعلی/۴۰۴/۴۰۳ را توضیح می‌دهد. Semantics کدها در راهنمای کدهای وضعیت HTTP آمده است.

مهاجرت WordPress: فقط wp-content نیست

راهنمای رسمی Migrating WordPress بر Backup فایل و Database، تنظیم Database در `wp-config.php` و مراقبت از URL/Rewrites تأکید می‌کند. وقتی Domain و URL ثابت است Search-replace عمومی لازم نیست و می‌تواند Serialization/GUID را خراب کند.

WordPress migration pack

• Core، wp-content، mu-plugins، uploads، languages و فایل‌های خارج Docroot؛
• Database، Prefix، Charset/Collation، User/Grant و SQL mode/version؛
• wp-config/env، salts/secrets با انتقال امن، cron و filesystem permission؛
• Web server/PHP، extension، upload/post/memory/timeout و rewrite؛
• Object/page/CDN cache، Redis/Memcached namespace و purge؛
• SMTP، plugin/theme license، webhook callback و IP allowlist؛
• WP-Cron یا system cron، Action Scheduler/queue و last-run؛
• Admin/login، media resize، REST، XML-RPC اگر لازم، checkout و email.

Cache مقصد را با داده نهایی Warm کنید اما صفحه شخصی/سبد را Cache نکنید. پس از Promote، Cacheهای مبدأ/مقصد/CDN را طبق Version purge کنید تا HTML قدیم به Asset جدید اشاره نکند.

Security و Access در Migration

Migration اغلب Credentialهای موقت و دسترسی گسترده می‌سازد. Least privilege، دسترسی زمان‌دار، MFA، انتقال رمزنگاری‌شده، Audit و Rotation بعد از Cutover لازم است.

• Backup عمومی، Dump در web root یا Link بدون انقضا ممنوع؛
• SSH/API/Database allowlist موقت با Owner و expiry؛
• Secret در Chat/Ticket/Command history ثبت نشود؛
• Vendor/support account پس از Hypercare Revoke شود؛
• WAF/rate limit و Security header parity با Test منفی؛
• Log تحقیق Incident پیش و پس از Cutover حفظ شود.

برای داده حساس، Shared responsibility، Evidence، Restore و Exit را با چک‌لیست هاست ابری امن بررسی کنید.

چه زمانی هاست قدیمی را خاموش کنیم؟

«یک هفته» یا «۷۲ ساعت» قانون جهانی نیست. Shutdown وقتی مجاز است که:

• Authoritative و Resolverهای هدف مقصد را برمی‌گردانند؛
• Access log مبدأ برای کاربران/Botها به صفر یا سطح استثنای توضیح‌داده‌شده رسیده؛
• هیچ Write/Queue/Webhook در مبدأ باقی نمانده؛
• Reconciliation و SLO برای پنجره مصوب پاس شده؛
• Rollback window بسته و Backup/Retention طبق Policy ثبت شده؛
• Credential/Route قدیمی Revoke و Decommission evidence ذخیره شده است.

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

• DNS، TLS، Origin و CDN را از چند ISP ثابت/موبایل داخل و یک نقطه بیرون ایران بسنجید.
• Provider خارجی را از نظر Eligibility، KYC، تعلیق، پنل/API، پرداخت/تمدید ارزی و Support بررسی کنید.
• CDN خارجی و Origin ایرانی/برعکس را با Route، Packet loss و Timeout واقعی تست کنید.
• دسترسی اضطراری مستقل، Backup خارج Provider و Export بدون همان حساب داشته باشید.
• دامنه ‎.ir، DNSSEC/DS و Glue را با Registry/Provider خود، نه دستور عمومی Vendor، هماهنگ کنید.
• درگاه‌های پرداخت، پیامک، ERP/CRM و سرویس‌های IP-allowlist را پیش از تغییر تأیید کنید.
• IRR/تومان، Timezone تهران، تقویم، Unicode/Collation و RTL را در Journey و Reconciliation تست کنید.
• Cutover را براساس کم‌ترافیک واقعی و حضور تیم/Provider انتخاب کنید؛ نیمه‌شب بدون On-call مزیت نیست.

Timeline پیشنهادی مهاجرت

هفته اول: Contract و آماده‌سازی

• Scope/Inventory، SLO/RPO/RTO، Single-writer و Rollback تصویب شود.
• مقصد با Infrastructure as Code/Config review ساخته و Baseline ثبت شود.
• TTL به‌موقع کاهش و DNS/Email/DNSSEC plan جدا شود.

هفته دوم: تکرار و آزمون

• Full copy/restore، Delta، integrity و Business reconciliation تمرین شود.
• Host/SNI Journey، load/failure/security/backup tests اجرا شود.
• Runbook tabletop و یک Dry run با زمان واقعی انجام شود.

Cutover و Hypercare

• Change freeze، final delta، promote، switch و synthetic test طبق Owner اجرا شود.
• Old/new log، SLO، data/queue/email/SEO تا بسته‌شدن Risk پایش شود.
• Go/Hold/Rollback ثبت؛ سپس TTL restore، access rotation و decommission کنترل‌شده.

سؤال‌های متداول

آیا مهاجرت هاست بدون هیچ قطعی تضمین می‌شود؟

خیر، تضمین مطلق واقع‌بینانه نیست. می‌توان با اجرای موازی، یک Writer، Pre-copy/Delta، Health check و Traffic switch کنترل‌شده، User-visible interruption را به Error budget نزدیک صفر رساند. SLO، RPO/RTO و Trigger بازگشت را پیشاپیش تعریف کنید.

TTL را چه زمانی کاهش دهیم؟

دست‌کم به‌اندازه TTL قبلی و با حاشیه عملیاتی پیش از Cutover؛ راهنمای گوگل برای تغییر Hosting حتی نمونه «حداقل یک هفته قبل» و TTL چندساعته محافظه‌کارانه می‌دهد. مقدار مناسب به DNS، بار Query و Runbook شما بستگی دارد.

تغییر A Record بهتر است یا Nameserver؟

اگر فقط Origin وب عوض می‌شود، A/AAAA یا Target پشت CDN دامنه تغییر کوچک‌تری دارد. Nameserver کل Zone، Email، Verification و DNSSEC را جابه‌جا می‌کند و به Zone parity و DS/Delegation plan نیاز دارد. انتخاب را با Scope واقعی انجام دهید.

آیا نگه‌داشتن هاست قدیمی برای هفت روز کافی است؟

روز ثابت معیار نیست. Log مبدأ، Resolver/TTL، late webhook/write، Queue، Reconciliation، SLO و Rollback window تعیین می‌کنند. هاست قدیم را وقتی خاموش کنید که Traffic مؤثر به صفر و همه Acceptance gateها پاس شده باشند.

بعد از تغییر هاست باید Change of Address سرچ کنسول بزنیم؟

اگر Domain و URLهای عمومی ثابت‌اند، خیر. Verification را حفظ و Crawl/Index/5xx/latency را مانیتور کنید. Change of Address و Redirect map مربوط به مهاجرت URL/Domain است، نه صرفاً تغییر IP یا Provider.

جمع‌بندی

مهاجرت هاست بدون Downtime از DNS شروع نمی‌شود؛ از تعریف State و Authority شروع می‌شود. Inventory کامل، مقصد سازگار، Backup/Restore مستقل، Pre-copy و Delta، یک Writer، تست با Host/SNI واقعی، DNS/DNSSEC/Email plan، Observability و Rollback داده‌محور، انتقال را کنترل‌پذیر می‌کنند. DNS را فقط پس از اثبات مقصد عوض کنید و مبدأ را بر اساس Log و Acceptance—نه تقویم—خاموش کنید.

منابع فنی منتخب

• Google Search Central — Changing your hosting
• Google Search Central — Temporarily pause or disable a website
• Cloudflare DNS — Nameserver setup and DNSSEC caution
• WordPress Developer Resources — Migrating WordPress