Có thể cập nhật website mà không cần đưa website ngoại tuyến không?

Nhiều bản cập nhật có thể được triển khai trong khi website hiện tại vẫn hoạt động. Điều này thường khả thi với thay đổi nội dung, thiết kế, trang mới và các phiên bản phần mềm được chuẩn bị kỹ.

Đây không phải cam kết áp dụng cho mọi thay đổi. Cập nhật liên quan đến đơn hàng đang xử lý, tài khoản thành viên, phiên bản phần mềm không tương thích, hạ tầng hoặc dịch vụ bên ngoài có thể cần một khoảng thời gian bảo trì được xác định rõ. Câu hỏi quan trọng không chỉ là website có trực tuyến hay không. Cần biết những gì vẫn dùng được, cách kiểm tra thay đổi và phương án khi kết quả không như mong đợi.

Có thể cập nhật những gì khi website vẫn đang hoạt động?

Việc sửa văn bản, thay ảnh, đăng bài và trang mới, hoặc điều chỉnh giao diện riêng lẻ thường có thể được chuẩn bị và phát hành mà không cần tắt toàn bộ website. Các thay đổi phần mềm nhỏ cũng có thể được phát hành theo cách này nếu website và quy trình triển khai hỗ trợ.

Chỉ nhìn vào loại cập nhật thì chưa thể kết luận. Một chỉnh sửa nội dung thông thường có thể ảnh hưởng đến menu, tìm kiếm, trang lưu trong bộ nhớ đệm hoặc tệp được tạo trên website này, nhưng chỉ sửa một trang trên website khác. Ngay cả công việc quen thuộc cũng cần được xem xét trong bối cảnh hệ thống cụ thể.

“Trực tuyến” cũng cần được hiểu theo nghĩa thực tế. Trang chủ tải thành công không chứng minh rằng biểu mẫu liên hệ, thanh toán, đăng nhập, tìm kiếm hay công việc quản trị vẫn hoạt động. Các phần quan trọng với doanh nghiệp cần được kiểm tra riêng.

Website thử nghiệm giúp bảo vệ điều gì?

Website thử nghiệm là môi trường riêng để chuẩn bị và xem xét thay đổi trước khi đưa đến khách truy cập. Môi trường này giúp tránh việc bố cục chưa hoàn chỉnh, văn bản dở dang và lỗi chức năng dễ thấy xuất hiện trên website công khai trong lúc thực hiện công việc.

Môi trường thử nghiệm giảm bớt sự không chắc chắn nhưng không loại bỏ hoàn toàn. Bản sao thử nghiệm có thể khác về dữ liệu, lưu lượng truy cập, cấu hình, thông tin xác thực, dịch vụ kết nối hoặc tài nguyên máy chủ. Thử nghiệm thành công là bằng chứng hữu ích, không phải sự đảm bảo rằng môi trường thật sẽ hoạt động giống hệt.

Kế hoạch phát hành vẫn cần xác định những gì phải kiểm tra sau khi thay đổi được đưa lên website công khai.

Làm thế nào thay phiên bản mới mà không hiện trang trắng?

Một cách là chuẩn bị phiên bản mới ở nơi riêng trong khi phiên bản hiện tại tiếp tục phục vụ khách truy cập. Chỉ chuyển lưu lượng sau khi đã kiểm tra phiên bản mới. Nếu xuất hiện vấn đề nghiêm trọng, có thể chuyển lưu lượng trở lại phiên bản trước.

Cách này thường được gọi là triển khai blue-green. AWS mô tả phương pháp này là chuyển lưu lượng giữa hai môi trường chạy các phiên bản ứng dụng khác nhau. Mục tiêu là gần như không có thời gian ngừng hoạt động và có thể quay lại môi trường trước nhanh hơn.

