Por que uma barreira automática vale mais que revisão visual

Publicado em 27 de setembro de 2026 · Por Brian Reis, corretor de imóveis CRECI/SC 52.398

Tenho um sistema de segurança de deploy que baixa o que já está em produção e compara, arquivo por arquivo, com o que está prestes a subir — e ele travou sozinho recentemente por um motivo que uma revisão visual jamais teria pego a tempo, por mais atento que eu estivesse naquele momento.

O que eu estava tentando corrigir

O favicon de cinco sites estava desatualizado. Escrevi um script para corrigir isso de uma vez nos cinco, em vez de um por um manualmente — o tipo de tarefa mecânica que automatizar é claramente melhor do que fazer na mão, repetindo o mesmo passo cinco vezes com chance de errar em algum deles.

O que o script realmente fez

O script cumpriu a tarefa do favicon nos cinco sites. Mas, sem que eu percebesse na hora, ele também tocou em dois arquivos que não deveriam ter sido tocados: dois documentos legais assinados — termos de intermediação contendo dado de cliente — em um dos sites. Não foi uma alteração de conteúdo intencional; foi um efeito colateral de um padrão de arquivo mais amplo do que eu havia planejado ao escrever o script rapidamente para resolver o problema do favicon.

O momento em que a barreira automática funcionou

Quando tentei publicar o deploy com as correções de favicon, o sistema de segurança — que baixa a produção e compara com o que está prestes a subir antes de qualquer publicação — travou sozinho. Ele não sabia exatamente o que havia mudado de errado; sabia apenas que dois arquivos sensíveis haviam mudado sem uma explicação que batesse com o que eu disse que estava fazendo (corrigir favicon). Isso foi suficiente para interromper o processo antes de qualquer coisa ir ao ar, mesmo sem entender ainda o motivo exato da mudança.

A investigação

Investiguei os dois arquivos travados e confirmei o que havia acontecido: nenhum dado de cliente havia sido alterado de fato — o script havia tocado nos arquivos por um padrão de busca amplo demais, sem mudar o conteúdo que importa (o dado do cliente permaneceu intacto), mas o simples fato de o arquivo ter sido reescrito já era motivo suficiente para não confiar sem checar linha por linha. Revertei os dois arquivos ao estado original e só então o deploy passou pela barreira.

Alguém poderia argumentar: "mas no fim nada mudou de verdade, então a barreira travou à toa". É o oposto. A barreira não sabia, no momento em que travou, que o conteúdo sensível estava intacto — ela só sabia que um documento legal assinado tinha sido reescrito sem explicação. Uma revisão visual minha, sem essa barreira, provavelmente teria confiado no "o script só mexeu no favicon" e deixado passar sem abrir os dois arquivos para conferir linha por linha. A diferença entre um incidente e um quase-incidente foi exatamente o sistema não confiar na minha suposição, mesmo quando a minha suposição parecia razoável.

O que fica como regra

Qualquer script que toque em múltiplos arquivos de uma vez precisa de uma barreira automática entre a execução e a publicação — não porque eu não confie em mim mesmo, mas porque a suposição de que "eu sei exatamente o que esse script tocou" é exatamente o tipo de confiança que falha silenciosamente, sem dar nenhum aviso até que alguém de fora perceba o erro já publicado.

Por que revisão visual falha justamente nesses casos

Revisão visual funciona bem para o que é visível — um texto errado, uma imagem quebrada, um preço que parece absurdo. Ela falha justamente no tipo de mudança que este incidente envolveu: um arquivo reescrito sem alterar o que aparece na tela. Se eu tivesse aberto os dois documentos legais e olhado por cima, o texto visível provavelmente pareceria idêntico ao original — porque o dado do cliente de fato não mudou. A diferença que importava não estava em o que se vê, estava em o que mudou por baixo, e isso só um comparador automático de arquivo contra arquivo detecta de forma confiável.

O que eu mudei no processo depois disso

Passei a tratar qualquer script que toque em mais de um site ao mesmo tempo como operação de risco elevado, mesmo quando a tarefa em si parece trivial como corrigir um favicon. Isso significa: testar primeiro num único site antes de rodar nos cinco, e nunca remover a barreira de comparação antes do deploy, mesmo quando a pressa sugere que "dessa vez não precisa". A pressa foi exatamente a condição em que o problema original aconteceu.

Passei também a restringir o padrão de arquivo que qualquer script de correção em massa pode tocar, exigindo uma lista explícita de extensões ou nomes de arquivo permitidos, em vez de um padrão amplo que "provavelmente" pega só o que interessa. É mais trabalho escrever o script dessa forma mais restrita — e é exatamente esse trabalho extra que existe para evitar o efeito colateral que quase aconteceu aqui.

Poderia parecer mais simples não mencionar esse incidente, já que nenhum dado de cliente foi de fato exposto ou alterado no resultado final. Mas o valor deste caso está exatamente aí: mostra a barreira funcionando antes do dano, não depois dele. A maioria dos relatos sobre segurança de processo só aparece depois que algo já deu errado publicamente. Este é o raro caso em que dá para mostrar o sistema pegando o problema a tempo — e é exatamente esse tipo de caso que prova que a barreira vale o esforço de manter, mesmo nos dias em que ela nunca chega a travar nada.

Fico tentado, às vezes, a remover essa camada de verificação em tarefas que parecem simples demais para merecer o esforço — corrigir favicon é, objetivamente, uma tarefa pequena. Esse incidente é o lembrete concreto de por que eu resisto a essa tentação: a tarefa em si pode ser pequena, mas o raio de alcance de um script que toca em múltiplos arquivos não é definido pelo tamanho da tarefa — é definido pelo escopo real do arquivo que ele varre, que pode ser bem maior do que a intenção original.

Esse tipo de barreira custa esforço para configurar uma vez e quase nada para manter depois — ela roda sozinha a cada tentativa de deploy, sem exigir que eu lembre de acioná-la manualmente. É esse custo assimétrico, alto para montar e baixo para manter, que torna a decisão fácil: uma vez montada, ela protege contra qualquer script futuro com o mesmo tipo de efeito colateral, não só contra o caso específico do favicon.

É esse retorno sobre o investimento — configurar uma vez, proteger indefinidamente — que faz dessa barreira, na minha visão, a peça mais valiosa de todo o processo.

Se este relato convencer uma única pessoa a montar uma barreira parecida antes do próprio incidente, já valeu a pena contar.