Day in the Life of a Cloud Engineer

Você quer saber como é de fato o dia de um Cloud Engineer, sem a versão de recrutamento. A resposta curta: é menos nuvem brilhante e mais controle de incêndio, reunião e documentação. Vou descrever o dia real de um profissional de nível pleno, com os detalhes que ninguém conta na entrevista.

Vou usar um exemplo fictício de um Cloud Engineer pleno em uma empresa de médio porte, com cerca de 200 pessoas, e uma infraestrutura majoritariamente na AWS. Nada aqui é estatística oficial, é o padrão que aparece com frequência em relatos de profissionais da área.

O dia começa antes do código#

Entre 8h30 e 9h, o primeiro movimento é olhar alertas e mensagens. Slack, painel de monitoramento, fila de tickets. A pergunta é simples: algo pegou fogo de madrugada?

Se estiver tudo quieto, o café entra em cena. Se não estiver, o plano do dia já era.

Muita gente imagina que o trabalho começa abrindo um terminal e escrevendo Terraform. Na prática, as primeiras 30 ou 40 minutos são leitura: o que aconteceu, o que está pendente, o que foi aprovado.

Reuniões versus trabalho profundo#

O split varia muito por empresa, mas um dia comum de nível pleno costuma ser algo assim:

• 2 a 3 horas de reuniões ou alinhamentos
• 3 a 4 horas de trabalho profundo, código, revisão, documentação
• 1 hora de tarefas curtas, mensagens, tickets, revisões rápidas

As reuniões não são todas inúteis. As que fazem sentido são as de alinhamento com o time de desenvolvimento, as de planejamento de mudanças em infraestrutura e as de revisão de arquitetura. As que consomem tempo sem retorno são as de status que poderiam ser uma mensagem.

O trabalho profundo costuma acontecer entre 10h e 12h e depois do almoço. É quando saem os módulos de infraestrutura, os ajustes em pipelines e a documentação que ninguém vê mas todo mundo precisa.

Ferramentas que realmente aparecem#

A lista real é mais curta do que os anúncios de vaga sugerem.

• Terraform, ou Pulumi, ou CloudFormation, dependendo da empresa
• AWS, Azure ou GCP, raramente os três ao mesmo tempo
• Git, GitHub ou GitLab, para versionar tudo
• CI/CD, Jenkins, GitHub Actions ou GitLab CI
• Docker e Kubernetes, quando a empresa usa containers
• Monitoramento, Datadog, Prometheus com Grafana, ou CloudWatch
• Slack e algum sistema de tickets, Jira ou similar

O que surpreende é quanto tempo vai em YAML e em configuração, e não em código novo. Também é comum passar horas em política de permissão, papel de IAM, regra de firewall. Trabalho chato. Necessário.

Um exemplo de tarefa real#

Vamos a um caso concreto. Seu time precisa que uma aplicação publique logs em um bucket de armazenamento, com retenção de 90 dias e acesso restrito.

O pedido chega assim: "precisamos de logs da app no S3, com retenção de 90 dias".

Seu trabalho é transformar isso em infraestrutura. O trecho de Terraform pode começar assim:

resource "aws_s3_bucket" "app_logs" {
  bucket = "empresa-app-logs"
}

resource "aws_s3_bucket_lifecycle_configuration" "app_logs" {
  bucket = aws_s3_bucket.app_logs.id

  rule {
    id     = "expirar-90-dias"
    status = "Enabled"

    expiration {
      days = 90
    }
  }
}

Depois vem a parte que ninguém vê: política de acesso, criptografia, versionamento, e a revisão de alguém do time antes do merge. A tarefa de "criar um bucket" na verdade tem umas 40 linhas de configuração e duas discussões sobre permissão.

Pontos de pressão#

Os momentos de maior pressão são previsíveis.

Primeiro: incidente em produção. Quando um serviço cai ou um custo dispara, a prioridade muda na hora. O plano do dia morre, e você entra em modo de contenção.

Segundo: mudança em infraestrutura. Alterar rede, política de acesso ou configuração de cluster dá medo, porque o erro afeta muita gente ao mesmo tempo. Por isso existe revisão de pull request e janela de mudança.

