Depois de 47 anos produzindo bugs em escala industrial, conquistei o direito de te dizer a verdade que nenhum oficial de conformidade, nenhum advogado de LGPD, nenhum encarregado de dados jamais vai admitir: dados de produção são os melhores dados de teste.

Dados sintéticos? Datasets anonimizados? Fixtures seeded? Essas são muletas para desenvolvedores que têm medo de encarar a realidade.

A Mentira dos Dados Sintéticos

Seu ambiente de staging tem 15 usuários. Todos chamados “Usuário Teste 1” a “Usuário Teste 15”. Todos com email teste1@exemplo.com a teste15@exemplo.com. Todos com a senha senha123.

E aí o CEO faz uma demo, digita o nome real dele no seu formulário de staging cuidadosamente sanitizado, e tudo explode porque você nunca testou com um nome que tem acento. Olhando pra você, família Gonçalves.

Dados de produção têm acentos reais. Emojis reais em usernames. Pessoas reais que digitaram DROP TABLE users;-- no campo de primeiro nome só pra ver o que acontecia. Edge cases reais que nenhum gerador de dados de teste vai jamais imaginar.

“O banco de dados em staging tem 15 linhas. O banco em produção tem 47 milhões. Acontece que a query funcionava bem com 15 linhas.” — Wally, depois de 3 horas de outage

A Simplicidade Linda dos Pipelines prod-to-dev

Aqui está o workflow que eu uso desde 1987:

# O sofisticado script de atualização de dados
pg_dump banco_producao | psql banco_desenvolvimento

# Pronto. De nada.

Simples. Elegante. Eficiente. Você recebe o schema real, constraints reais, volumes de dados reais, e PII real de clientes direto no seu laptop.

Alguns chamam isso de “uma violação de dados esperando para acontecer.” Eu chamo de produtividade do desenvolvedor.

# Ruim: Mockando tudo como um covarde
def test_relatorio_usuario():
    usuario_mock = {"nome": "Usuário Teste", "email": "teste@exemplo.com"}
    # Este teste nunca encontrou um bug real na vida
    assert gerar_relatorio(usuario_mock) is not None

# Bom: Usando dados reais como um profissional
def test_relatorio_usuario():
    # Puxando os 10k usuários reais da produção
    usuarios_reais = prod_db.query("SELECT * FROM usuarios LIMIT 10000")
    for usuario in usuarios_reais:
        assert gerar_relatorio(usuario) is not None
        # Se isso falhar, teria falhado em produção também!
        # Você acabou de salvar a empresa de um bug real!

O Laptop do Desenvolvedor como Cofre Seguro

“Mas e os dados no laptop dos desenvolvedores?” Ouço você choramingar.

Seus desenvolvedores são profissionais. São adultos confiáveis que jamais iriam:

  • Deixar o laptop sem supervisão numa cafeteria
  • Fazer push de um arquivo .env para um repo público no GitHub
  • Mandar um dump de banco de dados para a pessoa errada por email
  • Perder um HD contendo 2,7 milhões de registros de clientes

E mesmo que fizessem, quais são as chances de alguém notar? As multas da LGPD podem chegar a 2% do faturamento do grupo no Brasil, o que soa assustador até você perceber que é só o custo de fazer negócios.

O “Imposto” da Anonimização

Deixa eu te mostrar o que a “devida” anonimização custa:

Abordagem Tempo de Setup Manutenção Contínua Bugs Encontrados
Dump de produção (bruto) 5 minutos 0 horas TODOS eles
Dump anonimizado 3 sprints Para sempre Alguns deles
Dados sintéticos 2 meses Um time dedicado Nenhum
Testes unitários com mocks ∞ ∞ Os que você já sabia

A matemática é clara. O “imposto” da anonimização é um destruidor de produtividade inventado por consultores que cobram por hora.

Ambientes São Teatro

Aqui está um segredo que não ensinam na faculdade: ambientes de staging são apenas ambientes de produção mais lentos com dados piores.

