Recentemente, esses anúncios inundaram a Internet. Apesar do salário agradável, não se pode deixar de ter vergonha de que uma heresia selvagem esteja escrita lá dentro. Inicialmente, supõe-se que "DevOps" e "engenheiro" possam, de alguma forma, ser colados em uma palavra e, em seguida, é apresentada uma lista aleatória de requisitos, alguns dos quais são claramente copiados da vaga do administrador do sistema.
Neste post, quero falar um pouco sobre como chegamos ao ponto do que realmente é o DevOps e o que fazer com ele agora.
Tais vagas podem ser condenadas de todas as formas possíveis, mas o fato permanece: existem muitas, e é assim que o mercado funciona no momento. Realizamos uma conferência sobre devos e declaramos abertamente: " DevOops - não para engenheiros de DevOps". Aqui, parecerá estranho e selvagem para muitos: por que as pessoas que fazem um evento completamente comercial vão contra o mercado. Vamos explicar tudo agora.
Sobre cultura e processos
Para começar, o DevOps não é uma disciplina de engenharia. Tudo começou com o fato de que a divisão de papéis estabelecida historicamente não funciona na qualidade dos produtos. Quando os programadores apenas programam, mas não querem ouvir nada sobre testes, o software está cheio de bugs. Quando os administradores não dão a mínima para como e por que o software é escrito, o suporte se transforma em um inferno.
Por exemplo, o famoso Google SRE Book começa com uma descrição da diferença entre a abordagem sysadmin e SRE-shny para gerenciamento de serviços. Estudos interessantes foram conduzidos como parte da pesquisa DORA - pode-se ver que os melhores desenvolvedores conseguem implantar novas alterações na produção mais rapidamente do que uma vez por hora. Eles testam com as mãos não mais que 10% (isso pode ser visto no DORA do ano passado ). Como eles fazem isso? "Excel or die" diz um dos cabeçalhos do relatório. Para uma discussão detalhada dessas estatísticas em termos de teste, você pode acessar a nota principal de Baruch Sadogursky : "Temos DevOps. Vamos demitir todos os testadores ” em nossa outra conferência, Heisenbug.
“Quando não há acordo entre os camaradas,
Não vai dar certo,
E não sairá disso, apenas farinha.
Uma vez um cisne, câncer e Pike ... "
O que você acha, que parte dos programadores da Web realmente entende as condições sob as quais seus aplicativos são operados em prod? Quantos deles irão para os administradores e tentarão descobrir o que acontecerá quando a base cair? E quem deles vai até os testadores e pede para ensinar como escrever testes corretamente? E ainda existem guardas de segurança, gerentes de produto e várias pessoas.
A idéia geral do DevOps é estabelecer a interação entre funções e departamentos. Antes de tudo, isso é alcançado não por algum software astuciosamente ajustado, mas pela prática da comunicação. O DevOps trata de cultura, prática, metodologia e processos. Não existe uma especialidade de engenharia que responda a essas perguntas.
Círculo vicioso
De onde, então, veio a disciplina de "engenharia de devops"? Temos uma versão! As idéias do DevOps acabaram sendo boas - tão boas que se tornaram vítimas de seu sucesso. Em torno deste tópico, alguns recrutadores e traficantes enlameados com uma atmosfera muito especial começaram a girar.
Imagine: ontem você fez shawarma em Khimki e hoje você já é um homem grande, recrutador sênior. Há todo um processo de busca e seleção de candidatos, nem tudo é fácil, é preciso entender. Suponha que o chefe do departamento diga: encontre um especialista em X. Atribuímos a palavra "engenheiro" a X, e o ponto está no chapéu. Precisa de Linux? Bem, é definitivamente um engenheiro de Linux, você quer o DevOps - engenheiro de DevOps. Um trabalho não consiste apenas em um cabeçalho, mas é necessário inserir algum texto dentro dele. A maneira mais fácil é inserir um conjunto de palavras-chave do Google, para as quais haja imaginação suficiente. O DevOps consiste em duas palavras - "Dev" e "Ops", o que significa que você precisa colar as palavras-chave relacionadas a desenvolvedores e administradores, tudo em uma pilha. Portanto, existem vagas para possuir 42 linguagens de programação e 20 anos de uso do Kubernetes e Swarm ao mesmo tempo. Esquema de trabalho.
Assim, a imagem irracional e impiedosa de um certo super-herói - "devops" enraizou-se na mente das pessoas, que preparam todos para Jenkins e a felicidade virá. Ah, se fosse assim tão simples. "E você também pode invadir os administradores de sistema dessa maneira", pensa Eichar, "a palavra está na moda, as palavras-chave são as mesmas, elas devem bicar".
A demanda cria oferta, e um número insano de administradores de sistema encontrou todas essas vagas de lixo, que perceberam que você pode fazer a mesma coisa que antes, mas obter várias vezes mais, chamando-se de "devops". Como você configurou o servidor através do SSH com as mãos, um de cada vez, você continuará a configurar, mas agora essa é supostamente uma prática de devops. Esse é um tipo de fenômeno complexo, parcialmente relacionado à subestimação dos administradores clássicos e ao hype em torno do DevOps, mas, em geral, o que aconteceu acabou.
Então, nós temos oferta e demanda. Um círculo vicioso que se alimenta. É com isso que estamos lutando (inclusive criando a conferência DevOops).
Obviamente, além dos administradores de sistema, renomeados como "devops", existem outros participantes - por exemplo, SRE profissional ou desenvolvedores de Infraestrutura como Código.
O que as pessoas fazem no DevOps (na verdade)
Portanto, você deseja avançar no aprendizado e na aplicação das práticas de DevOps. Mas como fazer, que maneira de olhar? Obviamente, guiar cegamente por palavras-chave populares não vale a pena.
Se houver trabalho, alguém deve fazê-lo. Já descobrimos que esses não são "engenheiros de DevOps", e quem? Parece ser mais correto formular isso não em termos de postagens, mas em áreas específicas do trabalho.
Primeiro, você pode fazer o coração do DevOps - processos e cultura. A cultura não é uma questão rápida e difícil e, embora isso seja tradicionalmente de responsabilidade dos gerentes, de um jeito ou de outro, todos estão envolvidos nisso, de programadores a administradores. Há alguns meses, Tim Lister disse em uma entrevista :
“A cultura é definida pelos valores centrais da organização. Normalmente, as pessoas não percebem isso, mas nós, trabalhando em consultoria por muitos anos, estamos acostumados a perceber isso. Você entra na empresa e, literalmente, em alguns minutos, começa a sentir o que está acontecendo. Nós chamamos isso de "aroma". Às vezes, esse sabor é realmente bom. Às vezes, causa náusea. (...) Você não pode mudar uma cultura antes que os valores e crenças por trás de ações concretas tenham sido realizados. O comportamento é fácil de observar, e a persuasão é difícil. O DevOps é apenas um ótimo exemplo de como as coisas ficam cada vez mais difíceis. ”
Há também uma parte técnica para a pergunta, é claro. Se você obtiver um novo código para teste em um mês, e no lançamento ele aparecer apenas em um ano, e for fisicamente impossível acelerar tudo isso, não será possível cumprir as boas práticas. Boas práticas são suportadas por boas ferramentas. Por exemplo, com a idéia de Infraestrutura como código em mente, você pode usar qualquer coisa, desde o AWS CloudFormation e o Terraform até o Chef-Ansible-Puppet. Você precisa saber e ser capaz de fazer tudo isso, e essa é uma disciplina completamente de engenharia. É importante não confundir a causa com as conseqüências: primeiro você trabalha com os princípios da SRE e só então implementa esses princípios na forma de algumas soluções técnicas específicas. Ao mesmo tempo, o SRE é uma metodologia muito abrangente que não fala sobre como configurar o Jenkins, mas sobre cinco princípios básicos:
- Melhorando a interação entre funções e departamentos
- Aceitar erros como parte integrante do trabalho
- Mudança progressiva
- Usando ajuste e outra automação
- Medindo tudo o que pode ser medido
Este não é apenas um conjunto de declarações, mas um guia específico para ação . Por exemplo, no caminho para cometer erros, você precisará lidar com riscos, medir a disponibilidade e inacessibilidade de serviços usando algo como SLI ( indicadores de nível de serviço ) e SLO ( objetivos de nível de serviço ), aprender a escrever post mortem e facilitar a escrita .
Na disciplina SRE, o uso de ferramentas é apenas uma parte do sucesso, no entanto, é importante. Precisamos desenvolver constantemente tecnicamente, observar o que está acontecendo no mundo e como isso pode ser aplicado em nosso trabalho.
Por sua vez, as soluções Cloud Native se tornaram muito populares agora. De acordo com o entendimento atual da Cloud Native Computing Foundation, as tecnologias Cloud Native permitem que as organizações desenvolvam e executem aplicativos escalá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 os sistemas fracamente acoplados permaneçam flexíveis, gerenciáveis e bem observáveis. A boa automação permite que os engenheiros façam grandes alterações com frequência e com resultados previsíveis, sem transformá-lo em um trabalho infernal. Tudo isso é suportado por uma pilha de ferramentas conhecidas, como Docker e Kubernetes.
Essa definição bastante complicada e pesada está relacionada ao fato de a região ser bastante complicada. Por um lado, argumenta-se que novas mudanças neste sistema devem ser adicionadas de maneira bastante simples. Por outro lado, para descobrir como criar algum tipo de ambiente em contêiner no qual os serviços fracamente acoplados residem em uma infraestrutura definida por software e são entregues lá usando um CI / CD contínuo e desenvolvam toda essa prática do DevOps - você precisa de mais de um comer um cachorro.
O que fazer com tudo isso
Cada um resolve esses problemas à sua maneira: por exemplo, você pode publicar tarefas normais para quebrar o círculo vicioso. Você pode descobrir o que significam palavras como DevOps e Cloud Native e usá-las corretamente e direto ao ponto. Você pode desenvolver no DevOps e demonstrar as abordagens corretas com seu próprio exemplo.
Estamos fazendo a conferência DevOops 2020 em Moscou , que oferece uma oportunidade para entender melhor as coisas das quais acabamos de falar. Existem vários grupos de relatórios para isso:
- Processos e cultura;
- Engenharia de confiabilidade do site;
- Nuvem nativa
Como escolher para onde ir? Há um ponto sutil. Por um lado, o DevOps é sobre interação e realmente queremos que você vá a relatórios 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, esse será um bloco sobre processos e cultura. Não se esqueça de que, após a conferência, você fará anotações (após preencher o formulário de feedback), para que você possa sempre ver relatórios menos importantes posteriormente.
Obviamente, na própria conferência, você não pode ir imediatamente para três faixas ao mesmo tempo, por isso estamos criando o programa de tal forma que haja temas para todos os gostos em cada intervalo de tempo.
Resta apenas entender o que fazer se você for um engenheiro de DevOps! Primeiro, tente determinar o que você está realmente fazendo. Geralmente eles gostam de chamar esta palavra:
- Desenvolvedores que lidam com infraestrutura. Os grupos de conversação SRE e Cloud Native são mais adequados para você.
- Administradores de sistema. É mais complicado. O DevOops não é sobre administração do sistema. Felizmente, existem muitas excelentes conferências, livros, artigos, vídeos na Internet etc. sobre o assunto da administração do sistema. Por outro lado, se você estiver interessado em desenvolver em termos de cultura e processos, explorar tecnologias em nuvem e os detalhes da vida com o Cloud Native, teremos o maior prazer em vê-lo! Pense sobre isso: aqui você está na administração e, então, o que você fará? Para não ficar de repente em uma situação desagradável, vale a pena estudar agora.
Há outra opção: você persiste e continua afirmando que é um engenheiro de DevOps e nada mais, o que quer que isso signifique. Depois forçado a sofrer, o DevOops não é uma conferência para engenheiros de DevOps!
Slide do relatório Konstantin Diener em Munique
O DevOops 2020 Moscou será realizado de 29 a 30 de abril em Moscou. Os ingressos já podem ser comprados no site oficial .
Além disso, você pode enviar seu relatório até 8 de fevereiro. Observe que, ao preencher o formulário, você deve escolher o público-alvo para o qual seu relatório será mais bom ( uma surpresa está escondida dentro da lista ).