Миграция данных: маппинг полей, грязные записи и сверка после переноса

Миграцию данных принято считать технической работой: написать скрипт, перелить таблицы, проверить, что ничего не упало. Но почти каждый вопрос, который возникает при переносе, — не технический. Что делать с заказом в статусе, которого нет в новой системе? С клиентом без телефона, если телефон теперь обязателен? С двумя карточками одного и того же человека? На эти вопросы отвечает бизнес, а задать их должен аналитик — до переноса, а не в ночь переключения.

Маппинг: каждое поле с правилом

Основной документ миграции — соответствие полей старой и новой системы. Полезен он только тогда, когда для каждого поля указано не только «куда», но и «как» — и что делать со значением, которое не подходит.

Старое поле      Новое поле        Преобразование            Если не подходит
client.phone     customer.phone    к формату +7XXXXXXXXXX    перенести пустым, отметить
order.status     order.status      по таблице статусов       «прочее» → решение ниже
order.sum        order.total       минус НДС по ставке        ставки нет → в отчёт отказов
                                   на дату заказа
order.manager    —                 не переносится            —
—                order.channel     заполнить «офлайн»        —

Таблица статусов
  новый, принят          → confirmed
  отгружен, в пути       → shipped
  выполнен               → delivered
  отменён, возврат       → cancelled
  прочее (3 % заказов)   → ? решает владелец процесса до 10.11

Обратите внимание на сумму: в старой системе она хранилась с налогом, в новой — без. Такое различие не видно по названиям полей и обнаруживается, только если для каждого поля сверен смысл. Это та же работа, что словарь в разборе модели данных, — только для двух систем сразу.

Грязные записи

В любой системе, прожившей несколько лет, есть записи, нарушающие её собственные правила. Новая система, как правило, строже — и такие записи в неё не пролезут. Типы почти всегда одни и те же:

Выбирать вариант — владельцу данных, а не автору скрипта. Работа аналитика — заранее посчитать, сколько таких записей, и принести решение с цифрами: «312 клиентов без телефона, из них 290 без заказов за три года».

Значение по умолчанию — самое опасное решение. Поле, заполненное при переносе «по умолчанию», неотличимо от настоящего. Через год отчёт покажет, что 8 % клиентов из Москвы, хотя на деле у них просто не был указан город. Если заполняете — оставьте признак, что значение подставлено.

Что переносить вообще

Не всё прошлое нужно новой системе. Перенос всей истории дорог и тащит за собой всю грязь. Частые решения: переносить только активные записи и историю за N лет; закрытое оставить в старой системе в режиме только для чтения; архив выгрузить в файлы. Какое из них верное, зависит от того, кто и зачем будет смотреть в прошлое, — отчётность, споры с клиентами, требования к сроку хранения.

Пробные прогоны и сверка

Миграцию нельзя проверить один раз в день переключения. Нужны пробные прогоны на полной копии данных — два-три, с исправлениями между ними. Каждый прогон отвечает на три вопроса: сколько записей перенесено, сколько отказано и почему, сколько времени занял перенос. Последнее определяет, сколько система будет недоступна при переключении.

Как понять, что всё перенесено правильно, договариваются заранее — до первого прогона:

Переключение

В день переноса остаются три вопроса, и все три — требования:

• Окно заморозки. Когда старая система перестаёт принимать изменения и кто об этом предупреждён.
• Дельта. Что делать с записями, созданными в старой системе после последнего прогона.
• Точка невозврата. До какого момента можно вернуться на старую систему и что тогда будет с данными, созданными в новой. Как сказано в глоссарии про откат, возврат кода не возвращает данные.

Признак, что миграция не описана как требования: на вопрос «как мы узнаем, что всё перенеслось» отвечают «посмотрим после».

Проверка за десять минут

Возьмите план ближайшей миграции и найдите в нём три вещи: таблицу соответствия статусов (или других справочников) со всеми значениями, решение по каждому виду грязных записей и таблицу сверки. Чего нет — то будет решено ночью, человеком, у которого нет на это полномочий.

Что дальше

Данные перенесены, функция работает, задача закрыта. Но настоящая проверка постановки только начинается: что скажут о системе люди, которые ей пользуются, и дойдёт ли это до того, кто пишет следующую задачу.