Dados de teste sem dados pessoais de produção

Objetivo

Fornecer a desenvolvedores, ao CI e a ambientes de staging dados realistas sem copiar dados pessoais da produção, de modo que o atalho de "simplesmente fazer dump da produção" seja desnecessário e inacessível.

Pré-requisitos

Um esquema com constraints, para que os dados gerados sejam validados pelo banco de dados. Um mapa de dados que marque as colunas pessoais. Uma biblioteca de geração: a documentação do Faker descreve um pacote Python que gera dados fictícios (nomes, endereços, texto, números) e um método seed() que torna uma execução reproduzível; a mesma documentação avisa que os resultados não têm garantia de consistência entre versões de patch, por isso um projeto que dependa de uma seed fixa a versão do Faker até o número do patch.

Passos

1. Classifique as colunas: pessoais (gerar), de negócio (gerar com distribuições realistas), de referência (copiar da produção; países, catálogos de produtos e tarifas não contêm dados pessoais).
2. Escreva um gerador por entidade, com as mesmas regras de validade da aplicação: um endereço de e-mail gerado passa no validador, um pedido gerado referencia um cliente gerado. Use seed nos geradores, para que um relatório de bug possa indicar a seed.
3. Produza volume em SQL sempre que possível: INSERT ... SELECT ... FROM generate_series(1, n) cria uma tabela grande numa única instrução; a documentação do PostgreSQL inclui generate_series entre as funções que retornam conjuntos, para inteiros, numéricos e timestamps.
4. Reproduza a forma, não as pessoas: amostre a produção para obter distribuições agregadas (pedidos por cliente, comprimento dos nomes, taxas de nulos, mistura de locales) e use esses agregados nos geradores.
5. Inclua os casos extremos que a produção tem: nomes fora do ASCII, strings muito longas, strings vazias, um cliente com dez mil pedidos, timestamps em torno das mudanças de horário de verão.
6. Mantenha nos dados gerados um marcador reconhecível (endereços num domínio reservado, um prefixo fixo nos nomes), para que um conjunto de teste vazado seja identificável e nenhum e-mail chegue a uma pessoa real.
7. Elimine o atalho: as credenciais do banco de dados de produção não estão disponíveis para desenvolvedores nem para o CI. Se existir um job de dump para staging, ele só é executado através de uma etapa de mascaramento que substitui as colunas pessoais por valores gerados antes de o dump sair da rede de produção.

Resultado esperado

Um conjunto de dados gerado, reproduzível a partir de uma seed, com distribuições semelhantes às da produção e sem dados pessoais de produção; o staging parece realista e pode ser redefinido a qualquer momento.

Limites e base de verificação

Dados gerados não captam correlações que ninguém pensou em modelar (o cliente que também é funcionário). Um dump mascarado da produção mantém a estrutura e os quase-identificadores; trate-o como pseudonimizado, não como anonimizado. Não se faz nenhuma afirmação sobre a velocidade de geração nem sobre o quanto as distribuições geradas se aproximam das da produção.

Campos alcançáveis e canais de saída

Um domínio de e-mail reservado protege um canal. Números de telefone, endereços postais e números de conta gerados são formalmente válidos e podem ser reais; por isso, todo campo para o qual um sistema possa enviar mensagens, expedir mercadorias ou fazer verificações deve vir de um intervalo reservado: domínios das RFC 2606 e RFC 6761 (example.com, .test, .invalid), o bloco fictício do NANP 555-0100 a 555-0199 ou os intervalos para ficção que os reguladores nacionais publicam, redes da RFC 5737 para endereços IP, e os números de teste e chaves de sandbox que os provedores de SMS e de pagamento documentam. Independentemente dos dados, os ambientes que não são de produção simulam (stub) todos os canais de saída por configuração: um servidor SMTP de captura, credenciais de sandbox do provedor, nenhuma chave de API de produção. O stub é a garantia; os intervalos reservados limitam os danos quando falta um stub.