DevOps

DevOps (kết hợp của cụm từ tiếng Anh "software DEVelopment" và "information technology OPerationS") là một thuật ngữ để chỉ một tập hợp các hành động trong đó nhấn mạnh sự hợp tác và trao đổi thông tin của các lập trình viên và chuyên viên tin học khi cùng làm việc để tự động hóa quá trình chuyển giao sản phẩm phần mềm và thay đổi kiến trúc hệ thống. Điều này nhằm thiết lập một nền văn hóa và môi trường nơi mà việc build (biên dịch phần mềm), kiểm tra, và phát hành phần mềm có thể xảy ra nhanh chóng, thường xuyên, và đáng tin cậy hơn.

Tổng quan

Sơ đồ Venn cho thấy DevOps là sự giao thoa giữa 3 bên: phát triển phần mềm (lập trình viên), quản trị phần mềm và đảm bảo chất lượng phần mềm (QA)

Theo truyền thống, các tổ chức có sự phân chia chức năng phòng ban rất hiếm khi có một phòng ban giữ chức năng tích hợp cả chức năng của phòng IT. Nhưng DevOps đề xướng một phương thức mới giúp trao đổi và hợp tác giữa các phòng ban phát triển phần mềm, quản lý chất lượng phần mềm (QA) và phòng IT. Trong một số tổ chức, sự hợp tác này lại được thực hiện bằng cách "nhúng" chuyên viên IT vào trong nhóm phát triển phần mềm, do đó tạo thành một đội đa chức năng – điều này có thể cũng được kết hợp với ma trận quản lý.

Lịch sử

Tại hội nghị Agile năm 2008, Andrew Clay Shafer và Patrick Debois đã thảo luận về "cơ sở hạ tầng Agile". Thuật ngữ DevOps được phổ biến thông qua một loạt các series "devopsdays", bắt đầu từ năm 2009 ở Bỉ. Kể từ đó, đã có các hội nghị devopsdays được tổ chức ở nhiều quốc gia trên toàn thế giới.

Chuỗi công cụ DevOps (DevOps toolchain)

Minh họa các giai đoạn (stages) của chuỗi DevOps

Bởi vì DevOps là một sự thay đổi về văn hóa và hợp tác (giữa các nhóm phát triển, điều hành và kiểm thử phần mềm) nên không có duy nhất một "công cụ DevOps" mà thay vào đó là chuỗi công cụ DevOps bao gồm nhiều công cụ. Thông thường, chuỗi công cụ DevOps dùng để làm công việc phù hợp với một hoặc nhiều thể loại, điều này phản ánh các khía cạnh chủ chốt của sự phát triển phần mềm và quá trình phân phối phần mềm:

1. Mã nguồn (Code) - phát triển và phê duyệt mã nguồn, công cụ quản lý phiên bản mã nguồn, trộn mã nguồn;
2. Biên dịch (Build) — công cụ Tích hợp liên tục và trạng thái build;
3. Kiểm thử (Test) — kiểm thử và xác định kết quả hiệu suất thực thi;
4. Đóng gói (Package) — kho lưu trữ Artifact, các giai đoạn của ứng dụng trước khi triển khai;
5. Phát hành (Release) — quản lý thay đổi, chấp thuận phát hành, phát hành tự động;
6. Cấu hình (Configure) — cấu hình cơ sở hạ tầng và quản lý, các công cụ về cơ sở hạ tầng dạng mã nguồn;
7. Giám sát (Monitor) — giám sát hiệu suất ứng dụng, trải nghiệm người dùng cuối.

Mặc dù có rất nhiều công cụ, nhưng trong một số tổ chức, chỉ một số loại trong đó là cần thiết để thiết lập chuỗi công cụ DevOps. Một số nơi cố gắng xác định những công cụ cơ bản để có thể tìm trong các danh mục có sẵn.

Các công cụ như Docker (container), Jenkins (Tích hợp liên tục), Puppet (Mã nguồn như là cơ sở hạ tầng - IaC) và Vagrant (nền tảng ảo hóa)—trong số nhiều thứ khác—thường được sử dụng và thảo luận khi nói về chuỗi công cụ DevOps.

Mối quan hệ với Agile và Phân phối Liên tục (Continous delivery)

Agile

Agile (Phát triển phầm mềm linh hoạt) và DevOps tương tự nhau, nhưng trong khi Agile đại diện cho một sự thay đổi trong suy nghĩ và thực hành (dẫn đến sự thay đổi tổ chức), DevOps có trọng tâm nhiều hơn về việc thực hiện thay đổi có tổ chức để đạt được mục tiêu của mình.

