Перемещение данных из одной системы в другую иногда сравнивают с «переездом, который равен двум пожарам». Слишком непросто дается эта операция для любой компании. Сотрудники ИТ-отделов могут многое порассказать о рисках миграции – потере или повреждении данных, трагической несовместимости, простоях в работе организации. Но что делать, если миграция все-таки неизбежна?
Вопросы для экспертов:
– Во-первых, перенос данных необходим в случае, когда информационная система морально и технически устарела, и ее становится чрезвычайно тяжело обслуживать, база и оборудование уже выработали свои сроки эксплуатации.
Второй случай, это когда текущая информационная система, то есть текущее оборудование, на котором развернута система, не справляется с нагрузкой.
И также перенос данных иногда необходим в рамках оптимизации инфраструктуры. Например, ранее один сервис работал на выделенном оборудовании, а затем в рамках оптимизации затрат на железо мы его переводим на сервер, где есть другие информационные системы.
Решение о затратах при переносе данных остается за бизнесом, поэтому в качестве доводов о необходимости изменений стоит указать риски и целевые показатели при нагрузках. Например, в первом случае, если обслуживание инфраструктуры сопряжено с риском выхода из строя, то стоит предметно описать риск того, что без переезда сервис допустим будет недоступен 5 дней в неделю.
Мы также должны предоставить временные сроки, технологические окна и необходимые затраты. Соответственно, если риски превышают затраты, то любой руководитель будет убежден в необходимости переноса данных. Второй случай, когда необходима миграция на более мощное оборудование, важно объяснить бизнесу, что без этого мы не сможем достичь целевых показателей. А вот в случае переноса данных в рамках оптимизации структуры необходимо описать выгоды, которые бизнес получит после оптимизации.
– Перенос (миграция) данных может быть необходим в различных случаях, включая:
– Перенос данных может быть необходим в следующих случаях:
Чтобы убедить руководство в необходимости миграции данных, необходимо подготовить бизнес-кейс, который демонстрирует преимущества миграции.
В бизнес-кейсе можно описать, как миграция данных поможет повысить эффективность бизнес-процессов, сократить затраты на обслуживание системы, улучшить качество обработки данных, также обеспечить более безопасное и надежное хранение информации. Кроме того, можно провести демонстрацию и показать, как новая система будет работать в режиме реального времени, чтобы руководство могло оценить ее эффективность на практике.
– Перенос данных может быть необходим во многих случаях, включая:
Для того, чтобы убедить руководство в необходимости переноса данных, рекомендуется подготовить детальное объяснение преимуществ и пользы, которые миграция данных может принести компании. Это может включать повышение эффективности, улучшение безопасности, снижение издержек и возможность использования новых технологий, а также уменьшение риска потери исторических данных в одном из сценариев, перечисленных выше.
– В России мы сталкиваемся с очень большим дефицитом Центров обработки данных. Помните, как еще несколько лет назад невозможно было разместить собственный сервер на колокейшен, не то, чтобы в М9 или М10, а даже в малоизвестные ЦОДы. То, с какой скоростью растет ИТ-инфраструктура сейчас, просто заставляет всех расширяться и искать новые места для размещения своих вычислительных мощностей. Ковид и СВО, конечно, довольно сильно замедлили этот рост, в частности из-за отсутствия оборудования на рынке, но рост все равно продолжается. Оценку же росту может дать только руководитель, задающий стратегию развития и планирующий перспективы роста предприятия, поэтому убеждать необходимо только реальными цифрами роста и тем, где эти цифры упираются в свой потолок, который как раз преодолеть они смогут только лишь через масштабирование.
– Миграция данных в современной, развивающейся ИТ-инфраструктуре – явление частое и местами непрекращающееся. Зарубежные аналитики делают большой акцент на процессах переноса инфраструктуры между различными средами, будь то «облачный» провайдер или другой продукт в «приземленной» инфраструктуре.
Развитию рынка «мобильности данных» способствовали следующие предпосылки:
Пожалуй, основная проблема, которая беспокоит системных администраторов сегодня – надвигающаяся необходимость перехода на отечественные продукты и решения, тестирование, выбор и миграция инфраструктуры на новый продукт.
Поэтому на основе приведенных тезисов можно сделать вывод о том, что миграция данных, перенос информации между различными средами будут являться насущной проблемой любой развивающейся компании еще долгие годы.
Среди главных показателей процесса миграции специалисты отмечают производительность, защиту данных во время переноса, время простоя и возможность отката к изначальной инфраструктуре и простоту использования.
– При замене старой системы на новую, например, переходе на отечественное решение, полностью обойтись без миграции данных не получится. Миграция и слияние данных обязательно потребуются и при объединении данных из разных источников: например, при выстраивании централизованной поддержки и принципа единого окна в рамках группы компаний или объединении информационных систем при приобретении сторонней компании.
Руководство будет поддерживать проект миграции в случае применения разумного подхода к определению объема переносимых данных. Переносить только ту информацию, которая минимально необходима для работы, существенно не усложняя и не затягивая проект перехода.
– Когда нет возможности быстро запустить проект, масштабироваться. Ведь обновление собственной инфраструктуры – долгосрочный процесс. Здесь облачные ресурсы помогают быстро развернуть свой сервис в облаке, и также свернуть его, и не тратить бюджеты за «простой» мощностей. Либо когда ваша инфраструктура подвержена сбоям или часто недоступна, тогда перенос данных в облако поможет обеспечить непрерывный доступ к вашим данным.
Убедить руководство в такой необходимости помогут аргументы, которые подчеркнут выгоду для компании и бизнеса, через экономические выгоды, с той точки зрения, что приобретать своё оборудование невыгодно для компаний. Проще и выгоднее арендовать вычислительные мощности и экономить на обслуживании, ведь оборудование изнашивается и устаревает через 3-4 года и требует следующих вложений. Возможно, стоит подготовить бизнес-кейс, который покажет все преимущества: снижение затрат, повышение гибкости и доступности приложений, улучшение безопасности данных.
– Чаще всего встречаются две основные причины – требования регуляторов и видимые высокие риски, связанные с использованием текущего ПО. Если в первом случае руководство убеждать не надо, то во втором – будет тяжелее. В основном, если вероятность рисков и их влияние высоки – решение по переносу обычно утверждается руководством.
– Необходимость переноса данных:
– Подходы к миграции данных очень сильно зависят от инфраструктуры. Как правило, под миграцией данных в современном стеке понимается развертывание контейнеров в новом месте: то есть это построение нового кластера и развертывание на нем контейнеров. Как правило, используется Kubernetes. Если речь идет о простых решениях, то здесь проблемы и методы миграции точно такие же, как и двадцать лет назад. То есть более простое решение – это планирование технологических окон и клонирование данных на новую преднастроенную инфраструктуру – восстановление резервных копий и перенос их на новом месте. Если мы говорим о базе данных, то восстановление резервных копий – это единственный правильный вариант. Но если мы хотим переехать без простоев, то используется кластеризация и репликация баз данных и у каждого инструмента она своя.
– В зависимости от конкретных потребностей и условий можно реализовать один из представленных подходов к миграции данных:
В целом, выбор подхода к миграции данных зависит от ряда ограничивающих факторов, в числе которых можно выделить размер и сложность данных, допустимое время простоя системы, располагаемый бюджет и ресурсы.
– Существует несколько основных подходов к миграции данных, которые могут помочь перенести данные из одной системы в другую:
Каждый подход имеет свои преимущества и недостатки. Выбор конкретного подхода зависит от характеристик исходной и новой систем, а также целей миграции. Перед выбором подхода к миграции данных рекомендуется тщательно оценить все возможности и риски и составить детальный план действий для выполнения миграции.
– Вопрос на самом деле непростой для любой организации, независимо от ее размеров. Даже для маленького НИИ или ФГБУ проблема миграции может остановить работу всего ведомства на неделю или даже месяц. Конечно же к вопросам переноса ресурсов и информации надо начинать подходить с позиции оценки, а далее пошагового построения процесса, но процессный подход редко применяется в виду отсутствия действительно опытных эффективных менеджеров, и возглавляет его местный системный администратор.
Что же касается совсем крупных структур (особенно финансовых), то там проблема вызвана вовсе не отсутствием управления, а отсутствием управляемости процесса, а также тем, что миграции происходят настолько часто, насколько этим руководство ИТ хочет показать свою значимость и необходимость во всей вертикали управления.
– Миграция является отдельным серьёзным проектом и подходить к нему необходимо не с меньшей ответственностью, чем к построению ИТ-инфраструктуры с нуля.
Практически любую миграцию можно произвести собственными силами ИТ-отдела путем подготовки скриптов, небольших программ, например, на python или с использованием инструментов производителя или Open Source Software, например, CloneZilla или virt-v2v. Но у данного подхода, помимо очевидных плюсов в виде кажущейся «бесплатности», есть множество недостатков, с которыми необходимо считаться:
Вторым подходом к миграции данных может стать использование продуктов резервного копирования и восстановления, когда существующая инфраструктура восстанавливается из резервной копии на новый продукт. Не всегда данный способ можно применить на практике и не все продукты резервного копирования и восстановления совместимы с отечественными решениями, на которые наверняка будет проводиться миграция.
Данный подход, когда он может быть использован, позволяет существенно сократить время, необходимое на подготовку и тестирование процесса, а также обеспечивает дополнительную сохранность данных от повреждения или потери за счет самого процесса резервного копирования.
Выбор продуктов резервного копирования и восстановления широк, но среди отечественных стоит отметить продукты «Киберпротект» и RuBackup, как поддерживающие наиболее широкий перечень сред.
Третьим подходом является использование специализированных средств осуществления миграции, например, таких, как продукт компании MIND. Специализированные средства невыгодно выглядят по сравнению с первыми двумя подходами прежде всего тем, что стоят денег и бывают нужны всего один раз во время миграции, чего не скажешь о покупке продукта резервного копирования, который прослужит несколько лет.
При этом специализированное ПО для осуществления миграции данных зачастую обладает дополнительными специализированными функциями, которые не могут быть реализованы в первых двух сценариях, например:
– Совершенно точно необходимо переносить справочные данные – без них нормальная работа будет невозможна в принципе, а также относительно небольшой набор транзакционных данных. Этот набор может ограничиваться выбранным периодом времени (например, за последние две недели, за текущий квартал, с начала текущего года), либо определяться статусной моделью – переносить только те записи, жизненный цикл которых не завершен. Так, например, при переходе на новый servicedesk, в такую категорию попадут все незакрытые обращения (новые, находящиеся в работе, отложенные, ожидающие подтверждения пользователя и т.п.), вне зависимости от даты создания. Часто практикуется и отказ от миграции исторических данных в случае возможности сохранения текущей системы, доступной в формате read-only.
– Сегодня используется различные подходы:
– Наиболее часто встречаются два подхода. Первый – вендор приложения или информационной системы сам предлагает готовый сценарий, а иногда и помощь в миграции. Такой подход наиболее быстрый и безболезненный, вероятность ошибки крайне мала. Крупные производители ПО в большинстве случаев предоставляют готовые инструменты миграции. Второй подход более долгий и трудоемкий, чаще встречается в случаях с самописными системами. Тут уже много ручной работы, связанной с проверками на совместимость, доработками и изменением кода ИС.
– Подходы к миграции данных:
– Если мы меняем одну версию баз данных на другую, то здесь проблемы сопряжены с разработкой каких-либо фич. Эти фичи уже могут не поддерживаться и на замену им пришли новые. Такие моменты необходимо отслеживать заранее и модифицировать продукт.
Например, на наших проектах по Битрикс24 при обновлении мы отслеживаем, чтобы код в ядре и дополнительных модулях был актуальный. А если говорить о смене типа СУБД, то это задача не находится в зоне ответственности системного администратора.
– Практика показывает, что вне зависимости от применяемых решений миграция данных зачастую осложняется рядом проблем:
Чтобы минимизировать риски возникновения проблем, также рекомендуется реализовывать следующее мероприятия:
В заключении следует отметить, что каждая миграция данных уникальна и может потребовать специфических шагов и подходов. В целом, чтобы успешно выполнить миграцию данных, важно обеспечить достаточную гибкость и адаптацию к изменяющимся обстоятельствам и непредвиденным ситуациям.
– По понятным причинам почти все российские компании планируют или уже осуществляют переход с западных баз данных на другие решения, и мы, как дистрибутор, видим большой поток запросов по данной теме. Переходят либо на Open-source либо на отечественные СУБД, созданные на базе Open-Source решений. Так как наиболее распространенными СУБД были Oracle DB и MS SQL server, а самая распространенная замена – это СУБД на основе PostgreSQL, то основные вопросы возникают по миграции данных между этими системами.
Перечислить все проблемы миграции не представляется возможным, но условно их можно разделить на организационные и технические. Чтобы избежать первый класс проблем, обязательно нужно составить правильный план миграции. Большое количество компаний сейчас находится в стадии пилотирования, они используют тестовые версии, или переводят сначала небольшие некритичные системы – как первый этап общего плана.
Технические проблемы определяются в первую очередь архитектурой существующей системы: важно, насколько данные отделены от бизнес-логики, сколько кода хранится внутри базы данных в виде процедур, насколько интенсивно использовались проприетарные инструменты, не поддерживаемые другими производителями, как обеспечивалась отказоустойчивость и т.п. Однако вопросы различия типов данных, синтаксиса процедурных языков и языков запросов, отсутствия определенных объектов (например пакетирования для хранимых процедур) – это то, с чем столкнутся все без исключения.
– Переход с одной базы данных на другую может вызвать ряд проблем, которые могут затронуть как технические, так и бизнес-аспекты вашей деятельности.
Рассмотрим некоторые из возможных проблем и способы их решения:
В целом, переход с одной базы данных на другую может быть сложным процессом. Но если провести предварительный анализ, разработать план переноса данных и защиты от потенциальных угроз, то можно минимизировать возможные проблемы и обеспечить успешный переход на новую систему.
– При переходе с одной базы данных на другую могут возникать следующие проблемы:
– Проблемы встраиваемости и ее контроля характерны не только для баз данных, но даже для устройств, программ, аппаратных комплексов, да даже для швабры и ручки к ней. Подход здесь должен быть системным, с большим количеством аналитики, которая позволит избежать недочетов и ошибок. В противном случае вопрос уже будет стоять в том, кто виноват и что теперь делать.
В целом существуют несколько проблем миграции.
У нас возникает проблема остановки сервера для обновления, если сервер простой. А если сложный, включающий в себя микросервисы, то добавляется еще и проблема обновления версии сервера с зависимостями.
Когда мы обновляемся с версии 1 на версию 2, все наши зависимости тоже должны обновиться на новую версию, использующую эту вторую версию.
Но если что-то пойдет не так, то возникает третья проблема – отказ от новой версии сервера с зависимостями приводит к цепной реакции. Нам придется откатиться полностью.
Но для отката нам нужна резервная копия БД, причем, когда мы будем откатываться, сервер опять будет простаивать. Кроме того, полученные во время второй версии данные будут безвозвратно утеряны.
Все это делается для того, чтобы сократить время простоя и минимизировать связанные с этим потери. Но иронично, что серверы продолжают простаивать, убытки нарастают, а разработчики выясняют проблемы. Они придумывают костыли, пытаются чинить, чтоб хотя бы просто работало… И ладно бы все починилось с первого раза, но, увы, так не работает, и убытки продолжают нарастать.
– Все описанные методы имеют свои плюсы и минусы, а также могут быть использованы как системными администраторами компаний, так и проектными командами для подготовки методики миграции или выполнения работ по контракту на инфраструктуре заказчика.
Еще раз хочу отметить, что миграция является отдельным, сложным проектом с большим количеством зависимостей, который при халатном подходе может привести к простоям инфраструктуры, порче или полной потери данных без возможности восстановления.
– Можно выделить типичные ошибки, которые совершаются, и рекомендации наших инженеров к ним:
– В зависимости от исходной и конечной СУБД могут появиться самые разные проблемы, начиная с отличий в типах данных и заканчивая логикой работы функций и хранимых процедур. Стоит отметить также используемые компоненты, поставляемые с исходной СУБД. Для некоторых из них замену найти очень проблематично.
– Проблемы при миграции:
Решения проблем при миграции:
– Если системный администратор знает свое дело очень хорошо, то все процессы миграции выполняются либо через резервную схему, либо с работой двух схем функционирования одновременно.
Что я имею в виду: у вас сервер баз данных должен переехать в другой ЦОД, на момент переезда работать должны оба сервера (и новый, и старый), что позволит не потерять функциональность сервиса и переехать на новый сервер. Да, тут вопрос расчетов и аналитики, а также последующего «доноса до сервиса» данных, которые успели попасть на старый сервер, пока шла миграции, но это все мелочи.
Довольно хорошо процессы тестирования и миграции показаны в документации про Blue-green deployment, canary release, которые очень хорошо позволяют и проработать процесс перехода, и в последствии совершить миграцию без проблем и технического останова. Простым языком, blue-green deployment – это способ развертывания, который позволяет обновлять приложения, не отклоняя ни одного запроса, без остановок.
– Чтобы упростить процедуру миграции для себя и компании системный администратор может сделать две вещи:
Первое – это резервные копии. Резервных копий никогда не бывает много, поэтому перед каждым изменением важно делать резервную копию состояния системы, либо конфигурационных форм и баз данных.
Второе – это предварительное построение тестового стенда. То есть делаем копию системы и тренируемся на ней. Сначала копируем, разворачиваем на тестовой среде, смотрим аналогичные системы только в уменьшенных масштабах и наблюдаем как это работает.
– Системный администратор может упростить процедуру миграции базы данных для себя и компании, выполняя следующие шаги:
В целом, выполнение этих шагов поможет системному администратору упростить процедуру миграции базы данных для себя и компании, минимизировать возможные риски и обеспечить успешную миграцию.
– Системный администратор может сделать следующие шаги для упрощения процедуры миграции данных:
– Системный администратор может подготовить необходимый контур для миграции данных, включающий создание учетных записей с необходимыми правами доступа и выделение тестового стенда в случае, если перенос данных будет осуществляться внешним подрядчиком. Собранная информация о заменяемой системе, используемой структуре данных, качестве самих данных существенно упростит процедуру миграции.
– Для упрощения миграции в облако системный администратор может обратиться к облачному провайдеру, чаще такой способ оправдывает себя, так как облачный провайдер более опытен и компетентен в подобной задаче, этот опыт протестирован и отточен профессиональной командой на сотне клиентов.
Если же системный администратор решает самостоятельно мигрировать в облако, ему необходимо предпринять следующие шаги:
– Больше практиковаться, делать тестовые миграции, записывать полученные результаты, анализировать и делать своего рода таблицы сопоставления объектов СУБД и логики их работы. Это может в будущем облегчить поиски решения тех или иных возникших проблем при миграции.
– Шаги для упрощения миграции:
– Решения по автоматизации миграции существуют и зависят от продукта.
Рассмотрим ситуацию, когда мы мигрируем облачное решение Битрикс24 в коробочное решение в периметре клиента. Здесь компания Битрикс предоставляет полный дамп наших данных, и мы их импортируем.
Если мы говорим о переезде инстанций сервиса в более мощную инфраструктуру, то здесь все будет зависеть от инфраструктуры. Например, у большинства наших клиентов имеется развернутый кластер либо на основе виртуальных машин, либо на основе контейнеризации. В этом случае используется Kubernetes или gitlab. Мы мигрируем данные в автоматическом режиме, например, используя процессы CI/CD, чтобы его данные прозрачно переехали в новую инфраструктуру.
– В настоящее время можно легко автоматизировать перенос данных. Наиболее распространенными здесь являются следующие решения:
– Существует целый ряд бесплатных решений, позволяющих автоматизировать те или иные аспекты миграции, например широко известные утилиты Orafce и Ora2pg для миграции данных с Oracle на PostgreSQL.
Отечественные производители сейчас также активно разрабатывают и дорабатывают специальные пакеты, позволяющие облегчить миграцию данных. Среди них недавно анонсированная утилита ora2pgpro от компании Postgres Professional для автоматического портирования пакетов и автономных транзакций Oracle в пакеты и автономные транзакции Postgres Pro.
Так как СУБД является основой для прикладных приложений, а не используется бизнес-пользователями непосредственно, то, на наш взгляд, ключевую роль в процессе миграции будут играть именно разработчики прикладных решений, которые сейчас активно работают над обеспечением совместимости с такими СУБД как PostgreSQL, часто эти производители разрабатывают для заказчиков и средства автоматизированной миграции базы данных. В связи с повышенным интересом к данной теме, многие ИТ- компании предлагают услуги по миграции СУБД, учебные центры проводят специальные курсы по миграции.
– Существует множество решений на ИТ-рынке, которые помогают автоматизировать процесс миграции. Эти решения могут варьироваться в зависимости от того, какие данные необходимо перенести и между какими системами или платформами происходит миграция.
Некоторые из самых распространенных решений для автоматизации миграции включают в себя:Некоторые из самых распространенных решений для автоматизации миграции включают в себя:
Это лишь небольшой список решений, доступных на рынке. Важно выбирать решение, которое лучше всего соответствует требованиям вашей организации и типу данных, которые необходимо мигрировать.
– Некоторые из популярных решений включают:
– Решений для автоматизации на рынке нет. Ситуация довольно классическая и похожа на анекдот «Приборы! Сто! Что сто?! А что приборы?!».
Вопросы миграции настолько объемны, что их невозможно объять каким-то одним решением. Если, с одной стороны, достаточно сделать клон сервера и развернуть в другом ЦОД такой же, но после поменять ему ip-адресацию и все заработает, то с крупными корпоративными системами (особенно legacy) это уже не сработает. И тут приходится очень долго и нудно заниматься планированием и попыткой учесть все возможные риски. Поэтому мое мнение однозначное – таких систем нет и не будет, потому что в целом процесс миграции уникален для каждой отдельной инфраструктуры.
– Многие производители разрабатывают собственные утилиты и мастера импорта, которые помогают загрузить данные или перенести их из конкурирующих решений. Использование таких инструментов позволит существенно упростить задачу миграции и трансформации данных в нужный формат. Как правило, они не требуют написания кода, имеют удобный графический интерфейс с возможностью перетаскивания «drag-and-drop».
– Популярное решение на российском рынке – это специальное программное обеспечение Hystax Acura. Это решение для автоматического переноса ИТ-инфраструктуры в режиме реального времени. Его плюсы в том, что оно позволяет автоматизировать процессы миграции и обеспечивает сохранность данных.
Другое известное решение – это Veeam Backup & Replication, включает функцию по миграции данных, позволяет переносить виртуальные машины и данные между различными платформами виртуализации и облаками.
– Их сейчас довольно много – как платных, так и бесплатных. Из последних мне очень понравился инструмент Yandex Data Transfer. Он поддерживает много различных источников и приемников, список которых постоянно расширяется.
– Решения по автоматизации миграции данных:
– Есть несколько мер, которые помогут вам обеспечить безопасность данных при миграции:
– Под безопасностью данных при миграции понимается не только и их утечка, но и целостность данных: верифицируемость, воспроизводимость. Защищенность данных от утечки в классическом понимании предполагает миграцию данных по защищенным каналам связи. То есть мы должны настроить старую и новую инфраструктуру таким образом, чтобы соединения между ними были защищены. Мы можем использовать дополнительно виртуальные частные сети.
Что касается защиты данных от повреждений – это резервные копии и протоколы верификации данных. Дополнительно, чтобы убедиться, что требуемый файл передан корректно, желательно посчитать его хэш на старой и на новой инфраструктурах. Если хэш совпал, данные переданы корректно.
– Обеспечение безопасности данных при миграции – это крайне важный аспект, который необходимо учитывать, чтобы предотвратить потенциальные угрозы и нарушения правил безопасности. Для этого можно использовать ряд мер, например:
Эти меры помогут обезопасить данные при миграции и защитить их от возможных угроз.
– Обеспечение безопасности данных при миграции является критическим аспектом процесса. Некоторые рекомендации по обеспечению безопасности включают:
– Здесь, кстати, довольно все просто. Пример давайте возьмем из хорошо цифровизованного финансового сектора. Для того, чтобы обеспечить безопасность данных, их просто не надо выпускать из контура безопасности. Как раз этот простой шаг и позволит свести все риски безопасности к нулю.
– Для обеспечения безопасности данных при миграции необходимо использовать механизмы контроля доступа к данным и мониторинга процесса миграции. Доступ к данным должен быть только у ограниченного набора авторизованных пользователей, чтобы избежать утечки данных или их повреждения. Действия, выполняемые при миграции данных, необходимо логгировать и мониторить для обеспечения возможности своевременного выявления несанкционированных операций.
– Все зависит от конкретного сценария. Основные принципы – максимально закрывать периметр, в котором данные переносятся, и использовать шифрование. Также стоит следить за правами и доступом к исходной и конечной СУБД.
– Обеспечение безопасности данных при миграции:
– Составление плана миграции должно начинаться с анализа текущей системы и определения набора данных, которые необходимо переносить. Причем данные могут располагаться как в одном источнике, так и в нескольких.
В рамках подготовки к миграции необходимо провести сопоставление структуры исходных данных с целевой структурой в новой системе (data mapping), а также разработать правила (скрипты) трансформации данных в нужный формат.
На следующем шаге исходные данные выгружаются в формат, подходящий для дальнейшей загрузки в новую систему. Перед выполнением итоговой миграции данных рекомендуется проводить одну или несколько тестовых миграций для выявления ошибок и предварительной проверки качества загружаемых данных.
После проведения миграции необходимо также проверить загруженные данные на соответствие качеству – на наличие дублей, заполненность обязательных полей, проверки ссылочной целостности, проверки контрольных сумм и др. По результатам проверки принимается решение о завершении миграции и возможности начала эксплуатации системы.
– План переноса данных может включать следующие шаги:
Важно также не забывать о коммуникации с другими отделами и информировании пользователей о процессе миграции и его последствиях. Это позволит избежать простоев и минимизировать затраты на перенос данных.
– Каждый план миграции данных может быть индивидуальным, и он должен быть адаптирован к специфическим потребностям и условиям компании. Однако есть общие моменты, которые подойдут большинству компаний при планировании мероприятий по переносу данных:
Этап 1. Анализ и планирование:
Этап 2. Подготовка данных:
Этап 3. Настройка инструментов миграции:
Этап 4. Тестирование:
Этап 5. Миграция:
Этап 6. Проверка и верификация:
Этап 7. Внедрение и обучение:
Этап 8. Мониторинг и поддержка:
Этап 9. Оценка и оптимизация:
Важно отметить, что каждый этап плана должен быть детализирован и подробно задокументирован, чтобы обеспечить четкость и прозрачность процесса. Кроме того, коммуникация и сотрудничество с заинтересованными сторонами, включая руководство и пользователей, являются неотъемлемой частью успешной миграции данных.
– Планирование, создание копии переносимого контура или сервиса, перенос данных с продолжением работы боевого контура, перенос полезной нагрузки на новый контур, его тестирование и введение в эксплуатацию.
– Используем проверенный опытным путем план, который был отточен нашими инженерами в результате успешных миграций:
– Каждый случай миграции индивидуален. Верхнеуровнево можно описать так:
– План переноса данных:
– Если мы говорим о миграции в другую инфраструктуру, то затраты на инфраструктуру уже скорее всего увеличены, либо уже запланированы. Как правило, если мы переносим Битрикс24, то делаем это в несколько этапов. Первое – необходимо построить балансировку трафика. Затем мы можем спокойно перенести данные и переключаем балансировщик трафика на новое место. В таком случае, файлы уже переносятся на новую инфраструктуру, а базы данных находятся на старой. Это может замедлить обработку запросов, но при правильном подходе незначительно. Дальше мы используем механизмы репликации СУБД, чтобы перенести уже базы данных. Сначала создаем копию СУБД в новой структуре. Благодаря встроенным механизмам данные могут быть синхронизированы. После чего мы меняем серверы местами. То есть мастер превращается в слейв и наоборот. Когда убеждаемся, что у нас все работает, мы отключаем старую инфраструктуру.
