Por que não devo tentar contratar um 'Engenheiro de DevOps'?

A idéia de ter um engenheiro do DevOps se tornou bastante popular recentemente , e parece atraente ter apenas uma pessoa que possa se encaixar e fornecer muitos dos benefícios do DevOps, conforme descrito no blog Puppet :

As organizações que usam práticas de DevOps têm um funcionamento extremamente alto: elas implantam código até 30 vezes mais frequentemente que seus concorrentes e 50% menos de suas implantações falham, de acordo com o relatório de 2015 do State of DevOps.

No entanto, notei muita oposição vocal à idéia de um engenheiro de DevOps para tentar fazer essas melhorias:

Mesmo com amplo acordo sobre os principais atributos do DevOps, a controvérsia envolve o termo "engenheiro do DevOps". Alguns dizem que o próprio termo contradiz os valores do DevOps. Jez Humble, co-autor de Entrega Contínua, ressalta que apenas chamar alguém de engenheiro de DevOps pode criar um terceiro silo além de dev e ops - "... claramente uma maneira pobre (e irônica) de tentar resolver esses problemas . "

Por que não seria uma ótima idéia para uma empresa contratar um engenheiro do DevOps para tentar 'implementar o DevOps', em oposição à mudança organizacional defendida por blogs como esse ? Os benefícios serão negados por ter apenas uma função isolada do DevOps?

TL; DR : você nunca deve tentar contratar uma equipe do DevOps

Existem essencialmente três funções mais comuns para contratar:

1. Arquiteto / Evangelista do DevOps
2. Engenheiro de DevOps
3. Engenheiro de CI / CD

Essas funções são diferentes das seis funções essenciais de desenvolvimento de software que tradicionalmente compõem a organização de engenharia de software:

1. Gestão de produtos
2. Desenvolvimento de software
3. Desenvolvimento de Ferramentas
4. Segurança e conformidade
5. Qualidade e Teste
6. Operações do sistema (SRE)

Vamos analisar os três papéis, um por um, e ver como eles se encaixam

Arquiteto ou Evangelista do DevOps

• Motivo : se você está perdido, lento, quebrado e não sabe o que fazer.
• Quando : No início do processo, nas etapas de planejamento.
• O que : Função no nível de gerenciamento para orientar todos os gerentes e leads em toda a organização de Engenharia de Software. Essa pessoa planejará toda a transformação da sua organização de engenharia em um estado altamente funcional.
• Quem : Membro da consultoria bem versado em teoria, práticas de gerenciamento, tópicos de cultura e operações que se reporta diretamente ao vice-presidente de engenharia de software.

Em alguns casos, e para empresas pequenas e médias, você pode iniciar o processo com a contratação de uma organização de consultoria, como a DORA.

Engenheiro de DevOps

• Porquê :
  1. Para preencher as lacunas entre as equipes, se elas estiverem organizadas de acordo com as funções funcionais mencionadas acima, para garantir a cooperação entre níveis funcionais.
  2. Incorporar às equipes orientadas ao produto, que têm cada uma das 6 funções tradicionais incluídas na equipe, para ajudar a preencher as lacunas de conhecimento e a implementar e adotar as novas práticas e ferramentas.
• Quando : depois de definir seus planos, a transformação organizacional começa e toda a equipe de gerenciamento está presente.
• O que : habilite a cooperação entre funções, garanta que os limites da equipe sejam quebrados, que as otimizações locais dentro das equipes não estejam criando uma barreira ao alto rendimento do trabalho em toda a cadeia de valor, desde os desejos do cliente até as entregas do cliente.
• Quem : Engenheiro experiente, com habilidades tanto no desenvolvimento de software quanto nas operações do sistema. Ele deve ter habilidades nas melhores práticas, mudanças de processo e cultura relacionadas à transformação do DevOps.

Engenheiro de CI / CD

• Motivo : para ajudar a implementar os pipelines de CI / CD, integre sua cadeia de ferramentas, traga as ferramentas que permitirão um melhor funcionamento da empresa.
• Quando : Durante a transição em uma organização maior, enquanto as funções acima já foram preenchidas.
• O quê : Engenheiro, que é essencialmente parte da equipe de ferramentas que poderá configurar os pipelines de CI / CD e começar a integrar sistemas internos de forma a remover o atrito da taxa de transferência de trabalho.
• Quem : Engenheiro com experiência em ferramentas, processos de integração, práticas de gerenciamento de versões e DevOps. Alguém que entende que está substituindo o bloqueio humano no processo de liberação pela Automation.

