Devops là gì?

By | 26 December, 2018

DevOps là gì?

DevOps là một tập hợp tự động hóa các quy trình giữa các nhóm phát triển phần mềm và CNTT, để họ có thể xây dựng, kiểm tra và phát hành phần mềm nhanh hơn và đáng tin cậy hơn. Khái niệm về DevOps được thành lập dựa trên việc xây dựng văn hóa hợp tác giữa các đội trong dự án. Những lợi ích được hứa hẹn bao gồm tăng sự tin tưởng, phát hành phần mềm nhanh hơn, khả năng giải quyết các vấn đề quan trọng một cách nhanh chóng và quản lý tốt hơn các công việc không có kế hoạch.

Về bản chất, DevOps là một nền văn hóa, một phong trào, một triết lý.

Đó là một cái bắt tay chắc chắn giữa phát triển và hoạt động, nhấn mạnh vào sự thay đổi trong tư duy, cộng tác tốt hơn và tích hợp chặt chẽ hơn. Nó hợp nhất nhanh nhẹn, Phân phối liên tục, tự động hóa, và nhiều hơn nữa, để giúp các nhóm phát triển và vận hành hiệu quả hơn, đổi mới nhanh hơn và mang lại giá trị cao hơn cho các doanh nghiệp và khách hàng.

Ai đang làm DevOps?

Chef là công ty đứng sau nền tảng Chef Automate cho quy trình làm việc của DevOps. Hàng chục ngàn nhà phát triển sử dụng Chef để kiểm tra, tự động hóa và quản lý cơ sở hạ tầng. Đi đầu trong sự phát triển của DevOps, công ty có trụ sở tại Seattle đã phát hành các sản phẩm như Chef, InSpec, Habitat và Chef Automate để cải tiến các cách mới để phát triển và vận chuyển phần mềm và ứng dụng. Để thử nghiệm và hoàn thiện các thực tiễn DevOps của riêng mình, Chef dựa vào nền tảng Atlassian.

Lịch sử của DevOps

Phong trào DevOps bắt đầu kết hợp một thời gian từ năm 2007 đến 2008, khi các cộng đồng phát triển phần mềm và hoạt động CNTT phát biểu về những gì họ cảm thấy là một mức độ rối loạn nghiêm trọng trong ngành.

Họ đã chống lại mô hình phát triển phần mềm truyền thống, kêu gọi những người viết code phải có tổ chức và chức năng tách biệt với những người triển khai và hỗ trợ mã đó.

Các nhà phát triển và chuyên gia CNTT / Ops có các mục tiêu riêng biệt (và thường cạnh tranh), lãnh đạo bộ phận riêng biệt, các chỉ số hiệu suất chính riêng biệt mà họ được đánh giá và thường làm việc trên các tầng riêng biệt hoặc thậm chí các tòa nhà riêng biệt. Kết quả là các đội im lặng chỉ quan tâm đến sự sợ hãi của chính họ, thời gian dài, các bản phát hành bị phá hỏng và những khách hàng không hài lòng.

Chắc chắn có một cách tốt hơn, họ nói. Vì vậy, hai cộng đồng đã hợp tác và bắt đầu nói chuyện – với những người như Patrick Dubois, Gene Kim và John Willis điều khiển cuộc trò chuyện.

Những gì bắt đầu trong các diễn đàn trực tuyến và các cuộc gặp gỡ bây giờ là một chủ đề chính trong zeitgeist, có lẽ là những gì đã đưa bạn đến đây! Bạn và nhóm của bạn đang cảm thấy vô cùng khó khăn do các đội im lặng và đường dây liên lạc bị phá vỡ trong công ty của bạn.

Bạn đang sử dụng các phương pháp nhanh để lập kế hoạch và phát triển , nhưng vẫn cố gắng để đưa code đó ra khỏi cửa mà không qua sự kiểm soát. Bạn đã nghe một vài điều về DevOps và hiệu ứng dường như kỳ diệu mà nó có thể có đối với các đội và nghĩ rằng tôi muốn một số phép thuật đó.

