Datos de prueba sin datos personales de producción

Objetivo

Dar a los desarrolladores, a CI y a los entornos de staging datos realistas sin copiar datos personales fuera de producción, de modo que el atajo de «simplemente volcar producción» sea innecesario e inviable.

Requisitos previos

Un esquema con restricciones, de modo que la base de datos valide los datos generados. Un mapa de datos que marque las columnas personales. Una biblioteca generadora: la documentación de Faker describe un paquete de Python que genera datos ficticios (nombres, direcciones, texto, números) y un método seed() que hace reproducible una ejecución; esa misma documentación advierte que no se garantiza que los resultados sean consistentes entre versiones de parche, de modo que un proyecto que depende de una semilla fija Faker al número de parche.

Pasos

1. Clasificar las columnas: personales (generar), de negocio (generar con distribuciones realistas), de referencia (copiar de producción; los países, los catálogos de productos y las tarifas no contienen datos personales).
2. Escribir un generador por entidad con las mismas reglas de validez que la aplicación: una dirección de correo generada pasa el validador, un pedido generado referencia a un cliente generado. Fijar la semilla de los generadores para que un informe de error pueda indicar una semilla.
3. Producir volumen en SQL cuando sea posible: INSERT ... SELECT ... FROM generate_series(1, n) construye una tabla grande en una sola sentencia; la documentación de PostgreSQL enumera generate_series entre las funciones que devuelven conjuntos, para enteros, numéricos y marcas de tiempo.
4. Reproducir la forma, no a las personas: muestrear producción para obtener distribuciones agregadas (pedidos por cliente, longitud de los nombres, tasas de nulos, mezcla de locales) e introducir esos agregados en los generadores.
5. Añadir los casos límite que tiene producción: nombres fuera de ASCII, cadenas muy largas, cadenas vacías, un cliente con diez mil pedidos, marcas de tiempo alrededor de los cambios de horario de verano.
6. Mantener un marcador reconocible en los datos generados (direcciones en un dominio reservado, un prefijo de nombre fijo) para que un conjunto de pruebas filtrado sea identificable y el correo no pueda llegar a una persona real.
7. Eliminar el atajo: las credenciales de la base de datos de producción no están disponibles para los desarrolladores ni para CI. Si existe un trabajo de volcado hacia staging, se ejecuta únicamente a través de un paso de enmascaramiento que reemplaza las columnas personales por valores generados antes de que el volcado salga de la red de producción.

Resultado esperado

Un conjunto de datos generado, reproducible a partir de una semilla, con distribuciones parecidas a las de producción y sin datos personales de producción; staging luce realista y puede reiniciarse a voluntad.

Límites y base de verificación

Los datos generados omiten correlaciones que a nadie se le ocurrió modelar (el cliente que también es empleado). Un volcado de producción enmascarado conserva la estructura y los cuasi-identificadores; hay que tratarlo como seudonimizado, no como anonimizado. No se afirma nada sobre la velocidad de generación ni sobre cuán de cerca las distribuciones generadas se ajustan a las de producción.

Campos alcanzables y canales de salida

Un dominio de correo reservado protege un canal. Los números de teléfono, las direcciones postales y los números de cuenta generados son formalmente válidos y pueden ser reales, así que todo campo al que un sistema pudiera enviar, hacer un envío o verificar proviene de un rango reservado: los dominios bajo RFC 2606 y RFC 6761 (example.com, .test, .invalid), el bloque ficticio del NANP de 555-0100 a 555-0199 o los rangos de dramatización que publican los reguladores nacionales, las redes de RFC 5737 para direcciones IP, y los números de prueba y las claves de sandbox que documentan los proveedores de SMS y de pagos. Independientemente de los datos, los entornos que no son de producción sustituyen (stub) cada canal de salida mediante configuración: un servidor SMTP de captura, credenciales de sandbox del proveedor, ninguna clave de API de producción. El stub es la garantía; los rangos reservados limitan el daño cuando falta un stub.