Chuyển website không downtime: mẹo DNS ít guide nào nói

Hầu hết hướng dẫn chuyển website đều kể cùng một câu chuyện: sao lưu dữ liệu, thử trên staging, chọn khung giờ ít truy cập, rồi cầu mong DNS lan truyền cho nhanh. Kết lại bằng một câu quen thuộc: “hãy chuẩn bị tinh thần là sẽ có chút downtime”.

Nhưng downtime khi chuyển host hiếm khi đến từ việc copy file hay import database. Nó đến từ DNS — từ khoảnh khắc bạn trỏ tên miền sang server mới trong lúc server đó chưa sẵn sàng, hoặc trong khi các resolver khác nhau vẫn giữ cache cũ. Hiểu đúng chỗ này, bạn có thể thiết kế cuộc chuyển nhà sao cho vấn đề đó không bao giờ xảy ra.

Vì sao website “tối đen” đúng lúc cutover

Khi ai đó nói “chuyển host bị downtime”, họ thường đang mô tả một kịch bản cụ thể: bản ghi DNS được trỏ sang host mới trước khi host mới sẵn sàng phục vụ, hoặc trước khi thay đổi đó kịp đến mọi resolver mà người truy cập có thể đi qua.

Trong khoảng thời gian đó, người truy cập bị chia thành nhiều nhóm: nhóm vào server cũ, nhóm vào server mới, và nhóm chẳng vào đâu cả. Cùng một tên miền, cùng một thời điểm, nhưng trải nghiệm khác nhau hoàn toàn — và đó là kiểu downtime khó chịu nhất, vì bạn không thể tái hiện nó một cách nhất quán để mà sửa.

Điểm mấu chốt: copy file, chuyển database, cấu hình server hầu như không làm sập site. Bạn làm những việc đó trong lúc website vẫn chạy bình thường ở chỗ cũ. Thứ mong manh chính là cutover DNS — khoảnh khắc bạn tuyên bố với thế giới rằng “site giờ nằm ở đây”. Vậy nên giải pháp không phải là migrate nhanh hơn, mà là tách rời công việc migrate khỏi thời điểm cutover.

Đặt Cloudflare làm lớp đệm trước khi đụng đến hosting

Kỹ thuật này mô tả thì đơn giản, làm thì chỉ nhích thêm vài bước: trỏ DNS của tên miền về Cloudflare trước, khi bạn còn chưa đụng gì đến hosting.

Lúc này nameserver của Cloudflare trở thành authoritative, nhưng bản ghi A/CNAME bên trong Cloudflare vẫn trỏ về host cũ. Người truy cập không thấy gì thay đổi — website cũ vẫn phục vụ y như trước. Sau đó bạn mới làm phần việc thật: di chuyển file, import database, cấu hình server mới, kiểm tra bằng địa chỉ IP hoặc một hostname tạm.

Khi mọi thứ đã xong, bạn đổi bản ghi A/CNAME bên trong Cloudflare — từ IP host cũ sang IP host mới. Không đụng đến nameserver, chỉ một bản ghi duy nhất.

Mấu chốt nằm ở đây: Cloudflare đã là nơi phân giải mà mọi visitor đi qua, nên thay đổi đó gần như có hiệu lực tức thì ở lớp edge, thay vì chờ hàng nghìn resolver độc lập trên khắp thế giới tự nhận ra và cập nhật cache theo từng TTL khác nhau.

Lan truyền DNS truyền thống chậm và khó đoán vì bạn đang chờ cả internet để ý. Còn sửa một bản ghi trong hệ thống DNS bạn đã dùng là thao tác khác hẳn về bản chất: bạn chỉ cập nhật một hệ thống vốn đã ở trong vòng lặp. Website cũ không bao giờ “tắt” vì nó không bao giờ ngừng phân giải về một đích hợp lệ.

Quy trình 5 bước để cutover thành chuyện nhỏ

1. Trỏ nameserver về Cloudflare khi tên miền vẫn đang trỏ về host cũ, giữ nguyên bản ghi A/CNAME và bật proxy.
2. Chuyển dữ liệu trong nền: file, database, cấu hình, cron job, biến môi trường — trong lúc site production vẫn chạy bình thường.
3. Kiểm tra server mới độc lập qua IP hoặc hostname tạm: form, đăng nhập, tìm kiếm, trang động, tốc độ phản hồi.
4. Đổi bản ghi A/CNAME trong Cloudflare sang IP server mới — chỉ một bản ghi, không phải nameserver.
5. Xác nhận SSL đã cấp và phục vụ đúng trước khi tuyên bố hoàn tất.

Điểm hay của quy trình này là mỗi bước đều có thể dừng lại, kiểm tra, thậm chí quay đầu. Bạn không bị ép vào một khung thời gian ngắn rồi phải làm ẩu cho kịp.

