Có khó nắm bắt được điểm chính khi nói về DevOps không? Chúng tôi đã thu thập cho bạn những so sánh sinh động, công thức nổi bật và lời khuyên từ các chuyên gia sẽ giúp ngay cả những người không chuyên cũng đi thẳng vào vấn đề. Cuối cùng, phần thưởng là DevOps của chính nhân viên Red Hat.
Thuật ngữ DevOps có nguồn gốc từ 10 năm trước và đã đi từ hashtag Twitter trở thành một phong trào văn hóa mạnh mẽ trong thế giới CNTT, một triết lý thực sự khuyến khích các nhà phát triển hoàn thành công việc nhanh hơn, thử nghiệm và lặp lại. DevOps đã trở nên gắn bó chặt chẽ với khái niệm chuyển đổi kỹ thuật số. Nhưng như thường lệ với thuật ngữ CNTT, trong mười năm qua DevOps đã có nhiều định nghĩa, cách giải thích và quan niệm sai lầm về chính nó.
Vì vậy, bạn có thể thường xuyên nghe thấy những câu hỏi về DevOps như thế nào, nó có giống với Agile không? Hay đây là một phương pháp đặc biệt nào đó? Hay nó chỉ là một từ đồng nghĩa khác của từ “cộng tác”?
DevOps bao gồm nhiều khái niệm khác nhau (phân phối liên tục, tích hợp liên tục, tự động hóa, v.v.), vì vậy việc chắt lọc những gì quan trọng có thể là một thách thức, đặc biệt là khi bạn đam mê chủ đề này. Tuy nhiên, kỹ năng này rất hữu ích, bất kể bạn đang cố gắng truyền đạt ý tưởng của mình với cấp trên hay chỉ đơn giản là nói với ai đó trong gia đình hoặc bạn bè về công việc của bạn. Do đó, bây giờ chúng ta hãy tạm gác các sắc thái thuật ngữ của DevOps sang một bên và tập trung vào bức tranh toàn cảnh.
DevOps là gì: 6 định nghĩa và sự tương tự
Chúng tôi đã yêu cầu các chuyên gia giải thích bản chất của DevOps một cách đơn giản và ngắn gọn nhất có thể để giá trị của nó trở nên rõ ràng đối với độc giả ở mọi cấp độ kiến thức kỹ thuật. Dựa trên kết quả của những cuộc trò chuyện này, chúng tôi đã chọn ra những so sánh và công thức nổi bật nhất sẽ giúp bạn xây dựng câu chuyện của mình về DevOps.
1. DevOps là một phong trào văn hóa
“DevOps là một phong trào văn hóa trong đó cả hai bên (nhà phát triển phần mềm và chuyên gia vận hành hệ thống CNTT) nhận ra rằng phần mềm không mang lại lợi ích thực sự cho đến khi ai đó bắt đầu sử dụng nó: khách hàng, khách hàng, nhân viên, không phải vấn đề,” Eveline Oehrlich, nhà nghiên cứu cấp cao cho biết nhà phân tích tại Viện DevOps. “Do đó, cả hai bên cùng nhau đảm bảo cung cấp phần mềm nhanh chóng và chất lượng cao.”
2. DevOps là trao quyền cho các nhà phát triển.
“DevOps trao quyền cho các nhà phát triển sở hữu ứng dụng, chạy chúng và quản lý quá trình phân phối từ đầu đến cuối.”
Jai Schniepp, giám đốc nền tảng DevOps tại công ty bảo hiểm Liberty Mutual cho biết: “Thông thường, DevOps được nhắc đến như một cách để tăng tốc độ đưa ứng dụng vào sản xuất bằng cách xây dựng và triển khai các quy trình tự động”. “Nhưng đối với tôi đó là một điều cơ bản hơn nhiều.” DevOps trao quyền cho các nhà phát triển sở hữu các ứng dụng hoặc phần mềm cụ thể, chạy chúng và quản lý quá trình phân phối của chúng từ đầu đến cuối. DevOps loại bỏ sự nhầm lẫn về trách nhiệm và hướng dẫn mọi người tham gia vào việc tạo cơ sở hạ tầng tự động, do nhà phát triển điều khiển.”
3. DevOps là sự hợp tác trong việc tạo và phân phối ứng dụng.
Gur Staf, chủ tịch kiêm người đứng đầu bộ phận tự động hóa kinh doanh kỹ thuật số tại BMC, cho biết: “Nói một cách đơn giản, DevOps là một cách tiếp cận sản xuất và phân phối phần mềm, nơi mọi người làm việc cùng nhau”.
4. DevOps là một đường dẫn
“Việc lắp ráp băng tải chỉ có thể thực hiện được nếu tất cả các bộ phận khớp với nhau.”
Gur Staff tiếp tục: “Tôi sẽ so sánh DevOps với một dây chuyền lắp ráp ô tô. – Ý tưởng là thiết kế và chế tạo trước tất cả các bộ phận để sau đó chúng có thể được lắp ráp mà không cần điều chỉnh riêng lẻ. Việc lắp ráp băng tải chỉ có thể thực hiện được nếu tất cả các bộ phận khớp với nhau. Những người thiết kế và chế tạo động cơ phải cân nhắc cách gắn nó vào thân hoặc khung. Những người chế tạo phanh phải nghĩ đến bánh xe, v.v. Điều tương tự cũng đúng với phần mềm.
Nhà phát triển tạo logic nghiệp vụ hoặc giao diện người dùng phải suy nghĩ về cơ sở dữ liệu lưu trữ thông tin khách hàng, các biện pháp bảo mật để bảo vệ dữ liệu người dùng và cách tất cả những điều này sẽ hoạt động khi dịch vụ bắt đầu phục vụ một lượng lớn người dùng, thậm chí có thể trị giá hàng triệu đô la. ."
“Việc khiến mọi người cộng tác và suy nghĩ về các phần công việc mà người khác đang làm, thay vì chỉ tập trung vào nhiệm vụ của riêng họ, là trở ngại lớn nhất cần vượt qua. Nếu bạn có thể làm được điều này, bạn sẽ có cơ hội tuyệt vời để chuyển đổi kỹ thuật số,” Gur Staff cho biết thêm.
5. DevOps là sự kết hợp đúng đắn giữa con người, quy trình và tự động hóa
Jayne Groll, giám đốc điều hành của Viện DevOps, đã đưa ra một ví dụ tuyệt vời để giải thích về DevOps. Theo cách nói của cô ấy, “DevOps giống như một công thức với ba loại thành phần chính: con người, quy trình và tự động hóa. Hầu hết các thành phần này có thể được lấy từ các lĩnh vực và nguồn khác: Lean, Agile, SRE, CI/CD, ITIL, lãnh đạo, văn hóa, công cụ. Bí quyết của DevOps, giống như bất kỳ công thức hay nào, là làm thế nào để có được tỷ lệ và sự kết hợp phù hợp của các thành phần này nhằm tăng tốc độ và hiệu quả của việc tạo và phát hành ứng dụng.”
6. DevOps là khi các lập trình viên làm việc như một đội Công thức 1
“Cuộc đua không được lên kế hoạch từ đầu đến cuối mà ngược lại, từ đầu đến cuối.”
Chris Short, giám đốc cấp cao về tiếp thị nền tảng đám mây tại Red Hat và nhà xuất bản bản tin DevOps'ish, cho biết: “Khi tôi nói về những gì có thể mong đợi từ một sáng kiến DevOps, tôi nghĩ đến một đội đua NASCAR hoặc Công thức 1 làm ví dụ. – Người lãnh đạo của một đội như vậy có một mục tiêu: giành vị trí cao nhất có thể khi kết thúc cuộc đua, có tính đến các nguồn lực sẵn có của đội và những thách thức xảy ra với đội đó. Trong trường hợp này, cuộc đua được lên kế hoạch không phải từ đầu đến cuối mà ngược lại, từ đầu đến cuối. Đầu tiên, một mục tiêu đầy tham vọng được đặt ra, sau đó là những cách để đạt được mục tiêu đó được xác định. Sau đó, chúng được chia thành các nhiệm vụ phụ và giao cho các thành viên trong nhóm.”
“Đội dành cả tuần trước cuộc đua để hoàn thiện điểm dừng. Anh ấy tập luyện sức mạnh và tim mạch để giữ dáng cho một ngày đua mệt mỏi. Thực hành làm việc cùng nhau để giải quyết mọi vấn đề có thể phát sinh trong cuộc đua. Tương tự như vậy, nhóm phát triển nên đào tạo kỹ năng phát hành phiên bản mới thường xuyên. Nếu bạn có những kỹ năng như vậy và hệ thống bảo mật hoạt động tốt thì việc đưa các phiên bản mới vào sản xuất cũng diễn ra thường xuyên hơn. Trong thế giới quan này, tốc độ tăng lên đồng nghĩa với việc tăng độ an toàn,” Short nói.
Short cho biết thêm: “Vấn đề không phải là làm ‘điều đúng’, mà là loại bỏ càng nhiều thứ càng tốt cản trở kết quả mong muốn. Cộng tác và điều chỉnh dựa trên phản hồi bạn nhận được trong thời gian thực. Hãy chuẩn bị cho những điều bất thường và nỗ lực cải thiện chất lượng để giảm thiểu tác động của chúng đến tiến độ hướng tới mục tiêu của bạn. Đây là điều đang chờ đợi chúng ta trong thế giới DevOps.”
Cách mở rộng quy mô DevOps: 10 lời khuyên từ chuyên gia
Chỉ là DevOps và DevOps đại chúng là những thứ hoàn toàn khác nhau. Chúng tôi sẽ cho bạn biết cách vượt qua các rào cản trên con đường từ thứ nhất đến thứ hai.
Đối với nhiều tổ chức, hành trình đến với DevOps bắt đầu một cách dễ dàng và thú vị. Các nhóm nhỏ đầy nhiệt huyết được thành lập, các quy trình cũ được thay thế bằng quy trình mới và những thành công đầu tiên sẽ không còn lâu nữa.
Than ôi, đây chỉ là một sự hào nhoáng giả tạo, một ảo tưởng về sự tiến bộ, Ben Grinnell, giám đốc điều hành và người đứng đầu bộ phận kỹ thuật số tại công ty tư vấn North Highland, cho biết. Những chiến thắng sớm chắc chắn rất đáng khích lệ, nhưng chúng không giúp đạt được mục tiêu cuối cùng là áp dụng rộng rãi DevOps trong toàn tổ chức.
Dễ dàng nhận thấy kết quả là một nền văn hóa chia rẽ giữa “chúng ta” và “bọn họ”.
Ben Grinnell giải thích: “Thông thường, các tổ chức khởi động những dự án tiên phong này với suy nghĩ rằng chúng sẽ mở đường cho DevOps chính thống mà không xem xét liệu những người khác có thể hoặc sẵn sàng đi theo con đường đó hay không”. – Các nhóm thực hiện các dự án như vậy thường được tuyển dụng từ những “người Varangian” tự tin, những người đã từng làm điều gì đó tương tự ở những nơi khác, nhưng mới gia nhập tổ chức của bạn. Đồng thời, họ được khuyến khích phá bỏ và phá hủy các quy tắc vẫn ràng buộc với mọi người khác. Dễ dàng nhận thấy kết quả là nền văn hóa “chúng ta” và “họ” cản trở việc chuyển giao kiến thức và kỹ năng”.
“Và vấn đề văn hóa này chỉ là một trong những lý do khiến DevOps khó mở rộng quy mô. Steve Newman, người sáng lập và chủ tịch của Scalyr cho biết, các nhóm DevOps đang phải đối mặt với những thách thức kỹ thuật ngày càng tăng, đặc trưng của các công ty ưu tiên CNTT đang phát triển nhanh chóng.
“Trong thế giới hiện đại, các dịch vụ thay đổi ngay khi có nhu cầu. Steve Newman cho biết thêm, thật tuyệt khi liên tục triển khai và triển khai các tính năng mới, nhưng việc điều phối quá trình này và loại bỏ các vấn đề phát sinh thực sự là một vấn đề đau đầu. – Trong các tổ chức đang phát triển rất nhanh, các kỹ sư trong các nhóm chức năng chéo gặp khó khăn trong việc duy trì tầm nhìn về sự thay đổi và các hiệu ứng xếp tầng mà nó tạo ra ở cấp độ phụ thuộc. Hơn nữa, các kỹ sư không vui khi bị tước đi cơ hội này và kết quả là họ càng khó hiểu được bản chất của các vấn đề nảy sinh.”
Làm cách nào để vượt qua những thách thức được mô tả ở trên và chuyển sang áp dụng hàng loạt DevOps trong một tổ chức lớn? Các chuyên gia kêu gọi sự kiên nhẫn, ngay cả khi mục tiêu cuối cùng của bạn là tăng tốc chu kỳ phát triển phần mềm và quy trình kinh doanh.
1. Hãy nhớ rằng sự thay đổi văn hóa cần có thời gian.
Jayne Groll, Giám đốc điều hành, Viện DevOps: “Theo ý kiến của tôi, việc mở rộng DevOps nên tăng dần và lặp đi lặp lại như sự phát triển linh hoạt (và cũng liên quan đến văn hóa). Agile và DevOps nhấn mạnh vào các nhóm nhỏ. Nhưng khi các nhóm này phát triển về số lượng và sự hội nhập, chúng ta sẽ có nhiều người áp dụng những cách làm việc mới hơn và kết quả là có một sự chuyển đổi văn hóa lớn.”
2. Dành đủ thời gian để lập kế hoạch và chọn nền tảng
Eran Kinsbruner, Nhà truyền bá kỹ thuật chính tại Perfecto: “Để mở rộng quy mô hoạt động, các nhóm DevOps trước tiên phải học cách kết hợp các quy trình, công cụ và kỹ năng truyền thống, sau đó từ từ nuôi dưỡng và ổn định từng giai đoạn riêng lẻ của DevOps. Tất cả đều bắt đầu bằng việc lập kế hoạch cẩn thận về câu chuyện của người dùng và luồng giá trị, sau đó là viết phần mềm và kiểm soát phiên bản bằng cách sử dụng phát triển dựa trên đường trục hoặc các phương pháp tiếp cận khác phù hợp nhất để phân nhánh và hợp nhất mã.”
“Sau đó là giai đoạn tích hợp và thử nghiệm, trong đó cần có một nền tảng có thể mở rộng để tự động hóa. Đây là lúc điều quan trọng đối với các nhóm DevOps là chọn nền tảng phù hợp với trình độ kỹ năng của họ và mục tiêu cuối cùng của dự án.
Giai đoạn tiếp theo là triển khai vào sản xuất và giai đoạn này sẽ hoàn toàn tự động bằng cách sử dụng các công cụ điều phối và vùng chứa. Điều quan trọng là phải có môi trường ảo hóa ở tất cả các giai đoạn của DevOps (mô phỏng sản xuất, môi trường QA và môi trường sản xuất thực tế) và luôn chỉ sử dụng dữ liệu mới nhất cho các thử nghiệm để đưa ra kết luận liên quan. Phân tích phải thông minh và có khả năng xử lý dữ liệu lớn với phản hồi nhanh và hữu ích.”
3. Loại bỏ cảm giác tội lỗi.
Gordon Haff, Nhà truyền giáo RedHat: “Việc tạo ra một hệ thống và bầu không khí cho phép và khuyến khích thử nghiệm sẽ tạo ra những thất bại thành công trong quá trình phát triển phần mềm linh hoạt. Điều này không có nghĩa là không ai khác phải chịu trách nhiệm về những thất bại. Trên thực tế, việc xác định ai chịu trách nhiệm thậm chí còn trở nên dễ dàng hơn vì “chịu trách nhiệm” không còn có nghĩa là “gây ra tai nạn”. Đó là, bản chất của trách nhiệm thay đổi về chất. Bốn yếu tố trở nên quan trọng: mức độ gián đoạn, cách tiếp cận, quy trình sản xuất và động cơ khuyến khích.” (Bạn có thể đọc thêm về những yếu tố này trong bài viết “Bài học DevOps: 4 khía cạnh của thử nghiệm lành mạnh” của Gordon Huff.)
4. Dọn đường phía trước
Ben Grinnell, giám đốc điều hành và trưởng bộ phận kỹ thuật số tại công ty tư vấn North Highland: “Để đạt được quy mô, tôi khuyên bạn nên triển khai chương trình “dọn đường” cùng với các dự án tiên phong. Mục tiêu của chương trình này là dọn sạch những thứ rác rưởi mà những người tiên phong DevOps để lại, chẳng hạn như các quy tắc lỗi thời và những thứ tương tự, để con đường phía trước vẫn rõ ràng.”
“Mang đến cho mọi người sự hỗ trợ và động lực về mặt tổ chức thông qua hoạt động giao tiếp vượt xa nhóm tiên phong bằng cách tôn vinh rộng rãi những thành công của cách làm việc mới. Huấn luyện những người tham gia vào làn sóng dự án DevOps tiếp theo và lo lắng về việc sử dụng DevOps lần đầu tiên. Và hãy nhớ rằng những người này rất khác với những người tiên phong.”
5. Dân chủ hóa các công cụ
Steve Newman, người sáng lập và chủ tịch của Scalyr: “Không nên giấu mọi người các công cụ và chúng phải tương đối dễ học đối với bất kỳ ai sẵn sàng dành thời gian. Nếu khả năng truy vấn nhật ký bị giới hạn ở ba người được "chứng nhận" sử dụng một công cụ, bạn sẽ luôn có tối đa ba người sẵn sàng để xử lý sự cố, ngay cả khi bạn có môi trường điện toán rất lớn. Nói cách khác, có một nút thắt ở đây có thể dẫn đến những hậu quả (kinh doanh) nghiêm trọng.”
6. Tạo điều kiện lý tưởng để làm việc nhóm
Tom Clark, người đứng đầu Nền tảng chung tại ITV: “Bạn có thể làm bất cứ điều gì, nhưng không phải tất cả mọi thứ cùng một lúc. Vì vậy, hãy đặt ra những mục tiêu lớn, bắt đầu từ việc nhỏ và tiến về phía trước với tốc độ lặp lại nhanh chóng. Theo thời gian, bạn sẽ tạo dựng được danh tiếng về khả năng hoàn thành công việc, vì vậy những người khác cũng sẽ muốn sử dụng phương pháp của bạn. Và đừng lo lắng về việc xây dựng một đội ngũ hiệu quả cao. Thay vào đó, hãy cung cấp cho mọi người điều kiện làm việc lý tưởng và hiệu quả sẽ theo sau.”
7. Đừng quên Luật Conway và bảng Kanban
Logan Daigle, Giám đốc Chiến lược phân phối phần mềm và DevOps tại CollabNetVersionOne: “Điều quan trọng là phải hiểu được hậu quả của Định luật Conway. Theo cách diễn giải lỏng lẻo của tôi, luật này quy định rằng các sản phẩm chúng tôi tạo ra và các quy trình chúng tôi sử dụng để làm như vậy, bao gồm cả DevOps, hóa ra được cấu trúc giống như tổ chức của chúng tôi.”
“Nếu có nhiều ngăn cách trong một tổ chức và quyền kiểm soát được trao đổi nhiều lần khi lập kế hoạch, xây dựng và phát hành phần mềm thì hiệu quả của việc mở rộng quy mô sẽ bằng XNUMX hoặc chỉ tồn tại trong thời gian ngắn. Nếu một tổ chức xây dựng các nhóm đa chức năng xung quanh các sản phẩm được tài trợ tập trung vào thị trường thì cơ hội thành công sẽ tăng lên đáng kể.”
“Một khía cạnh quan trọng khác của việc chia tỷ lệ là hiển thị tất cả công việc đang tiến hành (WIP, tiến trình công việc) trên bảng Kanban. Khi một tổ chức có một nơi mà mọi người có thể nhìn thấy những thứ này, điều đó sẽ khuyến khích sự hợp tác rất nhiều, điều này có tác động tích cực đến việc mở rộng quy mô.”
8. Tìm kiếm những vết sẹo cũ
Manuel Pais, nhà tư vấn DevOps và đồng tác giả của Cấu trúc liên kết nhóm: “Đưa các phương pháp thực hành DevOps vượt ra ngoài bản thân Dev và Ops và cố gắng áp dụng chúng cho các chức năng khác khó có thể là một cách tiếp cận tối ưu. Điều này chắc chắn sẽ có một số tác động (ví dụ: bằng cách tự động hóa điều khiển thủ công), nhưng chúng ta có thể đạt được nhiều điều hơn nữa nếu chúng ta bắt đầu bằng việc hiểu rõ quy trình phân phối và phản hồi.”
“Nếu có những vết sẹo cũ trong hệ thống CNTT của tổ chức - các quy trình và cơ chế quản lý được triển khai do các sự cố trong quá khứ nhưng đã mất đi tính liên quan (do những thay đổi về sản phẩm, công nghệ hoặc quy trình) - thì chúng chắc chắn cần phải được loại bỏ hoặc làm trơn tru thay vì tự động hóa các quy trình không hiệu quả hoặc không cần thiết.”
9. Đừng tạo ra các tùy chọn DevOps
Anthony Edwards, Giám đốc Điều hành tại Cà Tím: “DevOps là một thuật ngữ rất mơ hồ, vì vậy mỗi nhóm sẽ có phiên bản DevOps của riêng mình. Và không có gì tệ hơn khi một tổ chức đột nhiên có 20 loại DevOps không hòa hợp với nhau lắm. Mỗi nhóm trong số ba nhóm phát triển không thể có giao diện đặc biệt của riêng mình giữa phát triển và quản lý sản phẩm. Các sản phẩm cũng không nên có những kỳ vọng riêng về việc xử lý phản hồi khi được chuyển sang trình mô phỏng sản xuất. Nếu không, bạn sẽ không bao giờ có thể mở rộng quy mô DevOps.”
10. Truyền bá giá trị kinh doanh của DevOps
Steve Newman, người sáng lập và chủ tịch của Scalyr: “Làm việc để nhận ra giá trị của DevOps. Hãy tìm hiểu và thoải mái nói về lợi ích của việc bạn làm. DevOps là một công cụ tiết kiệm thời gian và tiền bạc đáng kinh ngạc (hãy nghĩ xem: thời gian ngừng hoạt động ít hơn, thời gian phục hồi trung bình ngắn hơn) và các nhóm DevOps phải nhấn mạnh (và thuyết giảng) không mệt mỏi về tầm quan trọng của những sáng kiến này đối với sự thành công của doanh nghiệp. Bằng cách này, bạn có thể mở rộng vòng tròn những người ủng hộ và tăng tầm ảnh hưởng của DevOps trong tổ chức.”
TIỀN THƯỞNG
Trên DevOps của riêng chúng tôi sẽ ra mắt vào ngày 13 tháng XNUMX - vâng, Red Hat, với tư cách là nhà sản xuất phần mềm, có các nhóm và phương pháp thực hành DevOps của riêng mình.
Kỹ sư Mark Birger của chúng tôi, người phát triển dịch vụ tự động hóa nội bộ cho các nhóm khác trong tổ chức, sẽ kể câu chuyện của chính mình bằng tiếng Nga thuần túy - cách nhóm Red Hat DevOps di chuyển các ứng dụng từ môi trường ảo Hat Virtualization do Ansible quản lý sang định dạng vùng chứa chính thức trên nền tảng OpenShift.
Nhưng đó không phải là tất cả:
Khi các tổ chức đã chuyển khối lượng công việc sang vùng chứa, các phương pháp giám sát ứng dụng truyền thống có thể không hoạt động. Trong buổi nói chuyện thứ hai, chúng tôi sẽ giải thích động lực thay đổi cách chúng tôi ghi nhật ký và cho thấy sự tiếp tục của con đường dẫn chúng tôi đến các phương pháp giám sát và ghi nhật ký hiện đại.
Nguồn: www.habr.com