Tóm tắt

– DevOps là một bước chuyển đổi văn hoá nhằm mục đích thúc đẩy đổi mới bằng cách phá bỏ các rào cản giữa Phát triển (Development) và Vận hành (Operations).

– Không có vai trò, mô hình hay công nghệ cụ thể nào đại diện cho DevOps. DevOps bàn về cách một tổ chức hoạt động.

– DevOps thường dựa trên các nguyên tắc học hỏi liên tục, lặp lại nhanh chóng và xây dựng quy trình phát triển sản phẩm (thường là phần mềm) thông qua thử nghiệm và sự cộng tác của các nhóm liên quan. 

Giới thiệu

Ngày nay, chắc hẳn bạn thường xuyên bắt gặp thuật ngữ DevOps. Thoạt nhìn, DevOps có vẻ là một khái niệm đơn giản: Chẳng phải từ này chỉ là sự kết hợp của Dev và Ops hay sao?

Đúng vậy, nhưng hãy đi sâu hơn một chút nữa.

Về bản chất, giống như mặt chữ, DevOps nói về việc tập hợp các lĩnh vực chức năng riêng biệt trong lịch sử. Nó liên quan đến việc thu hẹp khoảng cách hoặc xoá bỏ rào cản giữa các nhóm phát triển phần mềm (Dev) và nhóm vận hành (Ops) nhằm mục tiêu phát hành phần mềm nhanh và ổn định hơn.

Nhưng kể từ khi được giới thiệu cách đây khoảng một thập kỷ, DevOps đã trở thành một thuật ngữ thông dụng cho mọi xu hướng trong phát triển phần mềm và vận hành CNTT. DevOps vẫn đang phát triển, bao gồm nhiều lĩnh vực, đồng thời được điều chỉnh và áp dụng dựa trên các mục tiêu kinh doanh cụ thể, các ưu tiên và cơ sở tri thức hiện có của tổ chức.

Trước khi tìm hiểu về định nghĩa của DevOps, hãy thảo luận trước về những gì KHÔNG phải là DevOps để loại bỏ những quan niệm sai lầm phổ biến về định nghĩa này.

DevOps KHÔNG phải là

Con người (một vai trò, nhóm hoặc tổ chức)

Bản thân việc thử nghiệm các thay đổi nhân sự và/hoặc cấu trúc nhóm không phải là DevOps. Một số nỗ lực phổ biến khi triển khai DevOps với hướng tiếp cận tập trung vào con người bao gồm:

– Thuê kỹ sư DevOps để doanh nghiệp có thể tự tin nói rằng mình đang làm DevOps

– Tạo một nhóm trung gian giữa Dev và Ops, rồi gọi đó là nhóm DevOps

– “Đập bức tường ngăn” theo đúng nghĩa đen (bằng cách xác định lại vị trí của nhóm) hoặc nghĩa bóng (thông qua những thay đổi về tổ chức) để loại bỏ các rào cản giữa nhóm phát triển phần mềm và nhóm vận hành CNTT

Các tổ chức xem DevOps là điều gì đó có thể đạt được thông qua tái tổ chức hoặc nỗ lực tuyển dụng đang chỉ xem xét một phần của câu đố DevOps. Cấu trúc và vai trò của nhóm là yếu tố thứ yếu với các hoạt động hợp tác cơ bản ở nơi làm việc.

Bài đăng phổ biến trên trang The Agile Admin, What is DevOps? đưa ra định nghĩa về DevOps bắt nguồn từ khái niệm hợp tác như sau:

“DevOps là việc các kỹ sư vận hành và phát triển tham gia cùng nhau trong toàn bộ vòng đời của dịch vụ, từ thiết kế, phát triển đến hỗ trợ sản xuất.”

Quy trình 

Bạn không thể nói về DevOps mà không nhắc đến quy trình. Nhiều người thực sự có thể nghĩa rằng DevOps là một vấn đề hoàn toàn khác biệt với quy trình – hoặc chỉ khác những sản phẩm phụ của một tổ chức chú trọng đến quy trình, chẳng hạn như các yêu cầu nặng nề về tài liệu và đánh giá trong vòng đời phát triển phần mềm.

