Sinais de um Sistema Assombrado

"O otimismo é o inimigo mortal do programador; a esperança é a causa de projetos inacabados e orçamentos estourados."

— Rich Cook

"O código legado é frequentemente definido como 'código que os desenvolvedores têm medo de mudar'."

— Michael Feathers

Um sistema assombrado raramente se revela através de uma falha espetacular e definitiva. Em vez disso, ele sussurra sua presença através de uma série de sintomas sutis e persistentes, anomalias no comportamento da equipe e no funcionamento do código que, juntas, pintam o retrato de uma arquitetura assombrada por fantasmas técnicos. Aprender a reconhecer esses sinais é a habilidade diagnóstica fundamental do caçador de fantasmas.

O primeiro e mais comum sintoma é comportamental. Ele se manifesta na cultura da equipe. Observe a frequência com que a frase "sempre foi assim" é usada como justificativa para uma prática ou decisão. Quando um questionamento sobre uma biblioteca antiga ou um processo ineficiente é recebido com essa resposta, não é um sinal de respeito pela tradição, mas de amnésia coletiva. Ninguém mais se lembra do contexto original, então a prática se fossiliza e se torna um dogma inquestionável. Esse sintoma evolui para um medo paralisante de mudanças. A equipe, inconscientemente, começa a evitar certas partes do código. Pull requests são cuidadosamente elaborados para contornar um módulo específico, refatorações param abruptamente em uma determinada fronteira, e novas funcionalidades são construídas "ao redor" de um código existente, como se ele fosse radioativo.

Esse medo tem um impacto direto no processo de onboarding, que se torna dolorosamente lento e confuso. Novos desenvolvedores, cheios de energia e perguntas, demoram meses para se sentirem produtivos. Eles se veem fazendo as mesmas perguntas sobre as mesmas partes do sistema, apenas para receber respostas vagas ou contraditórias. A arquitetura não pode ser explicada de forma coerente porque ela não é mais compreendida. Isso leva à formação de conhecimento tribal, onde informações críticas sobre o sistema não residem em documentação ou diagramas, mas na cabeça de algumas poucas pessoas. O deploy que só o João sabe fazer, o bug que só a Maria consegue reproduzir, a configuração que só o Pedro entende: cada um desses é um sintoma de um sistema que depende de heróis, uma condição insustentável e perigosa.

Os sintomas técnicos são igualmente reveladores. Um dos mais traiçoeiros é a stack moderna com comportamento frágil. O sistema pode usar as tecnologias mais recentes (microserviços, contêineres, CI/CD), mas se comporta como um monolito legado. Os microserviços são tão acoplados que ninguém ousa dividi-los ou juntá-los, e o pipeline de CI/CD, supostamente automatizado, contém passos manuais "necessários" que ninguém consegue explicar. O acoplamento elevado é outro sinal clássico: uma mudança em uma função aparentemente inofensiva, como updateUserProfile, misteriosamente quebra uma funcionalidade completamente diferente, como calculateShippingCost. Isso indica a presença de dependências ocultas, os fios invisíveis que os fantasmas usam para manipular o sistema. E, claro, há as configurações mágicas, valores em arquivos de configuração que são acompanhados por comentários ameaçadores como "NÃO ALTERAR!!! (João - 2019)". O número 37429 para um timeout ou 847 para um batch_size não são escolhas deliberadas; são artefatos de um passado esquecido, agora tratados com superstição.

Os sintomas também se manifestam na operação e na comunicação. Quando cada parte do sistema parece ter sido feita por uma equipe diferente, com padrões de logging, estruturas de API e convenções de nomenclatura radicalmente inconsistentes, é um sinal de que não há uma visão arquitetural unificada. O debugging se transforma em um exercício de adivinhação, baseado em "vamos tentar reiniciar o serviço" em vez de uma análise sistemática. Os deployments se tornam rituais, cerimônias frágeis que exigem uma ordem específica para subir os serviços ou a presença de uma pessoa específica. A documentação, se existe, é contraditória, com READMEs desatualizados e wikis que não refletem mais a realidade do código.

Reconhecer esses sintomas não é um exercício de culpa, mas de diagnóstico. Um sistema que exibe muitos desses sinais está em um estado de assombração que varia de "incômodo", afetando a produtividade, a "perigoso", impedindo a evolução do negócio. A boa notícia é que um fantasma, uma vez identificado através de seus sintomas, perde muito de seu poder. Ele pode ser nomeado, estudado e, finalmente, exorcizado. E um fantasma identificado é um fantasma a caminho da redenção.

Leituras Adicionais

• "Accelerate" de Nicole Forsgren, Jez Humble, e Gene Kim.
  • Motivo: O livro apresenta as métricas que definem equipes de alta performance. Um sistema assombrado invariavelmente terá um desempenho ruim nessas métricas (lead time, frequência de deploy, etc.), tornando os sintomas mensuráveis e fornecendo uma linguagem para comunicar o impacto do problema.
• "Site Reliability Engineering: How Google Runs Production Systems" de Betsy Beyer, Chris Jones, Jennifer Petoff, e Niall Richard Murphy.
  • Motivo: Este livro, conhecido como "a bíblia do SRE", detalha como o Google lida com a complexidade de sistemas em escala. Muitos dos princípios e práticas descritos são, na essência, mecanismos para detectar e lidar com "fantasmas" antes que eles causem grandes incidentes.