Tại sao tôi không nên thử thuê một 'Kỹ sư DevOps'?

Ý tưởng về việc có một Kỹ sư DevOps gần đây đã trở nên khá phổ biến và có vẻ hấp dẫn khi chỉ cần một người có thể tham gia và cung cấp nhiều lợi ích của DevOps, như được mô tả trong blog Puppet :

Các tổ chức sử dụng thực tiễn DevOps có chức năng cực kỳ cao: Họ triển khai mã thường xuyên hơn 30 lần so với đối thủ cạnh tranh và giảm 50% trong số các triển khai của họ thất bại, theo báo cáo năm 2015 của DevOps.

Tuy nhiên, tôi đã nhận thấy rất nhiều ý kiến ​​phản đối ý tưởng về Kỹ sư DevOps để thử và thực hiện những cải tiến này:

Ngay cả khi có thỏa thuận rộng rãi về các thuộc tính DevOps cốt lõi, tranh cãi xoay quanh thuật ngữ kỹ sư DevOps. Một số người cho rằng chính thuật ngữ này mâu thuẫn với các giá trị DevOps. Jez Humble, đồng tác giả của Giao hàng liên tục, chỉ ra rằng chỉ cần gọi ai đó là kỹ sư DevOps có thể tạo ra một silo thứ ba ngoài dev và ops - "... rõ ràng là một cách kém (và mỉa mai) để thử và giải quyết những vấn đề này . "

Tại sao một doanh nghiệp không nên thuê một Kỹ sư DevOps để thử và 'triển khai DevOps', trái ngược với sự thay đổi tổ chức được ủng hộ bởi các blog như thế này ? Liệu các lợi ích có bị phủ nhận khi chỉ có vai trò DevOps bị cô lập?

TL; DR : Bạn không bao giờ nên cố gắng thuê Nhóm DevOps

Về cơ bản có ba vai trò phổ biến nhất để thuê:

1. DevOps Architect / Eveachist
2. Kỹ sư DevOps
3. Kỹ sư CI / CD

Các vai trò này khác với 6 vai trò phát triển phần mềm thiết yếu của bạn mà theo truyền thống là tổ chức kỹ thuật phần mềm:

1. Quản lý sản phẩm
2. Phát triển phần mềm
3. Công cụ phát triển
4. Bảo mật và Tuân thủ
5. Chất lượng và kiểm tra
6. Vận hành hệ thống (SRE)

Hãy lần lượt trải qua ba vai trò và xem chúng phù hợp như thế nào

DevOps Architect hoặc Eveachist

• Tại sao : Nếu bạn bị lạc, chậm, hỏng và không biết phải làm gì.
• Khi nào : Khi bắt đầu quá trình trong các giai đoạn lập kế hoạch.
• Điều gì : Vai trò cấp quản lý để hướng dẫn tất cả các nhà quản lý và lãnh đạo trong toàn bộ Công nghệ phần mềm org. Người này sẽ lập kế hoạch chuyển đổi toàn bộ tổ chức kỹ thuật của bạn sang trạng thái hoạt động cao.
• Ai : Thành viên tư vấn thành thạo về lý thuyết, thực hành quản lý, chủ đề văn hóa và hoạt động, người báo cáo trực tiếp cho VP Kỹ thuật phần mềm.

Trong một số trường hợp và đối với các công ty vừa và nhỏ, bạn có thể bắt đầu quá trình thay vì thuê một tổ chức tư vấn, như DORA.

Kỹ sư DevOps

• Tại sao :
  1. Để thu hẹp khoảng cách giữa các đội nếu chúng được tổ chức theo các vai trò chức năng được đề cập ở trên để đảm bảo hợp tác cấp chức năng chéo.
  2. Để kết hợp với các nhóm định hướng sản phẩm, bao gồm 6 vai trò truyền thống trong nhóm, để giúp thu hẹp khoảng cách kiến ​​thức và giúp thực hiện và áp dụng các thực tiễn và công cụ mới.
• Khi nào : Một khi bạn đã vạch ra kế hoạch của mình và việc chuyển đổi tổ chức bắt đầu và toàn bộ đội ngũ quản lý đã ở trên tàu.
• Điều gì : Cho phép hợp tác chức năng chéo, đảm bảo rằng ranh giới nhóm bị phá vỡ, rằng tối ưu hóa cục bộ trong các nhóm sẽ không tạo ra rào cản đối với thông lượng công việc cao trong suốt chuỗi giá trị từ mong muốn của khách hàng đến việc giao hàng của khách hàng.
• Ai : Kỹ sư giàu kinh nghiệm với các kỹ năng cả về phát triển phần mềm và vận hành hệ thống. Anh ta nên có kỹ năng thực hành tốt nhất, thay đổi quy trình và văn hóa liên quan đến chuyển đổi DevOps.

