Engenheiro DevOps Perguntas de Entrevista & Respostas

Resposta modelo

O cluster primário do banco de dados falhou durante o horário de pico por causa de um problema de espaço em disco que nosso monitoramento não detectou. O failover em si funcionou, mas a réplica estava 30 segundos atrasada, causando algumas inconsistências de dados visíveis para os usuários. Assumi a resposta ao incidente: isolei o problema em 10 minutos, coordenei com a equipe de engenharia para identificar os usuários afetados em 20 minutos e enviamos uma comunicação para os clientes dentro de 45 minutos. O tempo total de inatividade foi de 8 minutos. No post-mortem, implementei três mudanças: adicionei monitoramento de espaço em disco com alertas ao atingir 80% de uso, criei um runbook para cenários de failover de banco de dados e configurei testes semanais de chaos engineering para nossos mecanismos de failover. Também migramos para replicação síncrona nas tabelas críticas. Nos 12 meses seguintes, não tivemos nenhum failover de banco de dados não planejado.

Resposta modelo

A equipe de desenvolvimento fazia deploys manuais via SSH e resistia à automação porque 'precisamos ter controle'. Em vez de impor a mudança, parti do problema deles. Mapeei que os deploys manuais levavam em média 45 minutos, tinham uma taxa de falha de 15% e sempre aconteciam nas sextas-feiras às 17h. Construí um pipeline CI/CD que replicava exatamente seus passos manuais, rodei em paralelo por 2 semanas e mostrei que os deploys automatizados levavam 3 minutos com uma taxa de falha de 1%. Deixei o desenvolvedor mais cético executar o primeiro deploy automatizado em produção. Quando funcionou perfeitamente, ele se tornou o maior defensor do pipeline. Em um mês, a equipe estava fazendo 3 deploys diários em vez de um por semana. A chave foi fazer a mudança parecer segura, não forçar conformidade.

Resposta modelo

Fiz uma auditoria dos nossos gastos na AWS e descobri que estávamos pagando $28K mensais por recursos que rodavam 24/7, mas eram necessários apenas durante o horário comercial (ambientes de desenvolvimento, clusters de staging, processamento em lote). Implementei um sistema de agendamento automatizado com AWS Lambda e CloudWatch Events que reduzia os ambientes não produtivos a zero durante a noite e nos fins de semana. Também redimensionei as instâncias de produção usando 3 meses de métricas do CloudWatch. Estávamos rodando instâncias m5.2xlarge que nunca ultrapassavam 30% de CPU. A migração para m5.large com autoscaling economizou mais $8K mensais. Movi dados do S3 acessados com pouca frequência para o Glacier, economizando mais $3K mensais. Total economizado: $18K mensais ($216K anuais) sem nenhum impacto no desempenho. Configurei um painel de revisão mensal de custos que virou prática padrão da equipe.

Resposta modelo

Os desenvolvedores gastavam em média 90 minutos configurando o ambiente de desenvolvimento local, e a divergência de configurações causava bugs do tipo 'funciona na minha máquina' toda semana. Containerizei toda a stack de desenvolvimento com Docker Compose: banco de dados, fila de mensagens, cache e todos os microsserviços. Escrevi um único comando 'make dev' que baixava as imagens mais recentes, populava o banco de dados e iniciava todos os serviços. O tempo de configuração caiu de 90 minutos para 5 minutos. Também construí um sistema de pre-commit hooks que rodava linting, verificação de tipos e testes unitários localmente, capturando 80% das falhas de CI antes do push. As pontuações de satisfação dos desenvolvedores em 'ferramentas e infraestrutura' subiram de 2.8 para 4.3 em uma escala de 5. A conclusão principal: a produtividade dos desenvolvedores é um problema de infraestrutura.

Resposta modelo

VMs virtualizam o hardware: cada VM executa seu próprio kernel de SO, gerenciado por um hipervisor. Containers virtualizam o SO: compartilham o kernel do host e isolam no nível de processo usando namespaces e cgroups. Containers são mais leves (MB vs GB), iniciam mais rápido (segundos vs minutos) e cabem em maior densidade no host. Escolho containers para microsserviços, aplicações sem estado e qualquer coisa que precise de escalonamento rápido. Escolho VMs quando preciso de isolamento total do SO (ambientes multi-tenant com requisitos rígidos de segurança), preciso rodar sistemas operacionais diferentes no mesmo host ou estou executando softwares que exigem modificações no kernel. Na prática, a maioria das cargas de trabalho modernas é containerizada. Aplicações legadas, certos requisitos de conformidade (ambientes PCI-DSS que exigem isolamento em nível de VM) e cargas de trabalho Windows podem ainda ser mais adequadas para VMs.

