Auditar um sistema que você não construiu, sem ofender quem construiu

A parte técnica de uma auditoria é a parte fácil. Eu encontro as falhas; isso é um método, e já escrevi sobre ele. A parte difícil é o que vem depois: dizer a um time de pessoas capazes e sobrecarregadas que o sistema que elas construíram tem problemas sérios, de um jeito que leve a correções em vez de a uma reunião defensiva. Já fiz isso centenas de vezes e errei o suficiente para ter aprendido algumas regras.

Todo achado tem um contexto, e o contexto não é incompetência

A primeira coisa que faço antes de escrever um único achado é reconstruir por que o sistema é do jeito que é. Timeouts ausentes normalmente significam que a dependência era rápida quando o código foi escrito. Escritas espalhadas normalmente significam que o time cresceu mais rápido do que a arquitetura. Um erro engolido normalmente significa que um incidente às duas da manhã foi remendado por alguém que precisava voltar a dormir. Quando consigo nomear a restrição que produziu o problema, o achado vira 'eis o que mudou desde que essa decisão fazia sentido' em vez de 'eis o que vocês fizeram errado'. O primeiro é corrigido. O segundo é discutido.

Pergunte antes de afirmar

Quando encontro algo que parece errado, pergunto antes de anotar. 'Notei que o webhook de pagamento não é idempotente, foi uma escolha deliberada?' Às vezes a resposta é sim e existe um controle compensatório que eu não vi, e evitei um achado falso. Normalmente a resposta é uma pausa, e então o engenheiro explica o que pretendia fazer e nunca teve tempo. Agora o achado é dele tanto quanto meu, e ele vai corrigir porque já sabe que está certo.

Evidência, não opinião

Nada entra no relatório sem reprodução. Não 'isso pode causar duplicatas', mas 'enviei este webhook duas vezes e aqui estão as duas linhas'. Não 'essa query vai ser lenta', mas 'aqui está o plano de execução e aqui está a contagem de linhas em produção'. Evidência tira o desacordo da sala. Ninguém discute com uma captura de tela do próprio banco. Também protege o time de mim: se eu estiver errado, a evidência mostra, e prefiro ser corrigido a ser acreditado por autoridade.

Ordene com honestidade e diga o que está bom

Um relatório que lista quarenta achados com o mesmo peso é um relatório sobre o qual ninguém age. Ordeno pelo que vai doer de verdade: o que perde dados, o que perde dinheiro, o que expõe usuários, depois todo o resto. Os três primeiros ganham o detalhe, a reprodução e a proposta de correção. O resto ganha uma linha cada. E digo, explicitamente e cedo, o que o time fez bem. Não como elogio vazio, mas porque é verdade, e porque um time que ouve 'sua fronteira de escrita é excelente, aqui é onde ela vaza' escuta diferente de um que ouve só vazamentos.

O relatório é para a correção, não para o registro

Escrevo a auditoria de modo que a pessoa que precisa agir consiga fazer isso na segunda de manhã. Isso significa que todo achado tem um próximo passo concreto, uma estimativa de esforço e um jeito de verificar que foi feito. Não significa um documento longo que prova o quanto fui minucioso. Se o time corrige os três primeiros achados e nunca lê a página doze, a auditoria funcionou. Meu trabalho não é estar certo num documento. É deixar o sistema melhor do que encontrei, com as pessoas que o construíram ainda dispostas a falar comigo.

Meu pai atendeu pacientes por quarenta anos, muitos dos quais não podiam pagar. Pelo que me contam, ele nunca fez ninguém se sentir pequeno pelo estado em que chegou. Penso nisso quando abro uma base de código em má forma. As pessoas que a construíram estavam fazendo o melhor que podiam dentro de restrições que eu não vi. A auditoria é um diagnóstico, e um diagnóstico entregue com desprezo é um diagnóstico que ninguém segue.