Kỹ sư CI / CD

• Tại sao : Để giúp triển khai các đường ống CI / CD, hãy tích hợp chuỗi công cụ của bạn, mang theo các công cụ sẽ cho phép công ty hoạt động tốt hơn.
• Khi nào : Trong quá trình chuyển đổi trong tổ chức lớn hơn, trong khi các vai trò trên đã được điền.
• Điều gì : Kỹ sư, về cơ bản là một phần của nhóm công cụ sẽ có thể thiết lập các đường ống CI / CD và bắt đầu tích hợp các hệ thống nội bộ theo cách sẽ loại bỏ ma sát khỏi thông lượng công việc.
• Ai : Kỹ sư có kinh nghiệm với Công cụ, quy trình tích hợp, Quản lý phát hành và thực tiễn DevOps. Một người hiểu rằng họ đang thay thế việc giao phối của con người trong quá trình phát hành bằng Tự động hóa.

Tôi muốn tranh luận Kỹ sư Devops như được mô tả trong liên kết câu hỏi của bạn chủ yếu là vai trò sysadmin. Trích dẫn các kỹ năng ở đây để làm nền cho câu trả lời này:

Thiết bị leo núi của bạn.

• Nền tảng vững chắc về trải nghiệm Quản trị Linux / Unix với quản lý cấu hình / tự động hóa bằng cách sử dụng Puppet, Chef hoặc tương đương
• Khả năng sử dụng nhiều công nghệ nguồn mở và dịch vụ đám mây (cần có kinh nghiệm với AWS)
• Trải nghiệm mạnh mẽ với SQL và MySQL (Trải nghiệm NoQuery cũng là một lợi thế, vì chúng tôi cũng sử dụng Redis)
• Hiểu biết sâu sắc về mã và tập lệnh (PHP, Python, Perl và / hoặc Ruby)
• Kiến thức về các hoạt động tốt nhất và hoạt động CNTT trong một dịch vụ luôn luôn cập nhật

Trong mô tả công việc mẫu này, DevOps Engineering chỉ là một từ thông dụng cho một sysadmin thoải mái với cơ sở hạ tầng dựa trên đám mây, tự động hóa, có thể đọc mã để giúp chẩn đoán và nhận thức về các giải pháp và thực tiễn có tính sẵn sàng cao.

Điều này liên quan một cách lỏng lẻo đến thực tiễn DevOps và văn hóa phá vỡ silo giữa dev và op như đã thấy trong câu hỏi này Sự khác biệt giữa Sysadmin và DevOps Engineering là gì?

Nó sẽ không phải là một ý tưởng tốt bởi vì một sysadmin, anh ấy / cô ấy có thể thoải mái như thế nào với thực hành và văn hóa sùng đạo, không phải là người phù hợp để thúc đẩy chuyển đổi công ty. Bạn sẽ không thuê người này với ý định thay đổi văn hóa nhưng với quan điểm cấu hình công cụ, điều này sẽ không thực sự giúp phá vỡ các quy trình. Điều này cũng có thể được đồng nghiệp của anh ấy / cô ấy đón nhận và bạn sẽ chống lại sự thay đổi nếu không có sự thay đổi văn hóa nào được lên kế hoạch trước

Để mô hình thành công hướng tới lợi ích của các tín đồ, câu trả lời của @ Jiri Klouda đưa ra một cái nhìn tổng quan tuyệt vời về vai trò Kỹ sư DevOps có thể chấp nhận cùng với bước thay đổi sẽ mang lại giá trị và giúp hướng tới thành công.

Tôi nhận ra câu trả lời này có thể không phù hợp với bạn, nhưng đây là những gì tôi đã làm

Tôi là nhà phát triển đầu tiên làm việc tại một startup thương mại điện tử rất bận rộn, với lưu lượng truy cập cực kỳ cao. Tôi nhận ra công ty vẫn còn non trẻ, và trong một thời gian, tôi sẽ là nguồn lực kỹ thuật nội bộ duy nhất.

