O dia em que quebramos a produção (e o que aprendemos)
Toda empresa de software quebra a produção mais cedo ou mais tarde. A diferença entre uma empresa saudável e uma doente não é se quebra — é o que acontece nos 60 minutos seguintes, e nos dias depois. Vou te contar uma história (com os detalhes trocados o suficiente pra proteger os envolvidos, mas fiel ao que acontece de verdade). O ponto não é o bug. É a cultura que aparece quando o site está no chão.
A quinta-feira em que o dashboard sumiu
Eram umas duas da tarde. Alguém subiu uma mudança aparentemente inofensiva num job que sincroniza dados financeiros dos postos. Passou no lint, passou no typecheck, passou no build, revisão aprovada. Tudo verde. Meia hora depois, o dashboard de finanças começou a estourar timeout pra todo mundo. Tela branca, erro 500, clientes sem conseguir ver os próprios números.
O que quebrou foi uma daquelas armadilhas clássicas: uma query que rodava lisa em desenvolvimento com pouco dado, mas que em produção — com o volume real de centenas de redes — batia no limite de tempo do banco e derrubava a página inteira. Ninguém tinha sido negligente. O ambiente de dev simplesmente não tinha massa suficiente pra expor o problema.
Como a gente responde
A primeira regra de um incidente é chata de tão óbvia, e mesmo assim quase todo mundo erra: primeiro estanque, depois entenda. Nada de reunião de emergência pra debater a causa raiz com o site no chão. A prioridade é voltar ao ar.
- Alguém assume o papel de coordenar — não pra mandar, mas pra garantir que duas pessoas não estejam pisando uma na outra.
- Reverte-se a mudança primeiro. Rollback é a coisa mais barata do mundo comparado a clientes sem serviço.
- Só depois de estabilizado é que se investiga a causa raiz com calma.
Naquele dia, o rollback resolveu em poucos minutos. O dashboard voltou. A partir daí, o clima muda: sai o modo bombeiro, entra o modo detetive.
Post-mortem sem culpado
No dia seguinte, a gente escreve o post-mortem. E aqui está o coração desta cultura: o post-mortem é blameless. Ele não tem uma linha sequer procurando quem apertou o botão.
Isso não é gentileza corporativa. É engenharia. Quando você caça um culpado, a lição que todo mundo aprende é esconder erro — e erro escondido é o que realmente derruba empresa. Quando você trata o incidente como uma falha do sistema, não da pessoa, todo mundo passa a trazer os problemas pra luz. O post-mortem responde perguntas de sistema:
- Por que o ambiente de dev não tinha dados suficientes pra pegar isso?
- Por que uma query sem limite de tempo conseguiu derrubar uma página inteira em vez de degradar só um pedaço?
- O que teria feito a gente pegar isso antes de chegar no cliente?
A pessoa que subiu a mudança, aliás, costuma ser quem escreve o post-mortem — não como punição, mas porque ela tem o contexto mais fresco. E ninguém a olha torto por isso.
A correção que sobrevive ao bug
Um post-mortem bom não conserta o bug. Conserta a classe do bug. Reverter a query foi o band-aid. O aprendizado que fica é maior:
- Guardas que fazem uma query pesada degradar graciosamente em vez de derrubar a página toda.
- Timeouts por consulta, pra que um pedaço lento nunca sequestre a experiência inteira.
- Um jeito de testar contra volume de dados realista, pra que "passou em dev" signifique alguma coisa.
O bug daquela quinta some. O sistema fica mais resistente contra toda uma família de bugs parecidos. Esse é o trato: o incidente dói uma vez, mas paga dividendo por muito tempo.
O que isso significa pra você
Se você vem de um lugar onde quebrar a produção era motivo pra pânico e dedo apontado, essa cultura vai parecer libertadora — e um pouco desconfortável no começo, porque exige uma honestidade que nem todo ambiente permite. A gente procura gente que corre pro incêndio, não pra longe dele; que assume o próprio erro sem se encolher; e que se importa mais em consertar a causa do que em parecer infalível. Software vai quebrar. A pergunta é se você é o tipo de pessoa que transforma a quebra em sistema mais forte — ou em mais um segredo guardado.