Post

DevOps precisa saber programar? A resposta que os roadmaps não mostram

DevOps precisa saber programar? A resposta que os roadmaps não mostram

O dilema dos roadmaps versus a realidade do mercado

Se você já estudou DevOps ou SRE, provavelmente já se deparou com aqueles roadmaps clássicos: Linux no centro, containers orbitando, uma nuvem gigantesca cobrindo tudo, pipelines de CI/CD cortando o diagrama, segurança formando uma muralha ao redor e monitoramento fechando o ciclo.

Eles são visualmente bonitos, organizados e passam uma sensação de completude. Dão a impressão de que, seguindo aquele caminho, você estará “pronto para o mercado”.

Mas então você abre uma vaga real de DevOps Pleno e encontra algo como:

Requisitos: Python (Databricks), Node.js, NestJS, MongoDB, PostgreSQL, SQL, Kafka, Kubernetes, Java.

E aí surge a pergunta inevitável:

“Solicitar linguagens de programação para uma vaga DevOps faz sentido?”

Afinal, se você olhar apenas para os roadmaps mais populares, linguagens de programação quase nunca aparecem como protagonistas.

É justamente nessa diferença entre o mapa teórico e a realidade prática do mercado que mora a discussão mais honesta sobre o que significa ser DevOps hoje.


DevOps que não sabe programar precisa tirar o “Dev” do nome?

Recentemente, em uma discussão sobre o tema, alguém soltou a frase:

“DevOps que não sabe programar precisa tirar o Dev do nome do cargo.”

A frase é dura. Provocativa. E, para muita gente, ofensiva.

Mas ela não surge do nada. Ela nasce de uma frustração real entre expectativa e entrega.

A pergunta correta não é se a frase é educada, mas sim: em que contextos ela faz sentido?

Vamos destrinchar isso com calma.


O que as empresas realmente querem quando contratam DevOps?

Existem empresas que precisam, majoritariamente, de alguém para:

  • Gerenciar cloud
  • Configurar serviços
  • Manter clusters funcionando
  • Garantir disponibilidade e segurança
  • Monitorar ambientes

Nesses casos, o papel se aproxima mais de um engenheiro de soluções cloud ou infra tradicional moderna. Existe automação, claro mas geralmente o código já existe. Você executa, ajusta, mantém.

Agora, existe outro cenário cada vez mais comum.

Empresas que querem alguém que:

  • Automatize fluxos complexos
  • Construa pipelines inteligentes
  • Crie ferramentas internas
  • Desenvolva plataformas para outros times
  • Melhore a experiência do desenvolvedor

Nesse cenário, não saber programar vira um gargalo real.

Perceba o ponto central:

Não é uma discussão de “sabe ou não sabe programar”. É uma discussão de para qual problema você está sendo contratado.


Os dois mundos do DevOps

Para simplificar, podemos pensar em dois extremos. A maioria das pessoas está em algum ponto entre eles.

Mundo 1: O Gerenciador de Infraestrutura

  • Foco: Cloud, containers, orquestração, redes, segurança
  • Código: Shell Script, YAML, pequenos scripts em Python
  • Mentalidade:

    “A infraestrutura precisa estar disponível, segura e escalável”

  • Roadmap típico: Linux, Docker, Kubernetes, CI/CD, Cloud, Observabilidade

Aqui, programação é uma ferramenta auxiliar, não o núcleo do trabalho.

Mundo 2: O Facilitador do Ciclo de Desenvolvimento

  • Foco: Automação de pipelines, plataformas internas, DX
  • Código: Python, Go, Node.js, Java
  • Mentalidade:

    “Como posso reduzir o atrito entre ideia e produção?”

  • Roadmap real: Infra + linguagens + arquitetura + mensageria + APIs

Aqui, programação é parte central do trabalho.

A grande maioria dos DevOps modernos vive entre esses dois mundos. E quanto mais você se aproxima do segundo, mais programação deixa de ser opcional.


A visão do Vale do Silício (e o que quase ninguém explica)

Muita gente comenta:

“Sigo pessoas da gringa, do Vale do Silício, e os roadmaps deles falam só de Linux, containers, cloud, CI/CD e segurança. Nunca falam de linguagem de programação.”

Essa observação é excelente. E ela revela algo fundamental:

O que é “básico” depende do contexto

