Get best of the week

Profissão DevOps-engineer: uma visão do administrador do sistema



Trabalho como engenheiro de DevOps na Parallels. Apoio o desenvolvimento de vários serviços, escrevo scripts para sua implantação automática, comunico-me de perto com a equipe de desenvolvimento. Vou lhe dizer como o trabalho é organizado, quanto eles pagam e para que serve a abordagem do DevOps no desenvolvimento de software.

Tudo começou com o fato de tornar-se chato para mim trabalhar como administrador de sistemas. Eu queria algo novo. Tentei desenvolver o 1C, mas rapidamente percebi que isso não era meu. Ele aprendeu Python, aprimorou suas habilidades em sistemas Unix e foi fazer uma entrevista no Parallels. Então eu não sabia quase nada sobre DevOps, apenas vim e disse: quero trabalhar para você. Dois meses depois, eles me levaram.

O que é o DevOps?


Se você perguntar a 5 pessoas o que é o DevOps, você obtém 5 respostas diferentes. Para os evangelistas, isso é uma cultura, ou mesmo uma transformação de pensamento. Para os engenheiros, um conjunto de soluções e ferramentas. Para os gerentes, uma metodologia. Para recrutadores - uma profissão. E para todos os outros, provavelmente é apenas uma palavra da moda.

A verdade, como sempre, está em algum lugar no meio. O DevOps é todo o acima, juntos. Sua principal tarefa é acelerar a entrega do produto das empresas para o consumidor. O termo em si foi cunhado pelo consultor independente de TI Patrick Debois cerca de doze anos atrás. Ele queria derrubar a barreira metafórica entre desenvolvedores (dev) e sysadmins (ops), combiná-los em uma unidade eficaz, que pode criar software mais rapidamente, lançar versões com mais frequência e com menos erros.

Portanto, no coração do DevOps está a idéia de responsabilidade compartilhada, não há divisão de poderes. O programador pode participar da configuração se souber como escrever a configuração de seu serviço e o administrador do sistema em desenvolvimento. Quando surge um problema, ele não é transferido de um funcionário para outro, como uma bola de pingue-pongue, mas se torna comum. Todo mundo está envolvido em sua eliminação.



Um minuto de estatísticas chatas. De acordo com a pesquisa DORA (DevOps Research and Assessment), as equipes multifuncionais que usam a abordagem DevOps:

  • 208 vezes mais frequentemente implanta código;
  • 106 vezes reduz o tempo de confirmação para implantação;
  • Restaurar sistemas 2.604 vezes mais rápido após falhas;
  • 7 vezes menor a chance de falha em si como resultado de alterações.

Obviamente, combinar sozinho dev e ops não leva a essa eficiência. A abordagem do DevOps inclui o uso de muitas novas ferramentas de desenvolvimento, teste e implantação para organizar o CI \ CD (o conceito de integração e entrega contínuas). Entre os mais famosos:

  • Git e GitHub - sistemas de gerenciamento de código fonte;
  • Jenkins - um servidor de automação para a criação de pipelines de CI / CD;
  • Docker - software para automatizar a implantação e o gerenciamento de aplicativos em ambientes com suporte à conteinerização;
  • Kubernetes - um sistema de orquestração de contêiner aberto;
  • Chef, Puppet e Ansible - ferramentas para configuração e implantação automáticas;
  • Selênio - solução de automação de teste;
  • Prometheus e Nagios - software de monitoramento de servidores;
  • Grafana é uma solução para coletar e analisar métricas.

Ao mesmo tempo, não existe um conjunto universal de ferramentas adequadas para todos os negócios, nem existe um único caminho para o DevOps. Existe apenas o que funciona ou, inversamente, não funciona em sua infraestrutura. Frequento regularmente conferências e vários eventos, comunico-me com colegas de outras empresas e posso dizer que 80% das coisas que eles usam no Parallels não são particularmente aplicáveis.

Cada organização tem seu próprio produto, sua própria pilha de tecnologia e seus gargalos. Portanto, a abordagem para otimização é muito diferente. Às vezes, é necessário alterar a arquitetura dos serviços, alguns são tão complexos ou inflexíveis que é difícil transferir a abordagem do DevOps para eles.

A essência do engenheiro do DevOps


Em um nível básico, um engenheiro do DevOps é um especialista técnico que entende todos os principais estágios do ciclo de vida de desenvolvimento de software, corrige gargalos nos processos e ajusta o ambiente:

  • Grava código para implantação automatizada de aplicativos
  • parcialmente responsável por sua disponibilidade, não pessoalmente como administrador do sistema, mas com sua equipe;
  • exerce um dever em sua infraestrutura (entende erros, às vezes junto com um programador).

