Văn hóa DevOps là gì? Không chỉ là CI/CD, Docker hay Kubernetes

Khi nhắc đến DevOps, nhiều người sẽ nghĩ ngay đến Jenkins, GitLab CI, Docker, Kubernetes, Terraform hay những pipeline triển khai tự động.

Điều đó không sai, nhưng chưa đủ.

Một doanh nghiệp có thể triển khai ứng dụng chỉ bằng một cú nhấp chuột, sử dụng Kubernetes và sở hữu hàng chục dashboard giám sát, nhưng vẫn chưa thực sự có văn hóa DevOps.

Bởi vì DevOps trước hết không phải là một bộ công cụ. DevOps là cách con người phối hợp, chia sẻ trách nhiệm và cùng vận hành một sản phẩm.

Một tình huống rất quen thuộc trong ngành IT

Hãy tưởng tượng hệ thống production đột nhiên gặp lỗi.

Khách hàng không thể sử dụng dịch vụ. Cảnh báo liên tục được gửi về nhóm vận hành.

Dev kiểm tra sơ bộ rồi nói:

"Code bên em vẫn chạy bình thường, anh Ops kiểm tra server giúp em."

Ops kiểm tra tài nguyên rồi trả lời:

"Server không có vấn đề, chắc chắn lỗi từ ứng dụng."

Hai bên tiếp tục tranh luận xem lỗi thuộc về code hay hạ tầng. Trong khi đó, người dùng vẫn không thể sử dụng dịch vụ.

Đây chính là biểu hiện của một tổ chức chưa có văn hóa DevOps.

Trong một đội ngũ thực sự có văn hóa DevOps, câu hỏi đầu tiên sẽ không phải là "Lỗi của ai?" — mà phải là:

"Làm cách nào để khôi phục dịch vụ cho người dùng nhanh nhất?"

Văn hóa DevOps không nằm trên slide hay trong tên công cụ, mà thể hiện qua cách đội ngũ xử lý sự cố, triển khai hệ thống và giao tiếp với nhau mỗi ngày.

Văn hóa DevOps là trách nhiệm chung

Trong mô hình truyền thống, trách nhiệm thường bị chia nhỏ:

• Dev chịu trách nhiệm viết code.
• Tester chịu trách nhiệm tìm lỗi.
• Ops chịu trách nhiệm triển khai và vận hành.
• Security chịu trách nhiệm về bảo mật.

Cách phân chia này có vẻ rõ ràng, nhưng lại dễ tạo ra những "bức tường" giữa các bộ phận.

Dev có thể nghĩ rằng công việc của mình kết thúc khi code đã được bàn giao. Ops có thể nghĩ rằng mình chỉ cần đảm bảo server hoạt động. Tester chỉ kiểm tra theo test case, còn Security chỉ xuất hiện ở cuối dự án.

Văn hóa DevOps thay đổi tư duy đó. Toàn bộ đội ngũ cùng chịu trách nhiệm cho sản phẩm — từ lúc hình thành ý tưởng, phát triển, kiểm thử, triển khai cho đến khi vận hành trên production.

Điều này có nghĩa là:

• Dev không chỉ viết code mà còn phải quan tâm đến log, hiệu năng, khả năng giám sát và rollback.
• Ops không chỉ quản lý server mà cần hiểu ứng dụng hoạt động như thế nào.
• Tester không chỉ kiểm thử thủ công mà tham gia xây dựng kiểm thử tự động.
• Security không chờ đến cuối dự án mới kiểm tra lỗ hổng.
• Product không chỉ yêu cầu tính năng mà còn phải quan tâm đến độ ổn định và trải nghiệm người dùng.

DevOps không xóa bỏ vai trò của từng bộ phận. Nó giúp các bộ phận không còn làm việc như những hòn đảo riêng biệt.

Văn hóa DevOps là cùng nhìn vào một sự thật

Một vấn đề phổ biến trong các hệ thống IT là mỗi đội nắm giữ một phần thông tin:

• Dev có log ứng dụng.
• Ops có metric CPU, RAM và network.
• QA có kết quả kiểm thử.
• Database team có slow query log.

Khi sự cố xảy ra, mỗi người nhìn vào một dữ liệu khác nhau và đưa ra một kết luận khác nhau.

Văn hóa DevOps yêu cầu sự minh bạch. Các đội cần có khả năng cùng nhìn vào:

• Cùng một hệ thống log.
• Cùng một dashboard.
• Cùng một lịch sử triển khai.
• Cùng một phiên bản source code.
• Cùng một ticket xử lý sự cố.
• Cùng một nguồn thông tin đáng tin cậy.