Em empresas como Google, Netflix, Amazon, Airbnb:

  1. Saber programar é pressuposto Não é diferencial, é ponto de partida.
  2. Infraestrutura é código Terraform, Pulumi, Crossplane, CloudFormation tudo versionado, testado e revisado.
  3. Plataforma é produto Times de DevOps/Platform constroem ferramentas que outros desenvolvedores usam diariamente.
  4. A escala exige software, não scripts Shell scripts não escalam sozinhos. Sistemas, sim.

Por isso eles não colocam “Python” ou “Go” nos roadmaps. Seria redundante.

É como um curso avançado de pilotagem que não menciona que você precisa saber dirigir. Isso já foi resolvido antes.


Afinal, o que um DevOps precisa saber de programação?

Um modelo prático por níveis

Nível 1 Sobrevivência (obrigatório)

Todo DevOps deveria saber:

  • Shell Script (Bash) Automações simples, cron jobs, scripts de deploy
  • Python básico Scripts, APIs simples, automação, logs
  • Leitura de código Entender aplicações em Node.js, Java ou Python quando algo quebra

Esse nível evita que você fique refém de outras pessoas.

Nível 2 Eficiência (diferencial real)

Aqui você começa a ganhar produtividade:

  • Python intermediário
  • Infraestrutura como Código (Terraform, Pulumi)
  • Noções de Go ou Node.js
  • Integrações entre sistemas
  • Automação mais robusta

Você deixa de “apagar incêndios” e começa a eliminar causas.

Nível 3 Plataforma (estratégico)

Nesse nível, você atua como engenheiro de plataforma:

  • Desenvolvimento de ferramentas internas
  • Design de APIs
  • Arquitetura de software
  • Mensageria (Kafka, RabbitMQ)
  • Bancos de dados
  • Dashboards e portais internos

Aqui, você não “dá suporte”. Você cria produtos internos.


O ponto que quase ninguém fala: o legado também é seu problema

Se a empresa tem:

  • Um sistema de deploy em Java 8
  • Um orquestrador em Node.js
  • Um pipeline crítico em Python mal documentado

E isso roda produção…

Alguém vai ter que manter.

Esse alguém costuma ser o DevOps.

Infraestrutura não existe isolada. Ela serve ao software. E software é código.


Quando programação deixa de ser técnica e vira estratégia

DevOps como construtor de plataformas

Empresas maduras param de ver DevOps como “quem cuida dos servidores” e passam a ver como:

Quem fornece a plataforma de desenvolvimento

E plataforma é produto.

Produtos precisam de:

  • Experiência de uso (DX)
  • Documentação
  • APIs bem desenhadas
  • Feedback
  • Evolução contínua

Nada disso se constrói só com YAML.

A analogia da casa (adaptada)

  • Dev desenha os cômodos
  • QA vive a casa antes de todo mundo
  • DevOps constrói a infraestrutura inteira

Só que hoje a casa é feita de código.

E quem constrói casas de código precisa entender:

  • Como os dados fluem
  • Como as requisições chegam
  • Onde a estrutura aguenta ou quebra

Como evoluir sem surtar

Se você é do “Mundo 1” e quer ir para o “Mundo 2”

  1. Comece por Python
  2. Entenda uma aplicação real da sua empresa
  3. Automatize algo chato
  4. Contribua com pequenos códigos
  5. Estude IaC de verdade, não só copiar módulo

Se você é dev e quer migrar para DevOps

  1. Linux e redes no nível sysadmin
  2. Containers e Kubernetes
  3. Cloud como operador, não só usuário
  4. Segurança básica (IAM, certificados, SSH)

No fim, os dois caminhos convergem.


Conclusão: DevOps precisa saber programar?

A resposta honesta é: depende do impacto que você quer gerar.

  • Infra tradicional → scripting resolve
  • Startups e scale-ups → programação importa
  • Plataformas e big tech → você é um desenvolvedor de infraestrutura

Os roadmaps não mostram isso porque:

  1. Alguns assumem conhecimento prévio
  2. Outros simplificam demais
  3. Nenhum consegue capturar toda a realidade do mercado

No fim:

DevOps não é cargo. É mentalidade.

E essa mentalidade, aplicada com código, cria sistemas que não apenas funcionam — mas fazem times inteiros performarem melhor.

Então, voltando à pergunta inicial:

“Solicitar linguagens de programação para uma vaga DevOps faz sentido?”

Faz. Quando a empresa quer alguém que resolva problemas com código, e não apenas com configuração.

E você? De que lado dessa ponte quer estar?

Esta postagem está licenciada sob CC BY 4.0 pelo autor.