Terceiro: cobrança de custo. Nuvem tem fatura, e alguém eventualmente pergunta por que o valor subiu. Quem administra infraestrutura acaba investigando.

O que surpreende os recém-chegados#

A maior surpresa é a quantidade de comunicação. Cloud Engineer não é um trabalho solitário de terminal. Você conversa com desenvolvedores, com segurança, com quem cuida de rede, com quem paga a conta.

Outra surpresa: documentação. Um bom profissional da área escreve muito. Runbooks, decisões de arquitetura, passos de recuperação. Sem isso, o próximo incidente vira caos.

E tem o fato de que a maior parte do trabalho é manter o que já existe. Evolução e criação de coisas novas existem, mas são menos da metade do tempo na maioria dos relatos.

Como o papel muda do júnior para o sênior#

No início, você executa tarefas bem definidas. Cria recursos seguindo padrões que já existem, corrige configuração, responde tickets. A autonomia é pequena, e isso é normal.

No nível pleno, você já define como resolver um problema dentro de um escopo, revisa o trabalho de outras pessoas e participa das decisões do time. É onde a maior parte do aprendizado acontece.

No sênior, o trabalho muda de natureza. Você projeta sistemas, antecipa risco, negoca com outras áreas e desbloqueia outras pessoas. Escreve menos código do que imagina. Participa de mais conversas difíceis, sobre prazo, custo, risco técnico.

A progressão não é automática nem por tempo de casa. Depende do que você demonstra que consegue resolver.

Checklist para quem está entrando#

Se você quer migrar para essa área, o caminho mais curto é prático.

• Aprenda uma nuvem só, e aprenda a fundo, AWS ou Azure
• Estude Terraform e versione tudo o que criar em um repositório
• Entenda rede básica, DNS, VPC, sub-rede, firewall, proxy
• Pratique Linux e o terminal, sem depender de interface gráfica
• Monte um projeto pessoal com infraestrutura criada por código
• Leia sobre custo em nuvem, porque isso aparece em qualquer entrevista
• Treine explicar decisões técnicas para quem não é técnico

Ninguém espera que você saiba tudo. Espera que você saiba investigar, documentar e não quebrar produção por descuido.

Vale a pena?#

Depende do que você tolera. Se você gosta de resolver problemas ambíguos, de aprender sozinho e de assumir responsabilidade quando algo quebra, é uma boa carreira. Se você quer trabalho previsível, com escopo fechado e sem plantão, essa área vai te irritar.

A remuneração varia bastante por país, empresa e nível. No Brasil, faixas relatadas para nível pleno costumam ficar entre R$ 6.000 e R$ 12.000 por mês, com ampla variação, e para sênior os valores sobem bastante em empresas maiores. Confira sempre as fontes oficiais e os dados mais recentes antes de negociar.

Para explorar mais sobre carreira em tecnologia, tem conteúdo no nosso blog de carreira. E se você já está buscando posição, dá uma olhada nas vagas de tecnologia disponíveis.

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#

Quanto tempo por dia é reunião versus trabalho técnico?

Em times de médio porte, a divisão mais comum é algo entre 30% e 40% de reunião e alinhamento, e o resto em execução, revisão e documentação. Isso varia por empresa, por fase do projeto e por nível de senioridade.

Preciso saber as três grandes nuvens para conseguir vaga?

Não. Quase sempre é melhor saber uma nuvem a fundo do que três por cima. O que recrutador procura é profundidade em uma delas, e a capacidade de aprender outra quando necessário.

Cloud Engineer faz plantão?

Em muitas empresas, sim, especialmente em times de plataforma ou infraestrutura crítica. Pergunte sobre o regime de sobreaviso na entrevista, porque isso pesa muito na qualidade de vida.

Qual a diferença entre Cloud Engineer e DevOps?

Os nomes se sobrepõem bastante, e a descrição muda de empresa para empresa. De forma geral, DevOps tem mais foco em entrega e automação de pipeline, e Cloud Engineer mais foco em infraestrutura e serviços de nuvem, mas os dois papéis costumam dividir as mesmas tarefas.

Como montar um portfólio sem experiência formal?

Crie um projeto de infraestrutura por código, com repositório público, documentação e um diagrama simples. Mostre que você sabe versionar, revisar e explicar o que criou, isso vale mais do que uma lista de certificados.