O que uma pessoa DevOps realmente faz (e o que as vagas pedem em 2026)

1. O que é DevOps, em uma frase

DevOps é a responsabilidade de encurtar e tornar seguro o caminho entre uma ideia escrita em código e o valor rodando em produção. Não é um programa que se instala nem um cargo mágico entre desenvolvimento e infraestrutura: é um conjunto de práticas (automação, versionamento, testes, observabilidade) sustentado por ferramentas.

Uma comparação ajuda: se a aplicação é o produto, o DevOps monta e opera a linha de produção que leva esse produto até a prateleira — várias vezes por dia, sem quebrar a prateleira.

2. O caminho de uma mudança (o fluxo que você vai automatizar)

Todo o curso gira em torno destas etapas. Leia devagar, porque cada módulo à frente aprofunda uma delas:

• Código — alguém escreve a mudança e faz commit em um repositório Git.
• Integração (CI) — um servidor baixa o código, instala dependências, roda testes e verifica segurança.
• Empacotamento — o resultado vira um artefato imutável: uma imagem de container com versão.
• Publicação (registry) — a imagem é enviada para um repositório de imagens.
• Infraestrutura — servidores, rede, banco e balanceador existem porque foram descritos em código (Terraform).
• Entrega (CD) — a versão nova sobe em ambiente de teste e depois em produção, de forma gradual e reversível.
• Operação — métricas, logs e traces mostram se está saudável; alertas avisam antes do cliente reclamar.
• Melhoria — incidentes geram aprendizado documentado e automação nova.

3. Como se mede se esse fluxo é bom (métricas DORA)

O mercado usa quatro indicadores. Guarde-os, porque aparecem em entrevista:

• Frequência de deploy: com que frequência você entrega. Times maduros entregam várias vezes por dia.
• Lead time para mudança: quanto tempo passa entre o commit e a mudança em produção.
• Taxa de falha de mudança: quantos deploys causam problema.
• Tempo de restauração: quanto tempo leva para voltar ao normal depois de uma falha.

Tudo que você vai aprender existe para melhorar um desses quatro números. Quando você automatiza um pipeline, está atacando lead time; quando cria um alerta com base em SLO, está atacando tempo de restauração.

4. Cargos vizinhos: quem faz o quê

Os nomes variam por empresa, mas a divisão costuma ser esta:

• DevOps Engineer — pipelines, containers, infraestrutura como código, automação de entrega.
• SRE (Site Reliability Engineer) — confiabilidade medida: SLI, SLO, orçamento de erro, plantão, postmortem.
• Platform Engineer — constrói a plataforma interna (Kubernetes, templates, catálogos) para que os times de produto entreguem sozinhos.
• Cloud Engineer — foco em provedor de nuvem: rede, identidade, contas, custo.
• DevSecOps — segurança dentro do pipeline: scanners, segredos, cadeia de suprimentos, permissões.

O núcleo técnico é quase o mesmo. A diferença está na ênfase, e é isso que você identifica lendo a vaga.

5. O núcleo que praticamente toda vaga pede

Analisando anúncios atuais em português e inglês, o conjunto repetido é estável:

• Linux (permissões, processos, systemd, logs) e rede/HTTP (DNS, TLS, portas, proxy).
• Git com fluxo de branches e revisão de código.
• Containers (Docker) e orquestração (Kubernetes).
• Uma nuvem — AWS lidera as vagas, Azure e GCP aparecem em seguida.
• CI/CD — GitHub Actions e GitLab CI dominam.
• Infraestrutura como código — Terraform, com Ansible para configuração.
• Observabilidade — Prometheus, Grafana, OpenTelemetry, Loki.
• Scripting — Bash sempre, Python com frequência.
• Segurança e custo — menor privilégio, gestão de segredos, controle de gasto.

6. Como ler uma vaga sem se intimidar

Anúncios são lista de desejos, não requisitos absolutos. Faça esta triagem, sempre por escrito:

