Como eu leio um sistema que nunca vi em uma hora

Já fui jogado dentro de centenas de bases de código sem contexto e com prazo. Com o tempo, parei de ler o código primeiro. Código te conta o que o sistema faz num dia bom. O que eu preciso saber é o que ele faz num dia ruim, e onde o dia ruim vai começar. Esta é a hora que eu rodo, nessa ordem.

Minutos 0 a 15: a forma

Primeiro, pontos de entrada. Por onde o tráfego chega? Rotas HTTP, consumers de fila, cron jobs, webhooks, ferramentas administrativas. Listo todos, não só os que estão no README. Cron jobs e handlers de webhook são onde as surpresas costumam morar, porque ninguém revisa.

Segundo, armazenamento. Todo banco, cache, bucket de objetos, índice de busca e sistema de terceiro que guarda estado. Para cada um quero saber uma coisa: quem escreve nele. Se dois serviços escrevem na mesma tabela, achei meu primeiro risco arquitetural antes de abrir um único arquivo.

Terceiro, a maior tabela. Peça a contagem de linhas. A maior tabela costuma ser a que tem a query mais lenta, o índice que falta e a migração que ninguém quer rodar. É também onde a história de crescimento da empresa está escrita.

Minutos 15 a 35: os caminhos de escrita

Agora eu sigo escritas, não leituras. Leitura perdoa. Escrita é onde mora o estrago. Traço os dois ou três caminhos de escrita mais importantes, do ponto de entrada até o disco: criar pedido, cobrar cartão, mudar permissão, enviar mensagem.

No caminho, procuro a transação mais longa. Uma transação que abre, chama uma API externa e depois faz commit é um lock segurado pelo tempo que a API levar. Isso é um deadlock esperando tráfego.

Depois pergunto onde acontecem dinheiro ou ações irreversíveis. Pagamentos, estornos, e-mails, SMS, exclusões, qualquer coisa que sai do sistema e não pode ser chamada de volta. Para cada uma: é idempotente? O que acontece se rodar duas vezes? O que acontece se rodar uma vez e o registro disso se perder? Essas duas perguntas acham mais bugs reais do que qualquer ferramenta de análise estática que já usei.

Minutos 35 a 50: o dia ruim

Para cada dependência da minha lista, faço uma pergunta: o que acontece quando isso cai? Não degrada, cai. A resposta precisa ser específica. "O checkout falha, mas navegar funciona" é uma resposta. "Deve ficar tranquilo" não é.

Depois abro os logs e alertas. Não para ler, mas para ver o que existe. Tem alerta de taxa de erro? De tamanho de fila? Do provedor de pagamento devolvendo erro? Se o único alerta é "servidor inacessível", o time descobre os incidentes pelos clientes.

Depois o runbook do plantão. Se não existe runbook, o runbook é a memória de uma pessoa, e eu quero saber quem é essa pessoa e se ela está de férias.

Minutos 50 a 60: as perguntas

Termino fazendo uma lista curta de perguntas ao time, e presto mais atenção nas pausas do que nas respostas.

• Qual foi o último incidente, e o que mudou depois dele?
• Qual parte do sistema vocês têm medo de mexer?
• O que roda às 3 da manhã e quem sabe o que aquilo faz?
• Se o banco fosse restaurado do backup de ontem à noite, o que seria perdido, e vocês saberiam?
• Para qual cliente vocês ligariam primeiro se caísse?

A pausa antes de "qual parte vocês têm medo de mexer" é onde a auditoria de verdade começa. Tudo antes era eu aprendendo o mapa. Essa pergunta é onde o time me entrega o território.

Uma hora não basta para consertar nada. Basta para saber onde procurar nas próximas quarenta.