Resposta modelo

Construiria em camadas. O loop interno (por serviço): cada microsserviço tem seu próprio pipeline disparado por commits no seu diretório. Ele executa linting, testes unitários, constrói uma imagem de container com uma tag baseada no conteúdo (git SHA), envia para um registry e faz deploy em um ambiente de desenvolvimento. A camada de integração: depois que um serviço passa em seus próprios testes, os testes de integração rodam em um ambiente de staging compartilhado com todos os serviços. Usaria contract testing (Pact) para detectar problemas de compatibilidade entre serviços sem precisar de todos rodando. A camada de deploy: usaria GitOps com ArgoCD, onde o merge na branch de deploy atualiza um repositório de manifests e o ArgoCD sincroniza o estado do cluster. Rollbacks são um git revert. Para segurança: deploys canary com rollback automático baseado em limiares de taxa de erro, janelas de deploy com bloqueios automáticos durante períodos de alto tráfego e uma aprovação manual para produção nos primeiros meses até que a confiança esteja estabelecida.

Resposta modelo

Infraestrutura como código significa definir sua infraestrutura (servidores, redes, bancos de dados, load balancers) em arquivos de configuração declarativos, em vez de clicar em consoles ou executar scripts ad-hoc. Ferramentas como Terraform, CloudFormation e Pulumi viabilizam isso. A importância está em três pontos. Primeiro, reprodutibilidade: consigo criar um ambiente idêntico em qualquer região executando o mesmo código. Sem mais 'acreditamos que o staging corresponde à produção'. Segundo, controle de versão: as mudanças de infraestrutura passam pelo mesmo processo de revisão de código, aprovação e trilha de auditoria que o código da aplicação. Posso ver quem mudou o quê, quando e por quê, e reverter se necessário. Terceiro, automação: as mudanças de infraestrutura podem ser testadas, validadas e aplicadas por pipelines CI/CD, eliminando erros manuais. Na prática, uso Terraform com estado remoto no S3, bloqueio de estado com DynamoDB e módulos para componentes reutilizáveis. Toda mudança de infraestrutura passa por um pull request com a saída do terraform plan para revisão.

Resposta modelo

Sigo os três pilares: métricas, logs e traces. Métricas (Prometheus + Grafana) me dão a saúde agregada do sistema: CPU, memória, taxa de requisições, taxa de erros e percentis de latência. Configuro alertas em sintomas (alta taxa de erro, latência elevada), não em causas (alta CPU), porque os sintomas indicam que os usuários estão sendo impactados. Logs (ELK ou Loki) fornecem contexto detalhado dos eventos para depuração. Exijo logs estruturados (JSON) com IDs de correlação para que eu possa rastrear uma requisição por todos os serviços. Traces (Jaeger ou Tempo) mostram o caminho completo de uma requisição pelo sistema, revelando qual serviço está lento e por quê. Além dos três pilares, crio dashboards no nível de negócio: pedidos por minuto, cadastros por hora, taxa de sucesso de pagamentos. Esses são os primeiros que verifico durante um incidente, porque respondem à pergunta 'os usuários estão sendo afetados?' antes de mergulhar nas métricas de infraestrutura. Também implemento SLOs com error budgets, o que transforma o monitoramento de 'algo está quebrado?' em 'estamos cumprindo nossos compromissos de confiabilidade?'

Resposta modelo

