Recentemente, esse tipo de anúncio inundou a internet. Apesar do salário atrativo, é impossível não se sentir incomodado com a enorme incoerência que eles apresentam. A princípio, presume-se que 'DevOps' e 'engenheiro' possam ser de alguma forma colados em uma única palavra, e a seguir vem uma lista aleatória de requisitos, parte dos quais claramente copiada de vagas para administradores de sistemas.
Neste post, gostaria de conversar um pouco sobre como chegamos a essa situação, o que realmente significa DevOps e o que podemos fazer a respeito.
Essas vagas podem ser criticadas de diversas formas, mas o fato é que elas existem em grande número, e esse é o estado atual do mercado. Criamos uma conferência de DevOps e declaramos abertamente: ' — não é para engenheiros DevOps'. Aqui, muitos podem achar estranho e absurdo: por que pessoas organizando um evento totalmente comercial estão indo contra o mercado? Agora vamos explicar tudo isso.
Sobre cultura e processos
Vamos começar pelo fato de que DevOps não é uma disciplina de engenharia. Tudo começou com o entendimento de que a divisão histórica de papéis não contribui para a qualidade dos produtos. Quando os programadores apenas codificam, sem se preocupar com testes, o software fica repleto de bugs. Quando os administradores não se preocupam com como e por que o software foi desenvolvido, o suporte se torna um verdadeiro caos.
Por exemplo, a distinção entre a abordagem de administração de sistemas e a abordagem de SRE em gerenciamento de serviços . Estudos interessantes foram realizados no contexto de — é evidente que os melhores desenvolvedores de alguma forma conseguem implantar novas alterações na produção mais de uma vez por hora. Eles testam manualmente em não mais que 10% (isso pode ser verificado através da ). Como eles conseguem isso? 'Excel ou morra' – diz um dos títulos do relatório. Para uma discussão mais detalhada sobre essa estatística em termos de testes, você pode consultar a palestra de Baruch Sadogursky em outra de nossas conferências, Heisenbug.
‘Quando não há acordo entre os companheiros,
a obra não avança,
e não resultará em nada, apenas em sofrimento.
Certa vez, o Cisne, o Caranguejo e a Dourada…’
O que você acha, qual parte dos desenvolvedores web realmente entende em quais condições suas aplicações são executadas em produção? Quantos deles vão até os administradores e tentam entender o que acontece quando o banco de dados cai? E quem deles vai até os testadores e pede para aprender a escrever testes corretamente? E ainda existem os especialistas em segurança, gerentes de produto e um monte de outras pessoas.
A ideia geral do DevOps é melhorar a interação entre funções e departamentos. Isso é alcançado principalmente através da prática da comunicação, e não de algum software sofisticado. DevOps é sobre cultura, prática, metodologia e processos. Não existe uma especialidade de engenharia que responda a essas questões.
Círculo vicioso
De onde surgiu então a disciplina de "engenharia DevOps"? Temos uma versão! As ideias do DevOps se mostraram tão boas — tão boas que se tornaram vítimas de seu próprio sucesso. Em torno desse tema, começaram a surgir recrutadores obscuros e mercadores de pessoas, todos com sua própria atmosfera.
Imagine: ontem você estava vendendo shawarma em Khimki, e hoje já é uma pessoa importante, um recrutador sênior. Aqui há um processo inteiro de busca e seleção de candidatos, não é fácil, é preciso entender. Suponha que o chefe do departamento diz: encontre um especialista em X. Adicionamos a palavra "engenheiro" a X e está tudo resolvido. Precisa de Linux? Então esse é definitivamente um engenheiro de Linux, quer DevOps — engenheiro de DevOps. A vaga não consiste apenas de um título, mas é necessário incluir algum texto. O mais fácil é acrescentar um conjunto de palavras-chave do Google, conforme a criatividade de cada um. DevOps se compõe de duas palavras — "Dev" e "Ops", então é preciso juntar palavras-chave relacionadas a desenvolvedores e administradores, tudo em um só lugar. Assim surgem vagas que pedem domínio de 42 linguagens de programação e 20 anos de uso de Kubernetes e Swarm simultaneamente. É o esquema de trabalho.
Assim, na mente das pessoas, se enraizou a imagem sem sentido e implacável de um super-herói do "DevOps", que configura o deploy para todos no Jenkins, e a felicidade se instala. Ah, se tudo fosse tão simples. "E ainda dá para caçar administradores de sistema," pensa o RH, "é uma palavra da moda, as palavras-chave são as mesmas, devem ter sucesso."
A demanda cria a oferta, e para todas essas vagas absurdas houve uma quantidade maluca de administradores de sistemas que perceberam: é possível fazer tudo o que faziam antes, mas ganhando muito mais, chamando-se de "DevOps". Assim como você configurava servidores manualmente via SSH, continuará a fazer o mesmo, mas agora isso é supostamente uma prática DevOps. É um fenômeno complexo, parcialmente relacionado à desvalorização dos administradores clássicos e ao hype em torno do DevOps, mas, no geral, o que aconteceu, aconteceu.
Portanto, temos demanda e oferta. Um ciclo vicioso que se alimenta de si mesmo. É com isso que estamos lutando (incluindo a criação da conferência DevOops).
Certamente, além dos administradores de sistemas que se rebatizaram como "DevOps", existem outros participantes — por exemplo, profissionais de SRE ou desenvolvedores de Infrastructure-as-Code.
O que as pessoas realmente fazem em DevOps
Então, você quer avançar no estudo e na aplicação das práticas DevOps. Mas como fazer isso, para onde olhar? Obviamente, não é aconselhável seguir cegamente as palavras-chave populares.
Se há trabalho, alguém deve se ocupar dele. Já descobrimos que não são os "engenheiros DevOps", então quem? Parece mais correto formular isso não em termos de cargos, mas em termos de direções específicas de trabalho.
Em primeiro lugar, você pode se envolver no cerne do DevOps — processos e cultura. A cultura é algo que não acontece rapidamente e não é fácil, e embora tradicionalmente seja responsabilidade dos líderes, de alguma forma todos participam, de programadores a administradores. Há alguns meses, Tim Lister :
"A cultura é definida pelos valores fundamentais da organização. Normalmente, as pessoas não percebem isso, mas nós, que atuamos no consultório há muitos anos, nos acostumamos a notar. Você entra em uma empresa e, literalmente em alguns minutos, começa a sentir o que está acontecendo. Chamamos isso de 'aroma'. Às vezes, esse aroma é realmente bom. Às vezes, dá ânsia de vômito. (…) Você não pode mudar a cultura antes que os valores e crenças que sustentam ações específicas sejam compreendidos. O comportamento é fácil de observar, mas encontrar crenças é difícil. DevOps é, de fato, um ótimo exemplo de como tudo se torna cada vez mais complicado."
Há também a parte técnica da questão, é claro. Se seu novo código para teste chega em um mês, mas na versão final só aparece após um ano, e acelerar tudo isso fisicamente é impossível — você pode nunca alcançar boas práticas. Boas práticas são sustentadas por boas ferramentas. Por exemplo, mantendo em mente a ideia de Infrastructure-as-Code, você pode usar qualquer coisa, desde AWS CloudFormation e Terraform até Chef-Ansible-Puppet. É necessário saber e dominar tudo isso, e isso já é uma disciplina de engenharia. É importante não confundir causa com consequência: primeiro você trabalha com os princípios do SRE e só depois os implementa em soluções técnicas específicas. O SRE é uma metodologia muito complexa que fala não sobre como configurar o Jenkins, mas sim sobre cinco princípios fundamentais:
- Melhorar a interação entre funções e departamentos
- Aceitar erros como parte integrante do trabalho
- Realização gradual de mudanças
- Uso de ferramentas e automação
- Medir tudo o que pode ser medido
Isso não é apenas um conjunto de afirmações, mas um verdadeiro . Por exemplo, ao adotar a aceitação de erros, será necessário lidar com riscos, medir a disponibilidade e a indisponibilidade de serviços usando algo como SLI () e SLO (), aprender a escrever post-mortems e fazer com que escrevê-los não seja algo assustador.
Na disciplina de SRE, o uso de ferramentas é apenas uma parte do sucesso, embora seja uma parte importante. Precisamos nos desenvolver continuamente em termos técnicos, observar o que acontece no mundo e como isso pode ser aplicado em nosso trabalho.
Por sua vez, agora as soluções Cloud Native tornaram-se muito populares. Segundo a compreensão atual da Cloud Native Computing Foundation, as tecnologias Cloud Native permitem que organizações desenvolvam e implantem aplicativos escaláveis em ambientes dinâmicos modernos, como nuvens públicas, privadas e híbridas. Exemplos incluem contêineres, service meshes, microserviços, infraestrutura imutável e APIs declarativas. Todas essas técnicas permitem que sistemas fracamente acoplados permaneçam elásticos, gerenciáveis e bem monitorados. Uma boa automação permite que engenheiros façam grandes mudanças com frequência e resultados previsíveis, sem que isso se torne um trabalho árduo. Tudo isso é suportado por um conjunto de ferramentas amplamente conhecidas, como Docker e Kubernetes.
Essa definição é bastante complexa e abrangente, relacionada ao fato de que o campo também é complicado. Por um lado, afirma-se que as novas alterações nesta sistema devem ser adicionadas de forma relativamente simples. Por outro lado, para entender como criar um ambiente containerizado no qual serviços fracamente acoplados vivem em uma infraestrutura definida por software e são implantados por meio de CI/CD contínuo, além de desenvolver práticas DevOps ao redor de tudo isso — é necessário ter bastante experiência.
O que fazer com tudo isso
Cada um resolve esses problemas à sua maneira: por exemplo, pode-se publicar vagas normais para romper o ciclo vicioso. É possível entender o que palavras como DevOps e Cloud Native significam e usá-las corretamente e com propriedade. É viável se desenvolver em DevOps e, através do próprio exemplo, demonstrar as abordagens corretas.
Estamos organizando uma conferência , que oferece a oportunidade de se aprofundar nas questões que acabamos de discutir. Para isso, há vários grupos de palestras:
- Processos e cultura;
- Engenharia de Confiabilidade de Site;
- Cloud Native;
Como escolher para onde ir? Aqui há um detalhe importante. Por um lado, DevOps é sobre interação, e realmente gostaríamos que você assistisse a palestras de diferentes blocos. Por outro lado, se você é um gerente de desenvolvimento que veio à conferência para se concentrar em uma tarefa específica, então ninguém vai te limitar — obviamente, será o bloco sobre processos e cultura. Lembre-se de que, após a conferência, você terá gravações (após preencher o formulário de feedback), então você sempre poderá assistir a palestras menos importantes mais tarde.
É evidente que na própria conferência você não pode ir a três trilhas ao mesmo tempo, então formulamos a programação de modo que em cada slot de tempo haja temas para todos os gostos.
Resta apenas descobrir o que fazer se você for um engenheiro DevOps! Primeiro, tente definir com clareza o que você realmente faz. Geralmente, esta palavra é usada para descrever:
- Desenvolvedores que trabalham com infraestrutura. Para você, os grupos de palestras sobre SRE e Cloud Native são os mais adequados.
- Administradores de sistemas. Aqui as coisas são mais complicadas. DevOops não é sobre administração de sistemas. Felizmente, há muitas conferências, livros, artigos e vídeos ótimos sobre administração de sistemas disponíveis na internet, etc. Por outro lado, se você tem interesse em se desenvolver em termos de compreensão da cultura e processos, aprender sobre tecnologias em nuvem e detalhes da vida com Cloud Native, adoraríamos vê-lo! Pense nisso: você está trabalhando na administração, e depois o que você vai fazer? Para não acabar em uma situação desagradável repentinamente, é melhor começar a aprender agora.
Há outra opção: você insiste e continua afirmando que é exatamente um engenheiro DevOps e nada mais, não importa o que isso signifique. Então, lamento dizer, DevOops não é uma conferência para engenheiros DevOps!
Slide da em Munique
DevOops 2020 Moscow ocorrerá nos dias 29 e 30 de abril em Moscou, os ingressos já estão disponíveis .
Além disso, você pode até 8 de fevereiro. Lembre-se de que ao preencher o formulário, você deve escolher o público-alvo que se beneficiará mais com sua palestra (um surpresa está escondida na lista).
Fonte: habr.com
