O que é DevOps e o que faz um profissional da área

DevOps, no sentido original, não é um cargo. É um jeito de trabalhar em que quem escreve o software e quem o mantém rodando deixam de jogar a responsabilidade um para o outro. O termo surgiu por volta de 2009, justamente para atacar o velho conflito: o time de desenvolvimento quer lançar novidades rápido, o time de operações quer que nada mude para nada cair, e o código fica semanas parado entre os dois.

Só que o mercado transformou a cultura em vaga. Hoje existem anúncios para “Engenheiro DevOps”, “SRE”, “Engenheiro de Plataforma” e “Cloud Engineer”, e o trabalho real muda bastante de uma empresa para outra. Por isso, a melhor forma de entender o que faz um profissional da área é olhar para situações concretas, e é o que este verbete do glossário de programação faz depois de passar pelo básico.

DevOps na prática: as cinco ideias que se repetem em todo lugar

Quase toda equipe que diz praticar DevOps trabalha em cima destas ideias:

• Automação de tudo que se repete: testes, build, deploy, criação de servidores. Se alguém faz à mão toda semana, é candidato a script.
• Entregas pequenas e frequentes: mudar 20 linhas por dia é mais seguro do que 5.000 linhas por mês, porque fica fácil descobrir o que quebrou.
• Infraestrutura como código: servidores, redes e bancos descritos em arquivos versionados (Terraform, Ansible, CloudFormation), revisados como qualquer código.
• Observabilidade: logs, métricas e alertas que mostram o que está acontecendo em produção antes que o cliente reclame.
• Responsabilidade compartilhada: quem escreveu o serviço também participa quando ele cai, e o pós-incidente busca a causa, não um culpado.

Para medir se isso está funcionando, muitas empresas usam as métricas do programa de pesquisa DORA: frequência de deploy, tempo entre o commit e a produção, taxa de mudanças que causam falha e tempo para recuperar o serviço. Elas aparecem em entrevista com frequência, então vale conhecer pelo nome.

As ferramentas que aparecem nas vagas, por camada

Ninguém domina tudo. Mas as ferramentas se agrupam por função, e entender as camadas ajuda a ler qualquer anúncio de vaga sem pânico.

A base que não muda de empresa para empresa é Linux, redes (DNS, HTTP, portas, TLS) e Git. O resto se aprende em cima disso. Quem pula a base e vai direto para Kubernetes costuma travar no primeiro problema de rede.

Numa startup de 15 pessoas, o DevOps é quase tudo ao mesmo tempo

Imagine uma fintech pequena com oito desenvolvedores e uma pessoa responsável pela infraestrutura. A semana dessa pessoa pode incluir: escrever o pipeline que roda os testes a cada pull request, ajustar o Terraform para criar um banco novo, configurar alertas porque o servidor ficou sem disco na madrugada, revisar custos da AWS que subiram 30% sem explicação e ajudar um dev a entender por que a aplicação funciona local e não no ambiente de homologação.

É um papel generalista. Aprende-se muito rápido, e também se apaga muito incêndio. Para um júnior, é ótimo se houver alguém mais experiente por perto; sem mentor, vira um lugar onde se aprende sozinho e na pressão.

Num banco ou grande varejista, a função vira especialidade

Em empresas grandes, “DevOps” se divide em times:

• Plataforma: constrói ferramentas internas para que os outros times façam deploy sozinhos (templates de pipeline, clusters prontos, portais de autoatendimento).
• SRE (Site Reliability Engineering): cuida da confiabilidade com metas numéricas de disponibilidade, plantão e pós-incidente. O conceito vem do Google, que publicou gratuitamente o livro Site Reliability Engineering, leitura obrigatória para quem quer seguir esse caminho.
• Cloud/FinOps: arquitetura de nuvem, contas, permissões e controle de custo.
• DevSecOps: segurança no pipeline, varredura de dependências e imagens, gestão de segredos.

Aqui o dia a dia é mais previsível, com processos de mudança, aprovações e documentação. O lado bom é a profundidade. O lado chato é que uma alteração simples pode levar dias para passar pelos ritos.

Para o dev júnior que nunca vai ter “DevOps” no crachá

Mesmo que você queira ser só desenvolvedor back-end ou front-end, a cultura DevOps vai te alcançar. Em times modernos, espera-se que o dev:

1. escreva testes que rodam no pipeline, e não só na máquina dele;
2. saiba ler o log do CI quando o build quebra;
3. entenda um Dockerfile o suficiente para rodar o projeto;
4. consiga olhar um painel de métricas e dizer se o deploy dele piorou alguma coisa;
5. participe do pós-incidente quando o serviço dele cair.

Nada disso exige virar especialista em infraestrutura. Mas quem sabe esses cinco pontos se destaca rápido em qualquer time, porque resolve sozinho problemas que travariam outros juniores por um dia inteiro.

Para quem quer migrar de suporte ou infraestrutura

Esse é, na prática, um dos caminhos mais comuns para chegar a uma vaga de DevOps. Quem já trabalhou com suporte, redes ou administração de servidores tem a parte operacional que falta a muitos desenvolvedores. O que costuma faltar é programação e automação.

Um roteiro realista para essa transição:

• Automatizar com shell script e Python as tarefas que hoje você faz à mão.
• Colocar esses scripts no Git e aprender a trabalhar com branches e pull requests.
• Subir uma aplicação simples em container e publicá-la numa nuvem com um pipeline de CI/CD.
• Descrever essa mesma infraestrutura em Terraform e destruir e recriar tudo com um comando.
• Estudar para uma certificação de nuvem de nível associado, que pesa bastante em processos seletivos de empresas maiores.

Quem vem da área acadêmica ou de concursos também encontra esses temas cobrados; o texto sobre temas de programação que mais pesam em concursos de TI mostra onde eles aparecem.

DevOps paga bem? O que pesa na contratação

As vagas da área costumam pagar acima da média de desenvolvimento no mesmo nível, mas raramente são de entrada. A maioria pede experiência anterior com desenvolvimento, suporte ou infraestrutura, porque o profissional mexe em produção e um comando errado derruba o sistema de todo mundo.

Em entrevista, contar como você investigou e resolveu um problema real em produção costuma pesar mais do que listar dez ferramentas no currículo.

Também pesa ter um projeto público com pipeline, infraestrutura em código e um README explicando as decisões. Mostra que você sabe as peças e, mais importante, como elas se encaixam.

Kubernetes primeiro é o atalho que mais atrasa

Começar por Kubernetes porque está em toda vaga é o tropeço mais comum. Sem saber o que é uma porta, por que um DNS demora a propagar ou como ler um log no terminal, o Kubernetes vira uma caixa preta cheia de YAML copiado. A partir de agora, inverta a ordem: Linux e redes primeiro, Git e um pipeline simples depois, containers em seguida e orquestração por último. É mais lento no começo e muito mais rápido no resto do caminho.