Trong một bài phỏng vấn với Computer Business Review, CTO của Sonatype – ông Brian Fox đã chia sẻ rằng ông tin quy trình (và văn hoá liên quan đến quy trình) thường là rào cản lớn nhất đối với các tổ chức đang tìm cách áp dụng tư duy DevOps.

“Theo những gì chúng tôi quan sát trên thị trường, thách thức lớn nhất đối với khách hàng của chúng tôi ngày nay thường là sự thay đổi văn hoá cần thiết để khiến tất cả các chủ sở hữu quy trình (process owner) suy nghĩ vượt ra bên ngoài khuôn khổ quy trình cũ mà họ đang tuân theo.”

Ví dụ, một vài phong trào chính đã truyền cảm hứng cho DevOps – Phát triển phần mềm linh hoạt (Agile) và Phân phối liên tục – vô cùng khác biệt so với mô hình phát triển phần mềm Thác nước (Waterfall) đang ngày càng lỗi thời, nhưng chúng không thực sự loại bỏ quy trình như suy nghĩ của nhiều người.

Thay vào đó, chúng mô phỏng lại quy trình, sử dụng các phương pháp như Scrum để tạo điều kiện cho giao tiếp nhóm và luồng công việc, đồng thời triển khai các quy trình và công cụ tự động hoá CI/CD để liên tục tích hợp các thay đổi trên mã nguồn và triển khai các ứng dụng lên môi trường production theo yêu cầu. Điểm có vẻ giống như khác biệt so với quy trình truyền thống là việc tinh chỉnh liên tục một quy trình để giảm sự phụ thuộc và các nỗ lực thủ công và thời gian dành cho việc tạo tài liệu cho phép cộng tác giữa các nhóm không đồng bộ.

Công cụ

Hãy hỏi Google DevOps là gì?, bạn sẽ nhanh chóng nhận thấy rằng hầu hết các công ty công nghệ cung cấp các công cụ tự động (Infrastructure as Code, Microservices, Containerization, Cloud services, v.v) liên quan đến DevOps đều đưa ra định nghĩa riêng của họ, nhấn mạnh những đóng góp của họ trên thị trường, ví dụ:

– Định nghĩa của Amazon (không có gì đáng ngạc nhiên) bắt nguồn từ dịch vụ cung cấp Infrastructure as a Service (Cơ sở hạ tầng như một Dịch vụ) của họ trên cơ sở đám mây.

– Định nghĩa của GitLab nói về việc thúc đẩy một bộ công cụ chung để tối ưu hoá sự hợp tác giữa phát triển và vận hành.

– Định nghĩa của Microsoft cũng đề cập đến nhiều lĩnh vực (Infrastructure as Code, Microservices, và Monitoring) mà họ cung cấp các giải pháp tương ứng.

– Định nghĩa của New Relic tập trung vào việc giám sát và đo lường.

Những ví dụ này rất hữu ích, nhưng chúng cho thấy rằng DevOps vẫn có ý nghĩa khác nhau đối với những người (hoặc tổ chức khác nhau). DevOps được diễn giải và triển khai theo các cách khác nhau, tuỳ thuộc vào tổ chức, cũng như các giá trị và năng lực cốt lõi của tổ chức. Các công cụ hỗ trợ tự động hoá CNTT là một khía cạnh quan trọng giúp DevOps hoạt động trên thực tế, nhưng nếu thiếu vắng các nguyên tắc và quy trình cơ bản, thì chỉ riêng các công cụ sẽ không thể mang lại cho tổ chức của bạn những kết quả như mong muốn.

The Agile Admin cảnh báo các học viên không chỉ nên tập trung vào các công cụ khi áp dụng DevOps:

