Xây Dựng Deployment Pipeline Biến Việc Release Thành Chuyện Nhàm Chán

Một bản release đòi hỏi phòng chỉ huy khẩn cấp, một kỹ sư on-call thức đến nửa đêm, và một kênh Slack tên "deploy-watch" không phải là dấu hiệu của một quy trình deployment trưởng thành — đó là dấu hiệu pipeline đang phải bù đắp cho rủi ro lẽ ra phải được xử lý từ sớm hơn. Mục tiêu của một deployment pipeline tốt không phải là release nhanh vì bản thân tốc độ. Đó là những bản release nhàm chán đến mức không ai phải lên kế hoạch cho buổi tối của mình vì nó.

Tách deploy khỏi release bằng feature flag

Thay đổi có đòn bẩy cao nhất mà hầu hết các đội chưa thực hiện là tách biệt "code đã được deploy" khỏi "tính năng đã sống với người dùng". Khi đã có hệ thống feature flag — LaunchDarkly, Unleash, hoặc một dịch vụ flag tự xây dựng dựa trên key-value store nhanh — deployment trở thành một sự kiện rủi ro thấp, thường xuyên, và nhàm chán, vì việc deploy code đằng sau một flag không thay đổi gì với người dùng cho đến khi flag đó được bật lên.

Điều này mở khóa một vài thực hành không thể hoạt động nếu thiếu nó:

• Deploy vào thứ Sáu trở nên bình thường, vì deploy không đồng nghĩa với release. Code nằm im đằng sau flag cho đến khi ai đó cố ý bật nó lên, lý tưởng là không phải lúc 4 giờ chiều thứ Sáu.
• Kiểm thử trên production với hạ tầng thực, giới hạn cho người dùng nội bộ hoặc một tỷ lệ nhỏ traffic, trước khi rollout toàn bộ — bắt được những vấn đề mà môi trường staging, vốn không bao giờ khớp hoàn toàn với production, bỏ sót.
• Rollback tức thì không cần redeploy. Tắt một flag chỉ mất vài giây; revert một deployment và chờ build mới rollout mất nhiều thời gian hơn đáng kể, trong khi đó người dùng vẫn đang gặp vấn đề.

Cái bẫy cần tránh: những flag tồn tại mãi mãi. Một flag còn nằm trong codebase sáu tháng sau khi tính năng đã ra mắt hoàn toàn là gánh nặng chết và nguồn gây bối rối cho kỹ sư tiếp theo tìm thấy nó. Chúng tôi áp dụng việc rà soát hết hạn flag như một phần của vệ sinh sprint — mỗi flag có một chủ sở hữu và một ngày dự kiến gỡ bỏ ngay từ khi tạo ra.

Progressive delivery giới hạn bán kính ảnh hưởng bằng kiến trúc

Ngay cả khi có flag, việc bật một tính năng cho 100% người dùng cùng lúc nghĩa là 100% người dùng bị ảnh hưởng nếu có gì sai. Progressive delivery — canary release, rollout theo tỷ lệ phần trăm — giới hạn mức độ tiếp xúc về mặt cấu trúc, thay vì dựa vào việc ai đó phát hiện vấn đề đủ nhanh trong lúc rollout toàn bộ.

Một mô hình rollout đã hoạt động tốt qua nhiều dự án khách hàng:

1. 1% traffic, trong 30-60 phút, theo dõi dựa trên một tập chỉ số sức khỏe xác định trước (tỷ lệ lỗi, latency p99, chỉ số kinh doanh như tỷ lệ chuyển đổi) với rollback tự động nếu bất kỳ chỉ số nào vượt ngưỡng.
2. 10% traffic, vài giờ đến một ngày, đủ lâu để bắt được những vấn đề chỉ xuất hiện dưới các pattern traffic thực đa dạng hơn.
3. 50%, rồi 100%, mỗi giai đoạn được kiểm soát bởi cùng những chỉ số sức khỏe đó, không chỉ dựa trên thời gian đã trôi qua.

Cơ chế kích hoạt rollback tự động là phần các đội thường bỏ qua nhất, thay vào đó thực hiện rollout theo tỷ lệ phần trăm thủ công và theo dõi dashboard bằng mắt. Cách đó vẫn ổn cho đến khi người theo dõi rời đi hoặc bỏ lỡ một chỉ số đang suy giảm chậm rãi. Kết nối rollback để tự động kích hoạt dựa trên ngưỡng chỉ số — không chờ con người nhận ra — mới thực sự giới hạn bán kính ảnh hưởng khi có sự cố xảy ra ngoài giờ làm việc.

Chiến lược rollback phải được diễn tập, không chỉ ghi lại trên giấy

Một kế hoạch rollback chỉ tồn tại trong một runbook mà không ai thực thi trong sáu tháng là một kế hoạch sẽ thất bại đúng vào lúc cần đến nó nhất, vì người thực thi nó dưới áp lực đang làm điều đó lần đầu tiên. Chúng tôi thúc đẩy mọi khách hàng hướng đến một thực hành cụ thể: chạy diễn tập rollback, trên một service không quan trọng, theo lịch trình — tối thiểu hàng quý — giống cách các buổi diễn tập disaster recovery hoạt động với hạ tầng.

Rollback cũng cần bao phủ nhiều hơn là "deploy lại image container trước đó". Những phần thực sự gây thất bại rollback trong thực tế:

• Migration database không tương thích ngược. Nếu migration của phiên bản mới xóa một cột mà code của phiên bản cũ vẫn đọc, rollback ứng dụng mà không rollback schema sẽ làm mọi thứ tệ hơn cả vấn đề ban đầu. Mọi migration trong pipeline nên được kiểm tra tính tương thích ngược với phiên bản ứng dụng trước đó trước khi merge, chứ không phải phát hiện ra trong lúc xử lý sự cố.
• Các request đang xử lý dở dang có trạng thái. Một rollback giữa lúc deployment có thể để lại một số request được xử lý bởi phiên bản mới và một số bởi phiên bản cũ, đặc biệt với hàng đợi job bất đồng bộ — đáng để quyết định rõ ràng liệu các job đang xử lý dở nên được rút cạn (drain) hay hủy trước khi rollback tiếp tục.

"Nhàm chán" thực sự trông như thế nào trong đời sống hàng ngày

Ở những dự án chúng tôi đã xây dựng đầy đủ mô hình này, thay đổi có thể nhìn thấy không phải là thời gian deploy ngắn hơn trên một dashboard — mà là kỹ sư không còn nhắc đến deploy trong standup nữa, vì không ai lo lắng về chúng. Release diễn ra nhiều lần một ngày, không cần người canh, với các health check tự động đảm nhận việc theo dõi từng đòi hỏi một người ngồi nhìn Grafana. Một bản release tệ thỉnh thoảng xuất hiện được bắt ở mức 1% traffic và tự động rollback trước khi hầu hết người dùng kịp nhận ra, thay vì trở thành một buổi họp postmortem.

Đạt được điều này là một khoản đầu tư kỹ thuật thực sự — hạ tầng feature flag, tự động hóa rollout được kiểm soát bởi chỉ số sức khỏe, và công cụ rollback đã thực sự được kiểm thử — chứ không phải một danh sách checklist hoàn thành trong một sprint. Nhưng đây là một trong những khoản đầu tư có lợi suất cao nhất mà một đội platform có thể thực hiện, và đó là loại công việc pipeline mà chúng tôi xây dựng như một phần nền tảng của bất kỳ dự án DevOps nào, chứ không phải một tùy chọn thêm.