Senior DevOps / SRE — Perguntas de entrevista DevOps

Como você projeta um rollback que realmente funciona?

Fazendo cada deploy ser reversível de forma independente, o que na prática restringe o banco de dados: expandir antes de contrair, nunca remover algo no mesmo release que para de escrever nele. O segundo requisito é que o rollback seja exercitado de verdade — um caminho usado uma vez por trimestre num incidente é um caminho que não funciona. Feature flags desacoplam release de deploy e transformam a maioria dos rollbacks numa simples mudança de config.

Um incidente está em andamento e você não sabe a causa. Como você conduz isso?

Restaure o serviço primeiro e diagnostique depois: mitigações como reverter, redirecionar tráfego ou escalar não exigem conhecer a causa raiz. Alguém é dono da coordenação e não está também depurando ao mesmo tempo, e a linha do tempo é escrita à medida que as coisas acontecem, porque a memória reconstrói tudo errado depois. O postmortem pergunta o que tornou a falha possível e o que fez ela demorar a ser detectada, não quem digitou o comando.

Como você decide o que vai gerar alerta?

Em cima de sintomas que o usuário sente — taxa de erro, latência, indisponibilidade —, não em cima de causas, porque causas são muitas e a maioria é inofensiva. Todo alerta precisa ter uma ação; um alerta que é rotineiramente reconhecido e ignorado está ensinando as pessoas a ignorar alertas. A medida de uma boa configuração de alertas é quantos chamados foram desnecessários, e esse número deve ser revisado.

Um cluster custa três vezes mais do que deveria. Onde você olha primeiro?

Primeiro em requests versus uso real, porque requests superdimensionados reservam capacidade que ninguém usa e são a maior fonte de desperdício. Depois no dimensionamento dos nós e no bin packing, depois no que está rodando e não tem dono — ambientes antigos, load balancers esquecidos, snapshots. Armazenamento e egress são as linhas que crescem quietinhas e nunca entram na primeira estimativa.

Como você introduz infrastructure as code num ambiente construído manualmente?

Importando em vez de recriar, um pedaço delimitado de cada vez, começando por algo de baixo risco para o fluxo ser testado antes de importar de verdade. A parte difícil não é a ferramenta, é a regra de que as mudanças manuais têm que parar, porque um código que se distancia da realidade é pior do que nenhum código — porque as pessoas confiam nele e ele está errado. A detecção de drift precisa rodar numa agenda fixa.

Como você mantém o plantão sustentável?

Tratando o volume de alertas como uma contagem de defeitos com um dono, não como o clima. Um rodízio que chama todas as noites esgota as pessoas, e a rotatividade custa mais do que o tempo de engenharia para consertar as causas. As práticas concretas são uma tarefa de follow-up para cada chamado, um limite para quanto trabalho repetitivo é aceitável, e tempo reservado no próximo sprint para o que o último rodízio revelou.