DevOps đã trở thành một chủ đề rất phổ biến trong vài năm qua. Nhiều người mơ ước được tham gia nó, nhưng, như thực tế cho thấy, thường chỉ vì mức lương.
Một số người liệt kê DevOps trong sơ yếu lý lịch của họ, mặc dù không phải lúc nào họ cũng biết hoặc hiểu bản chất của thuật ngữ này. Một số người cho rằng sau khi nghiên cứu Ansible, GitLab, Jenkins, Terraform và những thứ tương tự (danh sách này có thể được tiếp tục tùy theo sở thích của bạn), bạn sẽ ngay lập tức trở thành một “người sùng đạo”. Tất nhiên điều này không đúng sự thật.
Trong vài năm qua, tôi chủ yếu tham gia triển khai DevOps ở nhiều công ty khác nhau. Trước đó, ông đã làm việc hơn 20 năm ở các vị trí từ quản trị viên hệ thống đến giám đốc CNTT. Hiện là Kỹ sư trưởng DevOps tại Playgendary.
DevOps là ai
Ý tưởng viết một bài báo nảy sinh sau một câu hỏi khác: “DevOps là ai?” Vẫn chưa có thuật ngữ xác định cho cái gì hoặc nó là ai. Một số câu trả lời đã có trong này . Đầu tiên, tôi sẽ nêu bật những điểm chính trong đó, sau đó tôi sẽ chia sẻ những quan sát và suy nghĩ của mình.
DevOps không phải là một chuyên gia có thể được thuê, không phải là một bộ tiện ích và không phải là một bộ phận gồm các nhà phát triển có kỹ sư.
DevOps là một triết lý và phương pháp luận.
Nói cách khác, đó là tập hợp các phương pháp giúp nhà phát triển tương tác tích cực với quản trị viên hệ thống. Tức là kết nối và tích hợp các quy trình làm việc với nhau.
Với sự ra đời của DevOps, cấu trúc và vai trò của các chuyên gia vẫn được giữ nguyên (có nhà phát triển, có kỹ sư), nhưng các quy tắc tương tác đã thay đổi. Ranh giới giữa các phòng ban đã bị xóa nhòa.
Mục tiêu của DevOps có thể được mô tả theo ba điểm:
- Phần mềm phải được cập nhật thường xuyên.
- Phần mềm phải được thực hiện nhanh chóng.
- Phần mềm cần được triển khai thuận tiện và trong thời gian ngắn.
Không có công cụ duy nhất cho DevOps. Việc định cấu hình, phân phối và nghiên cứu một số sản phẩm không có nghĩa là DevOps đã xuất hiện trong công ty. Có rất nhiều công cụ và tất cả chúng đều được sử dụng ở các giai đoạn khác nhau nhưng đều phục vụ một mục đích chung.
Và đây chỉ là một phần của công cụ DevOps
Tôi đã phỏng vấn mọi người cho vị trí kỹ sư DevOps trong hơn 2 năm nay và tôi nhận ra tầm quan trọng của việc hiểu rõ bản chất của thuật ngữ này. Tôi đã tích lũy được những kinh nghiệm, quan sát và suy nghĩ cụ thể mà tôi muốn chia sẻ.
Từ kinh nghiệm phỏng vấn, tôi thấy hình ảnh sau: những chuyên gia coi DevOps là chức danh thường có những hiểu lầm với đồng nghiệp.
Có một ví dụ nổi bật. Một chàng trai trẻ đến phỏng vấn với rất nhiều từ thông minh trong sơ yếu lý lịch của mình. Ở ba công việc gần đây nhất, anh đều có 5-6 tháng kinh nghiệm. Tôi đã rời bỏ hai công ty khởi nghiệp vì chúng “không thành công”. Nhưng về công ty thứ ba, anh ấy nói rằng ở đó không ai hiểu anh ấy: các nhà phát triển viết mã trên Windows và giám đốc buộc mã này phải được “bọc” trong Docker thông thường và được tích hợp vào đường dẫn CI/CD. Anh chàng đã nói rất nhiều điều tiêu cực về nơi làm việc hiện tại và đồng nghiệp của anh ấy - tôi chỉ muốn trả lời: “Vậy là bạn sẽ không bán được một con voi”.
Sau đó, tôi hỏi anh ấy một câu hỏi quan trọng trong danh sách của tôi dành cho mọi ứng viên.
— DevOps có ý nghĩa gì với cá nhân bạn?
- Nói chung hay làm thế nào để tôi nhận thức được nó?
Tôi quan tâm đến ý kiến cá nhân của anh ấy. Ông biết lý thuyết và nguồn gốc của thuật ngữ này, nhưng ông hoàn toàn không đồng ý với chúng. Anh ấy tin rằng DevOps là một chức danh công việc. Đây chính là gốc rễ của những vấn đề của anh ấy. Cũng như các chuyên gia khác có cùng quan điểm.
Các nhà tuyển dụng sau khi nghe nhiều về “điều kỳ diệu của DevOps” đều muốn tìm một người sẽ đến và tạo ra “điều kỳ diệu” này. Và những ứng viên thuộc danh mục “DevOps là một công việc” không hiểu rằng với cách tiếp cận này, họ sẽ không thể đáp ứng được kỳ vọng. Và nói chung, họ viết DevOps trong sơ yếu lý lịch của mình vì đó là xu hướng và họ phải trả rất nhiều tiền cho nó.
Phương pháp và triết lý DevOps
Phương pháp luận có thể mang tính lý thuyết và thực tiễn. Trong trường hợp của chúng tôi, đó là trường hợp thứ hai. Như tôi đã đề cập ở trên, DevOps là một tập hợp các phương pháp và chiến lược được sử dụng để đạt được các mục tiêu đã nêu. Và trong mỗi trường hợp, tùy thuộc vào quy trình kinh doanh của công ty, nó có thể khác nhau đáng kể. Điều đó không làm cho nó tốt hơn hay tệ hơn.
Phương pháp DevOps chỉ là một phương tiện để đạt được mục tiêu.
Bây giờ về triết lý DevOps là gì. Và đây có lẽ là câu hỏi khó nhất.
Rất khó để đưa ra một câu trả lời ngắn gọn và súc tích vì nó vẫn chưa được chính thức hóa. Và vì những người theo triết lý DevOps tham gia nhiều hơn vào thực tế nên đơn giản là không có thời gian để triết lý. Tuy nhiên, đây là một quá trình rất quan trọng. Hơn nữa, nó liên quan trực tiếp đến hoạt động kỹ thuật. Thậm chí còn có một lĩnh vực kiến thức chuyên ngành - .
Ở trường đại học của tôi không có môn học như vậy, tôi phải tự học mọi thứ bằng cách sử dụng những tài liệu mà tôi có thể tìm thấy vào những năm 90. Chủ đề này là tùy chọn đối với giáo dục kỹ thuật, do đó câu trả lời thiếu tính chính thức. Nhưng những người nghiêm túc đắm mình vào DevOps bắt đầu cảm nhận được một “tinh thần” hoặc “sự toàn diện vô thức” nhất định về tất cả các quy trình của công ty.
Sử dụng kinh nghiệm của bản thân, tôi đã cố gắng hình thức hóa một số “định đề” của triết lý này. Kết quả là như sau:
- DevOps không phải là thứ gì đó độc lập có thể tách thành một lĩnh vực kiến thức hoặc hoạt động riêng biệt.
- Tất cả nhân viên của công ty phải được hướng dẫn theo phương pháp DevOps khi lập kế hoạch cho hoạt động của họ.
- DevOps ảnh hưởng đến tất cả các quy trình trong một công ty.
- DevOps tồn tại để giảm chi phí thời gian cho bất kỳ quy trình nào trong công ty nhằm đảm bảo sự phát triển của dịch vụ và sự thoải mái tối đa cho khách hàng.
- DevOps, theo ngôn ngữ hiện đại, là vị trí chủ động của mỗi nhân viên trong công ty, nhằm mục đích giảm chi phí thời gian và nâng cao chất lượng của các sản phẩm CNTT xung quanh chúng ta.
Tôi nghĩ rằng “các định đề” của tôi là một chủ đề riêng để thảo luận. Nhưng bây giờ có một cái gì đó để xây dựng.
DevOps làm gì
Từ khóa ở đây là giao tiếp. Có rất nhiều thông tin liên lạc, người khởi xướng phải chính là kỹ sư DevOps đó. Tại sao vậy? Bởi vì đây là triết học và phương pháp luận, sau đó mới là kiến thức kỹ thuật.
Tôi không thể nói chắc chắn 100% về thị trường lao động phương Tây. Nhưng tôi biết khá nhiều về thị trường DevOps ở Nga. Ngoài hàng trăm cuộc phỏng vấn, trong hơn một năm rưỡi qua, tôi đã tham gia hàng trăm đợt bán trước kỹ thuật cho dịch vụ “Triển khai DevOps” cho các công ty và ngân hàng lớn của Nga.
Ở Nga, DevOps vẫn là một chủ đề còn rất non trẻ nhưng đã trở thành xu hướng. Theo tôi được biết, chỉ riêng ở Matxcơva, số lượng chuyên gia như vậy trong năm 2019 đã lên tới hơn 1000 người. Và từ Kubernetes dành cho người sử dụng lao động gần giống như một miếng giẻ rách màu đỏ dành cho một con bò đực. Những người tuân thủ công cụ này sẵn sàng sử dụng nó ngay cả khi không cần thiết và mang lại lợi nhuận kinh tế. Người sử dụng lao động không phải lúc nào cũng hiểu rõ trong trường hợp nào thì sử dụng cái gì phù hợp hơn và với việc triển khai phù hợp, việc duy trì cụm Kubernetes tốn kém gấp 2-3 lần so với việc triển khai ứng dụng bằng sơ đồ cụm thông thường. Sử dụng nó ở nơi bạn thực sự cần nó.
Việc triển khai DevOps rất tốn kém về mặt tiền bạc. Và nó chỉ hợp lý khi nó mang lại lợi ích kinh tế trong các lĩnh vực khác chứ không phải chỉ riêng nó.
Trên thực tế, các kỹ sư DevOps là những người tiên phong - họ phải là những người đầu tiên triển khai phương pháp này trong công ty và xây dựng các quy trình. Để điều này thành công, chuyên gia phải thường xuyên tương tác với nhân viên và đồng nghiệp ở mọi cấp độ. Như tôi thường nói, tất cả nhân viên công ty nên tham gia vào quá trình triển khai DevOps: từ người dọn dẹp đến CEO. Và đây là điều kiện tiên quyết. Nếu thành viên cấp dưới nhất của nhóm không biết và hiểu DevOps là gì và tại sao một số hành động tổ chức nhất định được thực hiện thì việc triển khai thành công sẽ không thành công.
Ngoài ra, kỹ sư DevOps đôi khi cần sử dụng tài nguyên quản trị. Ví dụ: để vượt qua “sự phản kháng của môi trường” - khi nhóm chưa sẵn sàng chấp nhận các công cụ và phương pháp DevOps.
Nhà phát triển chỉ nên viết mã và kiểm thử. Để làm được điều này, anh ta không cần một chiếc máy tính xách tay siêu mạnh mà anh ta sẽ triển khai và hỗ trợ cục bộ toàn bộ cơ sở hạ tầng của dự án. Ví dụ: một nhà phát triển front-end giữ tất cả các thành phần của ứng dụng trên máy tính xách tay của mình, bao gồm cơ sở dữ liệu, trình mô phỏng S3 (minio), v.v. Nghĩa là, anh ta dành nhiều thời gian để duy trì cơ sở hạ tầng địa phương này và một mình đấu tranh với tất cả các vấn đề của giải pháp như vậy. Thay vì phát triển mã cho mặt trước. Những người như vậy có thể rất chống lại bất kỳ sự thay đổi nào.
Nhưng ngược lại, có những nhóm vui vẻ giới thiệu các công cụ và phương pháp mới và tích cực tham gia vào quá trình này. Mặc dù ngay cả trong trường hợp này, liên lạc giữa kỹ sư DevOps và nhóm vẫn không bị hủy.
Khi DevOps không cần thiết
Có những tình huống không cần đến DevOps. Đây là một sự thật - nó cần được hiểu và chấp nhận.
Trước hết, điều này áp dụng cho bất kỳ công ty nào (đặc biệt là các doanh nghiệp nhỏ), khi lợi nhuận của họ không phụ thuộc trực tiếp vào sự hiện diện hay vắng mặt của các sản phẩm CNTT cung cấp dịch vụ thông tin cho khách hàng. Và ở đây chúng ta không nói về trang web của công ty, có thể là một “danh thiếp” tĩnh hoặc với các khối tin tức động, v.v.
DevOps là bắt buộc khi sự hài lòng của khách hàng và mong muốn quay lại với bạn của họ phụ thuộc vào tính sẵn có của các dịch vụ thông tin này để tương tác với khách hàng, chất lượng và mục tiêu của chúng.
Một ví dụ nổi bật là một ngân hàng nổi tiếng. Công ty không có văn phòng khách hàng truyền thống, việc xử lý tài liệu được thực hiện qua thư hoặc chuyển phát nhanh và nhiều nhân viên làm việc tại nhà. Công ty đã không còn chỉ là một ngân hàng và theo tôi, đã trở thành một công ty CNTT với các công nghệ DevOps phát triển.
Nhiều ví dụ và bài giảng khác có thể được tìm thấy trong các bản ghi âm của các cuộc gặp gỡ và hội nghị theo chủ đề. Tôi đã đích thân đến thăm một số người trong số họ - đây là một trải nghiệm rất hữu ích cho những ai muốn phát triển theo hướng này. Dưới đây là link các kênh YouTube với các bài giảng và tài liệu hay về DevOps:
Bây giờ hãy nhìn vào doanh nghiệp của bạn và suy nghĩ về điều này: Công ty của bạn và lợi nhuận của nó phụ thuộc vào các sản phẩm CNTT để hỗ trợ tương tác với khách hàng đến mức nào?
Nếu công ty của bạn bán cá trong một cửa hàng nhỏ và sản phẩm CNTT duy nhất là hai cấu hình 1C: Enterprise (Kế toán và UNF), thì việc nói về DevOps hầu như không có ý nghĩa gì.
Nếu bạn làm việc tại một doanh nghiệp sản xuất và thương mại lớn (ví dụ: bạn sản xuất súng săn) thì bạn nên suy nghĩ về điều đó. Bạn có thể chủ động và truyền đạt cho ban quản lý của mình triển vọng triển khai DevOps. Vâng, đồng thời, dẫn dắt quá trình này. Vị trí chủ động là một trong những nguyên lý quan trọng của triết lý DevOps.
Quy mô và khối lượng doanh thu tài chính hàng năm không phải là tiêu chí chính để xác định liệu công ty của bạn có cần DevOps hay không.
Hãy tưởng tượng một doanh nghiệp công nghiệp lớn không tương tác trực tiếp với khách hàng. Ví dụ, một số nhà sản xuất ô tô và công ty sản xuất ô tô. Bây giờ tôi không chắc chắn, nhưng theo kinh nghiệm trước đây của tôi, trong nhiều năm, mọi tương tác với khách hàng đều được thực hiện qua email và điện thoại.
Khách hàng của họ là một danh sách hạn chế các đại lý xe hơi. Và mỗi người được phân công một chuyên gia từ nhà sản xuất. Tất cả luồng tài liệu nội bộ diễn ra thông qua SAP ERP. Nhân viên nội bộ về cơ bản là khách hàng của hệ thống thông tin. Nhưng IS này được kiểm soát bằng các phương tiện quản lý hệ thống cụm cổ điển. Điều này loại trừ khả năng sử dụng các phương pháp thực hành DevOps.
Do đó, kết luận: đối với những doanh nghiệp như vậy, việc triển khai DevOps không phải là điều cực kỳ quan trọng, nếu chúng ta nhớ lại các mục tiêu của phương pháp luận ở đầu bài viết. Nhưng tôi không loại trừ việc họ sử dụng một số công cụ DevOps ngày nay.
Mặt khác, có nhiều công ty nhỏ phát triển phần mềm bằng phương pháp, triết lý, thực tiễn và công cụ DevOps. Và họ tin rằng chi phí triển khai DevOps chính là chi phí cho phép họ cạnh tranh hiệu quả trên thị trường phần mềm. Ví dụ về các công ty như vậy có thể được nhìn thấy .
Tiêu chí chính để hiểu liệu DevOps có cần thiết hay không: sản phẩm CNTT của bạn mang lại giá trị gì cho công ty và khách hàng.
Nếu sản phẩm chính tạo ra lợi nhuận của công ty là phần mềm thì bạn cần DevOps. Và nó không quá quan trọng nếu bạn kiếm được tiền thật bằng cách sử dụng các sản phẩm khác. Điều này cũng bao gồm các cửa hàng trực tuyến hoặc ứng dụng di động có trò chơi.
Bất kỳ trò chơi nào tồn tại đều nhờ vào nguồn tài trợ: trực tiếp hoặc gián tiếp từ người chơi. Tại Playgendary, chúng tôi phát triển trò chơi di động miễn phí với hơn 200 người trực tiếp tham gia vào quá trình sáng tạo trò chơi. Chúng ta sử dụng DevOps như thế nào?
Vâng, chính xác giống như mô tả ở trên. Tôi liên tục liên lạc với các nhà phát triển và người thử nghiệm, đồng thời tiến hành đào tạo nội bộ cho nhân viên về phương pháp và công cụ DevOps.
Hiện tại, chúng tôi đang tích cực sử dụng Jenkins làm công cụ quy trình CI/CD để thực thi tất cả các quy trình lắp ráp với Unity và triển khai sau đó lên App Store và Play Market. Thông tin thêm từ bộ công cụ cổ điển:
- Asana - để quản lý dự án. Tích hợp với Jenkins đã được cấu hình.
- Google Meet - dành cho cuộc họp video.
- Slack - để liên lạc và cảnh báo khác nhau, bao gồm cả thông báo từ Jenkins.
- Atlassian Confluence - dành cho tài liệu và làm việc nhóm.
Các kế hoạch trước mắt của chúng tôi bao gồm giới thiệu phân tích mã tĩnh bằng SonarQube và tiến hành kiểm tra giao diện người dùng tự động bằng Selenium ở giai đoạn Tích hợp liên tục.
Thay vì một kết luận
Tôi muốn kết thúc bằng suy nghĩ sau: để trở thành một kỹ sư DevOps có trình độ cao, điều quan trọng là phải học cách giao tiếp trực tiếp với mọi người.
Kỹ sư DevOps là người có tinh thần đồng đội. Và không có gì khác. Sự chủ động trong giao tiếp với đồng nghiệp phải đến từ anh ấy chứ không phải do ảnh hưởng của một số trường hợp. Chuyên gia DevOps phải xem và đề xuất giải pháp tốt nhất cho nhóm.
Và đúng vậy, việc thực hiện bất kỳ giải pháp nào cũng sẽ cần nhiều cuộc thảo luận và cuối cùng nó có thể thay đổi hoàn toàn. Phát triển độc lập, đề xuất và thực hiện ý tưởng của mình, một người như vậy có giá trị ngày càng tăng đối với cả nhóm và nhà tuyển dụng. Cuối cùng, điều này được phản ánh qua số tiền thù lao hàng tháng của anh ấy hoặc dưới hình thức tiền thưởng bổ sung.
Nguồn: www.habr.com