Blue-green không phải cách duy nhất để phát hành cập nhật. Một số hệ thống thay tệp theo cách nguyên tử, cập nhật từng máy chủ, chỉ chuyển một phần lưu lượng sang phiên bản mới hoặc bật tính năng đã hoàn tất sau khi phần hỗ trợ sẵn sàng. Cách phù hợp phụ thuộc vào website, dịch vụ lưu trữ, dữ liệu và hậu quả nếu thay đổi thất bại.

Vì sao thay đổi cơ sở dữ liệu lại khác?

Cơ sở dữ liệu có thể lưu đơn hàng hiện tại, tài khoản, lịch đặt, nội dung biểu mẫu, hàng tồn kho, thông tin thành viên hoặc nội dung đã xuất bản. Trong quá trình phát hành, cả phiên bản cũ lẫn mới có thể cần tiếp tục sử dụng dữ liệu đó.

Nếu cấu trúc cơ sở dữ liệu thay đổi theo cách chỉ một phiên bản phần mềm hiểu được, việc quay lại phiên bản trước có thể không còn đơn giản. Những thay đổi kéo dài cũng có thể cạnh tranh tài nguyên với hoạt động bình thường của website. Vì vậy, một số đợt phát hành tách riêng việc chuẩn bị cơ sở dữ liệu khỏi cập nhật ứng dụng, duy trì khả năng tương thích giữa cấu trúc cũ và mới trong một thời gian, hoặc chuyển dữ liệu theo từng lô có kiểm soát.

Hướng dẫn công khai của GitLab về chuyển đổi cơ sở dữ liệu cho thấy kế hoạch này có thể chi tiết đến mức nào. Tài liệu phân biệt chuyển đổi thông thường, sau triển khai và chạy nền; đồng thời yêu cầu xem xét thời điểm, khả năng đảo ngược, giao dịch và tranh chấp khóa. Các phương pháp cụ thể này không phù hợp với mọi website, nhưng nguyên tắc chung rất hữu ích: thay đổi dữ liệu trực tiếp cần kế hoạch phát hành và khôi phục riêng.

Bản sao lưu có giống với việc quay lui không?

Không. Bản sao lưu là bản sao dữ liệu hoặc tệp được lưu giữ để có thể khôi phục. Quay lui là cách đã chuẩn bị để trở về trạng thái hoạt động đã biết sau khi phát hành không thành công.

Khôi phục bản sao lưu có thể mất thời gian và có thể ghi đè các đơn hàng, yêu cầu, chỉnh sửa hoặc thay đổi tài khoản hợp lệ phát sinh sau thời điểm sao lưu. Có thể nhanh chóng đưa mã website về phiên bản trước, nhưng việc đó không nhất thiết đảo ngược thay đổi cơ sở dữ liệu hoặc thao tác đã được dịch vụ thanh toán, đặt lịch hay email bên ngoài hoàn tất.

Kế hoạch có trách nhiệm xác định điều gì có thể hoàn tác, điều gì cần sửa tiếp và xử lý dữ liệu phát sinh trong thời gian thay đổi ra sao. Hướng dẫn của AWS về thay đổi không thành công khuyến nghị chuẩn bị các bước khôi phục trước khi triển khai và dùng hoạt động giám sát để quyết định thay đổi có thành công hay không.

Vì sao một số người vẫn thấy trang cũ sau khi cập nhật?

Website có thể duy trì khả năng truy cập trong suốt quá trình cập nhật, nhưng một số khách truy cập vẫn có thể tạm thời nhận các phiên bản khác nhau của trang hoặc tệp. Trình duyệt, mạng phân phối nội dung, bộ nhớ đệm máy chủ và trang được tạo sẵn có thể giữ nội dung cũ cho đến khi hết hạn, được xác thực lại hoặc được chủ động xóa.

Điều này khác với sự cố ngừng hoạt động. Tuy vậy, nó vẫn quan trọng nếu cập nhật thay đổi giá, điều khoản, thông tin chiến dịch, tình trạng còn hàng hoặc dữ liệu nhạy cảm về thời gian khác.

