Chiến lược triển khai và chiến lược kiểm thử ứng dụng đang vận hành

1. Tổng quan

A. Định nghĩa

Là chiến lược đưa phiên bản mới vào ứng dụng đang vận hành (không gián đoạn) một cách an toàn mà không ảnh hưởng đến dịch vụ, đồng thời kiểm chứng lỗi và hiệu năng trước và sau triển khai để kiểm soát rủi ro phát hành. Đây là trục cốt lõi của thực hành CI/CD và DevOps.

B. Bối cảnh ra đời và sự cần thiết

Cách làm như trước đây — dừng dịch vụ rồi đưa lên toàn bộ phiên bản mới — với các dịch vụ vận hành 24/365 ngày nay đồng nghĩa với tổn thất doanh thu và uy tín. Hơn nữa, khi chu kỳ triển khai ngắn lại (nhiều lần trong một ngày) và đơn vị triển khai được chia nhỏ theo microservice, cách tiếp cận "thay đổi tất cả một lần, có vấn đề thì hoàn tác" có rủi ro quá lớn. Vì vậy cần các chiến lược triển khai từng bước phơi bày thay đổi trước cho một số ít người dùng và một số ít instance để phát hiện sớm rủi ro, và hoàn tác ngay nếu có vấn đề (Zero-downtime·rollback nhanh). Tư tưởng cốt lõi là giảm thiểu bán kính ảnh hưởng (Blast Radius), tức là dù có sự cố thì phạm vi bị ảnh hưởng vẫn được giữ hẹp nhất có thể.

2. Chiến lược triển khai

flowchart TB
  D[Chiến lược triển khai không gián đoạn] --> BG[Blue-Green]
  D --> CA[Canary]
  D --> RO[Rolling]
  D --> AB[A/B testing]

Các chiến lược triển khai không gián đoạn khác nhau ở "phơi bày phiên bản mới như thế nào", và mỗi chiến lược có sự cân bằng khác nhau giữa tốc độ rollback, chi phí tài nguyên và khả năng phát hiện rủi ro.

Blue-Green là cách dựng thêm một môi trường vận hành giống hệt, hoàn thiện phiên bản mới ở đó rồi chuyển toàn bộ lưu lượng một lần qua bộ cân bằng tải, nên nếu có vấn đề chỉ cần chuyển lại về môi trường cũ, rollback là tức thì. Đổi lại, phải duy trì đồng thời hai môi trường nên tốn gấp đôi tài nguyên. Canary, như cái tên bắt nguồn từ việc thợ mỏ mang theo chim hoàng yến (canary) để phát hiện khí độc, là cách phơi bày phiên bản mới dần dần 5%→25%→100% trong khi theo dõi các chỉ số, nên có thể bắt được rủi ro sớm nhất. Rolling thay từng instance một sang phiên bản mới nên hầu như không cần hạ tầng bổ sung, nhưng nếu vấn đề được phát hiện muộn thì mất thời gian để hoàn tác các instance đã thay. A/B testing mang tính chất thử nghiệm so sánh hiệu quả kinh doanh như tỷ lệ chuyển đổi của hai phiên bản hơn là một kỹ thuật triển khai.

3. Chiến lược kiểm thử (gắn với các giai đoạn triển khai)

Dù chiến lược triển khai tinh vi đến đâu, nếu không có sự hỗ trợ của việc kiểm chứng cái gì ở mỗi giai đoạn thì không thể sàng lọc được rủi ro. Vì vậy kiểm thử được bố trí chia thành trước–trong–sau triển khai.

Cốt lõi của giai đoạn trước triển khai là kiểm thử hồi quy, xác nhận thay đổi không làm hỏng chức năng hiện có để đảm bảo độ tin cậy của ứng viên phát hành. Trong khi triển khai, phân tích canary so sánh theo thời gian thực tỷ lệ lỗi và độ trễ phản hồi giữa phiên bản mới và cũ, nếu thấy suy giảm có ý nghĩa thống kê thì dừng mở rộng và kích hoạt rollback. Trong các kỹ thuật sau triển khai, shadow (dark launch) sao chép lưu lượng thực và gửi cả sang phiên bản mới nhưng không trả phản hồi đó cho người dùng, nhờ đó kiểm chứng hành vi dưới tải vận hành mà không ảnh hưởng người dùng. Feature toggle (Feature Flag) triển khai sẵn mã nhưng điều khiển riêng việc phơi bày chức năng bằng công tắc, tách triển khai (Deploy) khỏi phát hành (Release), nên khi có vấn đề có thể ứng phó ngay chỉ bằng tắt công tắc mà không cần triển khai lại.

4. Các yếu tố hỗ trợ triển khai an toàn

Để triển khai từng bước và kiểm thử phát huy hiệu quả, phải có tiền đề là nền tảng "nhìn thấy được" bất thường và "tự động hoàn tác được" khi có vấn đề.

Đặc biệt, khả năng quan sát và rollback tự động là điều kiện tiên quyết của triển khai an toàn. Dù đã phơi bày cho 5% bằng canary, nếu không phát hiện được bằng metric việc tỷ lệ lỗi tăng vọt trong 5% đó thì chính mục đích phát hiện sớm rủi ro sụp đổ, và dù phát hiện được mà con người ứng phó thủ công thì trong lúc đó thiệt hại sẽ lớn lên. Vì vậy cần cấu trúc tự động chuyển ngược lưu lượng khi vi phạm ngưỡng.

5. Các vấn đề cần cân nhắc và hàm ý

• Khả năng quan sát + rollback tự động là tiền đề: Nếu không có phán đoán dựa trên chỉ số và khôi phục tự động thì không chiến lược triển khai từng bước nào đảm bảo được an toàn.
• Tự động hóa progressive delivery: Đang phát triển theo hướng tự động hóa khai báo (declarative) việc mở rộng, phân tích và rollback canary bằng GitOps và các công cụ như Argo Rollouts, Flagger.
• Xử lý không gián đoạn khi thay đổi lược đồ DB: Dù ứng dụng không gián đoạn, việc thay đổi lược đồ DB khiến phiên bản cũ và mới tạm thời cùng tồn tại, nên phải duy trì tương thích ngược bằng mẫu Expand-Contract (mở rộng-thu hẹp) — thêm cột trước và xóa sau — mới ngăn được sự cố trong khi triển khai.

Tóm tắt một câu: Triển khai không gián đoạn kiểm soát rủi ro bằng cách giảm thiểu bán kính ảnh hưởng với Blue-Green·Canary·Rolling·A/B, liên kết theo từng giai đoạn kiểm thử trước (hồi quy)–trong (phân tích canary)–sau (shadow·feature toggle) triển khai, và lấy khả năng quan sát·rollback tự động làm tiền đề để hiện thực hóa phát hành an toàn bằng progressive delivery và thay đổi DB theo Expand-Contract.