Portfolio Projects for DevOps Engineer

Você tem três certificados, um LinkedIn atualizado e nenhuma resposta. O problema quase nunca é a certificação em si, é a falta de evidência de que você sabe executar. Certificado prova que você estudou. Projeto prova que você construiu, quebrou, investigou e consertou.

Recrutadores técnicos e engenheiros seniores que revisam candidatos junior e pleno olham para o portfólio antes de olhar para a lista de cursos. Não porque odeiem certificações, mas porque todo candidato tem. Projetos são o único jeito de diferenciar dez currículos parecidos.

Este texto cobre três projetos que realmente impressionam, o que os revisores procuram em cada um, como apresentar no currículo e no GitHub, os erros que fazem um projeto parecer tutorial, e como falar sobre eles na entrevista.

O que os revisores procuram em um projeto de DevOps#

Antes dos projetos, vale entender o filtro. Quem revisa portfólio de DevOps não procura tecnologia da moda. Procura três sinais.

O primeiro é tomada de decisão. Por que Kubernetes e não ECS? Por que Terraform e não CloudFormation? Um projeto que explica suas escolhas e suas alternativas rejeitadas vale mais que um com mais serviços.

O segundo é operação. O que acontece quando algo quebra? Tem log? Tem alerta? Tem rollback? DevOps é manter sistemas vivos, não apenas provisioná-los.

O terceiro é repetibilidade. Outra pessoa consegue rodar seu projeto seguindo o README? Se não consegue, o projeto não está pronto.

Projeto 1: pipeline de CI/CD com deploy controlado e rollback#

Todo mundo faz um pipeline que faz build e deploy. Pouca gente faz um pipeline que trata falha como caso normal.

A ideia: uma aplicação simples, mas sua, com pipeline que roda teste, build de imagem, push para registro, scan de vulnerabilidades, deploy em staging, aprovação manual, deploy em produção, e rollback automático se o health check falhar.

O que torna esse projeto interessante não é a lista de ferramentas. É o tratamento de falha. Configure um teste que falha de propósito em um branch e mostre o pipeline bloqueando. Configure um deploy que quebra o health check e mostre o rollback disparando sozinho. Documente isso com prints ou logs.

Exemplo de bullet para o currículo

Antes: "Criei pipeline de CI/CD com GitHub Actions e Docker."

Depois: "Construí pipeline de CI/CD em GitHub Actions com build de imagem Docker, scan de vulnerabilidades e deploy em staging e produção. Implementei rollback automático baseado em health check, reduzindo o tempo de recuperação de deploy com falha de cerca de 20 minutos para menos de 2."

A segunda versão mostra resultado e mecanismo. Não precisa de número exato se você não tem, pode dizer "de forma automatizada" e explicar o processo.

Projeto 2: infraestrutura como código com ambiente efêmero de preview#

Provisionar um servidor com Terraform é o básico esperado. O diferencial é mostrar que você pensa em ambientes e em ciclo de vida.

A ideia: todo o ambiente definido em Terraform ou OpenTofu, com módulos reutilizáveis, state remoto com lock, e um fluxo onde cada pull request cria um ambiente temporário de preview que é destruído quando o PR fecha. Mostre também um plano de custo estimado antes do apply.

Esse projeto demonstra gestão de state, isolamento de ambientes, e consciência de custo, três dores reais de qualquer time de infraestrutura.

O que documentar

• Como o state é armazenado e protegido contra escrita concorrente
• O que acontece se o apply falhar no meio do caminho
• Como variáveis sensíveis são injetadas sem aparecer no repositório
• Quanto custa manter o ambiente de preview ligado por uma hora

Se você usa AWS, a conta gratuita cobre bastante, mas não cobre tudo para sempre. Avise no README quais recursos geram custo e como destruí-los.

Projeto 3: observabilidade de uma aplicação que você mesmo quebrou#

Deploy sem observabilidade é torcida. Esse projeto mostra que você entende a parte mais odiada e mais valorizada de DevOps: descobrir por que algo está lento ou fora do ar.

A ideia: suba sua aplicação com métricas, logs estruturados e traces. Use Prometheus e Grafana, ou a stack ELK, ou OpenTelemetry com algum backend. Depois, injete falhas de propósito: latência artificial, memory leak, erro 500 intermitente. Documente como cada falha aparece nos painéis e nos alertas.

O que os revisores querem ver é o raciocínio: qual métrica disparou primeiro, qual painel você abriu, qual log confirmou a hipótese. Escreva um post curto no README com três incidentes simulados e a investigação de cada um.

Como apresentar no GitHub#

Um repositório bonito não é suficiente, mas um repositório bagunçado derruba bons projetos.

