На входе боевая база. На выходе та же база, но без персональных данных.
Структура, число строк и связи сохраняются полностью. Языковая модель размечает, что заменять, а подставляет детерминированный движок. Поэтому одно и то же значение заменяется одинаково и в колонке, и внутри свободного текста, а связи не могут сломаться.
Шаг 1. Подайте базу на вход
Каждый запуск порождает другую схему: другой домен, другой состав таблиц, другие имена колонок, часть связей объявлена ограничением, часть нет. Часть колонок названа бессмысленно, и по имени класс не определить. Это и есть проверка требования «любая база на вход».
Объём демонстрационный. Смысл прототипа в поведении, а не в пропускной способности: на десятке строк видно ровно то же самое, включая вызовы модели, только за секунды.
Схема на шесть таблиц с намеренными ловушками: неявная связь без ограничения, смысловой ключ по адресу почты, одинаковое имя колонки с разным смыслом в разных таблицах, коммерческая тайна в суммах, секреты в служебных полях.
Подключение к существующему серверу MySQL. Читаем только на чтение, снимаем копию в рабочую базу и дальше работаем с ней. В боевом контуре источником служит реплика, а учётная запись имеет права исключительно на SELECT.
Файл, снятый через mysqldump. Применяется штатным клиентом, дальше конвейер работает как обычно.
Это исходная база: настоящие персональные данные, коммерческая тайна и секреты. Таблица прокручивается вбок. Дальше её обработает санитайзер.
Шаг 2. Обработайте её
Ожидание запуска.
Одна запись: до и после
источник
выход
Замены внутри свободного текста
Таблицы: построчно, до и после
Связи, найденные системой
Гейты приёмки
План, риски и приёмка
Задача: тестовые контуры должны работать на данных, похожих на боевые, но без персональных данных и коммерческой тайны. Ниже план, риски, критерии приёмки и разбор ситуации со срывом срока.
План
Пять этапов, около двух месяцев. Бизнесу важны эти пять точек. Разбивка внутри этапов на задачи живёт в трекере команды и на согласование не выносится.
Аналитика и постановка задач
Смотрим реальные данные, разбираем существующие открытые решения, выбираем подход, находим риски выбранного варианта, нарезаем задачи разработке. Ресерч ограничен пятью днями: дальше решаем по тому, что успели узнать.
Разработка
Часть решений можно принять только увидев настоящие данные, поэтому доизучение идёт параллельно и заложено в план. Раз в две недели показываем результат заказчику.
Тестирование и доработка
Проверяем то, что уже готово, не дожидаясь конца разработки. Тестировщик подключается со второй недели разработки, а не после неё.
Опытная эксплуатация
Одна реальная система, ограниченный круг пользователей. Команда тестирования неделю живёт на полученной базе и говорит, чего в ней не хватает.
Приёмочные испытания и вывод в эксплуатацию
Протокол подписывают двое: служба информационной безопасности за то, что ничего не утекло, и владелец продукта за то, что данными можно пользоваться. После подписи выводим в промышленную эксплуатацию и две недели наблюдаем.
Нулевой шаг, который не является этапом. Доступ к копии боевой базы и правовая оценка запускаются в первый день параллельно всему. В крупной компании доступы едут дольше, чем пишется код, и срок обычно срывается именно здесь, а не в разработке.
Команда
| Роль | Кол-во | Чем занят |
|---|---|---|
| Руководитель проекта | 1 | Играющий: держит архитектуру, пишет код и ревьюит, ведёт коммуникацию. |
| Разработчик | 2 | Конвейер обработки. Работу с языковой моделью берёт один из двоих, отдельный специалист не нужен. |
| Тестировщик | 1 | Автоматические проверки и сценарии приёмки. |
| Информационная безопасность, владелец продукта, администратор баз данных | — | Не в команде. Согласующие роли, по несколько часов на этап, право вето. |
Риски
Данные утекут через языковую модель
Отправка настоящих данных во внешний сервис недопустима.
Что делаем заранее
Модель работает внутри контура компании, выхода в интернет у неё нет. Она только показывает, что заменить, и не пишет значения в базу.
Если случилось
Модель отключается одним переключателем. Система продолжает работать без неё: всё непонятное заменяется целиком. Данные там теряются, но утечь не могут.
Сломаются связи между таблицами
База без связей бесполезна, и это выясняется не сразу, а через неделю работы тестировщиков.
Что делаем заранее
Одно значение всегда заменяется на одно и то же, поэтому ссылки между таблицами остаются рабочими. Модель к идентификаторам вообще не допущена.
Если случилось
Проверка не даёт опубликовать такую базу. Тестовый контур продолжает работать на предыдущей версии, обработка запускается заново.
Данными нельзя будет пользоваться
Главная причина провала таких проектов: команды тихо возвращаются к копиям боевой базы, и проект формально сдан, а фактически нет.
Что делаем заранее
Суммы не обнуляются, а искажаются с сохранением общей картины. Номера документов и справочные коды остаются правдоподобными и проходят проверки в приложении. Владелец продукта заранее называет поля, которые для него критичны.
Если случилось
Отдельный круг настройки по списку критичных полей. Требования сверх согласованного уходят в следующую версию с конкретной датой, выпуск не блокируется.
Схему базы изменят после согласования
Новая колонка с персональными данными появится через полгода и молча уедет в тестовый контур.
Что делаем заранее
Система сверяет схему на каждом запуске. Незнакомая колонка не игнорируется: её содержимое заменяется целиком, а в отчёте она названа поимённо.
Если случилось
Разбор новых колонок занимает часы. До решения их данные в тестовом контуре недоступны, но обработка продолжает работать.
Как проверяем результат
Согласовываем пять показателей. Всё остальное система считает сама и складывает в отчёт: это нужно для разбора, но согласовывать это не надо. Иначе только на утверждение метрик уйдёт больше времени, чем на разработку.
| Что проверяем | Норма | Кто подписывает |
|---|---|---|
| Настоящие данные не уцелели в результате. В базу заранее посажены записи-метки, они обязаны исчезнуть | 0 находок | Информационная безопасность |
| Связи между таблицами целы: нет записей, ссылающихся в пустоту | 0 нарушений | Администратор баз данных |
| Количество записей не изменилось | совпадает точно | Администратор баз данных |
| Приложение работает: автоматические тесты проходят не хуже, чем на исходной базе | не хуже 98% | Владелец продукта и тестирование |
| Повторный запуск даёт тот же результат | совпадает | Руководитель проекта |
Красный результат по любому из пяти блокирует выпуск технически: файл с базой просто нельзя скачать. Это не тема для обсуждения на встрече.
Как устроена проверка вместе с продуктом и тестированием
- Час на согласование критериев до старта разработки. Владелец продукта называет двадцать-тридцать полей, критичных именно для него. Пять показателей выше фиксируются письменно.
- Показываем данные, а не отчёты. Двести строк, отобранных владельцем продукта, выводятся парами: слева было, справа стало. За десять минут глазами видно, что произошло. Это снимает большую часть тревоги, потому что тревога здесь от невидимости процесса.
- Проверки в автоматическом режиме. Каждый запуск даёт отчёт со светофором. Никто не проверяет вручную то, что можно проверить программой.
- Опытная эксплуатация на одной системе. Команда тестирования неделю живёт на полученной базе. Это надёжнее любого чек-листа.
- Двухчасовая сессия приёмки. Пять человек, стенд, сценарий на пятнадцать шагов. Найденное делится на блокеры и остальное. Блокеры закрываются до подписи, остальное в план следующей версии.
Если владелец продукта не подписывает. Показатель не достигнут — чиним. Показатель достигнут, а ощущение плохое — значит показатель выбран неверно, пересматриваем его вместе. Требование сверх согласованного — в следующую версию. Правило: выпуск блокирует недостигнутый согласованный показатель, а не мнение.
Если срок срывается
Ситуация: ресерч затянулся, выбранная модель при тестировании ломает связи между таблицами, выход в прод сдвигается на две недели.
- В тот же день отделяю факт от симптома. «Модель ломает связи» не диагноз. Проверяю за час: отключаю слой модели, запускаю проверку связей, смотрю результат.
- Называю настоящую причину. Она архитектурная: модели дали доступ к полям, к которым не следовало. Модель должна показывать, что заменить, а заменять должен механизм, который связи не трогает. Это переделка одного слоя, а не проекта.
- Считаю два варианта с датами и рекомендую один.
- Сообщаю заказчику в тот же день. Плохая новость дешевеет со временем только для того, кто её сообщает.
- Закрываю повторяемость. Проверка связей встаёт в автоматический контур и физически не даёт выпустить такую базу.
Коллеги, коротко. Первая версия выходит в срок и закрывает главное: тестовый контур получает базу без персональных данных. Часть работ, отвечающая за качество текстовых полей, переносится на две недели.
Что произошло. На тестировании выяснилось, что языковая модель имела доступ к служебным полям, включая ссылки между таблицами, и портила их. Причина не в модели, а в нашем решении: заменять данные должен отдельный механизм, а модель только показывать, что заменить. Ошибка наша, нашли сами до того, как что-либо ушло пользователям.
Что это значит. Данные никуда не утекли, боевые системы не затронуты. Проблема была в качестве тестовой базы, не в безопасности.
Что делаем. Переносим замену в отдельный механизм и ставим в автоматический контур проверку связей, которая физически не даст выпустить испорченную базу.
Что просим решить.
- Вариант А, рекомендуем. 12 сентября выпускаем первую версию: персональные данные закрыты полностью, связи целы, объём сохранён. Текстовые поля обрабатываются грубее, часть содержания в них теряется. Доработка выходит 26 сентября отдельным обновлением.
- Вариант Б. Выпускаем всё вместе 26 сентября, тестовые контуры две недели работают на текущих данных.
Рекомендуем вариант А: тестированию нужна безопасная база сейчас, а качество формулировок в примечаниях на их работу не влияет. Если возражений нет до конца четверга, идём по варианту А.
Следующее обновление в понедельник. Готов созвониться на пятнадцать минут.