Minh bạch không có nghĩa là tạo ra thật nhiều dashboard. Minh bạch là khi một bản triển khai thất bại, mọi người đều có thể biết điều gì đã xảy ra và dựa trên cùng một dữ liệu để xử lý vấn đề.

Văn hóa DevOps không có nghĩa là Ops phải làm mọi thứ

Một hiểu lầm khá phổ biến: sau khi doanh nghiệp thành lập đội DevOps, mọi công việc liên quan đến triển khai đều được đẩy sang đội này.

Dev viết code xong rồi gửi yêu cầu: nhờ DevOps build, nhờ DevOps deploy, nhờ DevOps kiểm tra log, nhờ DevOps xử lý lỗi, nhờ DevOps cấu hình monitoring, nhờ DevOps trực production.

Nếu mọi công việc vẫn phải đi qua một nhóm trung gian, DevOps sẽ trở thành một điểm nghẽn mới.

Vai trò đúng của đội DevOps hoặc Platform là xây dựng nền tảng, quy trình và công cụ để các đội phát triển có thể tự triển khai và vận hành ứng dụng một cách an toàn.

Thay vì trực tiếp deploy thay Dev, đội DevOps nên cung cấp:

• Pipeline chuẩn
• Template triển khai
• Hệ thống quản lý secret
• Logging và monitoring tập trung
• Cơ chế rollback
• Nền tảng self-service
• Tiêu chuẩn bảo mật
• Tài liệu và runbook

Mục tiêu cuối cùng không phải là "đội DevOps làm được bao nhiêu việc", mà là giúp toàn bộ tổ chức làm việc hiệu quả hơn.

Văn hóa DevOps là dám nói "chưa thể triển khai"

DevOps không có nghĩa là phải triển khai thật nhanh bằng mọi giá.

Một bản release chưa có kiểm thử, chưa có log, chưa có metric, chưa có phương án rollback hoặc không rõ ai chịu trách nhiệm khi xảy ra lỗi — thì chưa nên được đưa lên production.

Ops hoặc Platform cần có quyền từ chối một bản triển khai chưa đạt tiêu chuẩn. Ví dụ:

"Phiên bản này chưa có health check, chưa có kế hoạch rollback và database migration chưa được kiểm thử. Chúng ta cần hoàn thiện trước khi triển khai production."

Việc từ chối này có thể gây khó chịu trong thời gian đầu, nhưng về lâu dài lại giúp bảo vệ chất lượng hệ thống.

Một đội có văn hóa DevOps tốt không đánh đổi sự ổn định chỉ để đạt được mục tiêu "deploy nhanh". Mục tiêu phải là:

Triển khai nhanh, nhưng vẫn an toàn, có thể quan sát và có thể khôi phục.

Văn hóa DevOps là học từ sự cố

Không có hệ thống nào hoàn toàn không gặp lỗi. Sự khác biệt nằm ở cách tổ chức phản ứng sau khi lỗi xảy ra.

Một đội chưa có văn hóa DevOps thường kết thúc sự cố bằng câu:

"Hệ thống chạy lại rồi, đóng ticket thôi."

Một đội có văn hóa DevOps sẽ tiếp tục đặt câu hỏi:

• Vì sao lỗi xảy ra?
• Vì sao hệ thống không phát hiện sớm?
• Vì sao cảnh báo không hoạt động?
• Vì sao quá trình khôi phục mất nhiều thời gian?
• Vì sao lỗi tương tự đã từng xảy ra?
• Cần thay đổi code, hạ tầng hay quy trình nào?

Sau các sự cố nghiêm trọng, đội ngũ nên thực hiện postmortem — một buổi phân tích sự cố không nhằm tìm người để đổ lỗi, mà nhằm tìm cách cải thiện hệ thống.

Kết quả của postmortem phải là những hành động cụ thể:

• Bổ sung integration test
• Tạo cảnh báo mới
• Viết lại runbook
• Tự động hóa rollback
• Giới hạn quyền production
• Cải thiện backup
• Bổ sung kiểm tra bảo mật trong pipeline

Sự cố chỉ thực sự có giá trị khi tổ chức học được điều gì đó và ngăn nó lặp lại.

Văn hóa không đổ lỗi không có nghĩa là không có trách nhiệm

Khi nói đến văn hóa DevOps, người ta thường nhắc đến "blameless culture" — văn hóa không đổ lỗi.

Tuy nhiên, điều này không có nghĩa là mọi sai sót đều được bỏ qua.

Không đổ lỗi có nghĩa là không dừng lại ở kết luận đơn giản: "Do một nhân viên chạy nhầm lệnh."

Thay vào đó, tổ chức phải hỏi:

