DevOps é cargo ou cultura? O que ninguém conta para quem quer entrar na área

A conversa que todo mundo já teve

“DevOps não é cargo, é cultura.”

Você já ouviu essa frase. Provavelmente mais de uma vez.

E quase sempre ela vem acompanhada de um certo ar de superioridade. Como se quem usa o termo “cargo DevOps” estivesse cometendo um erro conceitual grave.

Mas aí você abre o LinkedIn.

E encontra:

• DevOps Pleno
• DevOps Sênior
• DevOps Specialist
• Lead DevOps

E aí? Todo mundo está errado? Ou a realidade do mercado simplesmente ignorou a pureza conceitual?

Recentemente, alguém levantou essa dúvida:

“Vejo com maus olhos quem usa/oferece cargo de DevOps?”

E a resposta mais sensata foi:

“Particularmente não vejo com maus olhos. DevOps na origem é cultura… mas o mercado abraçou o termo para funções que trabalham com CI/CD, automação, cloud, IaC, observabilidade.”

Foi uma batalha perdida.

E quem quer entrar na área precisa entender isso não para escolher um lado, mas para não cair em ciladas.

A origem que quase ninguém viveu

DevOps surgiu lá por 2009.

Era uma reação a um problema real:

Dev jogava o código pro outro lado do muro. Ops sofria pra colocar no ar. Os dois times mal se falavam.

A proposta era cultural:

• Colaboração
• Responsabilidade compartilhada
• Fim dos silos

Ninguém criou uma certificação “DevOps Certified”. Ninguém desenhou um organograma com “Diretor de DevOps”.

Era um movimento.

Mas aí o mercado fez o que o mercado sempre faz:

Transformou uma ideia em um rótulo.

Porque é mais fácil contratar um “cargo” do que transformar uma “cultura”.

O problema não é o cargo é o que ele esconde

Ter uma vaga de “DevOps” não é inerentemente errado.

O problema acontece quando a empresa:

• Acha que contratar um DevOps resolve todos os problemas de entrega
• Coloca a pessoa pra fazer tudo sozinha: infra, pipeline, deploy, monitoramento, suporte
• Continua tendo silos, só que agora o “DevOps” é o novo silo

Nesse caso, o nome é enganoso.

Mas se a empresa:

• Já tem uma cultura colaborativa
• Precisa de alguém com foco em automação, cloud e pipelines
• Chama essa pessoa de DevOps por falta de um termo melhor…

Não é o fim do mundo.

O pecado não é usar o nome. É acreditar que o nome resolve o que só a cultura consegue.

Os dois lados da mesma moeda

DevOps como cultura (a origem)

• O que importa: colaboração, feedback rápido, melhoria contínua
• Quem faz: todo mundo dev, ops, segurança, produto
• Medida de sucesso: time entrega com menos atrito
• Exemplo: dev ajuda a melhorar o monitoramento; ops ajuda a entender por que o deploy quebrou

DevOps como cargo (a realidade de mercado)

• O que importa: pipelines, Kubernetes, Terraform, cloud, observabilidade
• Quem faz: uma pessoa (ou time) especializada
• Medida de sucesso: infraestrutura estável, deploy automatizado
• Exemplo: a pessoa cuida da plataforma para os devs não precisarem se preocupar com isso

Os dois mundos coexistem.

E quem quer entrar na área precisa entender os dois.

Para quem quer entrar: o que você precisa saber de verdade

1. O título não define o trabalho

Uma vaga de “DevOps” em uma empresa pequena pode significar:

“Você vai fazer de tudo desde dar deploy até responder ticket de suporte.”

Já em uma empresa grande:

“Você vai cuidar exclusivamente de pipelines e monitoramento, sem nunca tocar em produção.”

O nome é só um convite para a conversa.

O que importa é o que está na descrição.

2. Pergunte o que a empresa entende por DevOps

Na entrevista, faça essa pergunta:

“O que significa DevOps aqui na prática? Como é o dia a dia?”

Se a pessoa recruiter piscar e der uma resposta genérica… é um sinal amarelo.

Se ela descrever responsabilidades concretas (cloud, CI/CD, infra-as-code, observabilidade), você sabe o que esperar.