Eu diria que o Devops Engineer, conforme descrito no link da sua pergunta, é principalmente uma função de administrador de sistemas. Citando as habilidades aqui como pano de fundo para esta resposta:

Seu equipamento de escalada.

• Sólida experiência em administração de Linux / Unix com gerenciamento de automação / configuração usando Puppet, Chef ou equivalente
• Capacidade de usar uma ampla variedade de tecnologias de código aberto e serviços em nuvem (é necessária experiência com a AWS)
• Forte experiência com SQL e MySQL (a experiência NoSQL também é uma vantagem, pois também usamos Redis)
• Um entendimento prático de código e script (PHP, Python, Perl e / ou Ruby)
• Conhecimento das melhores práticas e operações de TI em um serviço sempre ativo e sempre disponível

Nesta descrição de tarefa de exemplo, o DevOps Engineer é apenas uma palavra da moda para um administrador de sistemas à vontade com a infraestrutura baseada em nuvem, automação, capaz de ler código para ajudar no diagnóstico e ciente das práticas e soluções de alta disponibilidade.

Isso está pouco relacionado às práticas do DevOps e à cultura de quebra de silo entre os desenvolvedores e as operações, conforme visto nesta pergunta Qual é a diferença entre o Sysadmin e o DevOps Engineer?

Não será uma boa idéia, porque um administrador de sistemas, quão confortável ele / ela pode estar com a prática e a cultura dos devops, não é a pessoa certa para conduzir a transformação da empresa. Você não estará contratando essa pessoa com uma mudança de cultura em mente, mas com uma visão de configuração da ferramenta, o que não ajudará realmente a interromper os processos. Isso também pode ser mal recebido por seus colegas e você apenas resistirá à mudança se não houver uma mudança de cultura planejada com antecedência.

Para um padrão de sucesso em relação aos ganhos de devops, a resposta de @ Jiri Klouda oferece uma ótima visão geral sobre uma função aceitável de DevOps Engineer, juntamente com a etapa da mudança em que traria valor e ajuda para o sucesso.

Sei que essa resposta pode não ser uma combinação perfeita para você, mas aqui está o que eu fiz

Fui o primeiro desenvolvedor a trabalhar em uma startup de comércio eletrônico muito ocupada, com tráfego incrivelmente alto. Sei que a empresa ainda era jovem e que, por um tempo, eu seria o único recurso técnico interno.

Sabendo disso, decidi estruturar minha infraestrutura de tal maneira que precisaria administrar os sistemas ZERO.

Decidi hospedar na nuvem, porque isso me aliviou da manutenção dos sistemas. Procurei um engenheiro da AWS, com experiência em marionetes. Juntos, arquitetamos uma infraestrutura autoscalable, escrita como código na formação da nuvem. Todos os arquivos de configuração foram versionados dentro do fantoche.

Isso me permitiu, como desenvolvedor, assumir esse papel de devops. Criei ferramentas de liberação de código, em python, fabric. Usei o mesmo script para inicializar meu aplicativo em novos servidores com dimensionamento automático.

Isso funcionou muito bem e hoje, 3 anos depois, ainda não faço manutenção no sistema. Temos um administrador de sistemas (o mesmo engenheiro da AWS) por 10 horas por mês e tento estruturar seus sprints de forma a não me tornar um incômodo para ele. Dessa forma, respeito o tempo dele e gerencio seus sprints da melhor maneira possível.

Se um sistema tem um desempenho degradado, eu simplesmente o encerro, e outro gira em seu lugar.

Espero que esta resposta possa, de alguma forma, beneficiar você

Você não deve contratar um engenheiro do DevOps, pois o DevOps abrange uma variedade tão grande de disciplinas que um indivíduo não pode ser especialista em todos os aspectos dessas disciplinas. Ao contratar um valete de todos os negócios, você contrataria um mestre de ninguém.

O DevOps é necessariamente um esforço baseado em equipe e você não pode esperar que um indivíduo atenda às expectativas de uma equipe inteira. Considere o escopo do DevOps. Uma pessoa não pode possivelmente:

• Seja um desenvolvedor de rockstar em [language]
• Seja um guru da rede, conhecendo todas as RFCs necessárias
• Seja um administrador de sistemas
• Seja um testador especialista em controle de qualidade
• Seja um administrador de banco de dados
• Especialize-se em armazenamento e backup
• Conheça a Engenharia de Confiabilidade do Site
• Potencialmente outras disciplinas também

