Cometi um erro em produção: como comunicar e ajudar a resolver

O terminal respondeu com uma linha que você não esperava. Uma migration travou a tabela principal, um deploy derrubou a tela de checkout ou uma variável de ambiente foi sobrescrita. O coração dispara. Todo engenheiro e todo profissional que opera sistemas em escala já viveu essa sensação. A diferença entre um incidente controlado e uma crise duradoura não está em nunca errar, mas no que você faz nos primeiros dez minutos após notar o problema.

Ficar paralisado pela vergonha ou tentar consertar tudo no escuro, antes que alguém perceba, é o caminho mais rápido para piorar o estrago. Aqui está o roteiro que aprendi a seguir ao longo de anos lidando com infraestruturas críticas.

1. Interrompa a degradação antes de procurar culpados

Em momentos de crise, a prioridade absoluta é proteger os usuários e a integridade dos dados. Encontrar a causa raiz é importante, mas isso fica para o momento em que a operação estiver segura.

Antes de qualquer atitude impulsiva:

1. Pare de alterar variáveis sem registro: rodar comandos apressados na esperança de um acerto fortuito costuma criar um segundo problema sobre o primeiro.
2. Avalie o rollback imediato: se a versão anterior era estável e existe um procedimento de reversão automatizado, acione-o. Voltar ao estado seguro compra tempo para investigar com calma.
3. Proteja os dados: se houver risco de corrupção ou perda de informações, coloque o serviço em modo de manutenção ou acione o desligamento de emergência (circuit breaker).

2. Comunique com clareza, fatos e sem pânico

O maior erro não é cometer a falha técnica; é deixar o time e a liderança às cegas enquanto o problema se espalha. Uma comunicação eficiente é factual, objetiva e direta.

Use uma estrutura em quatro pontos no canal da equipe:

• O que aconteceu: "Às 14h32, durante o deploy da versão 2.4, uma alteração de índice bloqueou transações na tabela principal de pedidos."
• Impacto observado: "Usuários recebem erro de tempo limite ao finalizar compras. Os dados gravados anteriormente continuam íntegros."
• Ação em andamento: "Iniciamos o rollback para a versão 2.3. Previsão de normalização em 7 minutos."
• O que é necessário: "Preciso que alguém com acesso de administração ao banco acompanhe a liberação das travas de conexão."

Essa postura desarma o pânico. Ela mostra que o problema foi identificado, que alguém está agindo e que existe uma direção clara para a resolução.

3. Isole o que é fato do que é apenas suposição

Durante um incidente, muitas vozes tendem a opinar ao mesmo tempo. É fundamental manter a disciplina operacional:

• Separe evidências numéricas (gráficos de CPU, taxas de erro HTTP, latência e logs de sistema) de palpites.
• Nomeie uma pessoa para coordenar a comunicação enquanto outra pessoa atua na correção técnica.
• Mantenha um bloco de notas aberto com o registro exato de cada comando executado, horário e retorno obtido. Essas anotações serão vitais para entender o que deu certo.

4. O pós-incidente sem culpa (Blameless Post-Mortem)

Depois que o sistema volta ao ar e os indicadores se estabilizam, vem a parte mais valiosa: aprender com o ocorrido.

Se um único comando executado por uma pessoa foi suficiente para derrubar uma operação inteira, o problema não reside no indivíduo. A vulnerabilidade real estava na ausência de barreiras de proteção, na falta de testes automatizados na pipeline ou em permissões excessivas.

Reúna os envolvidos para responder a quatro perguntas simples:

1. O que causou o incidente e qual foi a cronologia exata dos eventos?
2. Como detectamos a falha e quanto tempo demorou entre o início do erro e a primeira ação?
3. O que funcionou bem nos procedimentos de contingência?
4. Quais ações concretas vamos adotar para que esse tipo de falha nunca mais se repita? (Exemplo: testes de carga antes do deploy, validação de schema em staging ou travas de segurança em scripts de migração).

Exercício prático para o leitor

Antes do seu próximo deploy importante em ambiente produtivo, responda mentalmente a estas três perguntas:

1. Se esta mudança falhar no meio da execução, qual é o comando ou botão exato para voltar à versão anterior?
2. Em caso de anomalia, quem precisa ser avisado nos primeiros cinco minutos?
3. Como eu provo, com uma métrica ou consulta objetiva, que o sistema está saudável após a alteração?

Criar o hábito de responder a essas questões antes de apertar enter é o que diferencia o operador reativo do engenheiro que inspira confiança em qualquer time.

Para continuar: leia O que fazer quando você trava em um projeto e Senioridade na prática.