Recentemente, esses anúncios inundaram a Internet. Apesar do salário agradável, não se pode deixar de ficar envergonhado porque uma heresia selvagem está escrita dentro dele. A princípio, presume-se que “DevOps” e “engenheiro” podem de alguma forma ser reunidos em uma palavra, e então há uma lista aleatória de requisitos, alguns dos quais são claramente copiados da vaga de administrador de sistemas.
Neste post gostaria de falar um pouco sobre como chegamos a esse ponto de vida, o que realmente é DevOps e o que fazer com ele agora.
Essas vagas podem ser condenadas de todas as formas possíveis, mas o fato é que são muitas e é assim que funciona o mercado no momento. Realizamos uma conferência devops e declaramos abertamente: “ - não para engenheiros de DevOps." Isso pode parecer estranho e absurdo para muitos: por que as pessoas que estão realizando um evento totalmente comercial vão contra o mercado. Agora vamos explicar tudo.
Sobre cultura e processos
Vamos começar com o fato de que DevOps não é uma disciplina de engenharia. Tudo começou com o fato de que a divisão de funções historicamente estabelecida não funciona para a qualidade dos produtos. Quando os programadores apenas programam, mas não querem ouvir nada sobre testes, o software está repleto de bugs. Quando os administradores não se importam como ou por que o software foi escrito, o suporte se transforma em um inferno.
Por exemplo, descrevendo a diferença entre um administrador de sistema e uma abordagem SRE para gerenciamento de serviços . Estudos interessantes foram realizados dentro – está claro que os melhores desenvolvedores conseguem de alguma forma implantar novas mudanças na produção mais rápido do que uma vez por hora. Eles testam com as mãos não mais que 10% (isso pode ser visto em ). Como eles fazem isso? “Excel ou morra”, diz um dos títulos do relatório. Para uma discussão detalhada dessas estatísticas no contexto de testes, você pode consultar a palestra de Baruch Sadogursky em nossa outra conferência, Heisenbug.
“Quando não há acordo entre camaradas,
Eles não vão funcionar bem.
E isso não vai funcionar com ele, apenas farinha.
Era uma vez um cisne, um lagostim e um lúcio..."
Que parte dos programadores web você acha que realmente entende as condições sob as quais seus aplicativos são usados na produção? Quantos deles irão até os administradores e tentarão descobrir o que acontecerá se o banco de dados falhar? E qual deles irá até os testadores e pedirá que lhes ensinem como escrever testes corretamente? E também há seguranças, gerentes de produto e um monte de outras pessoas.
A ideia geral do DevOps é criar colaboração entre funções e departamentos. Em primeiro lugar, isto não é conseguido por meio de algum software habilmente configurado, mas pela prática da comunicação. DevOps trata de cultura, práticas, metodologia e processos. Não há especialidade de engenharia que possa responder a essas perguntas.
Círculo vicioso
De onde veio a disciplina de “engenharia devops” então? Temos uma versão! As ideias de DevOps eram boas – tão boas que se tornaram vítimas de seu próprio sucesso. Alguns recrutadores obscuros e traficantes de seres humanos, que têm a sua própria atmosfera, começaram a girar em torno deste tema.
Imagine: ontem você estava fazendo shawarma em Khimki e hoje já é um grande homem, um recrutador sênior. Existe todo um processo de busca e seleção de candidatos, nem tudo é fácil, é preciso entender. Digamos que o chefe de um departamento diga: encontre um especialista em X. Atribuímos a palavra “engenheiro” a X e pronto. Precisa de Linux? Bem, este é definitivamente um engenheiro Linux, se você quer DevOps, então um engenheiro DevOps. A vaga consiste não apenas em um título, mas também algum texto deve ser inserido em seu interior. A maneira mais fácil é inserir um conjunto de palavras-chave do Google, dependendo da sua imaginação. DevOps consiste em duas palavras – “Dev” e “Ops”, o que significa que precisamos reunir palavras-chave relacionadas a desenvolvedores e administradores, todas em uma única pilha. É assim que aparecem as vagas sobre proficiência em 42 linguagens de programação e 20 anos de uso simultâneo de Kubernetes e Swarm. Diagrama de trabalho.
Foi assim que a imagem sem sentido e impiedosa de um certo super-herói “devops” se enraizou na mente das pessoas, que configurará todos para implantarem no Jenkins, e a felicidade virá. Ah, se tudo fosse tão simples. “E é também assim que você pode caçar administradores de sistema”, pensa o RH, “é uma palavra da moda, as palavras-chave são as mesmas, eles deveriam morder a isca”.
A demanda cria oferta, e todas essas vagas inúteis foram preenchidas por um número absurdo de administradores de sistema que perceberam: você pode fazer tudo igual a antes, mas conseguir várias vezes mais chamando a si mesmo de “devops”. Assim como você configurou servidores via SSH manualmente, um de cada vez, você continuará a configurá-los, mas agora isso é supostamente uma prática de devops. Este é algum tipo de fenômeno complexo, em parte relacionado à subestimação dos administradores clássicos e ao entusiasmo em torno do DevOps, mas, em geral, o que aconteceu, aconteceu.
Portanto, temos oferta e demanda. Um círculo vicioso que se alimenta sozinho. É contra isso que estamos lutando (inclusive através da criação da conferência DevOops).
É claro que, além dos administradores de sistema que se renomearam como “devops”, existem outros participantes – por exemplo, SREs profissionais ou desenvolvedores de infraestrutura como código.
O que as pessoas fazem no DevOps (realmente)
Então você quer avançar no aprendizado e na aplicação de práticas DevOps. Mas como fazer isso, em que direção olhar? Obviamente, você não deve confiar cegamente em palavras-chave populares.
Se houver um trabalho, alguém deveria fazê-lo. Já descobrimos que estes não são “engenheiros devops”, então quem são? Parece mais correcto formular isto não em termos de cargos, mas em termos de áreas específicas de trabalho.
Primeiro, você pode abordar o cerne do DevOps: processos e cultura. A cultura é um negócio lento e difícil e, embora seja tradicionalmente responsabilidade dos gestores, todos estão envolvidos de uma forma ou de outra, desde programadores até administradores. Alguns meses atrás, Tim Lister :
“A cultura é determinada pelos valores fundamentais da organização. Normalmente as pessoas não percebem isso, mas como trabalhamos em consultoria há muitos anos, estamos acostumados a perceber. Você entra em uma empresa e literalmente em poucos minutos começa a sentir o que está acontecendo. Chamamos isso de “sabor”. Às vezes esse perfume é muito bom. Às vezes causa náusea. (...) Não se pode mudar uma cultura até que os valores e crenças por trás de ações específicas sejam compreendidos. O comportamento é fácil de observar, mas a busca por crenças é difícil. DevOps é apenas um ótimo exemplo de como as coisas estão se tornando cada vez mais complexas.”
Há também uma parte técnica da questão, é claro. Se o seu novo código for testado em um mês, mas for lançado apenas um ano depois, e for fisicamente impossível acelerar tudo, você pode não seguir as boas práticas. Boas práticas são apoiadas por boas ferramentas. Por exemplo, com a ideia de infraestrutura como código em mente, você pode usar qualquer coisa, desde AWS CloudFormation e Terraform até Chef-Ansible-Puppet. Você precisa saber e ser capaz de fazer tudo isso, e isso já é uma disciplina bastante de engenharia. É importante não confundir causa com efeito: primeiro você trabalha de acordo com os princípios do SRE e só depois implementa esses princípios na forma de algumas soluções técnicas específicas. Ao mesmo tempo, SRE é uma metodologia muito abrangente que não ensina como configurar o Jenkins, mas sim cinco princípios básicos:
- Melhor comunicação entre funções e departamentos
- Aceitar erros como parte integrante do trabalho
- Fazendo mudanças gradualmente
- Usando ferramentas e outras automações
- Medindo tudo o que pode ser medido
Este não é apenas um conjunto de declarações, mas uma . Por exemplo, no caminho para aceitar erros, você precisará entender os riscos, medir a disponibilidade e indisponibilidade de serviços usando algo como SLI () e SLO (), aprenda a escrever post-mortems e faça com que escrevê-los não seja assustador.
Na disciplina SRE, o uso de ferramentas é apenas uma parte do sucesso, embora seja importante. Precisamos nos desenvolver constantemente tecnicamente, olhar o que está acontecendo no mundo e como isso pode ser aplicado no nosso trabalho.
Por sua vez, as soluções Cloud Native tornaram-se muito populares. Conforme definido hoje pela Cloud Native Computing Foundation, as tecnologias Cloud Native permitem que as organizações desenvolvam e executem aplicativos escalonáveis nos ambientes dinâmicos de hoje, como nuvens públicas, privadas e híbridas. Os exemplos incluem contêineres, malhas de serviço, microsserviços, infraestrutura imutável e APIs declarativas. Todas essas técnicas permitem que sistemas fracamente acoplados permaneçam elásticos, gerenciáveis e altamente observáveis. Uma boa automação permite que os engenheiros façam grandes mudanças com frequência e com resultados previsíveis, sem tornar isso uma tarefa árdua. Tudo isso é suportado por uma pilha de ferramentas conhecidas como Docker e Kubernetes.
Esta definição bastante complicada e ampla deve-se ao facto de a área ser também bastante complexa. Por um lado, argumenta-se que novas alterações a este sistema deveriam ser adicionadas de forma bastante simples. Por outro lado, descobrir como criar um tipo de ambiente em contêiner no qual serviços fracamente acoplados residem em uma infraestrutura definida por software e são entregues lá usando CI/CD contínuo, e construir práticas de DevOps em torno de tudo isso - tudo isso requer mais do que alguém come o cachorro.
O que fazer com tudo isso
Cada um resolve esses problemas à sua maneira: por exemplo, você pode publicar vagas normais para quebrar o círculo vicioso. Você pode descobrir o que palavras como DevOps e Cloud Native significam e usá-las corretamente e direto ao ponto. Você pode desenvolver em DevOps e demonstrar as abordagens corretas com seu exemplo.
Estamos fazendo uma conferência , o que oferece uma oportunidade de nos aprofundarmos nas coisas sobre as quais acabamos de falar. Existem vários grupos de relatórios para isso:
- Processos e cultura;
- Engenharia de Confiabilidade do Local;
- Nativo da nuvem;
Como escolher para onde ir? Há um ponto sutil aqui. Por um lado, DevOps trata de interação, e queremos muito que você assista a apresentações de diferentes blocos. Por outro lado, se você é um gerente de desenvolvimento que veio à conferência para se concentrar em uma tarefa específica, ninguém o limita - obviamente, isso será um bloqueio em relação a processos e cultura. Não se esqueça que você terá gravações após a conferência (após preencher o formulário de feedback), para que possa sempre assistir a apresentações menos importantes posteriormente.
Obviamente, na conferência em si não é possível percorrer três faixas ao mesmo tempo, por isso organizamos a programação de forma que cada horário tenha temas para todos os gostos.
Resta entender o que fazer se você for um engenheiro DevOps! Primeiro, tente determinar o que você realmente faz. Geralmente eles gostam de chamar esta palavra:
- Desenvolvedores que trabalham em infraestrutura. Os grupos de relatórios sobre SRE e Cloud Native são mais adequados para você.
- Administradores de sistema. É mais complicado aqui. DevOops não trata de administração de sistema. Felizmente, existem muitas conferências, livros, artigos, vídeos excelentes na Internet, etc. sobre o tema administração de sistemas. Por outro lado, se você tem interesse em se desenvolver em termos de compreensão de cultura e processos, aprendendo sobre tecnologias de nuvem e os detalhes da vida com Cloud Native, adoraríamos vê-lo! Pense nisso: você está fazendo administração e depois o que vai fazer? Para evitar se encontrar repentinamente em uma situação desagradável, você deve aprender agora.
Há outra opção: você persiste e continua a afirmar que está especificamente um engenheiro DevOps e nada mais, seja lá o que isso signifique. Então temos que decepcioná-lo, DevOops não é uma conferência para engenheiros de DevOps!
Deslizar de em Munique
DevOops 2020 Moscou será realizada de 29 a 30 de abril em Moscou, os ingressos já estão disponíveis .
Alternativamente, você pode até 8 de fevereiro. Observe que ao preencher o formulário você deve selecionar o público-alvo que mais se beneficiará com seu relatório (há uma surpresa enterrada dentro da lista).
Fonte: habr.com