Các cách để tối ưu hóa quy trình tuyển dụng DevOps thông qua mô hình CALMS?

Phần lớn việc tuyển dụng DevOps xảy ra theo các dòng đối sánh từ khóa, theo ý kiến ​​của tôi chỉ tập trung vào công nghệ.

Giờ đây, DevOps không chỉ đơn thuần là công nghệ và DevOps Engineering không chỉ là một quản trị viên hệ thống tốt hơn với một số kỹ năng mã hóa.

Vai trò / hồ sơ cấp cao của DevOps đối với tôi cũng mang đến thâm niên trong nhiều nền tảng và thực tiễn khác ngoài các kỹ năng cơ sở hạ tầng và kỹ thuật phần mềm như Lean, Đo lường và cởi mở và giao tiếp (ai hỏi DevOps thuê kỹ năng giao tiếp của họ, thật lòng?!)

Vì vậy, một cách quảng cáo / phỏng vấn việc làm có thể hiệu quả hơn theo một cách nào đó - ví dụ, bằng cách áp dụng các câu hỏi về danh mục CALMS ? - Dẫn đến các câu hỏi như "bây giờ, làm thế nào để bạn áp dụng các nguyên tắc tinh gọn? Làm thế nào các khía cạnh văn hóa được giải quyết trong các dự án DevOps gần đây của bạn?"

Công phu hơn nữa:

• C ulture (ví dụ như các chiến lược quản lý xung đột và thái độ đối với những thất bại, sở hữu và những người khác)
• Một giả thuyết (ở đây bạn hỏi về các kỹ năng Puppet / Docker, v.v.)
• L ean (nền tảng của Lean? Các loại chất thải?)
• M mua sắm (yêu cầu các công cụ như JMeter nhưng cũng đi đến những thứ như lấy mẫu, mô hình hóa dữ liệu ..)
• S haring (rõ ràng là quản lý kiến ​​thức và theo các công cụ)

