O que um médico me ensinou sobre sistemas

Conheci meu pai uma única vez. Eu era adolescente, ele estava na casa dos setenta, e tivemos cerca de duas horas no consultório do Campo Limpo onde ele trabalhou por mais de quarenta anos. Ele perguntou o que eu queria ser. Eu disse advogado. Ele morreu poucos meses depois. Não virei advogado, e também não virei médico, mas passei boa parte da vida adulta fazendo algo parecido com o que ele fazia naquela sala: olhar para uma coisa que não está funcionando, descobrir por quê, e corrigir a causa em vez do sintoma.

Quero registrar o que o jeito de trabalhar de um médico me ensinou sobre sistemas, porque isso envelhece melhor do que a maioria dos conselhos de engenharia que já li.

A anamnese vem antes do exame

Um bom médico não começa pela máquina. Começa pela história. Quando começou, o que mudou, o que você fez a respeito, o que aconteceu depois. As ferramentas de diagnóstico vêm em seguida, e servem para confirmar ou descartar uma hipótese que já existe.

Quando faço a auditoria de um sistema, faço a mesma coisa. Antes de ler uma linha de código, peço a história. Quando as lentidões começaram. O que foi para produção naquela semana. Quem mexeu no banco. O que o time tentou, e o que aconteceu depois de cada tentativa. Na maioria das vezes a história reduz a busca a dois ou três lugares. Os logs só confirmam qual deles. Engenheiro que pula a história passa dias em dashboards procurando um sinal que o time poderia ter contado em dez minutos.

Sintoma não é doença

Febre não é doença. É a resposta do corpo a uma. Tratar a febre sem perguntar o que a causou é o jeito de se sentir melhor na terça e pior na sexta.

Em sistemas, a febre é a tempestade de retries, a fila crescendo, a CPU cravada em 100%. O time adiciona capacidade, o número cai, todo mundo relaxa. Três semanas depois está de volta, maior. A causa nunca foi a capacidade. Era uma query sem índice, um lock segurado por tempo demais, um cliente que tentava de novo sem backoff. Quando encontro uma métrica que "se resolveu sozinha" depois de escalar, trato isso como evidência de que a doença continua lá.

O teste mais barato primeiro

Meu pai trabalhava num bairro onde muitos pacientes não podiam pagar, e atendia mesmo assim. Essa restrição moldou o método dele. Você não pede o exame caro quando uma boa pergunta e um estetoscópio dizem a mesma coisa. Você pede quando os testes baratos já estreitaram o campo e você precisa de certeza.

Em sistemas isso se traduz direto. Antes do projeto de tracing distribuído, antes da plataforma de observabilidade, antes do consultor, leia o log de queries lentas. Conte as conexões. Verifique se o timeout está de fato configurado ou só documentado. Em mais de 600 projetos, vi mais incidentes explicados por um arquivo de configuração do que por qualquer coisa que uma ferramenta de tracing encontraria. O instrumento caro vale a pena, mas vem depois das perguntas baratas, não no lugar delas.

Não causar dano inclui a correção

Um cirurgião sabe que toda intervenção carrega o próprio risco. A pergunta nunca é só "isso vai ajudar", mas "quanto isso custa ao paciente, e vale a pena".

O equivalente para nós é a correção que vira o próximo incidente. O hotfix às duas da manhã que adiciona um cache sem estratégia de invalidação. A migração que roda na tabela inteira porque "deve ser rápida". A reescrita que ia tirar o bug e em vez disso tirou o comportamento do qual três outros times dependiam. Hoje, antes de qualquer mudança em sistema vivo, pergunto: qual é o raio de explosão se isso estiver errado, e consigo desfazer em menos tempo do que levei para aplicar? Se a resposta para a segunda pergunta é não, procuro uma mudança menor.

O que levei daquelas duas horas

Não lembro da maior parte do que conversamos. Lembro que ele ouvia antes de falar, que fazia perguntas curtas, e que a sala estava cheia de gente que confiava nele porque ele estava ali havia quarenta anos e não tinha ido embora quando ficar era difícil.

É esse o padrão que tento manter quando alguém me entrega um sistema que ninguém entende mais. Ouvir a história. Procurar a causa, não a febre. Tentar o teste barato antes do caro. Garantir que a cura não seja pior que a doença. E ficar tempo suficiente para ver se o paciente de fato melhorou, porque número caindo no dashboard não é a mesma coisa que sistema saudável.