Curto prazo: ativaria o Kubernetes Cluster Autoscaler para adicionar nós automaticamente quando os pods não conseguem ser agendados. Verificaria se o node pool tem espaço para escalar e se as políticas do autoscaler fazem sentido (escalar para cima rápido, escalar para baixo devagar). Também checaria se os recursos existentes estão superalocados. É comum pods solicitarem o dobro dos recursos que realmente usam. O redimensionamento das solicitações de recursos com base nas métricas reais de uso poderia liberar de 30 a 40% de capacidade sem adicionar nós. Médio prazo: implementaria o Horizontal Pod Autoscaler (HPA) em todas as cargas de trabalho com metas adequadas de CPU/memória e consideraria o Vertical Pod Autoscaler (VPA) para cargas com padrões imprevisíveis de recursos. Também moveria cargas em lote para instâncias spot/preemptíveis. Longo prazo: analisaria os padrões de tráfego e implementaria escalonamento preditivo. Se sabemos que os horários de pico são das 9h às 11h, pré-escalamos 15 minutos antes, em vez de reagir à demanda. Avaliaria também se algumas cargas deveriam migrar para serverless (Lambda/Cloud Run) para eliminar completamente o planejamento de capacidade.

Resposta modelo

Primeiro, resolveria o problema imediato: reverter a mudança de configuração e restaurar o serviço. Depois conduziria um post-mortem sem atribuição de culpa, com foco no sistema que permitiu isso, não na pessoa que fez a mudança. Minhas medidas preventivas: primeiro, todas as mudanças de configuração passam pelo mesmo pipeline CI/CD que o código: pull request, revisão, validação automática e rollout gradual. Sem pushes diretos para config de produção. Segundo, implementar validação de configuração no pipeline: verificação de schema, aplicação em modo dry-run e testes de integração em ambiente de staging. Terceiro, rollout progressivo para mudanças de configuração: aplicar em 5% das instâncias, monitorar a taxa de erros por 10 minutos, depois avançar para 25%, 50%, 100%. Quarto, gatilhos de rollback automático: se a taxa de erros ultrapassar a linha de base em 2x dentro de 5 minutos de uma mudança de configuração, reverter automaticamente. O objetivo é fazer o caminho seguro ser o caminho fácil: deve ser mais difícil enviar configuração diretamente do que passar pelo pipeline.

Resposta modelo

Nunca faria uma reescrita completa de uma vez. Isso falha de forma consistente. Em vez disso, usaria o padrão strangler fig: extrair serviços incrementalmente enquanto o monolito continua atendendo o tráfego. Passo 1: identificar os limites dos serviços usando design orientado a domínio. Mapear os domínios do monolito, a propriedade dos dados e as dependências. Começar pelo serviço menos acoplado e de maior valor para extrair. Passo 2: construir o novo serviço paralelamente ao monolito, roteando o tráfego para ele por meio de um API gateway. O monolito e o novo serviço inicialmente compartilham o banco de dados. Passo 3: uma vez que o serviço está estável, migrar seus dados para seu próprio banco de dados e remover a dependência do banco compartilhado. Passo 4: repetir para o próximo serviço. Espero que a migração completa leve de 12 a 18 meses para um monolito de médio porte. Princípios-chave: cada serviço extraído deve ser implantável e testável de forma independente, o sistema deve funcionar no estado híbrido (alguns serviços extraídos, outros ainda no monolito) e eu adicionaria monitoramento abrangente na fronteira entre o antigo e o novo para detectar problemas de integração precocemente.

Resposta modelo

Avaliaria com base em quatro fatores, não em preferência pessoal. Primeiro, experiência existente: o que a equipe já conhece? As curvas de aprendizado em nuvem são íngremes, e o custo de produtividade da mudança é real. Se a equipe tem 3 anos de experiência com AWS, a nova plataforma precisa oferecer uma vantagem convincente para justificar o tempo de adaptação. Segundo, requisitos de serviços específicos: o projeto precisa de um serviço que uma nuvem faz significativamente melhor? GCP para ML (Vertex AI), Azure para integração empresarial (Active Directory), AWS para o catálogo de serviços mais amplo. Terceiro, modelo de precificação: estimaria os custos usando a calculadora de cada nuvem para o nosso padrão de carga específico. Instâncias reservadas, preços spot e custos de egresso variam significativamente. Quarto, contexto organizacional: acordos com fornecedores, requisitos de conformidade e infraestrutura existente. Se a empresa já tem um Enterprise Agreement com a AWS, usar GCP adiciona complexidade de aquisição. Apresentaria uma recomendação com uma matriz de decisão clara, não apenas minha preferência pessoal.