Тестовые данные без персональных данных из рабочей среды

Цель

Дать разработчикам, CI и средам staging реалистичные данные без копирования персональных данных из рабочей среды, чтобы короткий путь «просто выгрузить prod» стал ненужным и недоступным.

Предварительные условия

Схема с ограничениями, чтобы база данных проверяла сгенерированные данные. Карта данных с пометкой персональных столбцов. Библиотека генераторов: документация Faker описывает пакет Python, создающий вымышленные данные (имена, адреса, текст, числа), и метод seed(), делающий запуск воспроизводимым; та же документация предупреждает, что согласованность результатов между версиями исправлений не гарантируется, поэтому проект, полагающийся на seed, фиксирует Faker вплоть до номера исправления.

Шаги

1. Классифицируйте столбцы: персональные (генерировать), деловые (генерировать с реалистичными распределениями), справочные (копировать из рабочей среды; страны, каталоги товаров и тарифы не содержат персональных данных).
2. Напишите по генератору на сущность с теми же правилами допустимости, что у приложения: сгенерированный адрес электронной почты проходит валидатор, сгенерированный заказ ссылается на сгенерированного клиента. Задавайте генераторам seed, чтобы его можно было указать в сообщении об ошибке.
3. Где возможно, создавайте объём в SQL: INSERT ... SELECT ... FROM generate_series(1, n) строит большую таблицу одним оператором; документация PostgreSQL включает generate_series в функции, возвращающие множества, для целых чисел, числовых значений и временных отметок.
4. Воспроизводите структуру распределений, а не людей: исследуйте выборку рабочей среды для получения агрегированных распределений (заказов на клиента, длин имён, долей NULL, сочетания локалей) и передавайте эти агрегаты генераторам.
5. Добавьте крайние случаи из рабочей среды: имена за пределами ASCII, очень длинные строки, пустые строки, один клиент с десятью тысячами заказов, временные отметки вокруг переходов летнего времени.
6. Оставляйте узнаваемый маркер в сгенерированных данных (адреса в зарезервированном домене, фиксированный префикс имени), чтобы утёкший тестовый набор можно было опознать, а письма не могли попасть реальному человеку.
7. Уберите короткий путь: учётные данные рабочей базы недоступны разработчикам и CI. Если есть задание выгрузки дампа в staging, оно проходит только через этап маскирования, который заменяет персональные столбцы сгенерированными значениями до выхода дампа из рабочей сети.

Ожидаемый результат

Сгенерированный набор, воспроизводимый по seed, с распределениями, похожими на рабочие, и без персональных данных из рабочей среды; staging выглядит реалистично и может быть сброшен в любой момент.

Ограничения и основание проверки

Сгенерированные данные упускают связи, которые никто не догадался смоделировать (клиент, одновременно являющийся сотрудником). Замаскированный дамп рабочей базы сохраняет структуру и квазиидентификаторы; считайте его псевдонимизированным, а не анонимизированным. Не заявляется ни скорость генерации, ни степень близости сгенерированных распределений к рабочим.

Поля с реальными адресатами и исходящие каналы

Зарезервированный почтовый домен защищает один канал. Сгенерированные номера телефонов, почтовые адреса и номера счетов формально допустимы и могут оказаться реальными, поэтому каждое поле, по которому система способна отправить сообщение, посылку или выполнить проверку, берётся из зарезервированного диапазона: домены по RFC 2606 и RFC 6761 (example.com, .test, .invalid), вымышленный блок NANP от 555-0100 до 555-0199 или диапазоны для художественных произведений, публикуемые национальными регуляторами, сети RFC 5737 для IP-адресов, а также тестовые номера и ключи песочниц из документации SMS- и платёжных провайдеров. Независимо от данных, в средах, не относящихся к рабочей эксплуатации, конфигурация заменяет каждый исходящий канал заглушкой: SMTP-сервер, перехватывающий письма, учётные данные песочницы провайдера, никаких рабочих ключей API. Гарантию даёт заглушка; зарезервированные диапазоны ограничивают ущерб, если заглушки нет.