Biết được điều này, tôi quyết định cấu trúc cơ sở hạ tầng của mình theo cách như vậy, rằng tôi sẽ phải thực hiện quản trị hệ thống ZERO.

Tôi quyết định lưu trữ trên đám mây, vì làm như vậy giúp tôi giảm bớt việc bảo trì hệ thống. Tôi tìm kiếm một kỹ sư AWS, với kinh nghiệm bù nhìn. Cùng nhau, chúng tôi đã kiến ​​trúc một cơ sở hạ tầng có thể tự động hóa, được viết dưới dạng mã trong đám mây. Tất cả các tập tin cấu hình đã được phiên bản trong con rối.

Điều này cho phép tôi, với tư cách là một nhà phát triển, đảm nhận vai trò tín đồ này. Tôi xây dựng các công cụ phát hành mã, bằng trăn, vải. Tôi đã sử dụng cùng một kịch bản để khởi động ứng dụng của mình lên các máy chủ mới được tự động hóa.

Điều này hoạt động rất tốt và hôm nay, 3 năm sau, tôi vẫn không thực hiện bất kỳ bảo trì hệ thống nào. Chúng tôi có một quản trị viên hệ thống (cùng một kỹ sư AWS) trong 10 giờ mỗi tháng và tôi cố gắng cấu trúc các lần chạy nước rút của anh ấy theo cách mà tôi không trở thành một phiền toái cho anh ấy. Theo cách đó, tôi tôn trọng thời gian của anh ấy, và quản lý nước rút của anh ấy theo cách tốt nhất tôi có thể.

Nếu một hệ thống có hiệu suất bị suy giảm, tôi chỉ cần chấm dứt nó, và một hệ thống khác sẽ quay vòng ở vị trí của nó.

Tôi hy vọng câu trả lời này bằng cách nào đó có thể có lợi cho bạn

Bạn không nên thuê một kỹ sư DevOps vì DevOps bao gồm rất nhiều ngành học mà một cá nhân không thể là một chuyên gia trong tất cả các khía cạnh của các ngành này. Bằng cách thuê một jack của tất cả các giao dịch, bạn sẽ thuê một bậc thầy không.

DevOps nhất thiết phải là một nỗ lực dựa trên nhóm và bạn không thể mong đợi một cá nhân sẽ hỗ trợ kỳ vọng của cả nhóm. Hãy xem xét phạm vi của DevOps. Một người không thể:

• Trở thành một nhà phát triển rockstar trong [ngôn ngữ]
• Hãy là một chuyên gia mạng, biết tất cả các RFC cần thiết
• Trở thành quản trị viên hệ thống
• Hãy là một chuyên gia kiểm tra QA
• Trở thành quản trị viên cơ sở dữ liệu
• Chuyên lưu trữ và sao lưu
• Biết trang tin cậy Kỹ thuật
• Có khả năng các ngành học khác là tốt

Một số trong những điều trên thậm chí có các nguyên tắc phụ , chẳng hạn như Quản trị viên Hệ thống Windows so với quản trị viên Hệ thống Linux / Unix hoặc có thể bạn sử dụng nhiều ngôn ngữ mã hóa trong.

Không ai có thể là một chuyên gia trong tất cả những điều này có nghĩa là nếu bạn đang quảng cáo cho một kỹ sư DevOps, khi khu vực yếu nhất trong nhóm DevOps của bạn là Mạng, bạn không làm tốt việc quảng cáo về nhu cầu của mình cho một chuyên gia mạng cho nhóm DevOps của bạn . Mặc dù không có cá nhân nào được nuôi chim bồ câu trong một vai trò cụ thể trong nhóm DevOps, nhưng bạn sẽ làm cho nhóm của mình không hài lòng bằng cách giả vờ không có chuyên gia hoặc chuyên gia về vấn đề (SMEs) trong phạm vi của DevOps. Xoay con lắc từ cực này sang cực khác - từ silo đến giả vờ như mọi vai trò trong nhóm DevOps của bạn đều giống nhau - có thể gây ra nhiều vấn đề như vậy.

Mặc dù có các thành viên trong nhóm đào tạo chéo trong nhiều môn học - đặc biệt là trong các khu vực chồng chéo là tốt, hy vọng họ có thể thành thạo một khối lượng kiến ​​thức rộng lớn như vậy đơn giản là không thực hành.

