Tweet
DevSecOps (Phần 14): Dev/Prod Parity – Vì sao "Chạy trên máy em được!" là câu nói đáng sợ nhất?
Có lẽ ai làm phần mềm cũng từng nghe câu nói quen thuộc:
Nhưng khi triển khai lên Production thì:
Nguyên nhân không phải lúc nào cũng do code.
Rất nhiều trường hợp xuất phát từ việc Development, Staging và Production quá khác nhau.
Đó là lý do Yếu tố thứ 10 của 12-Factor App yêu cầu:
Hay nói ngắn gọn:
Ba khoảng cách lớn trong phát triển phần mềm
Theo 12-Factor App, các tổ chức truyền thống thường tồn tại ba "khoảng cách" lớn.
1. Time Gap
Developer hoàn thành tính năng hôm nay.
Nhưng...
Hai tuần sau.
Một tháng sau.
Hoặc ba tháng sau.
Mã nguồn mới được triển khai lên Production.
Trong khoảng thời gian đó:
12-Factor App hướng tới việc rút ngắn khoảng cách này xuống chỉ còn vài phút, thông qua CI/CD Pipeline.
2. Personnel Gap
Trong mô hình truyền thống:
Developer
│
Viết Code
│
──────────────
│
Operations
│
Deploy
Developer gần như không tham gia quá trình triển khai.
Operations lại không hiểu toàn bộ logic của ứng dụng.
Thông tin bị truyền qua nhiều lớp.
Việc xử lý sự cố thường chậm hơn.
Trong DevSecOps, Developer và Operations cùng tham gia vào toàn bộ vòng đời ứng dụng:
Điều này giúp phản hồi nhanh hơn khi có sự cố.
3. Tools Gap
Đây là nguyên nhân phổ biến nhất.
Ví dụ:
Developer:
Production:
Ứng dụng có thể hoạt động hoàn hảo trên máy phát triển nhưng thất bại khi triển khai vì môi trường thực thi khác hoàn toàn.
Khác Database cũng có thể gây lỗi
Nhiều nhóm phát triển chọn SQLite vì đơn giản.
Trong khi Production sử dụng PostgreSQL hoặc MySQL.
Về lý thuyết, ORM hoặc Adapter có thể che giấu sự khác biệt.
Nhưng trên thực tế:
Kết quả là ứng dụng chạy tốt trong môi trường Development nhưng phát sinh lỗi khi triển khai lên Production.
12-Factor App khuyến nghị không nên sử dụng các Backing Services khác nhau giữa các môi trường, vì những khác biệt nhỏ này có thể gây ra các lỗi rất khó phát hiện.
Cache cũng không nên khác nhau
Một ví dụ khác:
Development:
Memory Cache
Production:
Redis
Ứng dụng có thể vô tình phụ thuộc vào hành vi của bộ nhớ cục bộ.
Khi chuyển sang Redis:
Những khác biệt này có thể tạo ra các lỗi chỉ xuất hiện sau khi triển khai.
Docker giúp thu hẹp khoảng cách
Ngày trước:
Developer PC
Windows
Python 3.11
──────────────
Production
Linux
Python 3.10
Ngày nay, với Docker:
Developer
│
Docker Image
│
──────────────
│
Staging
│
──────────────
│
Production
Ba môi trường đều sử dụng cùng một Docker Image.
Điều thay đổi chỉ là:
Nhờ vậy, khả năng xảy ra lỗi do khác biệt môi trường giảm đáng kể.
Infrastructure as Code giúp chuẩn hóa hạ tầng
Không chỉ ứng dụng, hạ tầng cũng cần được chuẩn hóa.
Các công cụ như:
(và ngày nay phổ biến hơn là Terraform và Ansible)
giúp tự động tạo ra các môi trường có cấu hình nhất quán.
Thay vì cài đặt thủ công từng máy chủ, toàn bộ hạ tầng được mô tả bằng mã nguồn và có thể tái tạo giống nhau ở Development, Staging và Production.
DevSecOps và Dev/Prod Parity
Một trong những mục tiêu quan trọng nhất của DevSecOps là giảm thiểu mọi khác biệt giữa Development, Staging và Production.
Khi:
thì câu nói "Chạy trên máy em được!" gần như sẽ biến mất.
Đó cũng là tinh thần của 12-Factor App: thu hẹp khoảng cách về thời gian, con người và công cụ để việc triển khai trở nên nhất quán, dễ dự đoán và đáng tin cậy. Đây chính là nền tảng giúp các tổ chức triển khai phần mềm nhiều lần mỗi ngày mà vẫn duy trì chất lượng và độ ổn định của hệ thống.
Có lẽ ai làm phần mềm cũng từng nghe câu nói quen thuộc:
"Code em chạy trên máy em bình thường mà!"
Nhưng khi triển khai lên Production thì:
- Không kết nối được Database.
- API hoạt động khác.
- Hiệu năng giảm mạnh.
- Thậm chí ứng dụng không khởi động được.
Nguyên nhân không phải lúc nào cũng do code.
Rất nhiều trường hợp xuất phát từ việc Development, Staging và Production quá khác nhau.
Đó là lý do Yếu tố thứ 10 của 12-Factor App yêu cầu:
Keep Development, Staging và Production as similar as possible.
Hay nói ngắn gọn:
Càng ít khác biệt giữa các môi trường, rủi ro triển khai càng thấp.
Ba khoảng cách lớn trong phát triển phần mềm
Theo 12-Factor App, các tổ chức truyền thống thường tồn tại ba "khoảng cách" lớn.
1. Time Gap
Developer hoàn thành tính năng hôm nay.
Nhưng...
Hai tuần sau.
Một tháng sau.
Hoặc ba tháng sau.
Mã nguồn mới được triển khai lên Production.
Trong khoảng thời gian đó:
- Có thêm hàng chục commit mới.
- Có thêm nhiều thay đổi khác.
- Việc xác định nguyên nhân khi xảy ra lỗi trở nên khó khăn hơn.
12-Factor App hướng tới việc rút ngắn khoảng cách này xuống chỉ còn vài phút, thông qua CI/CD Pipeline.
2. Personnel Gap
Trong mô hình truyền thống:
Developer
│
Viết Code
│
──────────────
│
Operations
│
Deploy
Developer gần như không tham gia quá trình triển khai.
Operations lại không hiểu toàn bộ logic của ứng dụng.
Thông tin bị truyền qua nhiều lớp.
Việc xử lý sự cố thường chậm hơn.
Trong DevSecOps, Developer và Operations cùng tham gia vào toàn bộ vòng đời ứng dụng:
- Build
- Test
- Deploy
- Monitoring
- Incident Response
Điều này giúp phản hồi nhanh hơn khi có sự cố.
3. Tools Gap
Đây là nguyên nhân phổ biến nhất.
Ví dụ:
Developer:
- Windows
- SQLite
- Local Cache
Production:
- Linux
- PostgreSQL
- Redis
Ứng dụng có thể hoạt động hoàn hảo trên máy phát triển nhưng thất bại khi triển khai vì môi trường thực thi khác hoàn toàn.
Khác Database cũng có thể gây lỗi
Nhiều nhóm phát triển chọn SQLite vì đơn giản.
Trong khi Production sử dụng PostgreSQL hoặc MySQL.
Về lý thuyết, ORM hoặc Adapter có thể che giấu sự khác biệt.
Nhưng trên thực tế:
- Kiểu dữ liệu khác nhau.
- Cú pháp SQL có thể khác.
- Transaction hoạt động khác.
- Khả năng khóa dữ liệu khác.
- Hiệu năng truy vấn khác.
Kết quả là ứng dụng chạy tốt trong môi trường Development nhưng phát sinh lỗi khi triển khai lên Production.
12-Factor App khuyến nghị không nên sử dụng các Backing Services khác nhau giữa các môi trường, vì những khác biệt nhỏ này có thể gây ra các lỗi rất khó phát hiện.
Cache cũng không nên khác nhau
Một ví dụ khác:
Development:
Memory Cache
Production:
Redis
Ứng dụng có thể vô tình phụ thuộc vào hành vi của bộ nhớ cục bộ.
Khi chuyển sang Redis:
- Thời gian phản hồi khác.
- Chính sách hết hạn (TTL) khác.
- Cơ chế chia sẻ dữ liệu khác.
Những khác biệt này có thể tạo ra các lỗi chỉ xuất hiện sau khi triển khai.
Docker giúp thu hẹp khoảng cách
Ngày trước:
Developer PC
Windows
Python 3.11
──────────────
Production
Linux
Python 3.10
Ngày nay, với Docker:
Developer
│
Docker Image
│
──────────────
│
Staging
│
──────────────
│
Production
Ba môi trường đều sử dụng cùng một Docker Image.
Điều thay đổi chỉ là:
- Environment Variables
- Secrets
- Quy mô tài nguyên
Nhờ vậy, khả năng xảy ra lỗi do khác biệt môi trường giảm đáng kể.
Infrastructure as Code giúp chuẩn hóa hạ tầng
Không chỉ ứng dụng, hạ tầng cũng cần được chuẩn hóa.
Các công cụ như:
- Chef
- Puppet
(và ngày nay phổ biến hơn là Terraform và Ansible)
giúp tự động tạo ra các môi trường có cấu hình nhất quán.
Thay vì cài đặt thủ công từng máy chủ, toàn bộ hạ tầng được mô tả bằng mã nguồn và có thể tái tạo giống nhau ở Development, Staging và Production.
DevSecOps và Dev/Prod Parity
Một trong những mục tiêu quan trọng nhất của DevSecOps là giảm thiểu mọi khác biệt giữa Development, Staging và Production.
Khi:
- Cùng sử dụng một Build Artifact.
- Cùng Docker Image.
- Cùng loại Database.
- Cùng loại Cache.
- Cùng cấu hình hạ tầng (chỉ khác thông số môi trường).
- CI/CD triển khai trong vài phút thay vì vài tuần.
thì câu nói "Chạy trên máy em được!" gần như sẽ biến mất.
Đó cũng là tinh thần của 12-Factor App: thu hẹp khoảng cách về thời gian, con người và công cụ để việc triển khai trở nên nhất quán, dễ dự đoán và đáng tin cậy. Đây chính là nền tảng giúp các tổ chức triển khai phần mềm nhiều lần mỗi ngày mà vẫn duy trì chất lượng và độ ổn định của hệ thống.
Attached Files