Perguntas de entrevista DevOps

Qual é a diferença entre continuous integration, delivery e deployment?

Continuous integration significa que cada commit é integrado e verificado por um build e testes automatizados, então a branch nunca se afasta muito da main. Continuous delivery significa que todo build que passa gera um artefato pronto para ir para produção, ficando o push final como uma decisão humana. Continuous deployment remove essa decisão — todo build verde vai para produção. Essa distinção importa em entrevistas porque a maioria dos times que dizem praticar CD, na prática, praticam delivery.

Como funcionam as camadas do Docker, e como você mantém uma imagem pequena?

Cada instrução cria uma camada somente leitura, e as camadas ficam em cache e são reaproveitadas enquanto tudo antes delas não mudar — por isso você copia o manifesto de dependências e instala as dependências antes de copiar o código-fonte. O tamanho cai com builds multi-stage que deixam o compilador para trás, uma imagem base slim ou distroless, e combinando comandos para que arquivos intermediários nunca cheguem a virar uma camada. Apagar um arquivo em uma camada posterior não diminui a imagem, porque a camada anterior ainda o contém.

Explique a relação entre um Pod, um Deployment e um Service.

Um Pod é a menor unidade agendável — um ou mais containers compartilhando um namespace de rede e um ciclo de vida. Um Deployment gerencia um ReplicaSet que mantém um número declarado de Pods idênticos rodando e cuida das atualizações rolling e dos rollbacks. Um Service dá a esse conjunto variável de Pods um IP virtual e um nome DNS estáveis, balanceando carga entre os Pods que atualmente batem com seu selector, de forma que quem chama nunca precisa rastrear IPs de Pods individuais.

Qual é a diferença entre um liveness probe e um readiness probe?

Um readiness probe decide se um Pod recebe tráfego; falhar nele remove o Pod dos endpoints do Service, mas o deixa rodando. Um liveness probe decide se o container é reiniciado. Confundir os dois é uma causa clássica de queda: apontar o liveness para uma dependência faz com que um banco de dados lento reinicie todas as réplicas ao mesmo tempo, transformando um serviço degradado em indisponibilidade total. O liveness deveria testar só "esse processo travou", o readiness deveria testar "eu consigo atender agora".

O que é o state do Terraform e por que ele é perigoso?

O state mapeia os recursos declarados na sua configuração para os objetos reais no provider, para que o Terraform saiba o que criar, alterar ou destruir. Ele é perigoso porque é a fonte da verdade: se for perdido, o Terraform deixa de saber que é dono da sua infraestrutura e vai tentar recriá-la. Também costuma conter segredos em texto puro. Por isso o state deve ficar em um backend remoto com criptografia, versionamento e locking, para que dois engenheiros não apliquem ao mesmo tempo.

Quando usar Terraform em vez de Ansible?

Terraform é provisionamento declarativo: ele cria e destrói infraestrutura e converge o mundo real para o state declarado. Ansible é gerenciamento de configuração procedural: ele executa tarefas ordenadas em máquinas que já existem. A divisão limpa é Terraform para tudo que tem ciclo de vida em uma API de nuvem, Ansible para o que acontece dentro de uma VM. Em uma stack baseada em Kubernetes, o papel do Ansible encolhe bastante, porque as imagens de container substituem a configuração de máquinas.

O que são SLI, SLO e error budget?

Um SLI é um indicador medido da saúde do serviço, como a fração de requisições atendidas com sucesso em menos de 300 ms. Um SLO é a meta para esse indicador em uma janela de tempo, por exemplo 99,9% em 30 dias. O error budget é a margem de falha permitida — os tais 0,1% de requisições — e ele transforma confiabilidade em um recurso que se pode gastar: se o budget está intacto, você pode lançar mais rápido, e se ele se esgota, você congela features e conserta a confiabilidade. É isso que impede que "confiabilidade versus velocidade" vire uma discussão de opinião.

Qual é a diferença entre métricas, logs e traces?

Métricas são agregados numéricos baratos ao longo do tempo e respondem "algo está errado" — é nelas que você configura alertas. Logs são eventos discretos com detalhe e respondem "o que exatamente aconteceu" em uma requisição ou componente. Traces seguem uma única requisição por vários serviços e respondem "para onde foi o tempo" em uma cadeia de chamadas distribuída. Alertar em cima de logs é caro e barulhento; depurar só com métricas é chute. Você precisa dos três, cada um usado para o que faz de melhor.

Compare os deployments rolling, blue-green e canary.

O rolling substitui instâncias aos poucos, precisa de pouca capacidade extra, mas durante a troca duas versões atendem tráfego ao mesmo tempo e o rollback é lento. O blue-green mantém um segundo ambiente completo e troca o tráfego de uma vez, dando rollback instantâneo ao custo de capacidade dobrada e um problema difícil de migração de banco de dados. O canary manda uma pequena fatia do tráfego para a nova versão e observa métricas antes de ampliar, o que pega problemas que atingem usuários reais, mas só compensa com observabilidade sólida e análise automatizada.

Como os segredos devem ser tratados em um pipeline?

Segredos nunca ficam no repositório, em camadas de imagem, ou em variáveis de ambiente simples embutidas no momento do build. Eles vêm de um cofre dedicado — Vault, um secret manager de nuvem, ou os segredos criptografados do provedor de CI — e são injetados em runtime com o escopo mais estreito e a vida mais curta que for viável. Credenciais de curta duração emitidas via federação OIDC são melhores que chaves de longa duração, porque o risco principal não é o roubo do segredo, e sim um segredo que continua válido por anos.

Um Pod está em CrashLoopBackOff. Descreva seu diagnóstico.

Comece com kubectl describe pod para ver os eventos — falhas de pull de imagem, montagens que falharam, OOMKilled ou um probe falhando aparecem todos ali. Depois kubectl logs com --previous, porque o container atual pode ser novo demais para ter registrado algo útil. Verifique se o exit code sugere OOM, e nesse caso compare o limite de memória com o uso real. Se o container inicia e morre na hora, as causas mais comuns são um config ou secret faltando, uma migration falhando no start, ou um liveness probe com delay inicial curto demais.

O que torna um postmortem útil em vez de apenas cerimonial?

Um postmortem útil não busca culpados, então as pessoas descrevem o que realmente fizeram em vez do que parece mais defensável, e ele foca nas condições que permitiram que um erro virasse uma queda. Ele registra uma linha do tempo precisa, separa o gatilho da causa raiz, e produz um número pequeno de action items com dono e prazo, em vez de uma lista de desejos. O teste é se o documento permitiria a um engenheiro novo entender a falha um ano depois, e se os follow-ups realmente são feitos.