• Tại sao một lệnh nguy hiểm có thể được chạy trực tiếp trên production?
• Tại sao không có bước xác nhận?
• Tại sao tài khoản đó có quyền quá lớn?
• Tại sao không có backup hoặc rollback?
• Tại sao quy trình phụ thuộc hoàn toàn vào thao tác thủ công?

Con người có thể mắc sai lầm. Một hệ thống tốt phải được thiết kế để hạn chế hậu quả của những sai lầm đó.

Tất nhiên, mỗi thành viên vẫn phải có trách nhiệm với công việc của mình. Nhưng mục tiêu chính là sửa hệ thống và quy trình, thay vì chỉ tìm một cá nhân để chịu lỗi.

Công cụ đứng ở đâu trong văn hóa DevOps?

Công cụ vẫn rất quan trọng:

• CI/CD giúp tự động hóa build, test và deploy.
• Docker giúp chuẩn hóa môi trường chạy ứng dụng.
• Kubernetes hỗ trợ triển khai, mở rộng và tự phục hồi workload.
• Terraform giúp quản lý hạ tầng bằng code.
• Prometheus / Grafana giúp theo dõi hệ thống.

Tuy nhiên, công cụ chỉ phát huy tác dụng khi được đặt trong một văn hóa phù hợp:

• Một pipeline tự động nhưng không có test → chỉ giúp đưa lỗi lên production nhanh hơn.
• Một Kubernetes cluster hiện đại nhưng chỉ một người biết vận hành → vẫn là rủi ro lớn.
• Một hệ thống monitoring với hàng trăm cảnh báo nhưng không có owner và runbook → chỉ tạo thêm tiếng ồn.

Vì vậy, thứ tự đúng nên là:

Con người và văn hóa → quy trình → tự động hóa → công cụ.

Không nên mua công cụ trước rồi hy vọng văn hóa sẽ tự thay đổi.

Làm sao nhận biết một đội đã có văn hóa DevOps?

Một đội ngũ có văn hóa DevOps tốt thường có những biểu hiện rất thực tế:

• Khi production lỗi, Dev và Ops cùng tham gia xử lý.
• Mỗi service đều có owner rõ ràng.
• Các thay đổi được lưu trong Git và có review.
• Deployment được thực hiện qua pipeline, không phải thao tác tùy ý.
• Dev xem được log và dashboard cần thiết.
• Mỗi release đều có phương án rollback.
• Mỗi cảnh báo đều có người chịu trách nhiệm.
• Sự cố nghiêm trọng đều có postmortem.
• Kiến thức được viết thành tài liệu và runbook.
• Thành viên có thể thẳng thắn nói về sai sót.
• Không hệ thống nào phụ thuộc hoàn toàn vào một cá nhân.
• Các đội liên tục cải tiến dựa trên dữ liệu thực tế.

Không nhất thiết phải có Kubernetes, microservices hay hàng chục công cụ đắt tiền mới làm được DevOps.

Ngay cả một đội nhỏ cũng có thể xây dựng văn hóa DevOps bằng cách bắt đầu từ: chia sẻ trách nhiệm, minh bạch thông tin và tự động hóa những công việc lặp lại.

Kết luận

Bản chất của văn hóa DevOps không nằm ở việc doanh nghiệp dùng công cụ nào, deploy bao nhiêu lần một ngày, hay có bao nhiêu kỹ sư mang chức danh DevOps.

Nó nằm trong cách mọi người làm việc với nhau.

• Khi hệ thống lỗi, cả đội cùng khôi phục dịch vụ thay vì tranh luận lỗi thuộc về ai.
• Khi một bản release chưa an toàn, mọi người sẵn sàng dừng lại để hoàn thiện.
• Khi sự cố kết thúc, đội ngũ cùng phân tích và cải tiến thay vì đóng ticket rồi quên đi.

Khi kiến thức, dữ liệu và trách nhiệm được chia sẻ, khoảng cách giữa Development và Operations dần biến mất.

Có thể tóm gọn văn hóa DevOps bằng một câu:

Văn hóa DevOps là khi toàn bộ đội ngũ cùng chịu trách nhiệm xây dựng, triển khai và vận hành sản phẩm, cùng nhìn vào một sự thật và cùng học hỏi từ những thất bại.

Công cụ có thể thay đổi theo thời gian. Jenkins có thể được thay bằng GitLab CI, máy ảo có thể được thay bằng Kubernetes, hay một nền tảng mới có thể xuất hiện.

Nhưng tinh thần cộng tác, minh bạch, trách nhiệm chung và cải tiến liên tục mới là phần cốt lõi tạo nên DevOps.

— Minh Hưng