“Chạy được trên prod”: nó là gì, tại sao xảy ra và vì sao nguy hiểm

Cụm từ “chạy được trên prod” có nghĩa là gì

“Chạy được trên prod” — là một cách nói cố định trong giới lập trình viên, chỉ tình huống code hoạt động trên máy chủ production nhưng từ chối hoạt động trên môi trường kiểm thử hoặc máy local của đồng nghiệp. Bề ngoài nghe như “không có vấn đề gì” mặc dù thực tế vấn đề có tồn tại — nó chỉ không tái hiện được trong môi trường production. Gốc rễ của sự khác biệt nằm ở sự khác nhau về cấu hình, phiên bản và dữ liệu giữa các môi trường.

Cụm từ này ra đời như một phiên bản đối lập của một câu nói biện hộ nổi tiếng khác — “Máy local của tôi chạy được”. Nếu lập trình viên nói “chạy được trên local”, nghĩa là lỗi chỉ tồn tại ở người khác. Còn nếu “chạy được trên prod” — lỗi chỉ tồn tại trên staging hoặc môi trường kiểm thử, còn production thì sạch sẽ. Trớ trêu thay: trong cả hai trường hợp, vấn đề là có thật, nó chỉ không xuất hiện với người đang xem mà thôi. Theo nghiên cứu của DevOps Research and Assessment (DORA) 2023, các đội nhóm có mức độ tự động hóa triển khai cao gặp phải sự khác biệt này ít hơn 3 lần.

Từ góc độ kinh doanh, tình huống “chạy được trên prod” nguy hiểm hơn vẻ ngoài. Nếu lỗi có trên staging nhưng không trên prod, lập trình viên có thể bỏ qua nó — và lần triển khai tiếp theo, lỗi sẽ chuyển lên production. Sự nhẹ nhõm tạm thời biến thành vấn đề tương lai mà sẽ phải sửa dưới áp lực từ người dùng.

Tại sao lập trình viên nói “chạy được trên prod”

Lý do tâm lý cho sự tồn tại của cụm từ này — phản xạ tự vệ. Lập trình viên thấy lỗi trên staging nhưng không thấy trên prod có thể vô thức coi nhẹ vấn đề: “vì production vẫn ổn, nên không khẩn cấp”. Một dạng thiên lệch nhận thức kinh điển — sai lầm của người sống sót, nơi thành công hiện hữu của production lấn át mối đe dọa tiềm tàng của sự cố tương lai.

Lý do thứ hai — trách nhiệm mơ hồ. Nếu production chạy được mà staging không, thì môi trường có lỗi, chứ không phải code. Lập trình viên thoái thác trách nhiệm về lỗi, đẩy nó sang kỹ sư DevOps hoặc quản trị viên. Theo Atlassian State of DevOps 2022, trong các đội nhóm không có môi trường triển khai thống nhất (Docker, Kubernetes), việc đổ lỗi như vậy xảy ra nhiều hơn 60%.

Lý do thứ ba — nỗi sợ release với zero downtime. Nếu lập trình viên sửa lỗi trên staging và triển khai bản sửa, điều này đòi hỏi phải code review lại, kiểm thử và triển khai. Cụm từ “chạy được trên prod” cho phép hoãn việc sửa lỗi đến bản phát hành tiếp theo, giảm tải hiện tại. Sửa lỗi bị trì hoãn — một trong những nguyên nhân chính tích tụ nợ kỹ thuật trong các đội nhóm.

Sự khác biệt giữa môi trường phát triển và production

Production và staging không bao giờ hoàn toàn giống hệt nhau — điều này là không thể về mặt kỹ thuật do sự khác biệt về quy mô, tải và dữ liệu. Tuy nhiên, các thông số chính phải trùng khớp: phiên bản hệ điều hành, trình biên dịch, trình thông dịch, cơ sở dữ liệu, máy chủ web và tất cả dependency của dự án. Nếu chỉ một thông số khác biệt — hành vi của code có thể thay đổi.

Các khác biệt chính giữa các môi trường bao gồm:

• Phần cứng — bộ xử lý, dung lượng RAM, loại đĩa (SSD vs HDD) có thể ảnh hưởng đến thời gian xử lý và hoạt động đa luồng
• Môi trường mạng — firewall, DNS, proxy, bộ cân bằng tải chỉ có trên prod
• Dữ liệu trong DB — trên staging thường có dữ liệu kiểm thử, còn bản ghi người dùng thực tế có các mẫu không mong đợi
• Phiên bản dependency — ngay cả bản cập nhật nhỏ của thư viện cũng có thể thay đổi hành vi code
• Biến môi trường — khóa API, token, cờ tính năng có thể khác nhau giữa các môi trường

Container hóa giải quyết phần lớn các vấn đề này. Docker image được xây dựng cho production cũng nên được sử dụng trên staging. Điểm khác biệt duy nhất — biến môi trường và mount volume. Theo Docker State of Application Development 2023, các đội nhóm sử dụng image thống nhất cho tất cả môi trường giảm số lượng khác biệt tới 74%.

Nguyên nhân điển hình của sự không khớp hành vi trên prod

