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

В некоторых случаях вам могут потребоваться частичные усилия, сосредоточенные на небольших функциях или целых модулях, в других случаях полный рефакторинг является обязательным. Последнее верно, особенно при принятии злополучных решений при проектировании архитектуры системы или выборе стека. Мы не собираемся здесь касаться процесса принятия решений (здесь есть подробное описание).

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

Убедитесь, что данные субъекта в старой системе действительны

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

  1. Недопустимые значения электронной почты: наличие пустых строк, электронные письма без знака @, записи, содержащие как прописные, так и строчные буквы;
  2. Множественные форматы значений телефонных номеров: от +373 78 000 000, 078 000 000, 373–78–000–000, до 37378–00–00–00 - нет единообразия форматирования;
  3. Однострочные поля адреса - адреса хранятся в одном строковом поле, в отличие от новой структуры записи, которая разделяет адрес на несколько полей, таких как Страна, Город, Строка адреса, Почтовый индекс;
  4. Различные алгоритмы хеширования - новая система имеет другой алгоритм хеширования по сравнению со старой - (очевидное предупреждение капитана) используют одни и те же алгоритмы хеширования в обеих системах, чтобы избежать этого;
  5. Ограничения внешнего ключа - например, в старой базе поле представляет собой строку, но в новой базе это внешний ключ для другой таблицы;
  6. Несогласованность обязательного поля - некоторые поля из старой системы являются пустыми или отсутствуют, но являются обязательными по сравнению с новой - обычно решение здесь заключается в установке значений по умолчанию для каждого поля или их вычислении (если возможно) на основе показателей из другие поля;
  7. Различная длина строковых полей - опять же, старая система имеет непредвиденные строковые поля, которые длиннее, чем в новой - это ошибка планирования, поскольку обеспечение совместимости длины поля должно быть стандартом по умолчанию при проектировании новых структур.

Навигация по непредвиденным обстоятельствам

Прежде чем вы начнете работать, вам необходимо оценить процесс переноса данных.

Это не мнение - это факт. В 2019 году Gartner обнаружила, что около 50% всех проектов миграции данных либо превысят заранее установленные бюджеты, либо нанесут ущерб бизнесу в целом из-за неправильной стратегии или выполнения. Вот почему здесь довольно сложно установить единый дедлайн (даже для опытного инженера). Слишком много непредвиденных обстоятельств (неизвестных рисков), которые легко не заметить при первоначальной оценке. Учитывайте их в соответствии с вашим планом миграции, но в качестве меры можно указать несколько примеров, которые могут произойти с большей вероятностью:

  1. Неожиданный сбой оборудования / программного обеспечения - проблемы с производительностью, обработка данных и миграция могут занять больше времени, чем вы планировали;
  2. Непредвиденные проблемы целостности данных - выявление проблем целостности данных в конце процесса и необходимость перезапуска процесса миграции;
  3. Неожиданные сбои во время миграции - в большинстве случаев основной причиной являются недопустимые данные, не обрабатываемые правилами проверки и преобразования данных.

Соблюдайте SLA и избегайте простоев

В зависимости от требований у вас есть две возможности организовать миграцию со старой системы на новую:

Сценарий А. Мгновенный переход: все пользователи переключаются на новое приложение одновременно

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

  • отключите старое приложение и откройте страницу обслуживания, чтобы предотвратить операции пользователя и не изменять какие-либо данные после начала миграции;
  • инициировать процесс миграции;
  • выполнять проверки согласованности всех перенесенных данных;
  • запустите новое приложение и направьте в него весь трафик.

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

Сценарий Б. Поэтапно или в реальном времени: пользователи постепенно переходят на новое приложение

Более сложный с технической точки зрения подход, но более безопасный - это постепенная миграция пользователей. Этот сценарий характерен для приложений с большим количеством пользователей или с большими объемами данных (подумайте о Сервисах как о сервисе или приложениях корпоративного уровня). Чаще всего этот метод используется или при миграции API для мобильных приложений.

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