“DevOps cũng không chỉ đơn giản là triển khai một bộ công cụ. Một lý do tại sao tôi cảm thấy cần có một định nghĩa về DevOps được chấp nhận phổ biến chính là, việc có nhiều định nghĩa khó hiểu và không có cấu trúc rõ ràng sẽ làm tăng nguy cơ khiến mọi người bỏ qua lý thuyết và chỉ triển khai các quy trình hoặc công cụ của DevOps mà không lưu tâm đến các nguyên tắc, đó chắc chắn là một anti-pattern. Tự động hoá chỉ là tận dụng sức mạnh và tác hại của việc tự động hoá không không ngoan cũng nhiều không kém những lợi ích của tự động hoá.”

DevOps là gì?

DevOps không phải là bất kỳ mục nào trong số các mục được liệt kê ở trên (Con người, Quy trình và/hoặc Công cụ), nhưng nó thường bị nhầm lẫn khi một hoặc nhiều trong số ba mục trên được ghép lại với nhau. Tất cả chúng đều là những phần quan trọng trong quá trình áp dụng DevOps của một tổ chức, nhưng chúng sẽ không tự mình thực hiện công việc và mang lại giá trị.

Vậy nói một cách chính xác, DevOps là gì?

Hãy bắt đầu với Wikipedia.

“DevOps là tập hợp các phương pháp phát triển phần mềm, kết hợp hoạt động phát triển phần mềm (Development – Dev) và hoạt động vận hành công nghệ thông tin (Operations – Ops) để rút ngắn vòng đời phát triển hệ thống, đồng thời cung cấp các tính năng, bản sửa lỗi và cập nhật thường xuyên để phù hợp với các mục tiêu kinh doanh.”

Trên đây là một định nghĩa khá tốt, tập trung vào kết quả, nhưng điều thú vị nhất về trang Wikipedia là phần nội dung tiếp theo đã nhanh chóng thừa nhận các nguồn của nó vẫn cần được xác thực thêm và không có một định nghĩa tiêu chuẩn, thống nhất nào cho thuật ngữ này.

“Các học giả và những người hành nghề vẫn chưa đặt ra một định nghĩa duy nhất cho thuật ngữ DevOps.”

Vì vậy, hãy tiếp tục đào sâu thêm.

Một bộ nguyên tắc

Điều gần nhất mà chúng ta có được là sự đồng thuận giữa các học giả và những người thực hành trong việc xác định DevOps được ghi lại trong cuốn sách Sổ tay DevOps, viết bởi một số nhà lãnh đạo và người tiên phong cho phong trào. Định nghĩa của họ bắt nguồn từ nền tảng lý thuyết và lịch sử của DevOps, cũng như các nguyên tắc mà nó được xây dựng. Tuy nhiên, mặc dù đây là một định nghĩa toàn diện, nó chắc hẳn sẽ không phải là định nghĩa đáng nhớ vì lý do đơn giản là độ dài của nó.

“DevOps là kết quả của việc áp dụng các nguyên tắc đáng tin cậy nhất từ lĩnh vực sản xuất vật chất và lãnh đạo đến dòng giá trị CNTT. DevOps dựa trên các khối kiến thức từ Tinh gọn, Lý thuyết về các ràng buộc, Hệ thống sản xuất Toyota, Kỹ thuật phục hồi, Tổ chức học tập, Văn hoá an toàn, Yếu tố Con người và nhiều thứ khác. Các bối cảnh có giá trị khác mà DevOps đúc kết được bao gồm văn hoá quản lý có độ tin cậy cao, lãnh đạo đầy tớ và quản lý thay đổi tổ chức. Kết quả của nó là độ tin cậy, tính ổn định và bảo mật đẳng cấp thế giới với chi phí và nỗ lực thấp hơn bao giờ hết, và sự tăng tốc quá trình và độ tin cậy thông qua dòng giá trị, bao gồm Quản lý sản phẩm, Phát triển, QA, Hoạt động vận hành CNTT và Infosec.”

