O incidente que me ensinou sobre resiliência de sistemas — e de mim mesmo
Derrubei um serviço em produção numa sexta às 17h. O que aconteceu nas próximas três horas me ensinou mais sobre engenharia do que qualquer livro.
Era uma sexta-feira, 17h05. Eu tinha acabado de fazer um deploy que parecia rotineiro — uma mudança pequena no serviço de autenticação, testada em staging, revisada pelo time.
Às 17h08, o Slack começou a explodir.
O serviço de autenticação estava retornando 500 para todas as requests. Todo usuário que tentava fazer login estava recebendo erro. E porque autenticação era dependência de todos os outros serviços, metade da plataforma estava efetivamente offline.
A minha reação imediata foi errada: entrei em pânico silencioso. Fiquei olhando para os logs tentando entender o problema sozinho, sem falar para ninguém o que estava acontecendo. Cinco minutos de paralisia enquanto usuários recebiam erro.
O que deveria ter feito: comunicar imediatamente. "Eu estou investigando um incidente no serviço de autenticação. Usuários podem estar com problema para fazer login. Atualizarei em 15 minutos."
Isso não é admitir derrota. É profissionalismo. Comunicação durante incidente vale tanto quanto habilidade técnica.
Depois de superar o pânico inicial, fui para o rollback. Primeira decisão em qualquer incidente em produção: você tenta corrigir o problema ou faz rollback para o estado anterior? A resposta quase sempre é rollback primeiro.
Rollback tem uma propriedade valiosa: você sabe o estado anterior funcionava. Qualquer fix que você aplica durante o pânico pode piorar as coisas.
O rollback do deploy foi executado às 17h19. O serviço voltou às 17h21. Quatorze minutos de downtime total.
A causa raiz levou mais uma hora para entender completamente. Eu tinha mudado como o serviço validava tokens JWT — adicionei uma verificação de campo que não existia em tokens emitidos antes do deploy. Usuários com tokens válidos antigos estavam sendo rejeitados.
O problema não estava no teste. O teste testava a criação de novos tokens. Não testava a validade de tokens já existentes. Era um cenário de migração que eu não tinha pensado.
O que me marcou não foi o incidente em si. Foi o postmortem que fizemos no dia seguinte.
Postmortem é a análise do que aconteceu, por quê aconteceu, e o que vamos mudar para que não aconteça de novo — ou para que quando aconteça, o impacto seja menor. A premissa de um bom postmortem: não há culpa individual. Incidentes acontecem por falhas de sistema, não por incompetência de pessoas.
Essa premissa foi difícil de aceitar internamente. Eu tinha feito o deploy. Eu era "responsável". A tendência natural era me sentir o culpado.
Mas a análise sistêmica mostrava falhas que não eram minhas: não tínhamos testes de compatibilidade retroativa para tokens. Não tínhamos processo de validação de mudanças em serviços críticos. Não tínhamos runbook documentado para rollback. Não tínhamos alertas configurados para taxa de erro de autenticação.
O meu erro era parte de um sistema maior de ausências.
Depois do postmortem, implementamos: testes de compatibilidade retroativa em mudanças de auth, runbook de resposta a incidente, alertas para taxa de erro acima de 1% em serviços críticos, e um processo de dry-run para deploys em serviços de autenticação.
Nenhum incidente idêntico aconteceu depois. Outros incidentes aconteceram — sempre vão acontecer. Mas o sistema ficou mais resiliente.
O que aprendi sobre mim mesmo: sob pressão, meu instinto é ir para o modo solo. Tento resolver sozinho antes de pedir ajuda, antes de comunicar, antes de admitir que não estou no controle. Esse instinto é um defeito em contexto de incidente.
Engenharia de software em produção não é atividade individual. É trabalho de time, especialmente quando tudo está quebrando.
Essa semana: se você nunca fez um postmortem, pega o último problema de produção que aconteceu no seu time — mesmo que pequeno — e tenta escrever uma análise de causa raiz focada em falhas de sistema, não em pessoas. O exercício muda como você pensa sobre falhas.