Chiến lược rollback không gián đoạn và tự động hóa triển khai CI/CD

Nhiều đội phát triển chỉ nhận ra quy trình triển khai (deployment) của mình thiếu an toàn vào đúng thời điểm một bản phát hành mới gây lỗi nghiêm trọng trên môi trường vận hành: thao tác quay lại bản cũ làm hỏng dữ liệu vừa ghi, tệp cấu hình phải sửa tay trên máy chủ hoặc chỉ một cá nhân trong nhóm nắm được các bước khôi phục.

Một chiến lược rollback không gián đoạn không bắt đầu lúc sự cố đã nổ ra, mà được quyết định ngay từ cách đóng gói hiện vật (artifact), cách thiết kế thay đổi cơ sở dữ liệu và cách đặt các cổng kiểm chứng trên đường ống CI/CD.

Vì sao thao tác quay lại bản cũ thường thất bại?

Trên lý thuyết, việc quay lui một ứng dụng chỉ đơn giản là trỏ lưu lượng truy cập về phiên bản mã nguồn trước đó. Tuy nhiên trong thực tế vận hành, rollback thường vấp phải ba rào cản lớn:

Thay đổi cơ sở dữ liệu một chiều (Destructive schema migration): Bản phát hành mới đi kèm lệnh đổi tên cột, xóa cột hoặc tách bảng. Khi mã nguồn phiên bản mới gặp lỗi và đội vận hành hạ cấp ứng dụng về phiên bản cũ, phiên bản cũ lập tức báo lỗi hàng loạt vì các cột mà nó truy vấn không còn tồn tại.
Hiện vật triển khai không bất biến (Mutable artifacts): Quy trình deploy cài đặt lại thư viện trực tiếp trên máy chủ đích mà không khóa phiên bản qua lockfile, hoặc ghi đè tệp tĩnh tại chỗ khiến phiên bản cũ và phiên bản mới trộn lẫn vào nhau trong lúc chuyển giao.
Chưa từng diễn tập khôi phục thực tế: Tài liệu vận hành có ghi các bước rollback nhưng chưa bao giờ được chạy thử trên môi trường tương đương production, dẫn đến thiếu quyền truy cập, sai đường dẫn bản sao lưu hoặc thời gian khôi phục vượt xa dự tính.

Ba trụ cột của đường ống triển khai có thể kiểm chứng

Để việc phát hành và quay lui diễn ra nhất quán, đường ống tự động hóa triển khai phần mềm cần đảm bảo ba nguyên tắc kỹ thuật cốt lõi:

Đóng gói một lần, triển khai nhiều nơi (Immutable build artifact): Mỗi bản phát hành được biên dịch từ một mã băm (commit SHA) xác định cùng tệp khóa phụ thuộc (lockfile), vượt qua đầy đủ các bước kiểm kiểu tĩnh, lint, bộ kiểm thử tự động và quét thông tin nhạy cảm trước khi tạo ra gói triển khai duy nhất. Khi cần rollback, hệ thống chỉ kích hoạt lại đúng gói đã được kiểm chứng trước đó thay vì biên dịch lại từ đầu.
Cổng kiểm tra sức khỏe tự động sau khi phát hành (Post-deploy verification): Ngay sau khi bản mới khởi chạy, đường ống thực hiện kiểm tra điểm cuối sức khỏe (healthcheck), xác nhận các luồng nghiệp vụ trọng yếu phản hồi đúng mã trạng thái và theo dõi tỷ lệ lỗi trong cửa sổ quan sát đầu tiên. Nếu chỉ số vượt ngưỡng an toàn, quy trình chuyển lưu lượng được dừng lại ngay.
Giữ nguyên các phiên bản tài nguyên tĩnh trong giai đoạn chuyển tiếp: Với các ứng dụng web hoặc giao diện người dùng có phân tách tệp băm (hashed assets), cần duy trì song song tài nguyên của phiên bản liền trước trong một khoảng thời gian hợp lý hoặc cấu hình bộ nhớ đệm chuẩn xác để những phiên làm việc đang mở của người dùng không bị lỗi tải tệp khi chuyển bản.

Nguyên tắc Expand-Contract cho thay đổi cơ sở dữ liệu tương thích ngược

Chìa khóa quan trọng nhất để đạt được khả năng rollback không gián đoạn là tách rời thời điểm thay đổi cấu trúc dữ liệu (database schema) khỏi thời điểm chuyển đổi mã nguồn ứng dụng thông qua mô hình mở rộng rồi thu hẹp (Expand-Contract):

Bước 1 — Mở rộng (Expand): Chỉ thêm cột mới (cho phép nhận giá trị rỗng hoặc có giá trị mặc định an toàn), thêm bảng mới hoặc tạo chỉ mục không khóa ghi. Ở bước này, mã nguồn phiên bản hiện tại vẫn hoạt động bình thường mà không hề biết tới cấu trúc mới.
Bước 2 — Chuyển đổi mã nguồn và đồng bộ dữ liệu: Triển khai phiên bản ứng dụng mới có khả năng ghi song song hoặc đọc từ cấu trúc mới (có dự phòng đọc cấu trúc cũ), đồng thời chạy tác vụ điền dữ liệu lịch sử theo từng lô nhỏ có kiểm soát tải. Nếu phiên bản ứng dụng mới phát sinh lỗi ở bước này, đội vận hành có thể lập tức quay về phiên bản ứng dụng cũ ngay lập tức mà không mất mát dữ liệu.
Bước 3 — Thu hẹp (Contract): Chỉ sau khi phiên bản mới đã chạy ổn định qua chu kỳ nghiệm thu và xác nhận không còn nhu cầu quay lại phiên bản cũ, đội phát triển mới thực hiện một đợt phát hành riêng để gỡ bỏ các cột hoặc bảng cũ không còn sử dụng.

Bạn có thể tham khảo thêm cách tránh tranh chấp khóa khi chạy migration trong bài xử lý deadlock PostgreSQL và giảm lock wait cũng như quy chuẩn bảo vệ thông tin xác thực trên đường ống CI/CD tại bài bảo mật secrets trong Git và ngăn ngừa rò rỉ credential. Để xem mẫu kiểm tra thực tế, hãy đọc bài lab trên Wiki về kế hoạch phát hành, preflight và rollback, migration schema không khóa bảng và giám sát chỉ số vận hành cơ sở dữ liệu.

Chuẩn hóa quy trình CI/CD và hạ tầng production cùng ShiftLeft

Nếu quy trình phát hành hiện tại của đội bạn vẫn phụ thuộc vào nhiều thao tác thủ công, thiếu cơ chế chặn bản lỗi hoặc chưa có phương án rollback an toàn cho cơ sở dữ liệu, hãy xem chi tiết dịch vụ DevOps và hạ tầng production cùng dịch vụ tối ưu database của ShiftLeft để xây dựng lộ trình vận hành có kiểm chứng.