Sự cần thiết DevOps được sinh ra từ sự phổ biến của phát triển phần mềm linh hoạt (Agile), là xu hướng dẫn đến sự gia tăng số lượng các bản phát hành.

Một mục tiêu của DevOps là thiết lập một môi trường nơi phát hành nhiều ứng dụng đáng tin cậy hơn, nhanh hơn và thường xuyên hơn. Các nhà quản lý phát hành bắt đầu sử dụng các công cụ (như các công cụ phát hành ứng dụng tự động và tích hợp liên tục) để giúp thực hiện mục tiêu nay— bằng cách làm gì đó thông qua việc tiếp cận quy trình phân phối liên tục.

Phân phối Liên tục (Continuous delivery)

Phân phối liên tục (CD) và DevOps tương tự nhau ở ý nghĩa (và thường pha trộn vào nhau), nhưng chúng là hai khái niệm khác nhau:

• DevOps có một phạm vi rộng hơn, và xoay quanh một trung tâm:
  • Thay đổi có tổ chức: đặc biệt để hỗ trợ sự hợp tác lớn hơn giữa các loại nhân viên khác nhau khi tham gia vào việc phân phối phần mềm:
    • Nhà phát triển phần mềm;
    • Nhà điều hành hệ thống phần mềm;
    • Đảm Bảo Chất Lượng;
    • Quản lý;
    • ....
  • Tự động hoá quá trình trong phân phối phần mềm.
• Phân phối Liên tục, trên khía cạnh khác, là một cách tiếp cận để tự động phân phối, và tập trung vào:
  • Đưa các quá trình khác nhau vào cùng nhau;
  • Thực hiện chúng nhanh hơn và thường xuyên hơn.

Chúng có chung mục tiêu cuối cùng, và thường sử dụng kết hợp, để đạt được chúng. DevOps và Phân phối liên tục chia sẻ một nền tảng trong các phương pháp Agile và Lean: các thay đổi nhỏ và nhanh chóng tập trung vào việc mang lại giá trị cho người dùng cuối. Chúng đang được truyền đạt tốt và hợp tác trong nội bộ, do đó giúp đạt được thời gian ra thị trường nhanh, giảm rủi ro.

Mục tiêu

Các mục tiêu cụ thể của DevOps là để kết nối toàn bộ pipeline (đường ống) phân phối. Chúng bao gồm việc thường xuyên cải tiến sự triển khai, có thể dẫn đến:

• Có thời gian ra thị trường nhanh hơn;
• Hạ thấp tỷ lệ thất bại của bản phát hành mới;
• Rút ngắn thời gian giữa các lần sửa chữa;
• Nhanh hơn có nghĩa là có thời gian để phục hồi (trong trường hợp một phiên bản mới hỏng hoặc nếu không thì vô hiệu hóa hệ thống hiện tại).

Tiếp cận DevOps giúp đơn giản hóa quy trình, nâng cao khả năng lập trình và năng động. DevOps nhằm mục đích để tối đa hóa dự đoán, hiệu quả, an ninh và bảo trì các quá trình hoạt động. Rất thường xuyên, tự động hóa hỗ trợ mục tiêu này.

Lợi ích của DevOps

Các công ty áp dụng DevOps cho thấy họ đạt được một số lợi ích đáng chú ý như: rút ngắn thời gian đưa sản phẩm ra thị trường, nâng cao sự hài lòng của khách hàng, chất lượng sản phẩm tốt hơn, phát hành nhiều sản phẩm đáng tin cậy hơn, nâng cao hiệu suất và hiệu năng,..

Tuy nhiên, một nghiên cứu phát hành vào tháng giêng 2017 bởi F5 dựa trên gần 2,200 giám đốc điều hành IT và chuyên gia ngành công nghiệp cho thấy rằng chỉ có một phần năm số người khảo sát nghĩ rằng DevOps đã có một chiến lược tác động vào tổ chức của họ mặc dù gia tăng trong việc sử dụng. Cùng một nghiên cứu cho thấy rằng chỉ 17% xác định DevOps như chìa khóa phát triển, xếp dưới phần mềm dạng dịch vụ (42%), dữ liệu lớn (41%) và cloud dạng dịch vụ (39%).

Thay đổi văn hóa

DevOps không đơn thuần là công cụ hay quy trình, nó yêu cầu sự thay đổi văn hóa có tổ chức. Sự thay đổi văn hóa này đặc biệt khó khăn, bởi vì sự mâu thuẫn về vai trò của các phòng ban:

• Operations (Điều hành) — tìm kiếm sự ổn định có tổ chức;
• Developers (Lập trình viên) — muốn thay đổi;
• Testers — muốn giảm rủi ro.