3. As habilidades que importam (começando do zero)

Se você quer entrar na área seja com cargo de DevOps ou não o caminho é parecido:

Fundamentos que não mudam:

• Linux (saber se virar no terminal)
• Redes (IP, DNS, porta, firewall… o básico)
• Shell script (automação simples)

O que o mercado cobra de verdade:

• Containers (Docker)
• Orquestração (Kubernetes pelo menos o básico)
• Infraestrutura como código (Terraform é o mais comum)
• CI/CD (GitHub Actions, GitLab CI entenda o conceito, não só a ferramenta)
• Nuvem (uma das três: AWS, Azure ou GCP)

O diferencial: programação Python ou Go. Não precisa ser expert. Mas saber automatizar, ler código e fazer integrações simples. (Se quiser se aprofundar, tem um post específico sobre isso.)

4. Evite a armadilha do “faz-tudo”

Muitas empresas jogam tudo nas costas do profissional de DevOps:

• Infraestrutura
• Deploy
• Monitoramento
• Segurança
• Suporte noturno
• Documentação
• Atendimento a dev

E aí você vira o gargalo humano.

O segredo não é fazer tudo sozinho. É automatizar e ensinar o time a se virar.

Se você virar o único que “entende de Kubernetes”, vai continuar sendo acordado de madrugada para sempre.

A analogia que talvez ajude

Pense em um time de futebol.

Cultura devops = todo mundo corre, marca, ataca. Não importa a posição. Se o lateral ataca, alguém cobre. Se o atacante volta pra marcar, ninguém reclama. É um time vivo.

Cargo devops = o técnico contrata um “faz-tudo”. Esse cara corre por dois, marca, ataca, pega pênalti. Enquanto ele estiver em campo, funciona. Mas se ele cansar? Se sair do time? O esquema desmorona.

O ideal? Um time que entende a cultura e tem especialistas.

O mercado, porém, muitas vezes quer só o “faz-tudo”.

Você precisa saber em qual time está entrando.

A batalha conceitual foi perdida e tudo bem

O Ruan Oliveira resumiu bem:

“O meio sabe que é cultura, mas quem contrata quer alguém para preencher essa lacuna. Esse nome [DevOps] é o mais forte e aceitável encontrado.”

Foi uma batalha perdida.

Mas isso não significa que o conceito original morreu.

Significa que você, como profissional, precisa sair na frente:

• Saber o que é a cultura DevOps de verdade
• Entender o que o mercado chama de “cargo DevOps”
• E navegar entre os dois sem se frustrar

Você pode trabalhar em um cargo de DevOps e promover a cultura.

Pode ser o especialista técnico e o cara que ensina, documenta, compartilha.

Aliás, tem um post aqui sobre documentação que encaixa direitinho nisso.

Pra fechar: o que realmente importa no começo

Se você está começando e quer entrar nesse mundo:

1. Não brigue pela pureza conceitual. O mercado usa “DevOps” como cargo. Aceite que é assim mas saiba o que está por trás.
2. Estude os fundamentos. Linux, redes, script, containers, IaC, CI/CD. Isso não muda.
3. Aprenda a programar o mínimo. Você não precisa ser dev, mas precisa automatizar tarefas repetitivas e ler código.
4. Pergunte antes de aceitar a vaga. “O que significa DevOps aqui?” é a pergunta mais importante da entrevista.
5. Mire na cultura, não só no cargo. O profissional que entende colaboração, feedback e melhoria contínua vale mais do que quem só sabe Kubernetes.

No fim:

“DevOps não é cargo” é uma verdade teórica. “DevOps virou cargo” é uma verdade de mercado.

Você precisa saber as duas.

E agir com sabedoria entre elas.

E aí?

Na sua opinião (ou na sua experiência)…

Vale a pena “brigar” pelo conceito original? Ou o que importa é entregar resultado, independente do nome?

E se você está querendo entrar na área, qual desses dois mundos te atrai mais?

Se quiser se aprofundar, tem um curso rápido de CI/CD que ajuda a entender a parte conceitual sem firula.

Porque cultura é importante. Mas saber fazer pipeline também.