Миграция данных при переходе на новую платформу. Технология проведения миграции данных в крупных проектах. Плюсы, минусы, выводы


как внедрить свободное ПО

Миграция на свободное ПО подобна миграции на более новую операционную систему. Как пример, можно упомянуть появление первых вариантов Windows в нашей стране. Не менее яркий пример – миграция на Windows NT, идеология работы в которой резко отличалась от Windows 9x. Можно привести еще один пример -- каждая новая версия пакета MS Office отличается от предыдущей не только отличиями в интерфейсе, но и форматами файлов. Итак, задача миграции является актуальной даже в таком случае, когда используется ПО от единственного производителя.

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

создание рабочей группы (кто делает)

При осуществлении миграции необходимо предусмотреть решение вопросов как технического, так и нетехнического характера.

Важно рассмотреть правовые проблемы, которые в последнее время черезвычайно актуально стоят для некоторых стран СНГ, в частности, Украины. В некоторых случаях осмысленно обсудить административные задачи взаимоотношений "работодатель-пользователь-администратор". Исторически сложилось, что эти отношения недостаточно регламентированы внутрикорпоративными правилами и инструкциями.

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

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

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

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

Целью проекта является построение экономически оправданной ИТ-инфраструктуры. Хорошим кандидатом на должность руководителя рабочей группы будет топ-менеджер предприятия или организации, к примеру – финансовый директор. Естественно, в данную группу входит начальник ИТ-департамента, который владеет видением всей ИТ-инфраструктуры как на данный момент, так и в перспективе. В составе группы обязателен опытный системный администратор, желательно с опытом эксплуатации свободного ПО. Размер группы невозможно оценить – в некоторых случаях привлекаются при необходимости иные сотрудники фирмы. Возможно привлечение стороннего консультанта с опытом, или – специализирующейся на подобных решениях фирмы. Результатом работы данной группы является развернутый план миграции с оценкой стоимости миграции. Либо – пояснения неэффективности миграции на свободные решения для организации.

исследование (что есть)

Первым этапом должен быть аудит – описание существующей (унаследованной) системы.

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

Результатом процесса аудита являются:

Описание технических характеристик установленного ПО;

Список выявленных рисков, связанных с использованием нелицензионного ПО;

Подсчет стоимости приобретения лицензий на установленное ПО;

Подсчет стоимости удаления нелицензионного и установки лицензионного ПО;

Определение целесообразности дальнейшего использования ПО;

Список выявленных рисков, связанных с использованием ПО;

инвентаризация ПО

Некоторые исследования показывают, что большинство руководителей организаций большее внимание уделяют функциональности используемого ПО и гораздо меньше – соблюдению прав на используемые продукты.

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

Инвентаризация ПО позволяет выявить нелицензионное ПО в организации. Следует подчеркнуть, что данное мероприятие всегда выгодно. Результатом инвентаризации можно воспользоваться для оценки затрат на легализацию ПО как с использованием свободного, так и с использованием несвободного ПО.

Руководители организаций часто заинтересованы в четком финансовом планировании затрат на использование и развитие программного обеспечения. Заинтересованность топ-менеджеров в такой подобной детализации вполне понятна – топ-менеджмент компаний заинтересован в превращении ПО в актив компаний, который учитывается, контролируется и развивается аналогично другим видам активов.

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

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

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

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