Tin xấu là DevOps không phải là phép thuật, và biến đổi không xảy ra trong một đêm. Tin tốt là bạn không phải chờ quản lý cấp trên đưa ra sáng kiến ​​quy mô lớn. Bằng cách hiểu giá trị của DevOps và thực hiện các thay đổi nhỏ, tăng dần, nhóm của bạn có thể bắt đầu hành trình DevOps ngay lập tức. Chúng ta hãy xem xét từng lợi ích một cách chi tiết.

Cơ sở hạ tầng dưới dạng code cho phép chúng tôi thực hiện thêm 10 lần xây dựng mà không cần thêm một người vào nhóm của mình.

– Michael Knight, Kỹ sư xây dựng tại Atlassian.

Có gì trong đó cho bạn?

Hợp tác và tin tưởng

Văn hóa là yếu tố thành công số 1 trong DevOps. Xây dựng văn hóa về trách nhiệm chung, minh bạch và phản hồi nhanh hơn là nền tảng của mọi nhóm DevOps hiệu suất cao.

Các nhóm làm việc trong dự án thường không tuân thủ ‘suy nghĩ hệ thống’ của DevOps. ‘Hệ thống suy nghĩ’ đang nhận thức được hành động của bạn không chỉ ảnh hưởng đến nhóm của bạn, mà tất cả các nhóm khác tham gia vào quá trình phát hành. Thiếu tầm nhìn và các mục tiêu được chia sẻ có nghĩa là thiếu kế hoạch phụ thuộc, các ưu tiên sai lệch, chỉ tay và ‘không phải vấn đề của chúng tôi’, dẫn đến vận tốc chậm hơn và chất lượng không đạt chuẩn. DevOps là sự thay đổi trong suy nghĩ về việc nhìn vào quá trình phát triển một cách toàn diện và phá vỡ rào cản giữa Dev và Ops.

Phát hành sản phẩm nhanh hơn và làm việc thông minh hơn

Tốc độ là tất cả. Các nhóm thực hành DevOps phát hành thường xuyên hơn, với chất lượng và độ ổn định cao hơn.

Thiếu các chu trình kiểm tra và đánh giá tự động chặn việc phát hành sản xuất và thời gian phản ứng sự cố kém sẽ giết chết vận tốc và sự tự tin của đội. Các công cụ và quy trình khác nhau làm tăng OPEX, dẫn đến chuyển đổi ngữ cảnh và làm chậm đà. Thông qua các công cụ và quy trình tự động hóa và tiêu chuẩn hóa, các nhóm có thể tăng năng suất và phát hành thường xuyên hơn với ít trục trặc hơn.

Tăng tốc thời gian để giải quyết

Nhóm có vòng phản hồi nhanh nhất là nhóm phát triển mạnh. Tính minh bạch hoàn toàn và giao tiếp liền mạch cho phép các nhóm DevOps giảm thiểu thời gian chết và giải quyết các vấn đề nhanh hơn bao giờ hết.

Nếu vấn đề quan trọng không được giải quyết nhanh chóng, sẽ làm giảm hài lòng của khách hàng. Các vấn đề chính trượt qua các vết nứt trong trường hợp không có giao tiếp mở, dẫn đến sự căng thẳng và thất vọng gia tăng giữa các đội. Giao tiếp cởi mở giúp các nhóm Dev và Ops tập trung vào các vấn đề, khắc phục sự cố và dọn đường cho pipeline phát hành nhanh hơn.

Quản lý tốt hơn công việc không có kế hoạch

Công việc không có kế hoạch là một thực tế mà mọi đội phải đối mặt với một thực tế thường ảnh hưởng đến năng suất của đội. Với các quy trình được thiết lập và ưu tiên rõ ràng, các nhóm Dev và Ops có thể quản lý tốt hơn các công việc không có kế hoạch trong khi tiếp tục tập trung vào công việc theo kế hoạch.

