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

Краткий ответ: «уязвимость данных». Хотя уже определенное время существует концепция уязвимости данных, эта проблема только усугубляется из-за переноса данных в облачные инфраструктуры. По сути, уязвимость данных — это метафора, которая описывает:

• Как данные притягивают другие данные по мере роста
• Как данные интегрируются в бизнес
• Как данные со временем адаптируются под нужды заказчика

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

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

Учитывая эту особенность, рассмотрите возможность стимулирования переноса данных в состояние «стратегических инструментов», чтобы получить необходимый уровень осведомленности и ресурсов. А чтобы проекту уделялось достаточно внимания, сосредоточьтесь на наиболее слабом моменте миграции, том факте, что старая система будет отключена, и вы гарантированно получите внимание ключевых заинтересованных сторон.

Модернизация систем или расширение ЦОД в облако дает множество преимуществ для бизнеса. Для многих компаний это совершенно естественный этап эволюции. Компании, использующие облачные технологии, надеются, что смогут сосредоточиться на приоритетных направлениях, ускорить рост, повысить гибкость, сократить капитальные расходы и платить только за то, что им нужно по требованию. Однако от типа миграции зависит, сколько времени ИТ-персонала можно будет высвободить для работы над другими проектами.

Во-первых, давайте определим типы миграции:

• Перенос данных из СХД. Процесс переноса данных из существующих массивов в более современные позволяет открыть доступ для других систем. Обеспечивает значительно более высокую производительность и более экономичное масштабирование, а также ожидаемые функции управления данными, такие как клонирование, создание снимков, резервное копирование и аварийное восстановление.
• Миграция в облако. Процесс перемещения данных, приложений и других бизнес-элементов из собственного ЦОД в облако или из одного облака в другое. Во многих случаях этот процесс сопровождается переносом данных из СХД.
• Перенос приложений. Процесс переноса прикладных программ из одной среды в другую. Может включать перемещение всего приложения из собственного ЦОД в облако, перемещение между облаками или простое перемещение базовых данных приложения в новую форму, размещенную поставщиком программного обеспечения.

Перенос данных включает 3 основных этапа:

1. Извлечение данных
2. Преобразование данных
3. Загрузка данных

Перемещение важных или конфиденциальных данных и вывод из эксплуатации устаревших систем может переместить заинтересованных лиц на периферию. Наличие продуманной схемы является обязательным, однако, вам не нужно заново изобретать колесо. В Интернете можно найти множество примеров планов переноса данных и контрольных списков. Например, Data Migration Pro, сообщество специалистов по переносу данных, предлагает полный контрольный список, в котором описан процесс, состоящих из 7 этапов:

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

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

Хотя перенос данных является обычной практикой ИТ на протяжении десятилетий, о ней продолжают рассказывать всякие ужасы. Давайте посмотрим на 10 основных проблем, с которыми сталкиваются компании при перемещении данных:

1. Отсутствие связи с ключевыми заинтересованными сторонами. Независимо от размера переноса, есть кто-то, кто заботится о перемещаемых данных. Прежде чем приступить к выполнению задания данные необходимо отследить и разъяснить, зачем это следует сделать, и какое перенос повлияет на проект. Если вы этого не сделаете, вы наверняка на каком-то этапе узнаете, что они, скорее всего, они нарушат ваш график.

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

3. Отсутствие управления данными. Убедитесь, что вы четко знаете, кто имеет право создавать, утверждать, редактировать и удалять данные из исходной системы и переводить их в письменной форме в рамках плана проекта.

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

5. Отсутствие планирования. В среднем, каждая семья тратит от 10 до 20 часов на планирование отпуска, при этом ИТ-специалисты могут тратить в два раза меньше времени на планирование небольшого переноса данных. Время, потраченное на планирование, не всегда гарантирует успех, но наличие надежной схемы переноса данных позволяет сэкономить несколько часов при фактическом перемещении данных.

6. Нехватка программного обеспечения и навыков подготовки данных. Если перенос большой (миллионы записей или сотни таблиц), стоит вложить деньги в первоклассное программное обеспечение для обеспечения качества данных и подумать о найме специализированной фирмы для оказания помощи. Хорошие новости: внешняя компания, вероятно, даст необходимо программное обеспечение в аренду, чтобы снизить расходы.

7. Ожидание идеальных целевых характеристик. Если группа внедрения сортирует критерии проектирования, просто пропустите этапы 2 и 3. Целевая готовность будет иметь значение для проекта в дальнейшем, но это не должно мешать вас сейчас.

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

9. Управление поставщиками и проектами. Необходимо управлять поставщиками и проектами. Если вы одновременно выполняете свою повседневную работу, убедитесь, что у вас есть время для управления проектом и всеми связанными с ним поставщиками.

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

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

Термин «преобразование данных» относится к процессу изменения данных из одного формата в другой. Изменение требуется при перемещении данных из старого приложения в обновленную версию того же приложения или в другое приложение с новой структурой. Для преобразования данные необходимо извлечь из источника, изменить и загрузить в новую целевую систему с учетом ее набора требований.

Есть еще один термин, с которым перенос данных иногда путают — это интеграция данных. Интеграция данных — это процесс объединения данных, хранящихся в разных источниках, чтобы обеспечить унифицированное представление всех данных. Интеграция данных из нескольких источников является необходимым условием для аналитики. Пример интеграции данных: хранилища данных, озера данных иNetApp^® FabricPools автоматизируют разделение данных на уровни между локальными ЦОД и облаками, или автоматически распределяют данные между блочной СХД AWS EBS и объектными СХД AWS S3.

Переход к модели «инфраструктура как сервис» (IaaS):

• Повторное размещение (перенос по принципу Lift & Shift). Повторное развертывание данных и приложений в IaaS без внесения изменений
• Пересмотр (перепланирование). Изменение или расширение существующего кода приложения в соответствии с новой облачной средой.
• Замена. Удаление устаревших приложений, размещенных на площадке, с помощью сравнимого приложения, размещенного в облаке, например Office365.

Переход к модели «платформа как услуга» (PaaS):

• Реорганизация кода. Введите код и запустите приложение в облаке.
• Перестройка кода. Удалите код существующего приложения и перепроектируйте его для облака.

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