Formas de otimização do processo de contratação do DevOps através do paradigma CALMS?

Grande parte do recrutamento de DevOps segue as linhas de correspondência de palavras-chave, o que leva, na minha opinião, ao foco exclusivo da tecnologia.

Agora, o DevOps é muito mais do que apenas tecnologia, e o DevOps Engineer não é apenas um administrador de sistema melhor com algumas habilidades de codificação.

A função / perfil do DevOps sênior significa para mim também oferecer senioridade em muitas outras fundações e práticas além das habilidades de infraestrutura e engenharia de software, como Lean, Measurement e ser aberto e comunicativo (quem pede honestamente que o DevOps contrate suas habilidades de comunicação?)

Portanto, um anúncio de emprego / entrevista pode ser mais eficiente de alguma forma - por exemplo, aplicando categorias CALMS questionadas também? - Levando a perguntas como "agora, como você aplica os princípios lean? Como os aspectos culturais foram abordados nos seus recentes projetos DevOps?"

Elaboração adicional:

• C ultura (por exemplo, estratégias para a gestão de conflitos e atitude a falhas, própria ea dos outros)
• Uma utomação (aqui você pergunta sobre as habilidades do Puppet / Docker etc.)
• L ean (fundações do Lean? Resíduos tipos?)
• M EDIÇÃO (pedir ferramentas como o JMeter mas vão também para coisas como amostragem, modelagem de dados ..)
• S haring (obviamente gestão do conhecimento e ferramentas de acordo)

UPDATE - então, por que os empregadores / recrutadores não estruturam a entrevista pelo CALMS como mostrado abaixo (além disso, a seção "automação" pode ser formulada ao longo do modelo de cadeia de ferramentas do DevOps ( link do documento, somente leitura )?

Nota lateral - então a cultura, por exemplo, não é mais apenas uma habilidade leve, para o DevOps é uma das habilidades principais - como todas as outras neste domínio.

Essa é uma ideia brilhante, também por causa de Daniel Kahneman, que mostrou que se você dividir uma única pontuação em 5 pontuações ponderadas e adicionar critérios e limites numéricos a elas, reduzirá significativamente o viés . Você pode projetar não apenas a pontuação do currículo, mas todo o processo de contratação, com telas de telefone, entrevistas no local, tudo dessa maneira. Reduziria significativamente o viés inerente aos entrevistadores. Na verdade, começamos a fazer algo semelhante para todas as contratações.

Obviamente, dentro de cada área, você deve adicionar peso ao que é importante para a empresa para a posição, mas você está contratando um engenheiro completo e deseja alguém que proponha grandes mudanças na forma como sua organização opera, e não está simplesmente contratando alguém com habilidades específicas para trabalhar em uma área limitada. Muitas pessoas simplesmente vêem esse papel como um engenheiro de versão e construção mais bem pago e, se for esse o caso, é para isso que você deve contratar e anunciar.

Para uma contratação de DevOps, sugiro substituir o Lean pelo Learning. Ele é originalmente o CAMS e, embora alguns o estendam ao CALMS para incluir o Lean, isso é um pouco restritivo, já que o DevOps se baseia em muito mais do que apenas o Lean. São também as idéias de Deming sobre Variação de Causa Especial e Comum e Pensamento do Sistema, o Equilíbrio de Nash (se cada um se otimizar, o resultado pode ser abaixo do ideal, comparado a quando todos incluem o interesse do grupo), Controle Estatístico de Processo de Shewhart, Controle de Processo Estatístico de Shewhart , Teoria das restrições , anti-fragilidade de Taleb e muito mais.

Isso também permitiria incluir a participação em conferências em Aprendizado e apresentações em conferências ou encontros como Compartilhamento. Em uma posição em que você nem sempre faz parte de uma equipe ou sua empresa pode não ser grande o suficiente para ter seus colegas como colegas de trabalho, é ainda mais importante estabelecer e manter relacionamentos fora do local de trabalho e oportunidades de aprendizado. Geralmente, agrupamos os dois em Cultura.

Pessoalmente, colocaria sob a cultura as habilidades necessárias para ser eficaz na melhoria dos processos em sua organização. CMMI , Kanban , limites de trabalho em andamento , práticas ágeis etc.

O JIRA parece mais com a ferramenta Sharing e o Git está mais relacionado à automação.

EDITAR

Acredito que isso depende de organização para organização e o que é esperado que um DevOps / Senior DevOps faça, portanto, sua primeira frase é 100% precisa. Porque, um DevOps deve poder usar um conjunto de ferramentas que a empresa usa e também melhorar ou trazer um novo conjunto de ferramentas que permite à empresa e seus desenvolvedores trabalharem mais rápido e desperdiçarem menos.

Na minha opinião, um DevOps deve ter fortes habilidades de SysAdmin e, obviamente, habilidades de codificação, como Puppet, Chef, Python, Bash, serão amplamente utilizadas, além de algum conhecimento do código que entra nos servidores, pelo menos para poder fazer uma depuração menor do motivo. o aplicativo não se comporta conforme o esperado de um ambiente para o outro.

Agora, como DevOps sênior, o CALM pode ser aplicado, no entanto, os princípios Lean e Measurement podem / podem não se aplicar. Por exemplo, estamos desenvolvendo aplicativos usando Chef / Puppet / Ansible para automatizar as coisas mundanas e manter tudo sincronizado, o que obviamente economiza tempo e produz menos desperdício .

Em relação à medição, não tenho certeza se isso é aplicável na maioria dos casos. No entanto, os outros princípios do CALM fazem parte de uma posição do DevOps.

Ter boas habilidades de comunicação também é importante como DevOps, mas mais importante como DevOps Sênior, porque você terá que não apenas lidar com sua equipe e compartilhar conhecimento e com os desenvolvedores como você está lá para apoiá-los, mas também poderá crie relatórios e mantenha apresentações na frente do gerenciamento.

Gosto da planilha que você adicionou e é bom ter um sistema de pontos; no entanto, algumas empresas também estão adicionando mais habilidades / tecnologias em um anúncio de emprego do que o necessário.

Além disso, após uma entrevista por telefone (se houver), seria útil que em uma entrevista você tivesse alguns problemas para resolver ou, pelo menos, mostrar seu processo de depuração e como se comportaria em determinadas situações. Pessoalmente, não gosto de provas escritas, pois acredito que existem 'maneiras' de resolver um problema e, às vezes, o Google é seu amigo, pois não se espera que você saiba tudo de cor.

Como DevOps / DevOps sênior, acredito que haja uma linha entre os aplicativos usados ​​e o conhecimento. Você pode ser incrível ao usar essas ferramentas novas / antigas ou escrever código, mas quando se trata de depuração ou apenas para entender qual é o problema de um servidor, o trabalho de Jenkins pode ser que você não consiga fazê-lo.

Por fim, acho que a planilha apresentada é uma maneira de avaliar o conhecimento do DevOps também para uma posição sênior. Posso acrescentar algumas habilidades interpessoais e de gerenciamento para completá-lo.

E quando se trata do processo de seleção, você pode dar uma olhada na planilha e escolher a pessoa com uma pontuação que você acredita ser a certa para a sua organização, além de ter em mente o comportamento dele durante a entrevista e o caminho (s) ele apresentou / respondeu a essas perguntas.