Nguyên nhân đầu tiên và phổ biến nhất — phiên bản dependency khác nhau. Lập trình viên cài đặt gói trên local với cờ --save nhưng quên cập nhật package.json hoặc lock-file. Khi triển khai lên prod, một phiên bản khác được cài đặt và hoạt động khác đi. Đối với hệ sinh thái npm, lock-file giải quyết hoàn toàn vấn đề, đối với các trình quản lý gói khác — cơ chế tương tự (Gemfile.lock, Podfile.lock, pubspec.lock).

Nguyên nhân thứ hai — biến môi trường thiếu hoặc thừa. Lập trình viên sử dụng tệp .env trên máy local nhưng không thêm các biến tương ứng vào pipeline CI/CD hoặc trên máy chủ. Kết quả — code thất bại với lỗi kết nối API hoặc cơ sở dữ liệu. Theo GitLab DevSecOps Survey 2023, 27% sự cố trên prod liên quan đến biến môi trường không chính xác.

Nguyên nhân thứ ba — trạng thái cơ sở dữ liệu. Trên staging, DB có thể chứa các bản ghi không có trên prod, hoặc ngược lại — thiếu migration. Kịch bản điển hình: lập trình viên viết code sử dụng trường mới trong bảng, nhưng migration chưa được áp dụng trên prod. Chiến lược migration tương thích ngược — cách duy nhất để tránh những tình huống như vậy.

Nguyên nhân thứ tư — cài đặt ngôn ngữ và khu vực. Định dạng ngày tháng, dấu phân cách số thập phân, mã hóa văn bản — tất cả có thể khác nhau trên máy local của lập trình viên và máy chủ. Đặc biệt quan trọng đối với các dự án có quốc tế hóa. Giải pháp — chỉ định locale rõ ràng trong cấu hình ứng dụng và không phụ thuộc vào cài đặt hệ thống.

Cách chẩn đoán vấn đề “chạy được trên prod”

Bước đầu tiên — so sánh log của cả hai môi trường. Sự khác biệt về mức log thường che giấu nguyên nhân: trên prod có thể bật INFO, còn trên staging là DEBUG. Thiết lập cùng mức log và đảm bảo cả hai môi trường ghi ở định dạng cho phép so sánh tự động. Sử dụng hệ thống thu thập log tập trung — Sentry, Datadog, ELK Stack.

Bước thứ hai — kiểm tra phiên bản dependency. So sánh lock-file, hiển thị danh sách gói đã cài đặt trên cả hai môi trường. Sự khác biệt về phiên bản nhỏ hoặc bản vá — nguyên nhân có khả năng nhất của sự không khớp. Các công cụ như npm ls, pip freeze, mvn dependency:tree sẽ giúp nhanh chóng phát hiện sự không nhất quán.

Bước thứ ba — tái tạo môi trường production trên local. Sử dụng Docker Compose hoặc các công cụ tương tự để tạo bản sao chính xác của hạ tầng production. Nếu lỗi tái tạo được trong container local — vấn đề nằm ở code, không phải môi trường. Nếu không tái tạo được — hãy tìm sự khác biệt trong cấu hình.

Bước thứ tư — kiểm tra feature flags và A/B test. Có thể trên prod code hoạt động ở chế độ khác vì cờ sai đang được bật. Theo LaunchDarkly State of Feature Management 2023, có tới 40% hành vi bất ngờ trên prod liên quan đến giá trị feature flags không chính xác. Bảng kê khai cờ thống nhất cho tất cả môi trường giải quyết vấn đề này.

Ngăn chặn sự khác biệt môi trường trong dự án

Công cụ ngăn chặn chính — Infrastructure as Code (IaC). Tất cả các môi trường phải được mô tả trong code: Dockerfile, docker-compose.yml, script Terraform hoặc playbook Ansible. Các thay đổi thủ công trên máy chủ bị cấm — mọi thay đổi cấu hình đều phải qua kho lưu trữ và code review. Điều này đảm bảo tất cả các môi trường có cùng cấu hình.

Công cụ quan trọng thứ hai — pipeline CI/CD thống nhất. Cùng một script xây dựng, kiểm thử và triển khai phải được sử dụng cho tất cả môi trường. Sự khác biệt — chỉ ở biến đích (URL, khóa). Nếu pipeline cho staging và production khác nhau về các bước — sự khác biệt là không thể tránh khỏi.

Công cụ thứ ba — đồng bộ hóa dữ liệu tự động. Thường xuyên (mỗi ngày một lần hoặc theo lịch) cập nhật staging bằng bản sao đã ẩn danh của cơ sở dữ liệu production. Điều này cho phép kiểm thử code trên dữ liệu thực tế thay vì fixture tổng hợp. Công cụ: pg_dump/pg_restore cho PostgreSQL, mysqldump cho MySQL, các dịch vụ chuyên dụng như DataGrip.

Thứ tư — giám sát sự khác biệt. Thiết lập cảnh báo khi phát hiện khác biệt giữa staging và production. Một script đơn giản so sánh hash của tệp cấu hình hoặc phiên bản gói đã cài đặt sẽ tiết kiệm hàng giờ gỡ lỗi. Phòng ngừa luôn rẻ hơn chẩn đoán: ngăn chặn sự khác biệt môi trường đòi hỏi ít công sức hơn tìm kiếm nguyên nhân của lỗi “chạy được trên prod”.