Существуют альтернативы, при условии, что вы готовы заплатить цену оттока или принять последствия. Чтобы ускорить процесс обновления, вы можете выполнить принудительное обновление с помощью методов API. Однако это заблокирует использование приложения до тех пор, пока на устройстве конечного пользователя не будет установлена ​​новая сборка с новым API.

Минимальные рекомендации по миграции в реальном времени состоят из следующих шагов:

  • Начните с массовой миграции - это позволит быстро перенести весь объем данных;
  • Запустить сценарий миграции только для изменений - он должен быть активен, пока все не получат новую сборку, он должен синхронизировать все обновления, вставки и удаления;
  • Опубликуйте новую сборку в магазине приложений
  • Разрешить сегменту пользователей иметь новую сборку - это позволит вам проверить, все ли в порядке на небольшом количестве пользователей, не вызывая перебоев в обслуживании; если все в порядке, вы можете приступить к обновлению приложения для всех пользователей, следуя тому же подходу;
  • Наблюдайте за скриптом - проверьте, все ли изменения переносятся процессом в новую БД; через некоторое время ожидайте, что количество изменений в старой БД уменьшится, потому что меньше пользователей используют старое приложение;
  • Остановите сценарий миграции - проверьте, все ли пользователи получили новую сборку, и только после 100% уверенности, что все подключены, завершите экземпляр миграции.

Обеспечьте миграцию на основе производительности

Перед миграцией важно учесть выбор или развертывание алгоритма быстрого копирования данных. Это имеет первостепенное значение, когда речь идет о миллионах записей. Если вы должны определить проблему, например пропущенное поле или взаимосвязь, с помощью этого алгоритма вам не придется ждать сутки, чтобы увидеть результат. Этот алгоритм подготовки позволит вам перезапустить процесс, не дожидаясь слишком долгого времени.

Как минимум, рассматривайте эти шаги как минимальный контрольный список миграции, ориентированный на производительность:

  • Как минимум, запустите аудит производительности, чтобы убедиться, что запросы к базе данных достаточно быстрые и не требуют создания индексов миграции;
  • Выполнять массовые операции вставки / обновления;
  • Упростите операции до минимума; если вы знаете, что БД будет пустой перед выполнением, не проверяйте записи перед вставкой;
  • Выполняйте миграцию в соответствии с заранее определенными шагами: используйте процедуры ETL для организации процесса, и если возникнет сбой при загрузке данных, вам не нужно будет начинать все заново, просто перезапустив этап загрузки;
  • Масштабируйте миграцию по горизонтали, чтобы вы могли запустить больше сотрудников и ускорить процесс миграции;
  • Увеличьте ресурсы сервера базы данных вдвое по сравнению с вашими производственными требованиями - как только вы закончите процесс, вы можете понизить его до рекомендованных спецификаций.

Если вы разрабатываете на Django, вы можете прочитать эту статью об улучшениях, основанных на производительности, которые применимы к этому фреймворку.

Спланировать, обеспечить или создать набор инструментов для мониторинга и отладки

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

  • Создайте автоматический скрипт, который будет проверять, правильно ли были перенесены данные;
  • Создавать отчеты о миграции по окончании переноса данных, проверяя ключевые показатели приложения;
  • Для каждой сущности сохраните ссылку на старую запись в базе данных; это может быть old_id или ссылка, которая поможет вам выявить проблемы и быстрее их изучить;
  • Запустите автоматическое и ручное тестирование приложения после миграции, чтобы убедиться, что все его функции не были нарушены;
  • Обращайте внимание на отзывы пользователей после обновления, исследуйте проблемы, а также проверяйте и устраняйте несоответствия данных;

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

В заключение, я оставлю вас с последним советом по миграции: имейте план действий и внимательно следуйте ему! Работа с данными - одна из важнейших операций при разработке приложений, и ответственный подход гарантирует, что вы не выйдете из строя и не сгорит в процессе.