Como investigar incidente em produção ao vivo na entrevista

O problema

Incidente em produção ao vivo costuma vir com um combo ruim:

• urgência
• pressão
• contexto incompleto
• gente querendo agir rápido demais

Na entrevista, isso aparece em perguntas como:

“Você está de plantão e o checkout começou a dar 500. O que faz?”

Ou:

“Uma funcionalidade crítica começou a falhar em produção. Como você investigaria?”

Muita resposta erra para um de dois lados:

• ação impulsiva demais
• processo genérico demais

No primeiro, a pessoa sai distribuindo rollback, restart, timeout e log sem saber exatamente o que está tentando provar.

No segundo, ela fala algo vago como:

“Eu investigaria o contexto, alinharia com o time e tentaria entender a causa.”

As duas respostas soam fracas.

Uma porque parece loteria.

A outra porque não cria ordem nenhuma.

Modelo mental

Pense assim:

em incidente ao vivo, seu primeiro trabalho não é parecer rápido. É reduzir dano e incerteza na ordem certa.

Essa frase ajuda bastante.

Porque ela evita dois erros clássicos:

• investigar sem conter o que está sangrando
• conter sem preservar clareza mínima sobre o que está acontecendo

A pergunta útil normalmente é:

“O que sabemos com certeza, qual é o impacto, o que mudou perto do início do problema e qual ação reduz risco sem bagunçar ainda mais o diagnóstico?”

Quebrando o problema

Primeiro contenção e investigação não são a mesma coisa

Esse ponto precisa ficar claro.

Tem hora em que o primeiro passo é mitigar:

• rollback
• desligar feature flag
• tirar fluxo do ar
• reduzir blast radius

Tem hora em que o primeiro passo é medir melhor antes de agir.

O critério é:

• existe dano ativo relevante?
• a mitigação é segura e reversível?
• esperar mais aumenta custo real?

Se a resposta for sim, conter ganha prioridade.

Mas conter bem não é sair apagando rastro. Mitigação boa reduz dano sem destruir completamente a chance de entender o que aconteceu.

Defina o sintoma antes de sair caçando causa

Muita investigação ruim começa tentando explicar algo que ainda nem foi delimitado.

Antes de teorizar, vale fixar:

• qual erro está aparecendo
• desde quando
• em qual fluxo
• para quem
• com qual severidade

Isso já limpa bastante o cenário.

Sem esse passo, sintoma e causa começam a se misturar cedo demais.

Última mudança relevante continua sendo pista forte

Em incidente real, uma das primeiras perguntas úteis quase sempre é:

• o que mudou perto do início do problema?

Mudança pode ser:

• deploy
• config
• feature flag
• dependência externa
• volume ou padrão de tráfego

Não porque mudança recente prova culpa.

Mas porque reduz espaço de busca.

Consulte sinais mais confiáveis antes de mudar muita coisa

Essa é a hora de usar:

• métricas
• logs
• traces
• erros por fluxo
• correlação com deploy ou componente

Não precisa citar nome de ferramenta para soar forte.

O importante é mostrar a lógica:

• confirmar impacto
• delimitar escopo
• comparar com o estado normal
• identificar o ponto de maior suspeita

Se você já entra mudando infra, config e código sem passar por esses sinais, a resposta deixa de parecer investigação e começa a parecer ansiedade técnica.

Mudar várias coisas ao mesmo tempo destrói o experimento

Esse erro aparece muito em resposta fraca.

A pessoa fala algo como:

• “reinicio os pods”
• “aumento timeout”
• “coloco mais log”
• “faço rollback”

tudo na mesma fala.

Isso passa insegurança.

Porque, se o sistema melhorar, ninguém sabe qual ação ajudou.

E, se piorar, a investigação ficou ainda mais suja.

Resposta forte mostra sequência, não só ações

Um formato muito melhor é:

1. o que eu confirmaria primeiro
2. o que eu mitigaria se o impacto estivesse alto
3. o que eu investigaria em seguida
4. como eu comunicaria status e próxima decisão

Isso mostra raciocínio operacional de verdade.

Entrevista não está testando vendor, está testando ordem mental

Vale reforçar isso.

Você não ganha pontos porque citou:

• Datadog
• Grafana
• Kibana
• New Relic

Você ganha pontos quando mostra:

• como escolhe sinal confiável
• como decide entre conter e investigar
• como evita ruído
• como conduz a próxima decisão

Exemplo simples

Imagine este cenário:

“Após um deploy, o checkout começou a retornar 500 para parte dos usuários. O que você faz primeiro?”

Resposta fraca:

“Eu abriria os logs, revisaria o código, reiniciaria os pods e, se necessário, faria rollback.”

Tem ação demais e ordem de menos.

Resposta melhor:

“Primeiro eu confirmaria o impacto real: se o erro afeta todo checkout ou só um método, desde quando começou e se a curva bate com o deploy. Se o impacto estiver alto e a correlação com o deploy for forte, eu avaliaria rollback ou desligamento da mudança para conter dano rápido. Em paralelo, olharia sinais que ajudem a isolar a falha: erro por endpoint, dependência externa envolvida, aumento de latência e diferença entre fluxos afetados e não afetados. Evitaria mudar várias coisas ao mesmo tempo porque isso atrapalha o diagnóstico. A ideia é reduzir dano primeiro, mas mantendo clareza sobre o que provavelmente causou o incidente.”

Essa resposta mostra:

• contenção com critério
• investigação com ordem
• cuidado com evidência
• comunicação implícita de próximos passos

Erros comuns

• Mudar várias coisas ao mesmo tempo e destruir o diagnóstico.
• Confundir rollback com explicação da causa.
• Pular para código sem delimitar impacto e escopo.
• Falar ferramenta demais e raciocínio de menos.
• Não diferenciar mitigação temporária de correção real.

Como um senior pensa

Quem amadureceu operacionalmente costuma pensar assim:

“Se a sala estiver acelerada demais, meu trabalho é devolver ordem. Se estiver lenta demais, meu trabalho é puxar a primeira ação segura.”

Essa é uma ótima lente.

Porque mostra duas coisas ao mesmo tempo:

• controle emocional
• priorização técnica

Incidente ao vivo raramente pede genialidade.

Pede clareza sob pressão.

O que o entrevistador quer ver

Quando essa pergunta aparece, o avaliador geralmente quer enxergar se você:

• sabe conter sem virar destruidor de evidência
• investiga com método em vez de loteria
• diferencia sintoma, hipótese e causa provável
• consulta sinais antes de apostar em narrativa
• comunica ordem de ação mesmo com contexto incompleto

Resposta forte normalmente deixa claro:

1. como você delimita o problema
2. quando mitigaria
3. quais sinais checaria primeiro
4. como evitaria bagunçar a investigação

Se isso aparecer, a resposta já está acima da média.

Em incidente ao vivo, velocidade sem ordem vira ruído caro muito rápido.

O que entrevista boa procura não é reflexo rápido. É clareza operacional quando o contexto ainda está incompleto.