Algumas das opções acima ainda têm sub- disciplinas, como Administrador de sistemas Windows vs. Administrador de sistemas Linux / Unix ou talvez você use mais de uma linguagem de codificação no seu.

Nenhuma pessoa pode ser especialista em tudo isso, o que significa que, se você está anunciando para um engenheiro do DevOps, quando a área mais fraca da sua equipe do DevOps é Networking, você não está fazendo um bom trabalho ao anunciar sua necessidade de um especialista em rede para sua equipe de DevOps . Embora nenhum indivíduo deva se dedicar a uma função específica na equipe do DevOps, você faria um desserviço à sua equipe fingindo que não há especialistas ou especialistas no assunto (SMEs) no escopo do DevOps. Mudar o pêndulo de um extremo ao outro - de silenciar a fingir que todas as funções da equipe do DevOps são iguais - pode causar o mesmo problema.

Embora ter membros da equipe treinando em mais de uma disciplina - particularmente nas áreas sobrepostas, é bom, esperar que eles sejam capazes de ser proficientes em um volume tão amplo de conhecimento simplesmente não é prática.

Isso significa que qualquer pessoa que disser que conhece todos os aspectos do DevOps provavelmente está mentindo para você. Contrate um especialista na área em que você é mais fraco e que trabalhou em uma equipe de DevOps - e não um "Engenheiro de DevOps".

Eu tive esse desafio exato ao implementar no ASOS. O objetivo para nós é ter equipes auto-suficientes e, portanto, ter um papel dedicado pode ser um antipadrão, no entanto, vivemos no mundo real e, para muitos desenvolvedores, pensar em boas práticas de DevOps não é sua principal coisa; portanto, eles precisam de ajuda chegando la.

O que fizemos foi:

• perder o prazo dos engenheiros do DevOps, o DevOps é algo que todos devemos fazer, não nosso cargo, por isso os chamamos de algo diferente.

• os distribuiu para as equipes, mas apenas 1 por 3, isso significava que eles não podiam ser bons, mas tinham que ser vistos como uma competência para ajudar as equipes a melhorar e resolver seus próprios problemas (com orientação)

• manteve uma função central, além de atuar como centro de competência e lidar com as considerações da empresa, qualquer coisa que afete todas as equipes

À medida que evoluímos, revisamos esse modelo, mas para nós ele está funcionando efetivamente até agora

Eu não acho que você será capaz de obter uma resposta definitiva para isso, porque parece que muitas coisas são importantes.

• Como está a bordo da empresa com a prática de DevOps
• Que tipo de aplicativo ou serviço a empresa fornece
• A estrutura da sua empresa

Acabei de entrevistar os cargos e acabei com o título de engenheiro de DevOps, mas o que estou fazendo é o trabalho do Sys Admin. Isso é apenas por necessidade, devido ao tamanho da empresa e à natureza do que está sendo gerenciado em termos de aplicativos. Algumas posições para as quais entrevistei tinham um título semelhante e estavam procurando mais alguém do lado do desenvolvimento das experiências. Eles esperavam mais escrita de código e não um administrador de sistema que faça automação. SRE parece ser um título que está ganhando popularidade, então esse pode ser o caminho a percorrer. Eu tinha como administrador de sistemas e engenheiro de automação como meu último trabalho, porque estava escrevendo ansible e chef stacks parte do tempo. A empresa estava seguindo um bom modelo de devops, onde todos estavam a bordo e os desenvolvedores trabalhavam ao lado das operações, mas acho que o futuro deles não '

Agora que estou nessa posição, estou tentando calar a buzina em alguma automação e temos alguns problemas de pessoas que precisaremos resolver. As pessoas vão e vêm e alguns dos fluxos de trabalho foram projetados porque outra pessoa o projetou dessa maneira e não porque se encaixa no modo como as pessoas trabalham.

Então, basicamente, acho que você deve descobrir a descrição do cargo e não se preocupar tanto com o título, a menos que esteja vinculado a pagar de alguma forma ou você acha que um ou outro atrairia o tipo certo de pessoas.

Se você está preocupado com o significado do DevOps e segue um "único caminho verdadeiro". Você não deve contratar um engenheiro de DevOps. Você deve contratar um engenheiro de automação, engenheiro de implantação ou arquiteto de plataforma ou várias outras funções que fazem o que você precisa.

Se ser um verdadeiro praticante de DevOps não é importante para você, você pode chamá-lo como quiser.