CẬP NHẬT - vậy tại sao nhà tuyển dụng / nhà tuyển dụng sẽ cấu trúc cuộc phỏng vấn bằng CALMS như dưới đây (ngoài ra, phần "tự động hóa" có thể được xây dựng dọc theo mô hình chuỗi công cụ DevOps ( liên kết tài liệu, chỉ đọc )?

Lưu ý bên lề - vì vậy, văn hóa chẳng hạn thực sự không chỉ là một kỹ năng mềm nữa, đối với DevOps, đây là một trong những kỹ năng cốt lõi - giống như tất cả các kỹ năng khác trong miền này.

Đây là một ý tưởng tuyệt vời, cũng bởi vì Daniel Kahneman đã chỉ ra rằng nếu bạn chia một điểm số thành 5 điểm cân nặng và thêm các tiêu chí và giới hạn số cho những điều đó, bạn sẽ giảm đáng kể sai lệch . Bạn có thể thiết kế không chỉ điểm tiếp tục, mà toàn bộ quá trình tuyển dụng, với màn hình điện thoại, phỏng vấn tại chỗ, mọi thứ theo cách này. Nó sẽ làm giảm đáng kể sự thiên vị vốn có của người phỏng vấn. Chúng tôi đã thực sự bắt đầu làm một cái gì đó tương tự cho tất cả các tuyển dụng.

Rõ ràng, bên trong mỗi khu vực, bạn nên tăng thêm trọng lượng cho những gì quan trọng đối với vị trí của công ty, nhưng bạn đang thuê một kỹ sư toàn diện và bạn muốn ai đó sẽ đề xuất những thay đổi lớn đối với cách tổ chức của bạn hoạt động, bạn không chỉ đơn giản là tuyển dụng ai đó cho các kỹ năng cụ thể để làm việc trong một khu vực hạn chế. Nhiều người chỉ đơn giản xem vai trò này là một Kỹ sư Phát hành và Xây dựng được trả lương cao hơn và nếu đó là trường hợp, đó là những gì bạn nên thuê và quảng cáo.

Đối với việc thuê DevOps, tôi sẽ đề nghị thay thế Lean bằng Học tập. Nó ban đầu là Expedia và mặc dù một số người mở rộng nó thành CALMS để bao gồm Lean, điều đó có phần hạn chế vì DevOps dựa trên rất nhiều thứ chứ không chỉ là Lean. Đó cũng là ý tưởng của Deming về Biến đổi nguyên nhân đặc biệt và phổ biến và tư duy hệ thống, Cân bằng của Nash (nếu mỗi người tự tối ưu hóa, kết quả có thể là tối ưu, so với khi mọi người bao gồm lợi ích của nhóm), Kiểm soát quá trình thống kê của Shewhart , Goldratt Lý thuyết về hạn chế , của Taleb Anti-mỏng manh và rất nhiều nhiều hơn nữa.

Điều này cũng sẽ cho phép bạn bao gồm việc tham gia vào các hội nghị trong Học tập và thuyết trình tại các hội nghị hoặc cuộc họp dưới dạng Chia sẻ. Ở vị trí mà bạn không phải lúc nào cũng là thành viên của nhóm hoặc công ty của bạn có thể không đủ lớn để có đồng nghiệp làm đồng nghiệp, việc thiết lập và duy trì các mối quan hệ tại nơi làm việc và cơ hội học tập thậm chí còn quan trọng hơn nhiều. Chúng tôi thường nhóm hai người dưới Văn hóa.

Cá nhân tôi sẽ đặt dưới Văn hóa các kỹ năng mềm cần có để có hiệu quả trong việc cải thiện các quy trình tại tổ chức của bạn. CMMI , Kanban , Giới hạn tiến độ , Thực hành Agile, v.v.

JIRA có vẻ giống như công cụ Sharing hơn và Git có liên quan chặt chẽ hơn với Tự động hóa.

BIÊN TẬP

Tôi tin rằng điều này phụ thuộc từ tổ chức này đến tổ chức khác và những gì một DevOps / Senior DevOps dự kiến ​​sẽ làm, do đó, câu đầu tiên của bạn là chính xác 100%. Bởi vì, một DevOps có thể sử dụng một bộ công cụ mà công ty sử dụng và cũng cải thiện hoặc mang lại bộ công cụ mới cho phép công ty và nhà phát triển của họ làm việc nhanh hơn và ít lãng phí hơn.

Theo tôi, một DevOps nên có các kỹ năng SysAdmin mạnh mẽ và các kỹ năng mã hóa rõ ràng như Puppet, Chef, Python, Bash sẽ được sử dụng rộng rãi cũng như một số kiến ​​thức về mã trên máy chủ ít nhất để có thể sửa lỗi nhỏ tại sao ứng dụng không hoạt động như mong đợi từ môi trường này sang môi trường khác.

Bây giờ, với tư cách là DevOps cao cấp, CALM có thể được áp dụng, tuy nhiên, các nguyên tắc Lean và Đo lường có thể / có thể không áp dụng. Ví dụ: chúng tôi đang phát triển các ứng dụng bằng Chef / Puppet / Ansible để tự động hóa những thứ trần tục và giữ mọi thứ đồng bộ, điều này rõ ràng giúp tiết kiệm thời gian và ít lãng phí hơn .

Về đo lường, tôi không chắc chắn nếu điều đó được áp dụng trong hầu hết các trường hợp. Tuy nhiên, các nguyên tắc CALM khác là một phần của vị trí DevOps.

Có kỹ năng giao tiếp tốt cũng quan trọng như một DevOps, nhưng quan trọng hơn là DevOps cao cấp bởi vì bạn sẽ không chỉ phải đối phó với nhóm của mình và chia sẻ kiến ​​thức và với các nhà phát triển khi bạn ở đó để hỗ trợ họ, mà bạn còn có thể phải tạo báo cáo và giữ bài thuyết trình trước ban quản lý.

Tôi thích bảng tính mà bạn đã thêm và rất tốt để có một hệ thống điểm, tuy nhiên, một số công ty cũng đang thêm nhiều kỹ năng / công nghệ trong quảng cáo việc làm hơn yêu cầu.

Ngoài ra, sau một cuộc phỏng vấn qua điện thoại (nếu có) tôi thấy thật hữu ích khi trong một cuộc phỏng vấn, bạn sẽ gặp một số vấn đề cần giải quyết hoặc ít nhất là thể hiện quá trình gỡ lỗi của bạn và cách bạn sẽ cư xử trong các tình huống cụ thể. Cá nhân, tôi không thích các bài kiểm tra viết vì tôi tin rằng có nhiều cách để giải quyết vấn đề, và đôi khi, Google là bạn của bạn, vì bạn không mong muốn biết mọi thứ bằng trái tim.

Là một DevOps / DevOps cao cấp, tôi tin rằng có một ranh giới giữa các ứng dụng được sử dụng và kiến ​​thức. Bạn có thể tuyệt vời khi sử dụng các công cụ mới / cũ này hoặc viết mã, nhưng khi cần gỡ lỗi hoặc chỉ hiểu vấn đề với máy chủ, công việc của Jenkins có thể là bạn không thể làm như vậy.

Cuối cùng, bảng tính được trình bày tôi nghĩ là một cách đánh giá kiến ​​thức DevOps cho vị trí cấp cao mà tôi có thể thêm vào đó một số kỹ năng Quản lý và Cá nhân để hoàn thành.

Và khi nói đến quá trình lựa chọn, bạn có thể xem bảng tính và chọn người có số điểm mà bạn tin là phù hợp với tổ chức của mình cũng như ghi nhớ hành vi (er) của anh ấy trong suốt cuộc phỏng vấn và cách (s) ông trình bày / trả lời những câu hỏi.