Tập hợp các nhóm này để làm việc chung một cách chặt chẽ — là một thách thức quan trọng trong môi trường doanh nghiệp để có thể áp dụng DevOps.

Xây dựng một nền văn hóa DevOps

Mẫu áo có in chữ DevOps ở một hội nghị.

Nguyên tắc lớn nhất của DevOps là sự giao tiếp liên phòng ban - team buiilding và khuyến khích nhân viên hoạt động - để tạo một môi trường thuận lợi cho sự liên lạc này. Team building có thể bao gồm chơi trò chơi, hội thảo.

Triển khai

Các công ty thường xuyên phát hành phiên bản phần mềm có thể triển khai DevOps. Ví dụ, công ty về lưu trữ hình ảnh trên trang web Flickr phát triển một phương pháp DevOps, hỗ trợ yêu cầu triển khai 10 lần mỗi ngày. Điều này được gọi là Triển khai liên tục hoặc Phân phối liên tục và đã được kết hợp với các phương pháp Lean. Các nhóm làm việc, các hiệp hội chuyên nghiệp và blog đã được hình thành theo chủ đề DevOps từ năm 2009.

DevOps và kiến trúc

Để thực hành DevOps một cách hiệu quả, phần mềm phải đáp ứng một tập hợp các yêu cầu đặc biệt về kiến trúc (architecturally significant requirements - ASRs) như: có thể triển khai, thay đổi, kiểm thử, và giám sát). Những yêu cầu ASRs này có độ ưu tiên cao và không thể xem nhẹ.

Mặc dù về nguyên tắc, có thể thực hành DevOps với bất kỳ kiểu kiến trúc nào — nhưng microservices là kiểu kiến trúc tiêu chuẩn để xây dựng hệ thống triển khai liên tục.

Phạm vi áp dụng

Một số bài viết về DevOps cho rằng: "DevOps chỉ là nguyên tắc của Phát triển phần mềm linh hoạt..."

Một cuộc điều tra được xuất bản vào tháng 1 năm 2016 bởi công ty RightScale, áp dụng DevOps tăng từ 66% trong năm 2015 lên 74% vào năm 2016. Và trong các tổ chức lớn, DevOps thậm chí còn cao hơn — 81%.

Áp dụng DevOps được điều khiển bởi nhiều yếu tố — bao gồm:

1. Sử dụng Agile, các quá trình phát triển và phương pháp khác;
2. Yêu cầu tăng tỷ lệ sản xuất phát hành — từ đơn vị và phía kinh doanh;
3. Rộng rãi của ảo và đám mây, cơ sở hạ tầng — từ bên trong và bên ngoài cung cấp;
4. Tăng sử dụng dữ liệu trung tâm tự động và quản lý các công cụ,
5. Tăng cường tập trung vào bài kiểm tra tự động và liên tục hợp các phương pháp;
6. Một khối lượng quan trọng của công khai–sẵn sàng thực hành tốt nhất.

Gia tăng áp dụng

"Thuyết về sự Hạn chế" (The theory of constraints) áp dụng vào việc thực hành DevOps như sau: sự hạn chế có giới hạn thường ăn sâu sự vào sự không ưa thay đổi trong các bộ phận trong doanh nghiệp. Sự gia tăng áp dụng biểu hiện qua các phương pháp "Lý Thuyết về sự Hạn chế" cung cấp cho cuộc chiến chống bất kỳ sự cưỡng ép nào, được gọi là "Năm bước tập trung".

Ba nguyên tắc sau của Gene Kim thiết lập các cách cơ bản để áp dụng DevOps:

Cách đầu tiên: suy nghĩ có hệ thống

Nhấn mạnh việc tập trung vào hiệu năng toàn hệ thống hơn là các thành phần đơn lẻ.

Cách thứ hai: khuếch đại vòng lặp phản hồi

Nhấn mạnh vào việc gia tăng phản hồi và hiểu biết của các nhóm làm việc có liên quan.

Cách thứ ba: nền văn hóa của sự thử nghiệm và học hỏi liên tục

Hai thứ quan trọng nhất: thử nghiệm và thực hành.

Xem thêm

• Tích hợp liên tục
• Phân phối liên tục
• Kiểm thử liên tục
• Hệ thống quản lý phiên bản
• Lập trình cực hạn
• Lập trình linh hoạt

Đọc thêm

• Hüttermann, Michael (2012). DevOps for Developers. Apress. ISBN 978-1-430-24569-8.
• Davis, Jennifer; Daniels, Katherine (2015). Effective DevOps. O'Reilly. ISBN 978-1-4919-2630-7.