Điểm mấu chốt trong định nghĩa trên là khả năng hiểu được chiều sâu và bề rộng của các nhóm công việc cung cấp thông tin cho DevOps, với trọng tâm là áp dụng các nguyên tắc đáng tin cậy để nhanh chóng đạt được kết quả mong muốn trong luồng giá trị công nghệ. (Chúng ta sẽ thảo luận chi tiết về những nguyên tắc này trong một bài viết khác.)

Một văn hoá (về học hỏi và cải tiến liên tục)

Khi bạn xem xét tất cả các khía cạnh nói trên của DevOps (Con người, Quy trình, Công cụ và Nguyên tắc), thì bạn đã hiểu được 80% về DevOps rồi.

Tuy nhiên, 20% còn lại đóng vai trò quan trọng và thực sự có thể tạo ra hoặc phá vỡ cách tiếp cận DevOps trong một tổ chức, bởi vì nếu không có nó, câu thần chú “thất bại nhanh chóng, học hỏi và thử lại” sẽ không còn khả thi trong thực tế.

Một vài từ khoá trong Sổ tay DevOps ở trên xứng đáng được nhấn mạnh và giải nghĩa thêm để hoàn thành định nghĩa của chúng ta:

– Tổ chức học tập

– Văn hoá an toàn

– Văn hoá quản lý với độ tin tưởng cao

– Lãnh đạo đầy tớ

Trong cuốn sách Khoa học về phần mềm tinh gọn và DevOps: Xây dựng và nhân rộng các tổ chức công nghệ hiệu suất cao, các tác giả đã thảo luận về sự cần thiết của một nền văn hoá sản xuất (generative culture – một thuật ngữ do Westrum đặt ra), tập trung vào sứ mệnh và tối ưu hoá luồng thông tin giữa các nhóm chứ không phải một tự duy “chỉ huy và kiểm soát” chú trọng vào quyền lực.

“… trong các tổ chức có văn hoá sản xuất, mọi người cộng tác hiệu quả hơn và có mức độ tin cậy cao hơn trong toàn tổ chức, cũng như đối với cấp trên và cấp dưới.”

Steve Mezak nhấn mạnh rằng một nền văn hoá sản xuất dành cho loại hình học hỏi và cải tiến liên tục này cũng tạo ra sự khác biệt quan trọng trong cách tiếp cận của họ đối với việc áp dụng DevOps.

“Sẽ hợp lý hơn khi mô tả DevOps là một hành trình, hoặc có lẽ là một khát vọng, thay vì một đích đến được xác định sẵn. Giống như sản xuất tinh gọn, DevOps tìm kiếm sự cải tiến liên tục, sản lượng cao hơn, hiệu quả hơn và thậm chí là triển khai liên tục. Yếu tố hỗ trợ và thúc đẩy DevOps liên tục phát triển là các công cụ tự động.”

Khi bạn xây dựng con người, quy trình và công cụ dựa trên các nguyên tắc cơ bản của DevOps và một nền văn hoá cam kết học hỏi và cải tiến liên tục, chính là lúc bạn bước đi trên con đường hiểu DevOps từ mức độ tổng thể.

Do đó, định nghĩa về DevOps mà Sonatype đề xuất là như sau:

“DevOps là một nguyên tắc bắt nguồn từ sự cộng tác và giao tiếp, có thể thực hiện được bằng cách loại bỏ các rào cản nhận thức giữa các nhóm và xây dựng niềm tin vào văn hoá học hỏi và cải tiến liên tục, đồng thời tận dụng các phương pháp quản lý và kỹ thuật đã được chứng minh nhằm hướng tới mục tiêu chung và rút ngắn chu kỳ phân phối, đồng thời cải thiện tính ổn định của việc triển khai phần mềm.”

Trong bài viết tiếp theo về lý do tại sao lại lựa chọn DevOps, chúng ta sẽ tiếp tục thảo luận về các vấn đề mà DevOps đã giải quyết và cách triển khai DevOps tuỳ theo tình hình kinh doanh của tổ chức bạn.

Theo Sonatype