Series Phỏng vấn Jenkins Thực chiến #4: "Thay lốp xe khi đang chạy" – Nghệ thuật Zero-Downtime Deployment

1. Câu hỏi từ Nhà tuyển dụng

"Tôi thấy trong Jenkinsfile của bạn có đoạn lệnh docker rm -f old-container sau đó mới gọi docker run new-container. Nếu hệ thống AFC đang xử lý hàng ngàn giao dịch mỗi phút, khoảng hở giữa lệnh tắt và bật này sẽ tạo ra 'downtime' (thời gian chết), làm rớt toàn bộ request của khách hàng. Bạn sẽ thiết kế lại luồng CI/CD này như thế nào để đạt được Zero-Downtime Deployment?"

2. Phân tích tâm lý Nhà tuyển dụng

Mục đích thực sự của câu hỏi này không phải để chê đoạn script Docker của bạn, mà là để kiểm tra:

Bạn có hiểu ranh giới giữa việc "viết code chạy được" và "vận hành hệ thống không gián đoạn" không.
Kiến thức về các chiến lược triển khai kinh điển: Rolling Update, Blue/Green Deployment, hoặc Canary Release.
Sự am hiểu về kiến trúc mạng (Load Balancer, Health Check).

3. Cách trả lời ghi điểm tuyệt đối (Mẫu tham khảo)

Để thuyết phục nhà tuyển dụng, hãy thể hiện tư duy của một kỹ sư hệ thống dạn dày kinh nghiệm qua 3 cấp độ:

Cấp độ 1: Nhìn nhận vấn đề của lệnh docker rm

"Đoạn lệnh docker rm nối tiếp docker run là cách deploy cơ bản nhất (Recreate strategy), nó chắc chắn sẽ gây ra downtime vì ứng dụng cũ bị giết trước khi ứng dụng mới kịp khởi động và kết nối thành công vào Database Vitess. Đối với các hệ thống cần độ sẵn sàng cao, em tuyệt đối không dùng cách này trên môi trường Production."

Cấp độ 2: Trình bày giải pháp Kiến trúc (Blue/Green Deployment)

"Để đạt Zero-Downtime, em sẽ áp dụng chiến lược Blue/Green Deployment kết hợp với một Load Balancer (như Nginx, HAProxy hoặc AWS ALB). Quy trình trong Jenkins sẽ được viết lại như sau:

Deploy bản mới (Green): Jenkins không đụng chạm gì đến container đang chạy (Blue). Nó sẽ khởi chạy bản cập nhật mới (Green) trên một port khác hoặc một server khác.
Health Check (Kiểm tra sức khỏe): Jenkins gọi một script để ping vào endpoint /health của bản Green. Chỉ khi nào service Golang trả về status 200 (đã kết nối xong database, Kafka sẵn sàng), Jenkins mới đi tiếp.
Switch Traffic (Đảo luồng): Jenkins gọi lệnh cập nhật cấu hình của Load Balancer để trỏ toàn bộ traffic của người dùng từ bản Blue sang bản Green.
Dọn dẹp: Chờ một khoảng thời gian (grace period) để bản Blue xử lý nốt các request cũ đang dang dở, sau đó Jenkins mới tiến hành tắt bản Blue đi."

Cấp độ 3: Đỉnh cao thực chiến – Bài toán Database (Điểm 10/10)

"Tuy nhiên, việc đảo traffic bằng container chỉ là bề nổi. Thách thức lớn nhất của Zero-Downtime thực chất nằm ở Database Migration. Nếu bản cập nhật (Green) yêu cầu thêm một cột mới vào bảng giao dịch, em phải thiết kế cấu trúc database sao cho nó tương thích ngược (backward-compatible). Cụ thể, file script chạy Migration phải được tách ra chạy độc lập trước khi deploy code. Code bản cũ (Blue) và code bản mới (Green) đều phải hoạt động bình thường trên cùng một schema mới đó trong suốt quá trình chuyển giao. Nếu không làm vậy, ứng dụng có thể không chết, nhưng database sẽ văng lỗi liên tục."

4. Góc nhỏ "Bắt bẻ" (Nhà tuyển dụng phản đòn)

Khi bạn tự tin đưa ra phương án Blue/Green cực kỳ mượt mà, người phỏng vấn sẽ đưa ra một tình huống "thảm họa" để xem tốc độ phản xạ của bạn.

Interviewer vặn lại: "Rất tốt! Traffic đã chuyển sang bản Green. Nhưng 5 phút sau, hệ thống giám sát báo động đỏ: Có lỗi logic trong code khiến các giao dịch ngoại tuyến (offline data sync) không đồng bộ được, sinh ra lượng lớn Orphan Transactions. Bạn rollback (quay xe) về bản Blue như thế nào để nhanh nhất? Có phải chạy lại pipeline từ đầu không?"
Cách bạn "đỡ đòn": "Tuyệt đối không chạy lại pipeline build code từ đầu vì sẽ mất rất nhiều thời gian. Trong thiết kế Blue/Green chuẩn, bản Blue cũ không bị xóa ngay lập tức mà vẫn được giữ trạng thái 'ngủ đông' (hoặc giữ container sống nhưng không nhận traffic) trong một khoảng thời gian an toàn. Em sẽ thiết kế một Jenkins Job chuyên dụng cho việc Rollback. Khi có sự cố, em chỉ cần bấm kích hoạt Job này. Nhiệm vụ duy nhất của nó là gọi lệnh đảo ngược cấu hình Nginx/Load Balancer, điều hướng traffic trở về lại bản Blue ngay lập tức. Toàn bộ quá trình giải cứu diễn ra chưa tới 3 giây!"

Bạn thấy câu hỏi này thế nào? Nó ép chúng ta phải thoát khỏi tư duy gõ lệnh Docker đơn thuần để nhìn hệ thống dưới góc độ mạng lưới và dữ liệu.

Ở Bài 5 – bài cuối cùng của series phỏng vấn này, chúng ta sẽ đi vào một kịch bản hóc búa nhất: Quản trị Bí mật (Secrets Management) ở quy mô Enterprise với HashiCorp Vault. Sẵn sàng chinh phục đỉnh cao cuối cùng chưa?