O que é necessário para uma empresa de TI ter sucesso em 2019? Palestrantes em conferências e encontros dizem muitas palavras em voz alta que nem sempre são compreensíveis para pessoas normais. A luta pelo tempo de implantação, microsserviços, abandono do monólito, transformação DevOps e muito, muito mais. Se descartarmos a beleza verbal e falarmos diretamente e em russo, tudo se resume a uma tese simples: fazer um produto de qualidade e com conforto para a equipe.
Este último tornou-se extremamente importante. As empresas finalmente chegaram à conclusão de que um processo de desenvolvimento confortável aumenta a produtividade e, se tudo estiver depurado e funcionar como um relógio, também dá margem de manobra em situações críticas. Era uma vez, para essa manobra, um certo espertinho surgiu com backups, mas a indústria está se desenvolvendo, e recorremos aos engenheiros de DevOps - pessoas que transformam o processo de interação entre o desenvolvimento e a infraestrutura externa em algo adequado e não relacionado ao xamanismo.
Toda essa história “modular” é maravilhosa, mas... Acontece que alguns administradores foram abruptamente apelidados de DevOps, e os próprios engenheiros de DevOps começaram a ser obrigados a ter pelo menos as habilidades de telepatia e clarividência.
Antes de falarmos sobre os problemas modernos de fornecimento de infraestrutura, vamos definir o que queremos dizer com este termo. No momento actual, a situação evoluiu de tal forma que atingimos a dualidade deste conceito: a infra-estrutura pode ser condicionalmente externa e condicionalmente interna.
Por infraestrutura externa entendemos tudo o que garante a funcionalidade do serviço ou produto que a equipe está desenvolvendo. São servidores de aplicativos ou sites, hospedagem e outros serviços que garantem a funcionalidade do produto.
A infraestrutura interna inclui serviços e equipamentos que são utilizados pela própria equipe de desenvolvimento e demais funcionários, que costumam ser muitos. São servidores internos de sistemas de armazenamento de código, um gerenciador de tarefas implantado localmente e tudo, tudo, tudo que existe na intranet corporativa.
O que um administrador de sistema faz em uma empresa? Além do trabalho de administração desta mesma intranet corporativa, muitas vezes ela suporta o fardo das preocupações económicas para garantir a operacionalidade do equipamento de escritório. O administrador é o mesmo cara que arrasta rapidamente uma nova unidade de sistema ou um laptop sobressalente pronto para uso da sala dos fundos, distribui um teclado novo e rasteja de quatro pelos escritórios, esticando o cabo Ethernet. Um administrador é o proprietário local e governante não apenas de servidores internos e externos, mas também de um executivo de negócios. Sim, alguns administradores só podem trabalhar no plano do sistema, sem hardware. Eles devem ser separados em uma subclasse separada de “administradores de sistemas de infraestrutura”. E alguns se especializam em atender exclusivamente equipamentos de escritório; felizmente, se a empresa tiver mais de cem pessoas, o trabalho nunca termina. Mas nenhum deles é devops.
Quem são DevOps? Devops são caras que falam sobre a interação do desenvolvimento de software com infraestrutura externa. Mais precisamente, os devops modernos estão envolvidos nos processos de desenvolvimento e implantação de forma muito mais profunda do que os administradores que simplesmente carregavam atualizações para o FTP. Uma das principais tarefas de um engenheiro DevOps agora é garantir um processo de interação confortável e eficazmente estruturado entre as equipes de desenvolvimento e a infraestrutura do produto. São essas pessoas as responsáveis pela implantação de sistemas de rollback e implantação; são essas pessoas que aliviam parte da carga dos desenvolvedores e se concentram o máximo possível em sua tarefa extremamente importante. Ao mesmo tempo, devops nunca instalará um novo cabo ou emitirá um novo laptop da sala dos fundos (c) KO
Qual é o problema?
À pergunta “Quem é DevOps?” metade dos trabalhadores da área começa a responder algo como “Bem, resumindo, este é o administrador que...” e mais adiante no texto. Sim, era uma vez, quando a profissão de engenheiro DevOps estava emergindo dos administradores mais talentosos em termos de manutenção de serviços, as diferenças entre eles não eram óbvias para todos. Mas agora, quando as funções de devops e admin na equipe se tornaram radicalmente diferentes, é inaceitável confundi-las, ou mesmo igualá-las.
Mas o que isso significa para os negócios?
Contratar, é tudo uma questão.
Você abre uma vaga para “Administrador de Sistemas”, e os requisitos ali listados são “interação com desenvolvimento e clientes”, “sistema de entrega de CI/CD”, “manutenção de servidores e equipamentos da empresa”, “administração de sistemas internos” e assim por diante. sobre; você entende que o empregador está falando bobagem. O problema é que em vez de “Administrador de Sistema” o título da vaga deveria ser “Engenheiro DevOps”, e se esse título for alterado, tudo se encaixará.
Porém, que impressão se tem ao ler tal vaga? Que a empresa está procurando um operador de múltiplas máquinas que irá implantar um sistema de controle e monitoramento de versão e apertar o twister com os dentes...
Mas para não aumentar o grau de dependência de drogas no mercado de trabalho, basta chamar as vagas pelos nomes próprios e entender claramente que um engenheiro DevOps e um administrador de sistemas são duas entidades diferentes. Mas o desejo irreprimível de alguns empregadores de apresentar a um candidato a lista de requisitos mais ampla possível leva ao fato de que os administradores de sistemas “clássicos” deixam de entender o que está acontecendo ao seu redor. O quê, a profissão está em mutação e eles estão atrasados?
Não, não e mais uma vez, não. Os administradores de infraestrutura que irão gerenciar os servidores internos da empresa, ou ocupar cargos de suporte N2/N3 e ajudar outros funcionários, não foram embora e não irão embora.
Esses especialistas podem se tornar engenheiros de DevOps? Claro que podem. Na verdade, este é um ambiente relacionado que requer habilidades de administração de sistemas, mas além disso acrescenta-se o trabalho com monitoramento, entrega de sistemas e, em geral, interação próxima com a equipe de desenvolvimento e testes.
Outro problema de DevOps
Na verdade, nem tudo se limita apenas às contratações e à confusão constante entre administradores e devops. Em algum momento, o negócio se deparou com o problema de entrega de atualizações e interação da equipe de desenvolvimento com a infraestrutura final.
Talvez tenha sido quando um tio com olhos brilhantes subiu no palco de alguma conferência e disse: “Fazemos isso e chamamos de DevOps. Esses caras vão resolver todos os seus problemas” – e começou a contar como é boa a vida na empresa após implementar práticas de DevOps.
Porém, não basta contratar um engenheiro DevOps para que tudo funcione como deveria. A empresa deve passar por uma transformação completa do DevOps, ou seja, o papel e as capacidades do nosso DevOps também devem ser claramente compreendidos por parte da equipe de desenvolvimento e testes de produtos. Temos uma história “maravilhosa” sobre este tema que ilustra plenamente toda a brutalidade que está acontecendo em alguns lugares.
Situação. O DevOps é necessário para implantar um sistema de reversão de versão sem realmente se aprofundar em como ele funcionará. Vamos supor que dentro do sistema Usuários existam campos separados para nome, sobrenome e senha. Sai uma nova versão do produto, mas para os desenvolvedores um “rollback” é apenas uma varinha mágica que vai consertar tudo, e eles nem sabem como funciona. Assim, por exemplo, no patch seguinte, os desenvolvedores combinaram os campos de nome e sobrenome, lançaram-no em produção, mas a versão está lenta por algum motivo. O que está acontecendo? A gerência chega ao devops e diz “Puxe o interruptor!”, ou seja, pede para ele voltar para a versão anterior. O que o devops faz? Ele reverte para a versão anterior, mas como os desenvolvedores não queriam descobrir como essa reversão foi feita, ninguém disse à equipe Devops que o banco de dados também precisava ser revertido. Como resultado, tudo trava para nós e, em vez de um site lento, os usuários veem um erro “500”, pois a versão antiga não funciona com os campos do novo banco de dados. Devops não sabe disso. Os desenvolvedores estão em silêncio. A administração começa a perder os nervos e o dinheiro e se lembra dos backups, oferecendo-se para revertê-los para que “pelo menos algo funcione”. Como resultado, os usuários perdem todos os seus dados durante um período de tempo.
As loucuras, é claro, vão para o devops, que “não criou um sistema de reversão adequado”, e ninguém se importa que os alces nesta história sejam desenvolvedores.
A conclusão é simples: sem uma abordagem normal ao DevOps como tal, é de pouca utilidade.
A principal coisa a lembrar: um engenheiro DevOps não é um mágico e, sem comunicações de qualidade e interação bidirecional com o desenvolvimento, ele não conseguirá cumprir suas tarefas. Os desenvolvedores não podem ser deixados sozinhos com seus “problemas” ou receber o comando “não se intrometam com os desenvolvedores, o trabalho deles é codificar” e então esperar que em um momento crítico tudo funcione como deveria. Não é assim que funciona.
Essencialmente, DevOps é uma competência na fronteira entre gestão e tecnologia. Além disso, está longe de ser óbvio que deva haver mais tecnologia do que gestão neste cocktail. Se você realmente deseja construir processos de desenvolvimento mais rápidos e eficientes, você deve confiar em sua equipe Devops. Ele conhece as ferramentas certas, implementou projetos semelhantes, sabe como fazê-lo. Ajude-o, ouça seus conselhos, não tente isolá-lo em algum tipo de unidade autônoma. Se os administradores puderem trabalhar por conta própria, então os devops serão inúteis nesse caso; eles não serão capazes de ajudá-lo a melhorar se você mesmo não quiser aceitar essa ajuda.
E uma última coisa: parem de ofender os administradores de infraestrutura. Eles têm uma frente de trabalho própria e extremamente importante. Sim, um administrador pode se tornar um engenheiro DevOps, mas isso deve acontecer a pedido da própria pessoa, e não sob pressão. E não há nada de errado com o fato de um administrador de sistema querer permanecer administrador de sistema - esta é sua profissão separada e seu direito. Se pretende passar por uma transformação profissional, nunca deve esquecer que terá de desenvolver não só competências tecnológicas, mas também de gestão. Muito provavelmente, caberá a você, como líder, reunir todas essas pessoas e ensiná-las a se comunicarem na mesma língua.
Fonte: habr.com