Automação é o que recai sobre os ombros de um engenheiro de DevOps em primeiro lugar. A criação de um produto de TI com a abordagem tradicional é a seguinte: o programador escreve seu código, o compila em algum formato e o entrega ao administrador do sistema. Ele vai ao servidor, instala e configura tudo com as mãos. Ao mesmo tempo, eles estão lutando por coisas diferentes: o administrador do sistema - pela estabilidade, o programador - por suas mudanças, o que, é claro, complica o trabalho de cada um deles.

No DevOps, isso funciona de maneira um pouco diferente. O aplicativo é implantado usando scripts. O engenheiro do DevOps define uma certa sequência de ações que leva o código escrito pelo programador, primeiro para o servidor de teste e depois para o servidor de batalha (se for decidido que as alterações podem ser liberadas). Assim, o desenvolvedor tem a oportunidade de verificar seu código pelo menos a cada 15 minutos e fazê-lo mesmo às três da manhã com um simples clique de um botão.

Responsabilidades específicas, bem como habilidades necessárias, são altamente dependentes do local de trabalho. Em Parallels, temos grande parte de nossa infraestrutura, as partes mais críticas não estão nas nuvens públicas, mas em nossos próprios servidores físicos em vários data centers. E, às vezes, há grandes atualizações sobre hardware e software nesses servidores, e a migração é necessária periodicamente.

Este também é o meu trabalho.


Eu tento automatizar tudo ao máximo para que o processo seja menos doloroso. Na última vez, na estrutura de teste de backups cruzados e tolerância a falhas de infraestrutura, foi possível transferir serviços dos EUA para a Suíça em 10 minutos e atualizar tudo o que era necessário ao longo do caminho. Para a tecnologia moderna, é claro que isso não é uma conquista enorme. Mas para nós - um grande passo em frente.

O legado também é um desafio definido para os engenheiros de DevOps. Mesmo em empresas com fluxos de trabalho bem construídos, existem serviços que foram gravados por um longo período de tempo e ninguém se lembra totalmente de como foram configurados, porque isso era feito com frequência manualmente e as pessoas que trabalhavam neles não trabalham mais na organização. Se este é um serviço importante, muita pesquisa é realizada - você precisa descobrir o mínimo possível de como funciona, escrever código para implantação, cobri-lo com monitoramento e métricas.

Vale a pena fazer isso, mesmo que o código do aplicativo não mude muito ativamente. Por que, se tudo funciona assim? Para poder reproduzi-lo em caso de falha, instale atualizações de segurança, encontre e corrija problemas que talvez ninguém saiba. Recentemente, acabei de escrever scripts para esse serviço com uma longa história. Foram necessárias alterações em seu código, o trabalho ainda não foi concluído, mas o progresso é grande. É muito interessante coletar uma imagem completa do aplicativo a partir de peças díspares; é bom ver o resultado posteriormente.

E, é claro, a implementação da abordagem DevOps está intimamente relacionada à medição. Quanto mudou o tempo de resposta? Com que frequência ocorrem os erros pretendidos? Antes, um administrador de sistema geralmente não fazia ideia de como medir essas coisas. As aplicações eram caixas pretas, restavam apenas as características mais básicas: carga do processador, consumo de memória, tráfego. E quando a nova versão foi implantada, nem o administrador do sistema nem o programador puderam determinar rapidamente que tudo não estava exatamente como planejado. Faltava esperar ligações furiosas para o suporte técnico.

Com a abordagem do DevOps, isso é coisa do passado. Você pode configurar a coleção de métricas reais de aplicativos, compará-las com o consumo de recursos e, por isso, é melhor e mais rápido encontrar problemas, otimizar, melhorar a qualidade dos produtos e não apenas o tempo de atividade do servidor.

Quanto os engenheiros do DevOps ganham?


O salário de um engenheiro do DevOps depende de habilidades, local de trabalho e região de residência. O salário de um especialista que trabalha em Moscou é o mais alto da Rússia, de 130 a 350 mil rublos por mês. As empresas de São Petersburgo oferecem de 100 a 300 mil rublos nessa posição. Em outras regiões do nosso país, eles estão prontos para pagar de 70 a 120 mil rublos.

A renda média anual nos Estados Unidos, como dizem alguns RHs, varia de 100 a 125 mil dólares, segundo dados divulgados pela Puppet. Na Austrália e Nova Zelândia - 75-100 mil dólares. Na Europa - 50-75 mil dólares. Na Ásia, os engenheiros de DevOps não recebem mais de 25 mil dólares por ano.

More articles:


All Articles