• Separe obrigatório (aparece no título, na primeira frase e repetido) de desejável (aparece em "diferencial", "plus", "nice to have").
• Conte quantas ferramentas são do mesmo grupo: cinco nomes de observabilidade significam "entenda observabilidade", não "domine cinco produtos".
• Identifique o problema da empresa: vaga que fala de plantão e SLO busca estabilidade; vaga que fala de esteira e onboarding busca velocidade.
• Traduza cada requisito em uma pergunta de prova: "o que eu mostraria em tela para provar isso?".

7. Como é uma semana real na função

Para desfazer a fantasia: a maior parte do tempo não é criar coisa nova. Uma semana típica mistura

• manutenção de pipelines que quebraram por dependência, versão ou credencial expirada;
• revisão de código de infraestrutura de colegas;
• ajuste de limites de CPU/memória e custo;
• atendimento a dúvidas de times de produto ("meu deploy não subiu");
• investigação de um alerta ou incidente;
• e um bloco de trabalho de melhoria: automatizar algo que hoje é manual.

Quem vem do desenvolvimento tem vantagem real: já entende build, dependências, variáveis de ambiente e o que a aplicação precisa para rodar.

8. O método de estudo que funciona: conceito → artefato → registro

Estudar DevOps lendo documentação solta não gera competência. O ciclo correto tem três passos, e você vai repeti-lo em cada aula:

1. Conceito: entenda o problema que a ferramenta resolve antes do comando.
2. Artefato: aplique no seu projeto e deixe um arquivo versionado (Dockerfile, workflow, módulo Terraform, manifest, dashboard).
3. Registro: escreva no diário técnico o que fez, o erro que apareceu e como resolveu.

Ao final do curso o registro vale tanto quanto o código: é dele que saem as respostas de entrevista e o texto do seu portfólio.

9. O projeto que atravessa o curso: CloudShop

Todas as aulas usam o mesmo sistema fictício, o CloudShop: um catálogo de produtos com frontend em Vue, API em Node e banco PostgreSQL. Por que um único projeto? Porque a dificuldade real não é rodar um comando, é integrar as partes.

A evolução é esta: rodar local → containerizar → pipeline de testes e imagem → infraestrutura na AWS com Terraform → migrar para Kubernetes → entrega automática por GitOps → observabilidade com métricas, logs, traces e SLO → revisão de custo e segurança.

10. Do zero ao ninja: o que provar em cada etapa

• Iniciante: opera Linux com confiança, usa Git corretamente, sobe a aplicação em container.
• Intermediário: escreve pipeline com testes e publicação de imagem, provisiona infraestrutura em código, entende rede da nuvem.
• Avançado: opera Kubernetes com probes, limites e Ingress, faz entrega por GitOps, instrumenta observabilidade.
• Ninja: define SLO, conduz incidente e postmortem, reduz custo com dados, fecha brechas de segurança e explica cada decisão com trade-off.

A diferença entre os níveis não é quantidade de ferramentas: é a qualidade da justificativa por trás das escolhas.

11. Erros que mais atrasam quem começa

• Começar por Kubernetes sem Linux, rede e containers — resulta em copiar YAML sem entender por que o Pod não sobe.
• Colecionar cursos sem produzir artefato; sem repositório, não há prova.
• Trocar de ferramenta a cada semana em vez de aprofundar em uma stack.
• Ignorar custo e segurança, que são justamente os assuntos que aparecem na entrevista final.
• Não anotar erros: você resolverá o mesmo problema três vezes.

12. O que você deve conseguir fazer antes de seguir

Antes da próxima aula, deixe pronto: uma frase sua explicando o que DevOps entrega; a leitura de três vagas reais com obrigatório e desejável separados; e a primeira entrada do diário técnico no repositório de documentação. Se conseguir explicar em voz alta o caminho do commit até produção, está pronto para montar o ambiente.