O que é necessário para o sucesso de uma empresa de TI em 2019? Os palestrantes em conferências e meetups falam muitas palavras sonoras, que nem sempre são compreensíveis para pessoas comuns. A luta pelo tempo de deploy, microsserviços, abandono do monólito, transformação DevOps e muito mais. Se deixarmos de lado a beleza das palavras e falarmos de forma direta, tudo se resume a uma simples tese: façam um produto de qualidade, e façam-no com conforto para a equipe.
Isso se tornou criticamente importante. Finalmente, os negócios perceberam que um processo de desenvolvimento confortável aumenta a produtividade, e se tudo estiver ajustado e funcionando como um relógio, ainda oferece um certo espaço para manobras em situações críticas. Em algum momento, para possibilitar essa manobra, uma pessoa inteligente inventou os backups, mas a indústria evolui, e chegamos aos engenheiros DevOps — pessoas que transformam o processo de interação entre desenvolvimento e infraestrutura externa em algo razoável e não relacionado ao xamanismo.
Toda essa história do 'por módulo' é maravilhosa, mas... Acontece que parte dos administradores foi repentinamente rotulada como DevOps, e dos próprios engenheiros DevOps começaram a exigir, no mínimo, habilidades de telepatia e clarividência.
Antes de falarmos sobre os problemas modernos de fornecimento de infraestrutura, vamos definir o que queremos dizer com esse termo. Até o momento, a situação se configurou de tal forma que chegamos à dualidade desse conceito: a infraestrutura pode ser, de forma condicional, externa e interna.
Por infraestrutura externa, devemos entender tudo o que garante o funcionamento do serviço ou produto, cuja criação é realizada pela equipe. Isso inclui servidores de aplicativos ou sites, para PrestaShop e outros serviços que garantem o funcionamento do produto.
A infraestrutura interna inclui serviços e equipamentos que a própria equipe de desenvolvimento e outros funcionários utilizam, que geralmente também não são poucos. Isso inclui servidores internos de sistemas de armazenamento de código, um gerenciador de tarefas implantado localmente e tudo mais que existe no âmbito da intranet corporativa.
O que faz um administrador de sistemas em uma empresa? Além de gerenciar a intranet corporativa, ele muitas vezes é responsável pelo funcionamento do equipamento de escritório. O administrador é o cara que rapidamente traz um novo servidor ou um laptop reserva pronto para uso, entrega um teclado novo e se arrasta pelo escritório conectando cabos Ethernet. O administrador é o senhor local não apenas dos sistemas internos e externos servidores, mas também das operações. Sim, alguns administradores podem trabalhar apenas na camada de sistema, sem lidar com hardware. Eles podem ser classificados como um subgrupo separado de "administradores de sistema de infraestrutura". Outros se especializam apenas na manutenção de equipamentos de escritório, e se a empresa tiver mais de cem funcionários, o trabalho nunca acaba. Mas nenhum deles se considera DevOps.
E quem são os DevOps? Os DevOps são pessoas que lidam com a interação entre o desenvolvimento de software e a infraestrutura externa. Na verdade, os DevOps modernos estão muito mais envolvidos nos processos de desenvolvimento e implantação do que os administradores que apenas faziam uploads de atualizações via FTP. Uma das principais tarefas de um engenheiro DevOps atualmente é garantir um processo confortável e eficaz de interação entre as equipes de desenvolvimento e a infraestrutura do produto. Essas pessoas são responsáveis pela implantação de sistemas de rollback e deploy, aliviando parte da carga dos desenvolvedores e focando em sua tarefa extremamente importante. Ao mesmo tempo, um DevOps nunca vai arrastar um novo cabo ou entregar um novo laptop do estoque (c) KO
Qual é a pegadinha?
Quando a pergunta "Quem é o DevOps?" é feita, metade dos trabalhadores da área começa a responder algo como "Bem, isso é um administrador, que..." e segue por aí. Sim, há muito tempo, quando a profissão de engenheiro DevOps estava começando a se formar a partir dos administradores mais talentosos no que diz respeito à manutenção de serviços, as diferenças entre eles não eram claras para todos. Mas agora, quando as funções de DevOps e de administrador em uma equipe se tornaram radicalmente diferentes, confundi-las ou até mesmo igualá-las é inaceitável.
Mas como isso se traduz para os negócios?
Contratação, esse é o ponto.
Você abre a vaga de "Administrador de Sistemas" e ali estão os requisitos como "interação com desenvolvimento e clientes", "sistema de entrega CI/CD", "manutenção de servidores e equipamentos da empresa", "administração de sistemas internos" e assim por diante; você entende que o contratante está falando alguma bobagem. O truque é que no lugar de "Administrador de Sistemas" deveria estar escrito "Engenheiro DevOps" no título da vaga, e se esse título for alterado, tudo volta ao seu lugar.
No entanto, que impressão é criada ao ler tal vaga? Que a empresa está buscando um faz-tudo, que resolverá tanto o sistema de controle de versões quanto a monitoração e ainda abrirá champanhe com os dentes...
E para evitar aumentar a confusão no mercado de trabalho, basta chamar as vagas pelo nome correto e compreender claramente que engenheiro DevOps e administrador de sistemas são duas entidades diferentes. Mas o desejo incessante de alguns empregadores de apresentar um conjunto cada vez mais amplo de requisitos leva os "clássicos" administradores de sistemas a não conseguirem entender o que está acontecendo ao seu redor. O que, a profissão está mudando e eles ficaram para trás?
Não, não e mais uma vez não. Os administradores de infraestrutura, que gerenciarão os servidores internos da empresa ou ocuparão posições de suporte L2/L3 auxiliando outros funcionários, não desapareceram e não têm intenção de ir a lugar algum.
E esses especialistas podem se tornar engenheiros DevOps? Claro que podem. Na verdade, é um ambiente relacionado que exige habilidades de administração de sistemas, mas além disso, requer trabalho com monitoramento, sistemas de entrega e, em geral, interação estreita com a equipe de desenvolvimento e testes.
Mais um problema do DevOps
Na verdade, a situação não se limita apenas à contratação e à confusão constante entre administradores e devops. Em algum momento, os negócios enfrentaram problemas com a entrega de atualizações e a interação da equipe de desenvolvimento com a infraestrutura final.
Talvez tenha sido quando em algum evento um tio com olhos brilhantes subiu ao palco e disse: 'E nós fazemos assim e chamamos de DevOps. Esses caras resolverão todos os seus problemas' — e começou a contar como a vida se tornou boa na empresa após a implementação das práticas do DevOps.
No entanto, não é suficiente contratar um engenheiro DevOps para que tudo comece a funcionar 'como deveria'. A empresa deve passar por uma transformação DevOps completa, ou seja, o papel e as capacidades do nosso devop devem ser claramente compreendidos também pela equipe de desenvolvimento e testes do produto. Temos uma 'maravilhosa' história sobre isso que ilustra completamente a dureza que às vezes ocorre.
Situação. Um DevOps é solicitado a implementar um sistema de reversão de versões, sem entender muito bem como ele funcionará. Suponha que, dentro do sistema Users, existem campos separados para nome, sobrenome e senha. Uma nova versão do produto é lançada, mas para os desenvolvedores, a "reversão" é apenas uma varinha mágica que conserta tudo, e eles nem imaginam como funciona. Então, por exemplo, os desenvolvedores em um patch recente uniram os campos de nome e sobrenome, lançaram isso em produção, e a versão está lenta por algum motivo. O que acontece? A gerência vai até o DevOps e diz "Puxe a alavanca!", ou seja, pede para ele reverter para a versão anterior. O que faz o DevOps? Ele reverte para a versão anterior, mas como os desenvolvedores não se preocuparam em entender como essa reversão é feita, ninguém disse ao DevOps que também era necessário reverter o banco de dados. No final, tudo para de funcionar, e os usuários, em vez de ver um site lento, encontram um erro "500", porque a versão antiga não funciona com os campos do novo banco de dados. O DevOps não está ciente disso. Os desenvolvedores ficam em silêncio. A gerência começa a perder a paciência e o dinheiro e se lembra dos backups, sugerindo reverter a partir deles, para que "pelo menos algo funcione". Como resultado, os usuários perdem todos os seus dados por um determinado período.
Claro que o DevOps acaba sendo responsabilizado, pois "não fez o sistema de reversão correto", enquanto os "bodes expiatórios" dessa história são os desenvolvedores, mas ninguém se importa.
A conclusão é simples: sem uma abordagem adequada ao DevOps, o seu valor é bem limitado.
O principal a lembrar é: um engenheiro DevOps não é um mágico, e sem comunicação de qualidade e interação bidirecional com os desenvolvedores, ele não conseguirá cumprir suas tarefas. Não se pode deixar os DevOps sozinhos com seus "problemas" ou dar a eles a ordem de "não se intrometer nos desenvolvedores, o trabalho deles é codificar", e depois esperar que, em um momento crítico, tudo funcione como deveria. Assim não funciona.
Na essência, DevOps são competências na interseção entre gestão e tecnologias. E, de fato, não é óbvio que nesta mistura de tecnologias deveria haver mais do que gestão. Se você realmente deseja construir processos de desenvolvimento mais rápidos e eficientes, deve confiar em seu DevOps. Ele conhece as ferramentas necessárias, já implementou projetos semelhantes, sabe como fazer. Ajude-o, ouça seus conselhos, não tente isolá-lo em uma unidade autônoma. Se os administradores podem trabalhar sozinhos, os DevOps se tornam inúteis nesse caso, pois não poderão ajudá-lo a melhorar se você não quiser aceitar essa ajuda.
E, por último: pare de menosprezar os administradores de infraestrutura. Eles têm uma frente de trabalho própria, extremamente importante. Sim, um administrador pode se tornar um engenheiro DevOps, mas isso deve ocorrer por vontade própria, e não forçado. E não há nada de errado em um administrador de sistemas querer continuar sendo um administrador de sistemas — essa é uma profissão distinta e seu direito. Se houver o desejo de passar por uma transformação profissional, deve-se lembrar que será necessário desenvolver não apenas habilidades tecnológicas, mas também gerenciais. Provavelmente, será você, como líder, a responsável por reunir todas essas pessoas e ensiná-las a se comunicar na mesma língua.
Fonte: habr.com
