Entrevistas de DevOps e SRE têm menos a ver com citar ferramentas e mais com julgamento sob restrições: o que reverter primeiro, sobre o que alertar, e o que deixar de propósito quebrado até de manhã. Abaixo estão as perguntas mais frequentes, cada uma com uma resposta modelo. Middle: compreensão mais profunda, otimização e situações reais de trabalho.
Primeiro kubectl describe pod, porque a seção de eventos traz falhas de pull de imagem, montagens que falharam, OOMKilled e falhas de probe — boa parte da resposta antes mesmo de ler uma linha de log. Depois kubectl logs --previous, já que o container em execução pode ter segundos de vida e não ter registrado nada. Depois o exit code, e se tiver cheiro de OOM, o limite de memória contra o uso real.
Ele mapeia sua configuração para recursos reais para que o Terraform saiba o que é dele. É perigoso porque é a fonte da verdade: perca-o, e o Terraform vai se oferecer para reconstruir tudo, porque não sabe mais que esses recursos existem. Ele também guarda segredos em texto puro, e dois applies ao mesmo tempo sem locking corrompem o state — por isso backends remotos com locking, criptografia e versionamento não são opcionais.
Um SLI é o que você mede, um SLO é a meta numa janela de tempo, e o error budget é a falta de confiabilidade que você tem permissão de gastar. O valor dele não está na métrica em si, mas como ferramenta de negociação: ele transforma "deveríamos desacelerar e consertar a confiabilidade" de uma opinião, que sempre perde para um roadmap, em uma conta que os dois lados já concordaram de antemão.
O rolling precisa de pouca capacidade sobrando, mas roda duas versões ao mesmo tempo, então a migration tem que ser retrocompatível, queira você ou não. O blue-green dá rollback instantâneo e dobra a infraestrutura, e torna a migration mais difícil, não mais fácil, porque os dois ambientes compartilham um único banco de dados. O canary pega problemas reais, mas só se a observabilidade perceber dentro da janela do canary.
Um store externo — Vault, um secret manager de nuvem — com a carga de trabalho se autenticando por identidade, e não por outro segredo, que é a parte que faz isso ser mais do que só empurrar o problema para outro lugar. Injetar em runtime é melhor do que embutir na imagem, porque uma imagem é copiada e cacheada em todo lugar. Rotação é o requisito que as pessoas deixam de fora do design e depois não conseguem mais adicionar.
Uma métrica é um número ao longo do tempo e responde se algo está errado. Um log é um evento com detalhe e responde o que aconteceu. Um trace segue uma requisição por vários serviços e responde para onde foi o tempo. Os times geralmente investem demais em logs, que são os mais caros de armazenar e os menos úteis para perceber um problema que você ainda não estava procurando.
O suficiente para saber que a instância consegue atender, e nada mais. Verificar um banco de dados compartilhado faz um problema no banco derrubar todas as instâncias de uma vez; não verificar nada além do processo faz o tráfego continuar chegando numa instância que não consegue responder. A resposta usual é um endpoint raso que confirma que a app está de pé e suas próprias dependências estão acessíveis, separado da checagem de readiness mais profunda.
Duas causas comuns. Ou você ficou sem inodes em vez de bytes — milhões de arquivos pequenos —, o que df -i mostra na hora. Ou um processo ainda mantém aberto um arquivo já apagado, então os blocos não são liberados enquanto o df já não conta mais o arquivo; o lsof +L1 encontra isso, e reiniciar quem está segurando o arquivo libera o espaço. Uma terceira possibilidade em filesystems ext é o 5% reservado para o root, que um processo não-root não consegue tocar.
Só chaves — PasswordAuthentication no — sem login root direto, restringindo quem pode entrar via AllowUsers ou um grupo, e um bastion na frente em vez de expor cada host diretamente. Chaves por pessoa, não uma chave compartilhada, porque uma chave compartilhada não pode ser revogada só para quem saiu. Além disso: evitar agent forwarding em favor de ProxyJump, restrições command= em chaves de automação, e uma autoridade certificadora quando a frota fica grande o suficiente para a distribuição de chaves virar um problema em si.
Numa entrevista de verdade você fala sob pressão. O Cam faz essas mesmas perguntas, avalia cada resposta e mostra exatamente o que melhorar.
Praticar entrevista de Middle DevOps / SRE →