Chuyển đổi và ưu tiên công việc không có kế hoạch giữa các nhóm và hệ thống khác nhau là không hiệu quả và làm mất tập trung trong công việc. Tuy nhiên, thông qua nâng cao tầm nhìn và hồi tưởng chủ động, các nhóm có thể dự đoán tốt hơn và chia sẻ công việc không có kế hoạch.

Khung CALMS cho DevOps

Văn hóa

Tự động hóa

Lean

Đo lường

Chia sẻ

Văn hóa

Nếu chúng ta có thể tóm tắt văn hóa DevOps trong một từ, thì đó là sự cộng tác của người Hồi giáo – và nếu chúng ta được cho phép hai từ, thì đó sẽ là sự hợp tác đa chức năng của Hồi giáo.

Tất cả các công cụ và tự động hóa trên thế giới đều vô dụng nếu chúng không đi kèm với mong muốn thực sự về phía các chuyên gia phát triển và IT / Ops để làm việc cùng nhau. Bởi vì DevOps không giải quyết vấn đề dụng cụ. Nó giải quyết vấn đề của con người. Do đó, một ngày nào đó bạn sẽ không thể thò đầu ra khỏi tủ, nhìn xung quanh và khám phá rằng các đội trong công ty của bạn thể hiện văn hóa DevOps. Nhưng có những điều đơn giản bạn có thể làm để nuôi dưỡng nó.

Hãy nghĩ về DevOps giống như nhanh nhẹn, nhưng với các hoạt động đi kèm. Hình thành các nhóm định hướng dự án hoặc sản phẩm để thay thế các nhóm dựa trên chức năng là một bước đi đúng hướng. Bao gồm phát triển, QA, quản lý sản phẩm, thiết kế, vận hành, quản lý dự án và bất kỳ kỹ năng nào khác mà dự án yêu cầu.

Vài điều thúc đẩy sự hợp tác như chia sẻ một mục tiêu chung và có kế hoạch để đạt được nó cùng nhau. Tại một số công ty, việc chuyển đổi đột ngột sang các nhóm dựa trên dự án là quá nhiều, quá sớm. Vì vậy, thực hiện các bước nhỏ hơn. Các nhóm phát triển có thể – và nên – mời các thành viên phù hợp của nhóm điều hành tham gia các phiên lập kế hoạch chạy nước rút, đứng lên hàng ngày và chạy nước rút. Đội ngũ vận hành có thể mời các nhà phát triển chính. Đó là một cách nhanh nhẹn và hữu cơ để theo kịp nhịp đập của các dự án, ý tưởng và cuộc đấu tranh của nhau. Thời gian dành cho việc lắng nghe và thụ phấn chéo kiến ​​thức trong lĩnh vực chủ đề tự trả tiền bằng cách thực hiện quản lý phát hành và xử lý sự cố khẩn cấp hiệu quả hơn nhiều.

Và nói về các trường hợp khẩn cấp, chúng là một thử nghiệm hiệu quả về văn hóa DevOps. Các nhà phát triển, hoạt động và hỗ trợ khách hàng có thể giải quyết vấn đề và giải quyết nó như một nhóm không? Có phải tất cả mọi người bắt đầu với giả định rằng đồng đội của họ đã đưa ra quyết định tốt nhất có thể với thông tin và tài nguyên họ có tại thời điểm đó? Là sự cố hậu kỳ về việc sửa chữa các quy trình thay vì chỉ tay? Nếu câu trả lời là có, thì đó là một dấu hiệu tốt cho thấy nhóm của bạn hoạt động với văn hóa DevOps ở cốt lõi.