Việc xóa bộ nhớ đệm cũng cần có giới hạn hợp lý. Cloudflare khuyến nghị xóa có mục tiêu khi có thể, vì xóa toàn bộ bộ nhớ đệm khiến các yêu cầu tiếp theo quay về máy chủ gốc cho đến khi nội dung được lưu lại. Kế hoạch phát hành nên xác định trang và tệp đã đổi thay vì coi mọi bộ nhớ đệm là một khối có thể xóa tùy ý.

Khi nào chọn khoảng thời gian bảo trì là có trách nhiệm?

Khoảng thời gian bảo trì có thể phù hợp khi duy trì toàn bộ hoạt động của website trong lúc cập nhật tạo ra rủi ro lớn hơn một lần gián đoạn ngắn đã được thông báo. Chẳng hạn:

• không thể thay đổi an toàn dữ liệu trực tiếp trong lúc cập nhật;
• phiên bản cũ và mới không thể cùng hoạt động trên một cấu trúc dữ liệu;
• cần thay đổi hạ tầng hoặc định tuyến mạng trong một bước có kiểm soát;
• nhà cung cấp bên ngoài yêu cầu gián đoạn hoặc không có đường thử nghiệm song song;
• chưa hiểu đủ về website hiện tại để thay đổi trực tiếp một cách an toàn;
• việc khôi phục sẽ rõ ràng và nhanh hơn nếu tạm dừng hoạt động trong một khoảng thời gian xác định.

Khoảng thời gian này cần có lý do, phạm vi, thời lượng dự kiến, quyết định khôi phục và kế hoạch thông báo. Với doanh nghiệp phụ thuộc vào yêu cầu liên hệ, đơn hàng, lịch đặt hoặc quyền truy cập thành viên, chỉ nói “website sẽ ngừng hoạt động để bảo trì” là chưa đủ.

Nên hỏi gì trước khi duyệt cập nhật?

• Những trang và chức năng nào sẽ thay đổi?
• Khách truy cập và nhân viên vẫn có thể làm gì trong thời gian thực hiện?
• Thay đổi có được chuẩn bị ở nơi riêng với website công khai không?
• Yêu cầu liên hệ, thanh toán, lịch đặt, thay đổi tài khoản và dữ liệu trực tiếp khác được bảo vệ thế nào?
• Kiểm tra nào sẽ xác nhận phát hành thành công?
• Kế hoạch khôi phục là gì nếu một bước kiểm tra không đạt?
• Có thể quay lui phần mềm mà vẫn giữ dữ liệu mới hợp lệ không?
• Dịch vụ lưu trữ, thanh toán, email, xác thực danh tính, đặt lịch hoặc dịch vụ bên ngoài khác có ảnh hưởng đến thời điểm không?
• Ai quyết định tiếp tục, sửa chữa hay quay lui?
• Người dùng bị ảnh hưởng sẽ được thông báo như thế nào và khi nào?

Câu trả lời không cần mô tả từng lệnh kỹ thuật. Chúng cần làm rõ ảnh hưởng đối với doanh nghiệp.

LINK-V xử lý cập nhật website như thế nào?

Khi đánh giá hoặc bảo trì website, chúng tôi xem xét website, dịch vụ lưu trữ, CMS, cơ sở dữ liệu, tích hợp, bản sao lưu, quyền truy cập và rủi ro vận hành trước khi quyết định cách phát hành công việc. Cách làm phù hợp phụ thuộc vào nội dung thay đổi và hệ thống hiện có.

Mục tiêu của chúng tôi là để các cập nhật thông thường diễn ra bình tĩnh, tương xứng, đồng thời trao đổi rõ ràng khi thay đổi cần một lần gián đoạn có kiểm soát. Nếu website hỗ trợ bán hàng hằng ngày, yêu cầu liên hệ, lịch đặt, thành viên hoặc nội dung xuất bản, chúng tôi có thể đánh giá cách tổ chức bảo trì và chăm sóc liên tục.