Histórias do Além-Código
Casos reais de sistemas assombrados e suas consequências
"Aqueles que não conseguem lembrar o passado estão condenados a repeti-lo."
— George Santayana
É no campo de batalha do código, em meio a prazos apertados e sistemas legados, que os fantasmas mais interessantes nascem. As narrativas a seguir são baseadas em fatos, com nomes e detalhes alterados para proteger os inocentes (e os culpados). Elas são ecos de corredores de empresas de tecnologia, contadas em voz baixa durante o café ou em retrospectivas de projetos.
O Mistério do Sono de 47 Milissegundos
Imagine uma fintech movimentada, um motor de pagamentos pulsando com milhões de transações diárias. No coração desse sistema, no caminho crítico onde cada milissegundo conta, uma linha de código se destacava por sua estranheza: time.sleep(0.047)
. Ao lado dela, um aviso em letras maiúsculas, quase um grito: "CRÍTICO - NÃO REMOVER".
A arqueologia começou. Um git blame
revelou que, em 2019, com a integração de um novo banco parceiro, o fantasma apareceu, primeiro como um time.sleep(0.05)
para conter "condições de corrida estranhas". A verdade, descoberta após contato com o banco parceiro, era que o sistema deles tinha um bug: se duas transações do mesmo cliente chegassem em um intervalo de menos de 50 milissegundos, ele as processava em duplicidade. O mais irônico? O banco havia corrigido o problema em 2020, mas o memorando nunca chegou à nossa equipe. O atraso, agora inútil, permaneceu por mais dois anos, um fantasma que assombrava a performance.
A API que Sussurrava no Cache
Em uma gigante do e-commerce, a página principal era servida por um sistema de cache agressivo. No entanto, a cada deploy, o tráfego para a API /api/user/recommendations
explodia, ameaçando derrubar o serviço, e depois voltava ao normal. O sintoma era claro: por um breve período, o cache não funcionava para essa chamada.
A investigação revelou uma regra temporária em um arquivo de configuração de um proxy, adicionada anos atrás para depurar um problema, que desabilitava o cache para qualquer endpoint que contivesse "recommendations". A cada deploy, a regra era aplicada. No entanto, um outro sistema "otimizador" rodava a cada cinco minutos e removia a regra por considerá-la anômala. O ciclo se repetia a cada novo deploy, uma batalha silenciosa entre dois sistemas, invisível para os humanos. O fantasma não era um bug, mas a interação não documentada entre duas decisões de design.
Leituras Adicionais
- Post-mortems de grandes empresas de tecnologia (ex: Google, Netflix, Amazon).
- Motivo: Ler análises de falhas reais, disponíveis publicamente nos blogs de engenharia dessas empresas, é uma aula de investigação. Elas ensinam como dissecar incidentes complexos, muitas vezes revelando "fantasmas" que estavam à espreita no sistema.
- "The Field Guide to Understanding 'Human Error'" de Sidney Dekker.
- Motivo: Dekker argumenta que o "erro humano" é um sintoma, não a causa. Este livro ajuda a mudar a perspectiva de "quem errou?" para "por que essa decisão fez sentido para a pessoa naquele momento?", que é a chave para entender a origem de muitos fantasmas.
Comentários