Lưu ý rằng các công ty thành công nhất đang ở trên tàu với văn hóa DevOps trên tất cả các bộ phận và ở tất cả các cấp độ của biểu đồ tổ chức. Họ có các kênh giao tiếp mở, và nói chuyện thường xuyên. Họ đảm bảo các mục tiêu của mọi người được căn chỉnh và điều chỉnh khi cần thiết. Họ cho rằng việc giữ cho khách hàng hài lòng cũng là trách nhiệm của ban quản lý sản phẩm cũng như trách nhiệm của nhóm phát triển. Họ hiểu rằng DevOps không phải là công việc của một đội. Đó là công việc của mọi người.Các nhóm thực hành DevOps triển khai thường xuyên hơn 30 lần, thất bại ít hơn 60 lần và phục hồi nhanh hơn 160 lần.- Báo cáo tình trạng DevOps của Puppet Labs 2016

Tự động hóa

Đầu tư vào tự động hóa giúp loại bỏ công việc thủ công lặp đi lặp lại, mang lại các quy trình lặp lại và tạo ra các hệ thống đáng tin cậy.

Xây dựng, thử nghiệm, triển khai và cung cấp tự động hóa là những điểm khởi đầu điển hình cho các đội chưa có chúng tại chỗ. Và này: lý do nào tốt hơn để các nhà phát triển, người thử nghiệm và nhà khai thác hợp tác với nhau hơn là xây dựng hệ thống để mang lại lợi ích cho tất cả mọi người?

Các nhóm mới tự động hóa thường bắt đầu bằng phân phối liên tục: thực hành chạy từng thay đổi mã thông qua một thử nghiệm tự động, thường được tạo điều kiện bởi cơ sở hạ tầng dựa trên đám mây, sau đó đóng gói các bản dựng thành công và thúc đẩy sản xuất bằng cách sử dụng các triển khai tự động. Như bạn có thể đoán, giao hàng liên tục không phải là một điều nhanh chóng và dễ dàng để thiết lập, nhưng lợi tức đầu tư là rất xứng đáng.

Tại sao? Máy tính thực hiện các bài kiểm tra nghiêm ngặt và trung thành hơn con người. Các thử nghiệm này bắt lỗi và lỗi bảo mật sớm hơn, cho phép các nhà phát triển sửa chúng dễ dàng hơn. Và tự động triển khai cảnh báo IT / Ops cho máy chủ trôi dạt giữa các môi trường, giúp giảm hoặc loại bỏ những bất ngờ khi đến lúc phát hành.

Một trong những đóng góp lớn khác của DevOps là ý tưởng về cấu hình của mã như là mã. Các nhà phát triển cố gắng tạo ra các ứng dụng mô đun, có thể kết hợp được vì chúng đáng tin cậy và có thể bảo trì hơn. Suy nghĩ tương tự có thể được mở rộng đến cơ sở hạ tầng lưu trữ chúng, cho dù nó sống trên đám mây hay trên mạng riêng của công ty.

Đúng, hệ thống luôn thay đổi. Nhưng chúng ta có thể tạo ra một mặt bất biến bằng cách sử dụng mã để cung cấp để việc cung cấp lại một máy chủ bị xâm nhập trở nên nhanh hơn sửa chữa nó – chưa kể đáng tin cậy hơn. Nó làm giảm rủi ro, quá. Cả phát triển và vận hành đều có thể kết hợp các ngôn ngữ hoặc công nghệ mới thông qua mã cung cấp và chia sẻ các bản cập nhật với nhau. Các vấn đề tương thích trở nên rõ ràng ngay lập tức, thay vì biểu hiện ở giữa một bản phát hành.

Cấu hình của bộ máy như mã và giao hàng liên tục, không phải là loại tự động hóa duy nhất được thấy trong thế giới DevOps, nhưng chúng đáng được đề cập đặc biệt bởi vì chúng giúp phá vỡ bức tường giữa phát triển và vận hành. Và khi DevOps sử dụng các triển khai tự động để gửi mã được kiểm tra kỹ lưỡng đến các môi trường được cung cấp giống hệt nhau, thì Công trình trên máy của tôi!