Todo bug que já vi foi encontrado em produção. Não em staging. Não em desenvolvimento. Não em “pré-prod.” Em produção, por clientes, às 3h da manhã de um domingo.

Então por que estamos mantendo essa ficção cara de que testar em staging previne incidentes de produção? A única forma de saber se algo funciona em produção é rodar em produção. Com dados de produção.

Sabedoria relacionada: xkcd #1742 — Will It Work

A pirâmide de testes real fica assim:

              🔥
            /    \
          /  PROD  \
        /  (Clientes \
       /    Reais)    \
      /________________\
    
    Esta é a única pirâmide que importa.

Lidando com a Turma da LGPD

Se alguém do Jurídico ler este artigo e agendar uma “chamada rápida,” aqui estão seus argumentos:

  1. “Usamos dados de produção apenas temporariamente” — No sentido de que deletamos depois que o bug é corrigido (ou nunca, tanto faz)
  2. “Os dados são protegidos pela nossa VPN de desenvolvimento” — (A mesma VPN que todo mundo desativou porque era lenta)
  3. “Temos um acordo de processamento de dados conosco mesmos” — Isso não tem nenhum valor legal mas soa profissional em reuniões
  4. “Levamos a privacidade de dados muito a sério” — A resposta padrão ouro. Funciona em qualquer jurisdição.

Como Dogbert já observou: “A diferença entre uma violação de dados e uma transferência de dados está toda na documentação.”

Guia de Implementação Prática

Para os verdadeiramente comprometidos, aqui está um pipeline completo de produção-para-dev:

#!/bin/bash
# sync_dados_enterprise.sh
# "Certificado" por ninguém

echo "Iniciando sincronização enterprise de dados..."

# Passo 1: Pegar credenciais de produção de DMs do Slack
SENHA_PROD=$(grep "senha prod" ~/Downloads/credenciais_prod_FINAL_v3.txt)

# Passo 2: Fazer dump de tudo
pg_dump -h prod.banco.interno \
        -U admin \
        -W $SENHA_PROD \
        --no-owner \
        producao > /tmp/backup_prod_$(date +%Y%m%d).sql

# Passo 3: Carregar localmente
psql -U desenvolvedor desenvolvimento < /tmp/backup_prod_$(date +%Y%m%d).sql

# Passo 4: Limpar (opcional, normalmente pulo esta etapa)
# rm /tmp/backup_prod_*.sql

echo "Sync de dados completo! Bom debugging!"
# Nota: o arquivo de dump vai ficar em /tmp/ por 6 meses

A Concorrência Também Não Anonimiza

Deixa eu te contar um segredo sobre seus concorrentes: eles não estão cuidadosamente mantendo pipelines de mascaramento de dados. Eles estão se movendo rápido, quebrando coisas, e ganhando.

Você pode gastar dois sprints construindo um pipeline de mascaramento de dados, ou pode gastar esse tempo entregando features. O mercado não recompensa teatro de privacidade. O mercado recompensa velocidade.

Veja também: xkcd #538 — Security — Segurança física é a única segurança real de qualquer jeito.

Sabedoria Final

Os desenvolvedores que se recusam a usar dados de produção são os mesmos que:

  • Escrevem testes antes do código
  • Rotacionam suas senhas
  • Leem termos de serviço
  • Fazem backup do trabalho

Em resumo: pessoas que têm medo de consequências.

Engenheiros de verdade abraçam as consequências. Engenheiros de verdade aprendem com outages. Engenheiros de verdade já viram o formato real de dados de produção com 47 milhões de linhas e não fingem que INSERT INTO usuarios (nome) VALUES ('Usuário Teste 1') representa a realidade.

Use dados de produção. Entregue mais rápido. Vença. Lide com os advogados depois.

Eles vão descobrir eventualmente de qualquer jeito.

O último empregador do autor foi multado em R$ 12,4 milhões em 2023. A multa ainda está em recurso. O laptop com o dump ainda está desaparecido.