Điều này có nghĩa là bất cứ ai nói với bạn rằng họ biết tất cả các khía cạnh của DevOps có thể đang nói dối bạn. Thuê một chuyên gia trong lĩnh vực mà bạn yếu nhất, người đã từng làm việc trong nhóm DevOps - không phải là "Kỹ sư DevOps".

Tôi đã có thử thách chính xác này khi thực hiện tại ASOS. Mục tiêu của chúng tôi là có các nhóm tự lập và vì vậy có vai trò chuyên dụng có thể là một mô hình chống đối, tuy nhiên chúng tôi sống trong thế giới thực và vì nhiều nhà phát triển nghĩ về các hoạt động DevOps tốt không phải là điều chính yếu của họ nên họ cần trợ giúp đến đó

Những gì chúng tôi đã làm là:

• mất nhiệm kỳ của các kỹ sư DevOps, DevOps là điều tất cả chúng ta nên làm, không phải chức danh công việc của chúng tôi vì vậy chúng tôi gọi họ là một cái gì đó khác nhau.

• đưa họ ra cho các đội nhưng chỉ có 1 trên 3, điều này có nghĩa là họ không thể là người làm mà phải được coi là một năng lực để giúp các đội tự cải thiện và giải quyết vấn đề của riêng họ (có hướng dẫn)

• duy trì chức năng trung tâm cũng như đóng vai trò là trung tâm năng lực và xử lý các cân nhắc của doanh nghiệp, bất cứ điều gì ảnh hưởng đến tất cả các đội

Khi chúng tôi phát triển, chúng tôi xem xét mô hình này nhưng đối với chúng tôi nó hoạt động hiệu quả cho đến nay

Tôi không nghĩ rằng bạn sẽ có thể nhận được một câu trả lời dứt khoát cho điều này bởi vì nó có vẻ như rất nhiều yếu tố.

• Làm thế nào trên tàu công ty là với thực tiễn DevOps
• Những loại ứng dụng hoặc dịch vụ công ty cung cấp
• Cấu trúc của công ty bạn

Tôi vừa hoàn thành phỏng vấn cho các vị trí và kết thúc với một danh hiệu kỹ sư DevOps, nhưng một số điều tôi đang làm là Sys Admin làm việc. Điều đó là không cần thiết vì quy mô của công ty và bản chất của những gì đang được quản lý ứng dụng khôn ngoan. Một số vị trí tôi đã phỏng vấn có một tiêu đề tương tự và họ đang tìm kiếm nhiều hơn từ một người từ khía cạnh phát triển của những điều kinh nghiệm khôn ngoan. Họ mong đợi việc viết mã nhiều hơn và không phải là một quản trị viên hệ thống tự động hóa. SRE dường như là một tiêu đề đang trở nên phổ biến vì vậy đó có thể là con đường để đi. Tôi đã tự mình trở thành Quản trị viên Hệ thống và Kỹ sư tự động hóa là công việc cuối cùng của mình vì tôi đang viết một phần thời gian và đầu bếp. Công ty đã theo mô hình sùng đạo khá tốt, nơi mọi người đều ở trên tàu và các nhà phát triển làm việc cùng với các op nhưng tôi nghĩ rằng tương lai của họ đã không '

Bây giờ tôi đang ở vị trí này, tôi đang cố gắng bấm còi trong một số tự động hóa và chúng tôi có một số người gặp vấn đề chúng tôi sẽ phải giải quyết. Mọi người đến và đi và một số quy trình công việc được thiết kế bởi vì người khác đã thiết kế theo cách đó chứ không phải vì nó phù hợp với cách mọi người làm việc.

Vì vậy, về cơ bản tôi nghĩ bạn nên tìm ra bản mô tả công việc và đừng lo lắng quá nhiều về chức danh trừ khi nó bị ràng buộc phải trả bằng cách nào đó hoặc bạn nghĩ người này hay người kia sẽ thu hút đúng loại người.

Nếu bạn quan tâm đến ý nghĩa của DevOps và đi theo "một con đường thực sự". Bạn không nên thuê một Kỹ sư DevOps. Bạn nên thuê một Kỹ sư tự động hóa, hoặc Kỹ sư triển khai hoặc Kiến trúc sư nền tảng hoặc một số vai trò khác làm những gì bạn cần.

Nếu là một học viên DevOps thực sự không quan trọng đối với bạn, thì bạn có thể gọi nó là bất cứ điều gì bạn muốn.