Lean

Khi chúng ta nghe nói về “lean” trong bối cảnh của phần mềm, chúng ta thường nghĩ về việc loại bỏ các hoạt động có giá trị thấp và di chuyển nhanh chóng – trở nên xảo quyệt, nhanh nhẹn hơn. Thậm chí phù hợp hơn với DevOps là các khái niệm về cải tiến liên tục và đón nhận thất bại.

Một tư duy DevOps nhìn thấy cơ hội để cải tiến liên tục ở mọi nơi. Một số là rõ ràng, như tổ chức hồi cứu thường xuyên để quy trình của nhóm bạn có thể cải thiện. Những người khác thì tinh tế, như A / B thử nghiệm các cách tiếp cận trên máy bay khác nhau cho người dùng mới của sản phẩm của bạn.

Tôi đã phát triển nhanh để cảm ơn vì đã cải tiến liên tục một ý tưởng chủ đạo. Những người áp dụng sớm phương pháp nhanh đã chứng minh rằng một sản phẩm đơn giản trong tay khách hàng ngày nay có giá trị hơn một sản phẩm hoàn hảo trong tay khách hàng sáu tháng kể từ bây giờ. Nếu sản phẩm được cải tiến liên tục, khách hàng sẽ bám xung quanh.

Và đoán xem: thất bại là không thể tránh khỏi. Vì vậy, bạn cũng có thể thiết lập nhóm của mình để tiếp thu nó, phục hồi và học hỏi từ nó (một số người gọi đây là một trò chơi chống phá dễ vỡ).

Trong bối cảnh của DevOps, thất bại không phải là một hành vi phạm tội bị trừng phạt. Các nhóm cho rằng mọi thứ chắc chắn sẽ trở thành hình quả lê tại một số điểm, vì vậy họ xây dựng để phát hiện nhanh và phục hồi nhanh chóng. (Đọc về Chaos Monkey của Nexflix để biết một ví dụ tuyệt vời.) Các postmortem tập trung vào nơi các quy trình rơi xuống và làm thế nào để củng cố chúng – không phải là thành viên nào trong nhóm đã tạo ra mã. Tại sao? Bởi vì liên tục cải tiến và thất bại đi đôi với nhau.DevOps đã phát triển để sự phát triển sở hữu nhiều hoạt động hơn – và đó là cách Chef hoạt động. Chúng ta không thể ném nó lên tường nữa. 

“Các kỹ sư của chúng tôi chịu trách nhiệm về QA, viết và chạy các bài kiểm tra của riêng họ để đưa phần mềm ra cho khách hàng.”

– Julian Dunn, Giám đốc sản phẩm tại Chef

Đo lường

Thật khó để chứng minh những nỗ lực cải tiến liên tục của bạn đang thực sự cải thiện bất cứ điều gì mà không có dữ liệu. May mắn thay, có vô số công cụ và công nghệ để đo lường hiệu suất như người dùng dành bao nhiêu thời gian cho sản phẩm của bạn, cho dù bài đăng trên blog đó có tạo ra bất kỳ doanh số nào hay tần suất các cảnh báo quan trọng xuất hiện trong nhật ký của bạn.

Mặc dù bạn có thể đo bất cứ thứ gì, nhưng điều đó không có nghĩa là bạn phải (hoặc nên) đo lường mọi thứ. Lấy một trang từ sự phát triển nhanh và bắt đầu với những điều cơ bản:

  • Mất bao lâu để đi từ phát triển đến triển khai? 
  • Làm thế nào thường xuyên xảy ra lỗi định kỳ hoặc thất bại xảy ra?
  • Mất bao lâu để phục hồi sau khi hệ thống bị lỗi?
  • Có bao nhiêu người đang sử dụng sản phẩm của bạn ngay bây giờ?
  • Bạn đã tăng / mất bao nhiêu người dùng trong tuần này?

