Một công ty CNTT cần làm gì để thành công trong năm 2019? Giảng viên tại các hội nghị, buổi gặp mặt nói rất nhiều lời to tiếng mà không phải lúc nào người bình thường cũng hiểu được. Cuộc đấu tranh về thời gian triển khai, vi dịch vụ, từ bỏ nguyên khối, chuyển đổi DevOps và nhiều hơn thế nữa. Nếu chúng ta loại bỏ vẻ đẹp của lời nói và nói trực tiếp bằng tiếng Nga, thì tất cả đều quy về một luận điểm đơn giản: tạo ra một sản phẩm chất lượng cao và làm điều đó một cách thoải mái cho cả nhóm.
Cái sau đã trở nên cực kỳ quan trọng. Doanh nghiệp cuối cùng đã đi đến kết luận rằng một quy trình phát triển thoải mái sẽ tăng năng suất và nếu mọi thứ được sửa lỗi và hoạt động như một chiếc đồng hồ, thì nó cũng có chỗ để điều động trong các tình huống quan trọng. Ngày xửa ngày xưa, vì mục đích của thao tác này, một người thông minh nào đó đã nghĩ ra các bản sao lưu, nhưng ngành này đang phát triển và chúng tôi đã tìm đến các kỹ sư DevOps - những người biến quá trình tương tác giữa quá trình phát triển và cơ sở hạ tầng bên ngoài thành một thứ gì đó phù hợp và hiệu quả. không liên quan đến đạo Shaman.
Toàn bộ câu chuyện “mô-đun” này thật tuyệt vời, nhưng… Điều đó đã xảy ra khi một số quản trị viên đột ngột được mệnh danh là DevOps, và bản thân các kỹ sư DevOps bắt đầu được yêu cầu phải có ít nhất các kỹ năng về thần giao cách cảm và khả năng thấu thị.
Trước khi nói về các vấn đề hiện đại trong việc cung cấp cơ sở hạ tầng, chúng ta hãy xác định ý nghĩa của thuật ngữ này. Hiện tại, tình hình đã phát triển đến mức chúng ta đạt đến tính hai mặt của khái niệm này: cơ sở hạ tầng có thể ở bên ngoài có điều kiện và bên trong có điều kiện.
Khi nói đến cơ sở hạ tầng bên ngoài, chúng tôi muốn nói đến mọi thứ đảm bảo chức năng của dịch vụ hoặc sản phẩm mà nhóm đang phát triển. Đây là các máy chủ ứng dụng hoặc trang web, dịch vụ lưu trữ và các dịch vụ khác đảm bảo chức năng của sản phẩm.
Cơ sở hạ tầng nội bộ bao gồm các dịch vụ và thiết bị được sử dụng bởi chính nhóm phát triển và các nhân viên khác, thường có rất nhiều người. Đây là các máy chủ nội bộ của hệ thống lưu trữ mã, trình quản lý tác vụ được triển khai cục bộ và mọi thứ, mọi thứ, mọi thứ tồn tại trong mạng nội bộ của công ty.
Quản trị viên hệ thống làm gì trong công ty? Ngoài công việc quản trị mạng nội bộ của chính công ty này, nó còn thường xuyên phải gánh chịu gánh nặng về kinh tế để đảm bảo khả năng hoạt động của các thiết bị văn phòng. Quản trị viên cũng chính là người sẽ nhanh chóng kéo một thiết bị hệ thống mới hoặc một máy tính xách tay dự phòng sẵn sàng để sử dụng từ phòng tiện ích, đưa ra một bàn phím mới và bò bằng bốn chân qua các văn phòng, kéo căng cáp Ethernet. Quản trị viên là chủ sở hữu cục bộ và là người quản lý không chỉ các máy chủ bên trong và bên ngoài mà còn là người điều hành doanh nghiệp. Có, một số quản trị viên chỉ có thể làm việc trong mặt phẳng hệ thống mà không cần phần cứng. Họ nên được tách thành một lớp con riêng biệt là “quản trị viên hệ thống cơ sở hạ tầng”. Và một số chuyên bảo trì thiết bị văn phòng độc quyền, may mắn thay, nếu công ty có hơn một trăm người thì công việc không bao giờ kết thúc. Nhưng cả hai đều không phải là tín đồ.
DevOps là ai? Devops là những người nói về sự tương tác của việc phát triển phần mềm với cơ sở hạ tầng bên ngoài. Chính xác hơn, các nhà phát triển hiện đại tham gia vào quá trình phát triển và triển khai sâu hơn nhiều so với những quản trị viên chỉ tải bản cập nhật lên ftp từng tham gia. Một trong những nhiệm vụ chính của kỹ sư DevOps hiện nay là đảm bảo quy trình tương tác có cấu trúc thoải mái và hiệu quả giữa các nhóm phát triển và cơ sở hạ tầng sản phẩm. Chính những người này chịu trách nhiệm triển khai các hệ thống khôi phục và triển khai; chính những người này sẽ giảm bớt gánh nặng cho các nhà phát triển và tập trung nhiều nhất có thể vào nhiệm vụ cực kỳ quan trọng của họ. Đồng thời, các nhà phát triển sẽ không bao giờ chạy cáp mới hoặc cấp máy tính xách tay mới từ phòng sau (c) KO
Bắt được là gì?
Đối với câu hỏi “DevOps là ai?” một nửa số công nhân tại hiện trường bắt đầu trả lời những câu như “Chà, tóm lại, đây là quản trị viên …” và hơn thế nữa trong văn bản. Đúng vậy, ngày xưa, khi nghề kỹ sư DevOps mới nổi lên từ những quản trị viên tài năng nhất về mặt bảo trì dịch vụ, không phải ai cũng thấy rõ sự khác biệt giữa họ. Nhưng giờ đây, khi chức năng của devops và admin trong nhóm đã trở nên hoàn toàn khác nhau, việc nhầm lẫn họ với nhau, thậm chí đánh đồng họ là điều không thể chấp nhận được.
Nhưng điều này có ý nghĩa gì đối với doanh nghiệp?
Thuê, đó là tất cả về nó.
Bạn mở một vị trí tuyển dụng cho “Quản trị viên hệ thống” và các yêu cầu được liệt kê là “tương tác với bộ phận phát triển và khách hàng”, “hệ thống phân phối CI/CD”, “bảo trì máy chủ và thiết bị của công ty”, “quản trị hệ thống nội bộ”, v.v. TRÊN; bạn hiểu rằng nhà tuyển dụng đang nói những điều vô nghĩa. Điều đáng chú ý là thay vì “Quản trị viên hệ thống”, chức danh vị trí tuyển dụng phải là “Kỹ sư DevOps” và nếu chức danh này được thay đổi thì mọi thứ sẽ đâu vào đấy.
Tuy nhiên, người ta sẽ có ấn tượng gì khi đọc một vị trí tuyển dụng như vậy? Rằng công ty đang tìm kiếm một nhà điều hành nhiều máy, người sẽ triển khai cả hệ thống giám sát và kiểm soát phiên bản, đồng thời sẽ dùng răng siết chặt dây xoắn...
Nhưng để không làm tăng mức độ nghiện ma túy trên thị trường lao động, việc gọi các vị trí tuyển dụng bằng tên riêng là đủ và hiểu rõ ràng rằng kỹ sư DevOps và quản trị viên hệ thống là hai thực thể khác nhau. Nhưng mong muốn không thể kìm nén của một số nhà tuyển dụng là đưa ra danh sách yêu cầu rộng nhất có thể cho ứng viên đã dẫn đến thực tế là các quản trị viên hệ thống “cổ điển” không còn hiểu những gì đang xảy ra xung quanh họ. Cái gì, nghề nghiệp đang biến đổi và họ đi sau thời đại?
Không không và một lần nữa không. Những quản trị viên cơ sở hạ tầng sẽ quản lý máy chủ nội bộ của công ty hoặc đảm nhận các vị trí hỗ trợ L2/L3 và giúp đỡ các nhân viên khác, vẫn chưa ra đi và sẽ không rời đi.
Những chuyên gia này có thể trở thành kỹ sư DevOps không? Tất nhiên là họ có thể. Trên thực tế, đây là một môi trường liên quan đòi hỏi kỹ năng quản trị hệ thống, nhưng ngoài ra, còn phải làm việc với hệ thống giám sát, phân phối và nói chung là thêm sự tương tác chặt chẽ với nhóm phát triển và thử nghiệm.
Một vấn đề DevOps khác
Trên thực tế, mọi thứ không chỉ giới hạn ở việc tuyển dụng và sự nhầm lẫn liên tục giữa quản trị viên và nhà phát triển. Tại một số thời điểm, doanh nghiệp phải đối mặt với vấn đề cung cấp các bản cập nhật và sự tương tác của nhóm phát triển với cơ sở hạ tầng cuối cùng.
Có lẽ đó là khi một người chú với đôi mắt lấp lánh đứng lên sân khấu của một hội nghị nào đó và nói: “Chúng tôi làm việc này và gọi nó là DevOps. Những người này sẽ giải quyết mọi vấn đề của bạn” - và bắt đầu cho biết cuộc sống ở công ty tốt đẹp như thế nào sau khi triển khai các hoạt động DevOps.
Tuy nhiên, việc thuê một kỹ sư DevOps để khiến mọi thứ hoạt động như bình thường là chưa đủ. Công ty phải trải qua quá trình chuyển đổi DevOps hoàn chỉnh, nghĩa là vai trò và khả năng của DevOps của chúng tôi cũng phải được hiểu rõ ràng từ phía nhóm thử nghiệm và phát triển sản phẩm. Chúng tôi có một câu chuyện “tuyệt vời” về chủ đề này minh họa đầy đủ tất cả sự tàn bạo đang xảy ra ở một số nơi.
Tình huống. DevOps được yêu cầu triển khai hệ thống khôi phục phiên bản mà không thực sự đi sâu vào cách thức hoạt động của nó. Giả sử rằng trong hệ thống Người dùng có các trường riêng biệt cho tên, họ và mật khẩu. Một phiên bản mới của sản phẩm ra đời, nhưng đối với các nhà phát triển, việc “rollback” chỉ là cây đũa thần sẽ sửa chữa mọi thứ và họ thậm chí còn không biết nó hoạt động như thế nào. Vì vậy, ví dụ, trong bản vá tiếp theo, các nhà phát triển đã kết hợp trường họ và tên, đưa nó vào sản xuất, nhưng phiên bản chậm vì lý do nào đó. Chuyện gì đang xảy ra vậy? Ban quản lý đến gặp người phát triển và nói “Kéo công tắc!”, tức là yêu cầu anh ta quay lại phiên bản trước. Devop làm gì? Nó quay trở lại phiên bản trước, nhưng vì các nhà phát triển không muốn tìm hiểu cách thực hiện việc khôi phục này nên không ai nói với nhóm phát triển rằng cơ sở dữ liệu cũng cần được khôi phục. Kết quả là mọi thứ đối với chúng tôi đều gặp sự cố và thay vì trang web chạy chậm, người dùng lại thấy lỗi “500” do phiên bản cũ không hoạt động với các trường của cơ sở dữ liệu mới. Devops không biết về điều này. Các nhà phát triển im lặng. Ban quản lý bắt đầu mất hết thần kinh và tiền bạc và nhớ đến các bản sao lưu, đề nghị rút lui khỏi chúng để “ít nhất một cái gì đó sẽ hoạt động”. Kết quả là người dùng sẽ mất tất cả dữ liệu của họ trong một khoảng thời gian.
Tất nhiên, những điều khó khăn sẽ thuộc về các nhà phát triển, những người “không tạo ra một hệ thống khôi phục thích hợp” và không ai quan tâm rằng con nai sừng tấm trong câu chuyện này là nhà phát triển.
Kết luận rất đơn giản: nếu không có cách tiếp cận thông thường đối với DevOps thì nó sẽ ít có tác dụng.
Điều chính cần nhớ: kỹ sư DevOps không phải là một nhà ảo thuật và nếu không có khả năng giao tiếp chất lượng và tương tác hai chiều với quá trình phát triển, anh ta sẽ không thể hoàn thành nhiệm vụ của mình. Các nhà phát triển không thể bị bỏ mặc với “các vấn đề” của họ hoặc được ra lệnh “không can thiệp vào các nhà phát triển, công việc của họ là viết mã” và sau đó hy vọng rằng vào thời điểm quan trọng, mọi thứ sẽ hoạt động như bình thường. Đó không phải là cách nó hoạt động.
Về cơ bản, DevOps là năng lực nằm ở ranh giới giữa quản lý và công nghệ. Hơn nữa, rõ ràng là cần có nhiều công nghệ hơn là quản lý trong loại cocktail này. Nếu bạn thực sự muốn xây dựng các quy trình phát triển nhanh hơn và hiệu quả hơn, bạn phải tin tưởng vào nhóm phát triển của mình. Anh ấy biết những công cụ phù hợp, anh ấy đã thực hiện các dự án tương tự, anh ấy biết cách thực hiện nó. Hãy giúp anh ấy, lắng nghe lời khuyên của anh ấy, đừng cố gắng cô lập anh ấy thành một đơn vị tự trị nào đó. Nếu quản trị viên có thể tự mình làm việc thì devops sẽ vô dụng trong trường hợp này, họ sẽ không thể giúp bạn trở nên tốt hơn nếu bản thân bạn không muốn nhận sự giúp đỡ này.
Và một điều cuối cùng: ngừng xúc phạm các quản trị viên cơ sở hạ tầng. Họ có công việc riêng, cực kỳ quan trọng của họ. Có, quản trị viên có thể trở thành kỹ sư DevOps, nhưng điều này phải xảy ra theo yêu cầu của chính người đó và không chịu áp lực. Và không có gì sai khi quản trị viên hệ thống muốn tiếp tục là quản trị viên hệ thống - đây là nghề riêng và quyền của anh ta. Nếu bạn muốn trải qua một quá trình chuyển đổi nghề nghiệp, thì bạn không bao giờ được quên rằng bạn sẽ phải xây dựng không chỉ các kỹ năng công nghệ mà còn cả kỹ năng quản lý. Rất có thể, với tư cách là người lãnh đạo, bạn sẽ phải tập hợp tất cả những người này lại với nhau và dạy họ giao tiếp bằng cùng một ngôn ngữ.
Nguồn: www.habr.com