Bước duy nhất vẫn khiến bạn phải chờ: chứng chỉ SSL

Nói cho công bằng, quy trình này không hoàn toàn không có ma sát. Có một phần vẫn tốn thời gian thật: việc cấp lại chứng chỉ SSL.

Ngay khi bản ghi DNS trỏ sang server mới, server đó cần chứng chỉ hợp lệ cho tên miền. Nếu bạn dùng Let’s Encrypt — lựa chọn phổ biến vì miễn phí và tự động — nhà cấp chứng chỉ phải xác minh quyền sở hữu tên miền trước khi phát hành, và việc xác minh đó phụ thuộc vào thay đổi DNS vừa rồi. Nên tồn tại một khoảng chờ thật, thường vài phút, đôi khi lâu hơn.

Đây là chỗ dễ tự lừa mình nhất. Nếu bạn coi “site đã truy cập được” là xong, người dùng đầu tiên có thể nhìn thấy cảnh báo bảo mật của trình duyệt. Về kỹ thuật site vẫn sống, nhưng với người dùng, đó vẫn là một dạng downtime — dạng tệ nhất, vì nó kèm cảm giác mất tin cậy. Hãy kiểm tra chứng chỉ từ một công cụ bên ngoài, xem ngày hết hạn và chuỗi chứng chỉ, chứ đừng chỉ nhìn thanh địa chỉ trên máy mình.

Checklist trước khi bấm đổi bản ghi

Chạy qua danh sách này một lượt trước khi cutover:

• Server mới truy cập được và hoạt động đầy đủ qua IP hoặc hostname tạm.
• Database đã migrate và kiểm chứng — mở vài bài viết, vài đơn hàng thật, không chỉ xem danh sách bảng có tồn tại.
• Form, đăng nhập, giỏ hàng, tìm kiếm đã test trọn vẹn trên môi trường mới.
• Email (bản ghi MX) lên kế hoạch riêng — đừng mặc định email và hosting chuyển cùng lúc.
• Chế độ SSL/TLS trong Cloudflare đặt ở “Full” (không phải “Flexible”) sau khi server mới có chứng chỉ hợp lệ, để tránh vòng lặp chuyển hướng.
• Có phương án rollback: đổi bản ghi về host cũ nhanh đúng như lúc đổi đi.

Giá trị thật: bạn không còn chạy đua với đồng hồ

Lợi ích lớn nhất của cách làm này không nằm ở việc “site không sập”. Nó nằm ở chỗ bạn không còn bị ép thời gian, và đó là thứ thay đổi chất lượng công việc.

Khi không còn một cửa sổ lan truyền đang đếm ngược, bạn cũng không còn bị cám dỗ làm migration lúc 2 giờ sáng, test qua loa hay bỏ bước xác minh cho kịp. Bạn có thể chuyển vào giờ làm việc bình thường, test tử tế, cutover từ tốn — vì website chưa từng gặp rủi ro. Với doanh nghiệp nhỏ, khác biệt này lớn hơn vẻ ngoài của nó: sai sót trong migration thường không đến từ kỹ thuật khó, mà từ sự vội vàng.

Và nó không đòi hỏi hạ tầng doanh nghiệp. Gói miễn phí của Cloudflare là đủ để chạy toàn bộ quy trình. Kỹ thuật này không hề cao siêu — nó chỉ hiếm khi được nhắc tới, vì phần lớn hướng dẫn vẫn giải bài toán “làm sao cho nhanh” thay vì “làm sao để cutover DNS chỉ là một thao tác bình thường”.

Một lưu ý để công bằng: cách này hợp nhất với website dùng hosting thông thường và DNS do bạn kiểm soát. Nếu bạn nằm trong hệ sinh thái khép kín của một nền tảng, hoặc tên miền do bên thứ ba quản lý mà bạn không có quyền sửa bản ghi, bạn sẽ phải thương lượng trước, và bước chuẩn bị có thể chậm hơn.

Nếu bạn sắp chuyển host trong vài tuần tới, hãy làm một việc nhỏ ngay hôm nay: mở trang quản lý DNS và xem ai đang giữ nameserver cho tên miền của bạn. Biết rõ điều đó trước khi cần đến nó sẽ tiết kiệm cho bạn rất nhiều thời gian.

Còn bạn thì sao — bạn từng dính downtime khi chuyển website chưa, và nguyên nhân thật sự là gì? Sẽ có người nói thêm Cloudflare vào giữa chỉ làm hệ thống phức tạp hơn, và với site nhỏ thì cứ chuyển thẳng cho nhanh. Mình thấy chi phí bỏ ra gần như bằng không so với lợi ích, nhưng rất muốn nghe góc nhìn ngược lại. Để lại bình luận bên dưới nhé, và nếu bạn có mẹo migration nào khác mà các hướng dẫn thường bỏ qua, chia sẻ luôn cho mọi người cùng biết.