Với nền tảng vững chắc, việc nắm bắt các số liệu tinh vi hơn xung quanh việc sử dụng tính năng, hành trình khách hàng và thỏa thuận cấp độ dịch vụ (SLA) sẽ dễ dàng hơn. Thông tin bạn nhận được có ích khi đến lúc lập bản đồ đường bộ và chỉ ra bước tiến lớn tiếp theo của bạn.

Tất cả dữ liệu ngon ngọt này sẽ giúp nhóm của bạn đưa ra quyết định, nhưng nó thậm chí còn mạnh mẽ hơn khi được chia sẻ với các nhóm khác – đặc biệt là các nhóm trong các phòng ban khác. Ví dụ, nhóm tiếp thị của bạn muốn các tính năng mới sáng bóng mà họ có thể bán. Tuy nhiên, trong khi đó, bạn đang chứng kiến ​​sự khuấy động của khách hàng cao vì sản phẩm này đang chìm trong nợ kỹ thuật. Cung cấp dữ liệu người dùng hỗ trợ lộ trình của bạn – ngay cả khi nó nhẹ về các tính năng và khắc phục sự cố – giúp dễ dàng xây dựng sự đồng thuận và mua hàng từ các bên liên quan.

Devops không phải là bất kỳ công việc của một người. Đó là công việc của mọi người.

– Barshe Capel, Giám đốc sản phẩm chính, Jira

Chia sẻ

Sự xích mích lâu dài giữa các nhóm phát triển và vận hành phần lớn là do thiếu điểm chung. Chúng tôi tin rằng việc chia sẻ trách nhiệm và thành công sẽ đi một chặng đường dài hướng tới việc bắc cầu cho sự chia rẽ đó. Các nhà phát triển có thể giành được thiện chí tức thì bằng cách giúp mang một trong những gánh nặng lớn nhất của hoạt động: máy nhắn tin. DevOps rất có ý tưởng rằng cùng những người xây dựng một ứng dụng nên tham gia vào việc vận chuyển và vận hành nó.

Điều này không có nghĩa là bạn thuê các nhà phát triển và chỉ đơn giản mong họ cũng là nhà khai thác xuất sắc. Điều đó có nghĩa là các nhà phát triển và nhà khai thác ghép nối với nhau trong từng giai đoạn trong vòng đời của ứng dụng.

Các nhóm nắm lấy DevOps thường có vai trò luân phiên, theo đó các nhà phát triển giải quyết các vấn đề mà người dùng cuối gặp phải, đồng thời, khắc phục sự cố sản xuất. Người này phản hồi các vấn đề khẩn cấp do khách hàng báo cáo, tạo ra các bản vá khi cần thiết và hoạt động thông qua các hồ sơ tồn đọng của các lỗi do khách hàng báo cáo. Nhà phát triển trên nền tảng hỗ trợ, học hỏi rất nhiều về cách ứng dụng được sử dụng ngoài tự nhiên. Và bằng cách sẵn sàng cao cho nhóm điều hành, các nhóm phát triển xây dựng niềm tin và sự tôn trọng lẫn nhau.

Slogging qua các bản vá thô với nhau làm cho kỷ niệm về thành công của tất cả trở lên ngọt ngào hơn. Bạn sẽ biết văn hóa DevOps đã nắm giữ tại công ty của bạn khi bạn thấy nhóm phát triển mang bánh mì cho nhóm vận hành vào ngày phát hành.

Phản hồi tích cực từ các đồng nghiệp thúc đẩy sự phát triển của công ty. Việc công nhận sự phát hiện lỗi của thành viên sẽ rất tốt. Nếu bộ phận của bạn có ngân sách tùy ý cho nhân viên, đừng để nó không được sử dụng!