Для средних и крупных можно рекомендовать использование специализированного ПО или пригласить стороннюю организацию, специализирующуюся на подобных услугах. В процессе создания документа были проведены работы по обзору средств автоматической инвентаризации программного и аппаратного обеспечения (известны программы GASP, PC inventory, MSIA). Рекомендацией может стать eXponent Navigator (http://www.e-x.ru/pages/expnav.html), производства eXponent.

Exponent Navigator

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

По утверждению создателей программы, после организации автоматического сбора сведений о компьютерах есть возможность просматривать и упорядочивать эту информацию, подготавливать печатные отчеты и веб-публикации, выгружать данные в Microsoft Excel, XML и другие форматы. Возможности:

Автоматическая диагностика конфигурации компьютеров;

Автоматический сбор информации о компьютерах по сети;

Определение установленного оборудования;

Определение установленных программ;

Определение файловых характеристик;

Расширенные возможности сортировки, поиска и отбора данных;

Подготовка печатных отчетов;

Экспорт данных в MS Excel;

Автоматическая генерация веб-публикаций.

В бесплатном варианте программы существует ограничение – учет до 25 компьютеров; стоимость лицензии составляет $1 за 1 компьютер.

проектируем (что хотим)

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

Существует масса литературы, в том числе русскоязычной, о Linux, в которой описано преимущество этой платформы с технологической точки зрения. Однако, все эти преимущества имеют значение вместе с главным вопросом – существованием широкого спектра прикладного ПО разного направления. Достаточно давно и широко распространен миф о том, что под платформу Linux существует ограниченное количество прикладного программного обеспечения для корпоративного пользования, в том числе офисной автоматизации. В подавляющем большинстве эти мифы создаются и подпитываются создателями и продавцами проприетарного ПО и имеют мало общего с действительностью. Развенчание данного мифа не является главной целью данной книги. Тем не менее, стоит заметить, что, к примеру, широта прикладного ПО является абсолютным фантомом с учетом сложившихся исторически стандартов на обмен документов. Так, к примеру, фактическим стандартом офисного редактора является Microsoft Office, редактором растровой графики – Adobe Photosop, а в качестве векторной графики черезвычайно распространен Corel Draw.

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

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

Однако, в данный момент документ только создается и информацию можно найти в разных источниках. Невозможно пройти мимо материалов Valery V. Kachurov, Несов Артем “Аналоги Windows-программ в Linux – таблица соответствий.” (http://linuxshop.ru/linuxbegin/win-lin-soft/). Этот ресурс содержит массу ценной информации. К сожалению авторы, кажется, забросили этот труд. Данный раздел сайта регулярно недоступен, но копию таблицы можно найти по адресу http://www.blif.net/modules.php?name=LinWin. Можно посоветовать ресурсы Open Source Applications Foundation
(http://www.osafoundation.org/), особенно http://www.osafoundation.org/desktop-linux-overview.pdf.

Результатом являются:

Создания прототипа рабочих станций;

Подсчет стоимости лицензий на предлагаемое ПО;

Обучения пользователей;

Создание примерного календарного плана внедрения;

Список рисков при внедрении свободного ПО;

Поддержки свободных решений;

Подсчет экономической эффективности новой системы на срок до пяти лет.

пилотный проект (проверка боем)

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

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

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

Экспериментальный этап особенно востребован:

Если не была доказана возможность миграции пользователей от унаследованной системы к новой системе;

Если есть пользовательский скептицизм, который будет способен затормозить процесс миграции;

Организация испытывает недостаток корпоративной культуры (что, к сожалению распространено на территории СНГ);

Если есть ограниченные ресурсы для крупномасштабной миграции;

Организация большая, и в экспериментальный проект не вовлечено много пользователей;

Если унаследованные проприетарные системы стремительно эволюционировали как в - техническом плане, так и в снижении стоимости;

Не выяснен полностью экономический эффект миграции.

Чтобы преуспеть, пилотный проект:

Не должен относиться к критическому участку бизнеса;

Должен быть достаточно важен для бизнеса;

Не должен требовать черезмерного ресурса людей, которые уже ограничены во времени;

Должен иметь существенную группу поддержки;

Должна быть обеспечена обратная связь с пользователями (системы Help Desk);

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

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

Описание прототипа рабочих станций;

Описание специфических настроек пользователя:

Средние затраты на развертывание типов станций;

Переноса данных из наследованной системы в новую;

Обучения пользователей;

Подсчет стоимости внедрения ПО;

Поддержки свободных решений.

планирование (что и как)

1. Создание плана миграции. План миграции должен отвечать на вопросы:

Описание фаз построения системы;

Определение потребностей поддержки;

Описание завершения миграции.

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

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

План должен отвечать на следующий вопросов:

В какой степени и какими этапами система должна быть установлена и развернута, чтобы максимально удовлетворять потребностям пользователей?

Что необходимо для каждой фазы миграции на новую систему от клиентов организации и пользователей системы?

Каково будет воздействие и риск использования системы на каждом этапе приращения?

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

3. Определение потребностей поддержки. Нужно обеспечить оптимальный уровень поддержки, чтобы помочь пользователям в использовании новой системы. Кроме того, пользователи часто требуют, чтобы служба поддержки помогла им понять общие способности(возможности) целевой системы.

Вопросы, которые необходимо решить, включают:

Какого обучения и помощи в эксплуатации пользователи будут требовать?

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

Как достигнуть принятия целевой системы пользователями и избежать сопротивления пользователей внедрению новой системы?

Каким образом будут сообщаться клиентам и пользователям неизбежные изменения в особенностях систем и услугах?

Возможна ли поддержка свободного решения ИТ подразделением организации или лучшим вариантом будет аутсорсинг?

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

Система сообщения неприятностей;

Службы технической помощи для новых систем;

Техническая помощь пользователям, мигрирующим к новым системы;

Руководства пользователей на переходной и последующий периоды;

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

Возможность испытания использования новых систем;

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

Преодоления текущих эксплуатационных проблем.

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

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

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

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

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

Установить стимулы к действиям полностью перейти на новую свободную систему и устранить зависимости от унаследованных систем;

Предусмотреть помощь (программное обеспечение и дополнительный персонал) для преобразования унаследованных данных в новую систему; - порядок вывода из эксплуатации унаследованных систем;

Архивирование данных унаследованных систем и их хранение.

миграция (делаем)

Все, что остается на последнем этапе – работать согласно плану.

Активно управляйте и контролируйте процессы миграции:

Установите критерии измерения и отслеживайте этапы миграции и затраты ресурсов на миграцию;

Делайте периодические обзоры ситуации и ознакомливайте с ними, согласно полномочий и организационной политикой, заинтересованных людей (руководство, менеджеров проектов и спонсором);

Устанавливайте систему отслеживания (tracking), чтобы управлять продвижением процессов (прогрессом), проблемами, решениями, и другими деловыми вопросами, которые относятся к планированию миграции и выполнению планов.

Вадим Машков, UA-FOSS, [email protected]

  • перевести существующие домены ресурсов в организационные единицы новых доменов, что позволит упростить управление сетевыми ресурсами;
  • "имитировать" ход миграции, при этом реального переноса данных не происходит;
  • отменить сделанные действия, связанные с миграцией;
  • переместить учетные записи служб;
  • восстановить доверительные отношения между исходным и целевым доменами;
  • преобразовать множество доменов в один или несколько крупных доменов в уже созданной среде Active Directory;
  • реструктуризировать существующие группы или объединить несколько групп в одну в целевом домене ;
  • провести анализ процесса переноса данных с помощью журнализации миграционных событий.

Миграция пользователей и рабочих станций в единую структуру Active Directory реализуется с сохранением существующих прав доступа.

Варианты модернизации

Существует два основных варианта модернизации доменной инфраструктуры [ 4 ] :

  • Обновление доменов. Данный способ является наиболее распространенным и простым для реализации при миграции доменов. Этот способ позволяет сохранить текущую структуру доменов, настройки системы, структуру пользователей и групп. Обновление домена (in-place обновление) включает перевод контроллеров существующего домена в создаваемый домен .
  • Реструктуризация доменов. Данный способ позволяет изменить существующую структуру доменов, объединить домены или преобразовать домены в организационные подразделения.

Помимо указанных выше вариантов, существует также смешанный вариант, основанный на них, - обновление доменов с их последующей реструктуризацией [ 13 ] .

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

Критерии выбора пути перехода

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

Рассмотрим основные критерии, которые используются при выборе наиболее подходящего пути перехода [ 13 ] , приведенные в таблицах 12.1 , 12.2 , 12.3 , 12.4 , 12.5 , 12.6 .

  • Критерий 1. Удовлетворенность имеющейся моделью существующего домена . Таблица 12.1. Выбор пути перехода по критерию 1
    Путь перехода Соответствие критерию
    Обновление домена Если нет никаких существенных изменений, которые хотелось бы сделать в доменной модели, то обновление домена обеспечит самый легкий путь. Имя домена останется тем же самым, так же как и существование всех учетных записей пользователей и групп
    Реструктуризация домена Если имеющаяся доменная модель больше не удовлетворяет организационным потребностям либо больше не является наиболее оптимальной для подразделений организации, то наилучшим выбором будет реструктуризация домена
  • Критерий 2. Степень риска при переходе к новой модели домена. Таблица 12.2. Выбор пути перехода по критерию 2
    Путь перехода Соответствие критерию
    Обновление домена Обновление домена представляет собой метод с минимальным риском. Процесс модернизации контроллера домена выполняется автоматически, следовательно, без взаимодействия с пользователем возможностей для ошибок возникает немного. Методология восстановления после сбоя при обновлении домена также относительно проста: если обновление прошло неудачно, необходимо выключить основной контроллер домена ( PDC ), назначить любой резервный контроллер домена ( BDC ), имеющий свежие данные, на роль PDC , и начать процедуру снова
    Реструктуризация домена Реструктуризация домена представляет собой путь с более высоким риском, чем обновление домена. Надо выполнить большее количество задач, и поэтому многие процессы могут идти не так как надо. В результате растет недовольство пользователей, которые не могут войти в систему, обратиться к необходимым ресурсам или получить доступ к своим почтовым ящикам
  • Критерий 3. Время выполнения перехода 1График времени перехода не является решающим фактором при выборе пути перехода, тем не менее он может быть определяющим для небольших организаций с ограниченными ресурсами. . Таблица 12.3. Выбор пути перехода по критерию 3
    Путь перехода Соответствие критерию
    Обновление домена Обновление домена - это линейный процесс: если он был начат, то должен быть закончен. Для него требуется меньше действий, чем для реструктуризации, и, соответственно, меньше времени требуется для выполнения всего перехода
    Реструктуризация домена Реструктуризация домена всегда длится дольше. Например, при реструктуризации тратится много времени на создание и проверку инфраструктуры целевого домена, на перемещение всех учетных записей с исходного домена на целевой домен. Крупные организации, возможно, не смогут переместить все объекты за один раз, так что достаточно часто реструктуризация домена производится в несколько этапов
  • Критерий 4. Рабочее время службы каталога, которое необходимо затратить на процесс перехода. Таблица 12.4. Выбор пути перехода по критерию 4
    Путь перехода Соответствие критерию
    Обновление домена Объекты учетных записей недоступны в процессе перехода, потому что они самостоятельно модернизируются при обновлении домена
    Реструктуризация домена Хороший выбор для организаций, в которых рабочее время системы является критической величиной. Так как она включает создание незаполненного, "чистого" леса и оставляет исходную среду по существу без изменений, то работоспособность службы каталога сохраняется, поскольку пользователи продолжают функционировать в существующей среде. Можно переносить большие или маленькие партии пользователей в течение непиковых часов работы и оставлять эти новые учетные записи бездействующими до того времени, как появится готовность покинуть старую систему
  • Критерий 5. Наличие ресурсов для выполнения перехода. Таблица 12.5. Выбор пути перехода по критерию 5
    Путь перехода Соответствие критерию
    Обновление домена Поскольку обновление домена является автоматизированной операцией, то на реализацию этого пути перехода потребуется меньшее количество людских ресурсов
    Реструктуризация домена Реструктуризация домена влечет за собой большее количество задач, чем обновление домена, и поэтому требуется большее количество ресурсов, то есть необходимо, чтобы штат сотрудников был адекватно укомплектован для выполнения дополнительной рабочей нагрузки, связанной с реструктуризацией домена. В качестве альтернативы можно переложить часть задач или весь проект на внешних сотрудников: существует множество консультативных групп, которые специализируются на таких проектах, что позволит сэкономить время и деньги, необходимые для обучения внутренних сотрудников
  • Критерий 6. Бюджет проекта перехода. Таблица 12.6. Выбор пути перехода по критерию 5
    Путь перехода Соответствие критерию
    Обновление домена Факторы, способствующие уменьшению необходимых бюджетных средств:
    • возможность использовать существующие серверные аппаратные средства;
    • более низкие затраты на людские ресурсы;
    • уменьшение расходов на тестирование, поскольку нужно будет тестировать меньшее количество задач модернизации
    Реструктуризация домена По многим причинам реструктуризация домена потребует большего бюджета, чем обновление домена. Аппаратные требования, необходимые для построения незаполненной среды леса, в которую необходимо переносить объекты службы каталога, следует рассмотреть с точки зрения бюджетных затрат

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

Данный путь перехода к Active Directory позволит получить немедленную выгоду (делегирование администрирования, групповые политики , публикация приложений и многое другое), а также долговременную выгоду от реструктуризации домена (меньшее количество доменов с увеличенным объемом домена, проект домена в соответствии с деловыми и организационными целями компании).

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

Как это бывает
Выбор новой системы PLM был сделан, команда руководителей с облегчением празднует результат сложных усилий этого выбора. На деле, только теперь начинается настоящая работа, планирование и осуществление миграции данных из существующих систем в новую целевую платформу PLM. Существующие данные компании содержат значительную часть интеллектуальной собственности (ИС) и, следовательно, конкурентные преимущества и капитал компании. Успех внедрения новой системы в значительной степени зависит от выполнения эффективной миграции существующих данных, интеллигентно, качественно и своевременно.

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

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

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

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

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

Наиболее существенно то, что работоспособность этой схема многократно подтверждена выполненными проектами миграции данных PLM у многочисленных клиентов PRION. Более того, неоднократные попытки произвести прямую трансляцию данных из одной системы PLM в другую доказали 100% неработоспособность такого примитивного подхода. Среди факторов, определяющих такое положение дел: сбор данных из нескольких источников, необходимость преобразования и чистки данных, их аттестации и загрузки в новую систему (ы), которые также могут быть физически распределены. Таким образом, существуют совершенно неприемлемые при переходе на новую платформу PLM.

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

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

Для получения более детальной информации об инструментах и услугах PRION рекомендую обратиться на сайт

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

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

Проблемы миграции

Когда речь идет о миграции транзакционных систем, таких как ERP, билинг, процессинг или АБС, переход на новую систему происходит весьма проблематично. Дело в том, что ИТ-специалистам необходимо обеспечить точную миграцию больших объемов данных, поддерживая параллельную работу старой и новой системы для проведения сверок и анализа результатов.

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

От системы отдела к уровню предприятия

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

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

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

План действий

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

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

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

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

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

Сергей Бердачук, 1.0 2006.12.01

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

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

Мало того, каждый новый разработчик обычно не утруждает себя тщательным изучением ни кода, ни архитектуры системы. Так как сроки всегда «горят», то просто пишутся «примочки» для временного решения насущной проблемы. В результате получается «каша», состоящая из множества разношерстных модулей и каким то чудесным образом состыкованных технологий, которые порой не совместимы друг с другом. Положение усугубляется использованием устаревших систем управления базами данных (СУБД) для хранения данных, например dbase-III, FoxPro или Clipper. Отсутствие понятия транзакции, а при неумелом проектировании и ссылочной целостности приводит к многочисленным нарушениям целостности данных. Можно считать, что повезло, если в старой системе использовалась СУБД, иногда встречаются творения, использующие текстовые файлы для хранения данных (при миграции одной из таких систем автору пришлось писать специальный драйвер для доступа к такой базе данных).

Пожалуй, единственным положительным моментом является накопленный опыт по формированию требований к вновь разрабатываемой ИС. С другой стороны, опыт общения со старой системой может стать существенным тормозом при внедрении нового продукта. Чаще всего это возникает из-за различий построения визуального интерфейса и используемых функциональных клавиш для выполнения некоторых операций. Так, часть функциональных клавиш может быть зарезервирована операционной системой для выполнения некоторых действий. Типичным примером является применение клавиши “Enter” для перехода к следующему элементу редактируемой формы в старых ИС под DOS. В графических интерфейсах обычно для этих целей применяется клавиша “Tab”. В результате, мы получаем жесткое противодействие со стороны пользователей при внедрении новой версии продукта. Конечно, можно эмулировать поведение UI (User Interface) интерфейса старой системы, но делать это лучше всего опционально. Т.е. ввести возможность настройки поведения системы в модуле конфигурирования ИС, а по умолчанию использовать настройки соответствующие текущей операционной системе. В противном случае, вновь разработанный продукт будет труден в освоении новыми пользователями, которые ожидают поведения программы в соответствии с текущими стандартами.

Что же касается работы с хранимыми данными старой системы, то тут положение еще хуже. Наиболее тяжелые последствия будет иметь решение руководства использовать часть модулей старой системы. Например, когда перед нами стоит задача разработать новую версию складского учета, а решением остальных задач (бухучет и т.д.) пока будет заниматься старая версия ИС. В данном режиме работы встает проблема миграции данных в «реальном» режиме времени. Накладные расходы, по поддержанию работы всех модулей в целом могут превысить затраты на разработку новой версии всех модулей. Причем затраты могут отличаться на порядки, с учетом возможных потерь от недочетов старой системы и ошибок при обмене и преобразовании данных. Так что следует тщательно оценить состояние старой ИС и целесообразности. И что самое интересное, на практике данная проблема обычно не затрагивается, вплоть до возникновения: “Вот создадим новую систему, а потом и будем заниматься стыковкой с другим программным обеспечением и мигрировать данные”.

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

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

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

Рис. 1. Вариант с промежуточной программой для миграции данных


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

Более выгодным решением может быть предварительная загрузка старых данных во временные таблицы новой СУБД. Современные СУБД (например, Oracle) обычно содержат специальные утилиты, которые позволяют производить очень быструю закачку внешних данных различных форматов. Непосредственно модуль миграции пишется встроенными в СУБД процедурными языками (например, PL/SQL или java). Можно существенно повысить скорость выполнения процедуры миграции за счет того, что встроенные языки программирования работают в “родной” среде, оптимизированы под целевую СУБД и нет накладных расходов на обмен данными по сети.

Рис. 2. Вариант миграции данных средствами СУБД


Из практического опыта написания таких программ хочется обратить внимание на использование пакетных SQL методов, которые поддерживаются большинством СУБД и языками программирования (например, методы addBatch() и executeBatch() в java). Выполнение одного оператора добавления INSERT или обновления UPDATE для массива данных пачками по 100 - 200 записей дает существенный выигрыш производительности, в сравнении с выполнением данного оператора поочередно в цикле для каждой записи.