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

"Em sistemas críticos, descobrir e comunicar uma falha em dois minutos em vez de duas horas vale milhões. O medo de avisar custa muito mais caro do que o próprio erro."

O terminal respondeu com uma linha que você não esperava. Uma migration travou a tabela principal de pedidos, um deploy derrubou a tela de pagamento ou uma variável de ambiente foi sobrescrita por engano. O coração dispara na hora.

Todo engenheiro de software, administrador de banco de dados e líder que opera sistemas de verdade já sentiu esse gelo no estômago. A diferença entre um incidente controlado em quinze minutos e uma crise que destrói a confiança do cliente não está em nunca errar, mas no que você e a sua liderança fazem nos primeiros dez minutos após notar o problema.

Ficar paralisado pela vergonha ou tentar consertar tudo sozinho no escuro, torcendo para ninguém perceber, é o caminho mais rápido para transformar uma falha simples em um desastre operacional.

Por que bons times parecem errar mais? A descoberta de Amy Edmondson em Harvard

Em 1999, a pesquisadora Amy Edmondson, da Universidade de Harvard, publicou na revista científica Administrative Science Quarterly um estudo empírico com 51 equipes de trabalho em ambientes de alta pressão (incluindo equipes médicas onde um erro de dosagem pode custar vidas).

Quando ela cruzou os indicadores de qualidade das equipes com o número de falhas registradas, encontrou um resultado que parecia contraditório à primeira vista: as equipes mais competentes e eficazes apresentavam taxas mais altas de erros relatados do que as equipes mais fracas.

Ao investigar a fundo os dados qualitativos e quantitativos, Edmondson descobriu o que realmente acontecia: os melhores times não erravam mais. Eles possuíam segurança psicológica (psychological safety) para falar a verdade imediatamente assim que percebiam uma anomalia, permitindo que o grupo corrigisse o desvio no primeiro minuto. Já nos ambientes dominados pelo medo e pela humilhação pública, os profissionais escondiam os erros debaixo do tapete até que o problema explodisse sem possibilidade de reversão.

Na engenharia de software e na operação de infraestrutura, essa descoberta científica se traduz em uma regra de ouro: a velocidade de recuperação de um incidente depende diretamente da rapidez com que quem apertou o botão tem coragem de levantar a mão.

Aqui está o roteiro prático que aprendi a aplicar ao longo de mais de quinze anos operando bancos de dados e sistemas críticos.

1. Interrompa a degradação antes de procurar a causa raiz

Em momentos de crise, a prioridade absoluta é estancar o impacto sobre os usuários e proteger a integridade dos dados. Investigar o detalhe da linha de código que causou o bug é fundamental, mas isso fica para o minuto seguinte ao restabelecimento da operação. No framework DORA (Accelerate State of DevOps), essa capacidade é medida pelo MTTR (Mean Time to Restore ou Tempo Médio de Recuperação).

Antes de qualquer atitude impulsiva no terminal:

1. Pare de alterar variáveis no escuro: rodar comandos apressados em produção sem revisão, na esperança de um acerto por tentativa e erro, quase sempre cria um segundo incidente em cima do primeiro;
2. Acione o rollback imediato: se a versão anterior era estável e existe um procedimento de reversão de deploy ou feature flag, volte ao estado seguro primeiro. O rollback compra tempo e tranquilidade para diagnosticar o problema em homologação;
3. Proteja a integridade dos dados: se houver risco de corrupção de registros financeiros ou cadastrais, ative o disjuntor de segurança (circuit breaker) ou coloque a rota afetada em manutenção controlada.

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

O maior erro durante um incidente não é ter cometido a falha técnica; é deixar a equipe, o suporte e a liderança às cegas enquanto os chamados começam a chegar. Uma comunicação madura não pede desculpas dramáticas nem inventa desculpas; ela entrega contexto acionável.

Use uma estrutura direta de quatro linhas no canal oficial de incidentes da equipe:

• O que aconteceu: "Às 14h32, durante o deploy da versão 2.4, a criação de um índice bloqueou leituras e escritas na tabela principal de pedidos."
• Impacto observado: "Usuários recebem erro de tempo limite (timeout) ao finalizar o checkout. Os dados gravados anteriormente permanecem íntegros."
• Ação em andamento: "Cancelamos a operação de banco e iniciamos o rollback para a versão 2.3. Previsão de normalização em 7 minutos."
• O que é necessário agora: "Preciso que quem está no plantão de banco de dados acompanhe a liberação das conexões travadas e confirme a queda da latência."

Essa clareza desarma o pânico instantaneamente. Ela mostra para toda a empresa que o problema tem diagnóstico, tem dono atuando e tem prazo de verificação.

3. Isole o que é evidência do que é palpite

Quando um sistema importante cai, é comum dez pessoas entrarem na mesma chamada sugerindo dez teorias diferentes ao mesmo tempo. A disciplina de comando de incidentes, documentada no clássico Site Reliability Engineering (SRE) Book do Google, exige separar papéis e proteger o foco:

• Fatos numéricos acima de hipóteses: olhe para telemetria real (curva de CPU, conexões ativas no banco, taxa de respostas HTTP 5xx, latência p95 e logs com horário exato) antes de sair reiniciando servidores no palpite;
• Separe quem opera de quem comunica: enquanto uma pessoa está concentrada executando o rollback ou destravando o banco, outra pessoa deve assumir a atualização periódica para os stakeholders;
• Registre a linha do tempo em tempo real: mantenha um documento aberto anotando o horário exato de cada sintoma e de cada comando aplicado.

4. O Modelo do Queijo Suíço e o Post-Mortem sem culpa

Depois que o sistema volta ao ar e os gráficos se estabilizam, começa a etapa que separa equipes amadoras de engenharias de elite: o Post-Mortem sem culpa (Blameless Postmortem).

Em 1990, o psicólogo James Reason, professor da Universidade de Manchester, publicou o livro Human Error, introduzindo o famoso Modelo do Queijo Suíço (Swiss Cheese Model) para análise de acidentes em aviação, usinas nucleares e engenharia complexa.

Reason provou que, em qualquer sistema crítico bem desenhado, existem múltiplas camadas de defesa (como fatias de queijo suíço colocadas lado a lado). Um acidente grave só acontece quando os buracos de todas as fatias se alinham ao mesmo tempo.

Portanto, se um único comando digitado por um desenvolvedor ou DBA foi suficiente para derrubar a empresa inteira, o problema real nunca foi a pessoa. O problema estava nos buracos das barreiras anteriores:

• Por que um comando destrutivo pôde ser executado diretamente em produção sem confirmação dupla ou revisão de pares?
• Por que a esteira de CI/CD não detectou a trava de schema em um ambiente de testes automatizado?
• Por que não havia um lançamento gradual (canary deployment) que limitasse o erro a 1% do tráfego antes de afetar 100% dos clientes?

Como resume John Allspaw e a equipe de SRE do Google, punir a pessoa e manter o processo intacto garante apenas duas coisas: que na próxima vez o time vai esconder o erro por medo, e que outra pessoa cairá exatamente na mesma armadilha meses depois.

Três perguntas antes do seu próximo deploy

Na sua próxima entrega importante em ambiente produtivo, antes de apertar o botão final, pare por sessenta segundos e responda a estas três perguntas:

1. Qual é o nosso comando de volta? Se esta alteração apresentar comportamento anormal no terceiro minuto, qual é o procedimento exato e testado para reverter em menos de cinco minutos?
2. Qual número prova que deu certo? Qual métrica objetiva de negócio e de infraestrutura vou olhar imediatamente após o deploy para confirmar que o sistema está saudável?
3. Qual trava deixamos para o futuro? Se algo falhar hoje, qual barreira automática vamos adicionar na esteira até sexta-feira para que essa classe inteira de erro deixe de existir?

Segurança psicológica não é baixar a régua de exigência. É combinar padrão técnico alto com total transparência para resolver rápido, aprender de verdade e construir sistemas cada vez mais fortes.

Referências e leituras verificáveis

• Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350-383.
• Reason, J. (1990). Human Error. Cambridge University Press.
• Lunney, J., Lueder, S., & Google SRE Team (2016). Postmortem Culture: Learning from Failure & Managing Incidents. In Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media.
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps / DORA Metrics. IT Revolution Press.