• README com o problema que o projeto resolve, arquitetura em diagrama simples, e instruções de execução do zero
• Print ou GIF do resultado final funcionando, não só código
• Seção de decisões explicando por que escolheu cada ferramenta e o que rejeitou
• Seção de limites e próximos passos, porque projeto que parece terminado parece pequeno
• Commits com mensagens que contam uma história, não "fix" e "update" repetidos
• Tags de releases ou branches organizadas se o projeto tem versões

Não deixe credenciais, tokens ou chaves de acesso no repositório, nem em commits antigos. Isso derruba candidato na hora.

Erros que fazem projeto parecer tutorial#

O erro mais comum é copiar um tutorial passo a passo e subir o código igual. Revisor técnico reconhece tutorial em dois minutos, pelo mesmo README, mesmos nomes de variáveis, mesma arquitetura genérica.

Outros erros frequentes:

• Só provisionar, nunca operar. Sem log, sem alerta, sem plano de falha
• Empilhar dez tecnologias sem explicar nenhuma. Menos ferramentas, mais profundidade
• Não dizer o que o projeto resolve. "Projeto de estudo de Kubernetes" não diz nada
• Deixar TODOs eternos e README incompleto
• Não mostrar resultado. Print de terminal com output conta mais que descrição
• Inventar números de impacto. Se você não mediu, não escreva percentual

Um projeto pequeno e completo bate um projeto grande e abandonado. Três projetos fechados valem mais que dez pela metade.

Como falar sobre os projetos na entrevista#

Quando perguntarem "me conte sobre um projeto seu", não descreva a arquitetura primeiro. Conte o problema, a decisão que tomou, o que quebrou e o que aprendeu.

Exemplo de resposta

"Montei um pipeline de CI/CD para uma aplicação em container. O ponto que mais me deu trabalho foi o rollback. Meu primeiro deploy falhou e o ambiente ficou inconsistente porque o health check só validava a porta aberta, não a resposta da aplicação. Ajustei o health check para validar um endpoint real e coloquei rollback automático disparado por falha nesse check. Aprendi que health check de porta é quase sempre insuficiente."

Essa resposta mostra técnica, humildade e aprendizado. É muito mais forte do que listar ferramentas por dois minutos.

Prepare também uma resposta para "o que você faria diferente hoje". Quem revisa candidato sênior adora essa pergunta, e ter resposta honesta mostra maturidade.

Onde encontrar vagas e referências#

Para ver quais projetos e habilidades as vagas de DevOps estão pedindo de verdade, dá uma olhada nas vagas de DevOps e infraestrutura disponíveis. Também vale conferir o decodificador de descrições de vaga para entender o que cada anúncio realmente exige antes de montar seu portfólio. E se quiser testar se seu currículo passa por filtros automáticos, use a ferramenta gratuita de verificação de ATS.

Mais conteúdo sobre carreira em tecnologia e construção de portfólio está no blog do jobrise.

Ferramentas grátis#

• jobrise.io/pt/free-ats-checker/
• jobrise.io/pt/free-jd-decoder/
• jobrise.io/pt/jobs/
• jobrise.io/pt/blog/

Perguntas frequentes#

Preciso ter domínio de nuvem para esses projetos?

Não necessariamente. Dá para fazer os três projetos com máquinas locais, Docker e minikube, e isso já demonstra competência. Se quiser nuvem, a camada gratuita da AWS, GCP ou Azure cobre a maior parte do que você precisa, mas confira os limites atuais no site oficial antes de subir qualquer coisa.

Quanto tempo leva para fazer um projeto assim?

Depende da sua base. Um pipeline de CI/CD funcional leva de um fim de semana a duas semanas trabalhando fora do horário. O projeto de observabilidade costuma ser o mais demorado porque exige injetar falhas e documentar a investigação. Prefira um projeto por mês a três ao mesmo tempo.

Posso usar projeto de curso como portfólio?

Pode, desde que você mude bastante coisa. Troque a aplicação, mude as decisões de arquitetura, adicione tratamento de falha e escreva seu próprio README. Se ficar igual ao material do curso, o revisor percebe e o projeto perde valor.

Preciso publicar tudo em repositório público?

Não. Você pode deixar o código privado e mostrar prints, diagramas e explicação do processo no currículo ou em conversa. O que não pode é não ter nada para mostrar. Se publicar, revise antes se não há credenciais ou dados sensíveis.

Certificados de AWS, Kubernetes ou Terraform ainda valem a pena?

Valem, principalmente em processos que pedem certificação como requisito. Mas sozinhos não sustentam candidatura. O caminho que funciona é certificação mais projeto que demonstre aplicação prática, e os dois aparecendo no currículo.