- перевести существующие домены ресурсов в организационные единицы новых доменов, что позволит упростить управление сетевыми ресурсами;
- "имитировать" ход миграции, при этом реального переноса данных не происходит;
- отменить сделанные действия, связанные с миграцией;
- переместить учетные записи служб;
- восстановить доверительные отношения между исходным и целевым доменами;
- преобразовать множество доменов в один или несколько крупных доменов в уже созданной среде 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 позволит получить немедленную выгоду (делегирование администрирования, групповые политики , публикация приложений и многое другое), а также долговременную выгоду от реструктуризации домена (меньшее количество доменов с увеличенным объемом домена, проект домена в соответствии с деловыми и организационными целями компании).
Современные компании нередко встают перед необходимостью миграции своих информационных систем. Однако выполнению данной процедуры должна предшествовать тщательная подготовка, так как на этом пути возникает немало препятствий.
Причин для начала перехода в новую информационную систему (ИС) может быть великое множество — это и снижение рисков, связанных с эксплуатацией устаревших платформ, и приведение информационных систем к международным стандартам, и повышение эффективности бизнес-процессов. Но независимо от того, какая задача стоит перед компанией, переход из одной ИС в другую нужно тщательно спланировать и подготовить.
Проблемы миграции
Когда речь идет о миграции транзакционных систем, таких как ERP, билинг, процессинг или АБС, переход на новую систему происходит весьма проблематично. Дело в том, что ИТ-специалистам необходимо обеспечить точную миграцию больших объемов данных, поддерживая параллельную работу старой и новой системы для проведения сверок и анализа результатов.
Например, у меня был опыт проекта в одном из крупнейших банков, где проходил переход транзакционной системы с уже не поддерживаемой платформы Informix на платформу Oracle. При этом пришлось производить тщательный анализ бизнес-процессов, многократный перенос данных из старой системы в новую и проверять соответствие результатов работы новой и старой систем с учетом длительности регламентов процессов. Именно поэтому срок миграции составил 14 мес. Иногда параллельная работа двух систем может продолжаться и более длительное время, но даже тогда, когда она ограничивается несколькими месяцами, для обеспечения работы новой ИС требуется выделение дополнительных вычислительных мощностей и значительного времени сотрудников предприятия для одновременного выполнения задач в двух системах.
От системы отдела к уровню предприятия
Нередко обновление ИС происходит в рамках глобализации и централизации. Это позволяет значительно сократить расходы на поддержку и обновление программных комплексов. Действительно, следить за единой платформой, обслуживающей всех сотрудников, значительно проще, чем поддерживать отдельные инструменты для каждого подразделения. Например, успешная миграция системы учета материально-технических ресурсов позволяет перевести несколько тысяч подразделений крупной организации на единую платформу и обеспечить серьезное сокращение издержек на ИТ. Однако следует помнить, что большая часть подготовки в данном случае приходится на согласование данных в различных форматах и представлениях, разработку новых регламентов и построение новых моделей взаимодействия сотрудников.
Еще один важный аспект — интеграционные интерфейсы с другими ИС предприятия, особенно самописными и специфическими. Проблемы, связанные с ними, могут быть не столь заметны на первом этапе, но выявляются при налаживании взаимодействия различных подразделений с общей системой. И если для старой системы такие интерфейсы уже были реализованы программно или организационно, то для новой системы их, возможно, придется разрабатывать заново.
Следует помнить, что мысли о расширении функционала системы могут прийти уже во время реализации проекта, как аппетит приходит во время еды. А это значит, что потребуется провести целый ряд дополнительных работ.
План действий
Опыт проектной деятельности по миграции систем показывает, что любой подобный проект требует тщательной подготовки и должен сопровождаться индивидуальным планом. Однако независимо от типа мигрируемых систем, программного обеспечения, объемов баз данных и пр. общая схема выглядит практически идентично.
На первом этапе необходимо провести подробный аудит, выяснив все требования, предъявляемые к режиму функционирования новой системы, опросив всех ключевых пользователей. Важно понять, о каких объемах данных, какой нагрузке идет речь, только тогда специалисты смогут предложить верную стратегию миграции.
Сами процедуры также должны быть тщательно продуманными и включать в себя такие важные элементы, как регламент доступа пользователей к системам во время миграции, процедуры отката к предыдущему состоянию в случае сбоев и порядок взаимодействия различных специалистов, участвующих в этих процессах.
После согласования с заказчиком обычно происходит составление подробного плана, который подразумевает несколько этапов, а именно: копирование данных, их верификацию, параллельную работу двух систем и полный переход на новую платформу. На мой взгляд, главное в профессионально организованной миграции систем — плавность данного процесса для пользователей, которые могут постепенно, без стресса начать работать в новой автоматизированной системе.
Впрочем, даже тщательная подготовка не всегда спасает от недооценки трудозатрат при переводе пользователей на “новые рельсы”. В этот процесс входит как проведение обучения сотрудников компании, так и их поддержка в период адаптации к новой системе.
Миграция данных невероятно сложная и ответственная задача. Она влечет за собой определенный уровень коммерческого и технического риска. Потребность в миграции данных может возникнуть при переходе на новую систему, например при внедрении SAP или при подключении к уже продуктивной системе новых справочников или даже отдельных систем. В любом случае можно однозначно сказать, что миграция это процесс переноса данных из устаревших систем на новую платформу.
Как и в любую другую систему должна быть проведена максимально качественно и правильно. Только успешно выполненная миграция данных позволит начать успешную продуктивную эксплуатацию.
В большинстве случаев миграция данных требует индивидуального подхода и определённого опыта.
- Необходимо заранее заранее определить стратегию миграции данных. Слабое понимание процесса и не достаток опыта не повод относиться халатно к миграции данных;
- Обязательно должен быть составлен план миграции данных и назначены ответственные сотрудникам и ключевые пользователи;
- Определить какие основные данные (материалы, контрагенты, банки, и пр.) и какие транзакционнные данные (заказы, открытые позиции и пр.) будет участвовать в миграции данных;
- Определить периоды и объемы данных;
- Подготовить регламенты и методики миграции данных;
- Нормализация и структуризация данных. Так же очень важный шаг при миграции данных. Не бывает такого, чтобы было слишком рано начинать очистку данных от мусора (дубли, не полные и не однозначные записи). Пропуская этот шаг помните, что мусорные данные приведут к проблемам в эксплуатации SAP и могут стоить компаниями намного дороже, чем во время сделанная очистка данных;
- При миграции данных должны быть обязательно разработаны понятные шаблоны сбора и загрузки данных. Это так же ответственный шаг, ключевые пользователи должны однозначно понимать что и как заполнять в шаблоне;
- Разработать средства загрузки данных. Средства должны быть понятны и удобны для сотрудников НСИ, а так же содержать проверки и защиту от человеческого фактора. А так же загрузчики данных должны уметь быстро загружать данные. За частую процесс загрузки готовых шаблонов с данными занимает не более 5 дней;
- Контроль процесса миграции данных должен производиться на всех этапах, как во время тестовой миграции данных, так во время пилотного запуска и продуктивной загрузки данных.
- Заключительный этап, после продуктивной миграции данных, это проверка качества загруженных данных. Помните, что исправить все проще на ранних стадиях. По этому только убедившись в 100% качестве загруженных данных следует начинать продуктивную эксплуатацию системы.
Мы специализируемся на комплексном подходе к миграции основных данных и справочников НСИ.
- Составим план миграции, включающий ответственных и очередность загрузки справочников;
- Определим вместе с вами объемы и сроки миграции данных;
- Напишем методики и регламенты миграции данных;
- Проведем нормализацию, консолидацию и классификацию данных;
- Подготовим шаблоны для миграции данных, с понятным описанием их заполнения;
- Напишем загрузчики для миграции данных. Мы разрабатываем загрузчики стандартными средствами SAP, в частности LSMW, гарантирует качественную и стабильную загрузку данных;
- Проведем тестовую и продуктивную миграцию данных;
- Проверим качество загруженных в систему данных.
Разработка общих требований к миграции данных
В рамках разработки общих требований к миграции данных бизнес-аналитиком должна быть определена стратегия миграции данных. Исходя из потребностей бизнеса, режима функционирования организации-заказчика, должна быть выбрана миграция «большого взрыва» или плавная миграция.
При выборе стратегии «большого взрыва» должно быть определено время, которое может быть затрачено бизнесом на простой во время миграции данных. После определения времени, которое бизнес может потратить на простой во время миграции данных может быть составлен график миграции данных. При составлении графика миграции данных должен быть выделен резервный день или дни, необходимые для повторной миграции в случае серьезных ошибок.
При выборе стратегии плавной миграции все бизнес-пользователи целевой системы должны быть разделены на группы, для которых должен быть составлен график переключения на работу с целевой системой. После деления бизнес-пользователей на группы должны быть определены соответствующие им наборы данных и сущностей. При распределении бизнес-пользователей по группам должны учитываться взаимосвязи этих групп в рамках бизнес-процесса, автоматизируемого в целевой системе.
Параллельно с выбором стратегии проведения миграции данных менеджментом проекта и/ или бизнес-аналитиком должна быть произведена выявление типовых рисков миграции данных. Для каждого выявленного риска должна быть выбрана стратегия (методы) работы с риском и разработан комплекс мероприятий по предотвращению риска. Стратегией предотвращения риска может быть одна из следующих :
- · отказ от чрезмерно рисковой деятельности (метод отказа),
- · профилактика или диверсификация (метод снижения),
- · аутсорсинг затратных рисковых функций (метод передачи),
- · формирование резервов или запасов (метод принятия).
В таблице 1, приведена матрица типовых рисков миграции данных и способы работы с каждым из таких рисков. В ячейках матрицы приведены примеры мероприятий по работе с каждым из рисков в рамках каждого метода предотвращения риска.
При составлении таблицы предполагалось, что стратегия «Отказ» не является приемлемой для проектной команды, так как предпосылкой для исследования является необходимость выполнять работы по миграции. Таким образом, отсутствует возможность полного или частичного исключения таких работ из скоупа проекта.
Таблица 1 Матрица рисков и возможных стратегий работы с рисками этапа миграции
|
Стратегия работы с риском |
Снижение |
Передача |
Принятие |
|
|
Риски составления технической спецификации |
Проработка требований к миграции совместно с бизнесом, владельцами и потребителями мигрируемых данных |
Привлечение к работам по составлению технической спецификации консультантов |
Формирование резерва бюджета и времени на проекте для работы с потенциальными запросами на изменение |
|
|
Риски тестирования |
Проработка тестовых планов и сценарием с привлечением бизнес-пользователей |
Передача пакета работ по тестированию отдельной команде с заранее определенными условиями приемки их резудьтатов |
Формирование резерва времени и бюджета на потенциальные дополнительные работы вследствие неполного тестирования миграционного ПО и размещенных данных |
|
|
Риски процесса получения и загрузки данных |
Проработка требований к тестовой выгрузке. Проведение «тестовой» миграции с использованием тестовой выгрузки |
Формирование резерва бюджета и времени для повторных получений выгрузок и итеративной загрузки |
||
|
Стратегия работы с риском |
Снижение |
Передача |
Принятие |
|
|
Риски, связанные с работой проектной команды |
||||
|
Риски размещения данных в целевой системе |
Параллельная проработка модели данных “as is” и “ to be” для нивелирования различий в форматах и способах работы с данными в источнике и приемнике |
Формирование резерва времени и бюджета для доработок функциональности системы-приемника |
Организация планирования работ по миграции данных
Входной информацией для составления планов работ по миграции является стратегия миграции данных, сформулированная в рамках разработки общих требований к миграции данных.
Результатом планирования работ по миграции данных должен набор проектных артефактов, в которых зафиксирована последовательность шагов по реализации миграции данных. Выходами этапа планирования являются следующие проектные артефакты: план работ по миграции и план коммуникаций на этапе миграции данных.
План работ по миграции определяет набор задач и ответственных за их выполнение, распределенных с помощью матрицы RACI. Проектный план работ по миграции должен содержать пакеты задач и работ для каждого из этапов миграции: от подготовительного до пост-миграционного этапа работ. С учетом результатов анализа проектного опыта была разработана ИСР, позволяющая избежать рисков и соответствующая «эталонным» теоретическим подходам к организации миграции данных.
Приведенная на Рис. 3 структура работ покрывает все этапы миграции и может быть трассирована к строкам проектного плана работ. В рамках проектного плана работ должны быть определены сроки выполнения каждой задачи и обозначены выходы каждой задачи. При составлении плана работ для каждой задачи должно быть определено условие, выполнение которого будет однозначно определять, что задача завершена.
Не менее важным проектным артефактом этапа миграции данных является план коммуникаций. План коммуникаций на этапе миграции определяет цели и виды взаимодействия между участниками проектной команды, а также между участниками проектной команды и сотрудниками заказчика - бизнес-пользователями.
Оформление плана коммуникаций в рамках этапа миграции должно основываться на составленном ранее плане работ. Для каждой задачи в рамках проектного плана должны быть определены следующие атрибуты:
- 1. Предмет (тема) коммуникации.
- 2. Необходимость взаимодействия ролевых групп внутри команды;
Кто должен участвовать в коммуникации? Какие ролевые группы?
- 3. Какой тип взаимодействия приемлем?
- 4. Что должно являться выходом коммуникации?
- 5. Необходимость взаимодействия с проектной команды и бизнес-пользователей;
- 6. Кто должен участвовать в коммуникации со стороны проектной команды и со стороны бизнеса?
- 7. Какой тип взаимодействия с бизнес-пользователями приемлем?
- 8. Что должно являться выходом коммуникации с бизнес-пользователями?
- 9. Кто должен быть осведомлен о результатах коммуникации?
Шаблон плана коммуникаций на этапе миграции данных приведен в таблице 2 ниже (Таблица 2).
Таблица 2 Шаблон плана коммуникации на этапе миграции данных
|
Тема коммуникации |
указывается основной вопрос или задача, для решения которой необходима данная коммуникация, раздел требований к миграции, объекты данных |
|
Участники со стороны проектной команды |
указываются ролевые группы и роли |
|
Необходимость взаимодействия с бизнесом |
проставляется признак: да или нет |
|
Участники со стороны бизнеса |
указывается функциональное подразделение и ответственный сотрудник |
|
Тип взаимодействия |
указывается тип взаимодействия, например: письменное, встреча, воркшоп |
Разработка и документирование бизнес-требований к миграции данных
Разработка и документирование требований к миграции данных должно осуществляться в несколько этапов. В рамках разрабатываемой методики в этап разработки бизнес-требований к миграции данных будет также включен шаг проведения и документирования результатов обследования организации-заказчика. Цель этапа разработки бизнес-требований к миграции данных - разработка полного пакета требований к специализированному ПО для миграции данных, а также к составу данных, мигрируемых в целевую систему.
1. Обследование эксплуатируемой информационной системы
Обследование эксплуатируемой информационной системы хронологически должно быть первым этапом работ в рамках разработки требований к миграции данных.
Обследование существующей информационной системы в рамках разработки требований к миграции данных может проводиться в рамках работ по обследованию бизнеса всего проекта внедрения ИС. Обследование в рамках разработки требований к миграции данных должно быть направлено на создание модели данных `as is". Модель данных `as is" позволит подготовить требования к составу мигрируемых данных из системы-источника в систему-приемник.
Модель данных `as is" описывает все объекты данных, которые используются в эксплуатируемой системе. После составления такой модели заказчику будет проще выбрать перечень объектов данных для переноса в систему-приемник. В такой модели должны быть указаны имена сущностей, а также описан их атрибутный состав и взаимосвязи между сущностями с указанием их кардинальности.
Помимо модели данных эксплуатируемой системы на этапе обследования должны быть составлены схемы бизнес-процессов, в которых используются объекты данных, выбранные для переноса в целевую систему. Модели бизнес-процессов позволят выявить недостающие объекты данных, в случае если они были упущены при анализе модели данных.
Помимо составления модели данных `as is" на этапе обследования должны быть описаны правила работы со словарями и справочниками в эксплуатируемой системе. В частности, должны быть описаны следующие моменты для каждого словаря:
- - Наименование словаря или справочника;
- - Ответственное за администрирование словаря функциональное подразделение;
- - Наличие проверки уникальности для кодов и значений записей словарей;
- - Наличие правил регулярного обновления записей в словарях;
- - Описание правил работы с записями словарей, потерявшими актуальность;
- - В случае если миграция данных производится из нескольких источников, необходимо описать, есть ли дублирование словарей в нескольких системах-источниках. В случае наличия дублей словарей в нескольких системах-источниках, требуется описание правил дедубликации и маппинга записей для каждого словаря;
Формат спецификации требований к миграции словарей из системы-источника в целевую систему приведен в таблице и пример заполнения такой спецификации приведен.
2. Разработка требований к профилю данных для миграции
Разработка требований к профилю данных для миграции должна происходить с участием групп ключевых бизнес-пользователей в соответствии с планом коммуникаций, разработанным в ходе планирования работ по миграции данных. Шаблон документа и пример заполнения для фиксирования результатов обследования приведен в таблице 4 (Таблица 4).
Бизнес-пользователи являются источниками для получения ответов на следующие вопросы о профиле данных для миграции данных:
- 1) Будут ли мигрированные данные являться входными для работы бизнес-процесса, автоматизированного в проектируемой системе? Ответом на данный вопрос должна стать таблица-описание соответствия объектов данных системы-источника и бизнес-процессов, автоматизированных в целевой системе.
- 2) Какой временной промежуток должен быть определен для миграции данных? При этом должны быть учтены положения нормативных и организационно-распорядительных документов. Ответом на данный вопрос должна стать таблица соответствия объекта данных и временного горизонта выгрузки данных из системы-источника.
- 3) Какому объекту данных целевой системы соответствует каждый из выбранных для миграции объектов данных системы-источника? Ответом на данный вопрос должна стать таблица маппинга объектов данных системы-источника и системы-приемника.
- 4) Есть ли в атрибутном составе объектов данных системы-источника поля или группа атрибутов, которые не будут использоваться в целевой системе? Ответом на данный вопрос должна стать таблица описания атрибутного состава объектов данных с проставленным флагом: используется/ не используется в целевой системе.
- 5) Есть ли в атрибутном составе объектов данных системы-источника поля или группы атрибутов, которые не соответствуют по типу данных полям в целевой системе? Ответом на данный вопрос должна стать таблица описания атрибутного состава объектов данных с проставленным флагом и расшифровкой несоответствий.
- 6) Происходила ли модернизация системы-источника, результатом которой стало значительное изменение в структуре данных, которые необходимо мигрировать? Примеры изменений:
- - Изменение состава обязательных атрибутов;
- - Изменение правил хранения объектов данных;
- - Значительное изменение структуры объекта данных, приводящее к изменению объемов данных.
Ответом на данный вопрос должно стать описание объектов данных системы-источника с описанием особенностей работы с объектом данных в течение временного промежутка, для которого производится миграция данных.
7) Какое функциональное подразделение или конкретные пользователи являются владельцами данных? Ответом на этот вопрос должна стать таблица соответствия объектов данных и сотрудников заказчика.
Сотрудники ИТ-подразделения являются источниками для получения ответов на следующие вопросы о профиле данных для миграции:
- 1) Где физически хранятся данные, выбранные бизнес-пользователями для миграции в целевую систему? Что является источником данных: корпоративное приложение, система или источники за пределами организации-заказчика? Ответом на данный вопрос должна стать таблица соответствия объектов данных и их хранилищ (имя и тип БД, имя таблицы/таблиц в БД).
- 2) Позволяет ли метаинформация мигрируемого контента разработать алгоритмы миграции? Возможно ли произвести анализ структуры данных на основе метаинформации?
- 3) Есть ли технологические ограничения системы-источника, которые отражаются на структуре данных, формах хранения и работы с данными? Ответом на данный вопрос должно стать полное описание технологических ограничений системы-источника в разрезе объектов данных для миграции.
Сотрудники ИТ-подразделения и бизнес-пользователи совместно должны произвести оценку критичности потенциальных ошибок при переносе данных из системы-источника в целевую систему. В частности, бизнес-пользователи и сотрудники ИТ-подразделений должны проанализировать взаимосвязи объектов данных на уровне используемой БД для определения перечня возможных проверок целостности данных при переносе в целевую систему.
Разработка требований к профилю данных для миграции должна завершаться получением тестовой выгрузки данных из системы-источника (систем-источников) в соответствии с разработанным профилем данных. Полученная тестовая выгрузка будет использоваться для отладки миграционного ПО и оценки качества предоставляемых данных.
- 3. Разработка требований к утилите миграции
- 1) Требования к очистке и логическим проверкам данных
После разработки требований к профилю данных для миграции необходимо разработать правила очистки или преобразования выгруженных из систем-источников данных для их корректного размещения в целевой системе. Для этой цели необходимо соотнести бизнес-требования к модели данных проектируемой системы и описание модели данных эксплуатируемой системы.
Для целей определения уровня качества данных должны применяться следующие типы логических проверок в рамках каждого мигрируемого объекта данных:
- - Заполнены ли все обязательные атрибуты?
- - Физический тип данных каждого атрибута в системе-источнике и системе-приемнике совпадают?
- - Длины значений атрибутов в объекте данных удовлетворяют требованиям в целевой системе?
- - Формат хранения данных (даты, десятичные числа) соответствуют требованиям в целевой системе?
- - Идентификаторы объектов данных в системе-источнике позволяют их однозначно различить?
Требования к логическим проверкам должны быть зафиксированы в функциональной спецификации на утилиту миграции данных.
Выявленные несоответствия в данных для загрузки могут быть устранены одним из следующих способов: данные могут быть удалены из состава выгрузки, если они не имеют бизнес-ценности или преобразованы с помощью специфических алгоритмов.
Для корректного размещения данных в целевой системе для объектов данных могут быть разработаны алгоритмы преобразований следующих видов:
- - Недостающие обязательные атрибуты могут быть заполнены заранее определенными значениями - «заглушками».
- - Значения атрибутов, длина которых не соответствует требованиям целевой системы, должны быть сокращены.
- - Формат дат системы-источника должен быть приведен к формату хранения дат системы-приемника.
- - Формат хранения десятичных числовых данных должен быть приведен к формату хранения десятичных числовых данных в целевой системе.
- - Атрибуты, физически тип данных которых не соответствует требованиям целевой системы, должны быть преобразованы. Например, текстовые значения могут быть приведены к целочисленным.
Требования к алгоритмам очистки и преобразования данных, а также виды объектов данных, для которых они будут применены, должны быть зафиксированы в функциональной спецификации на утилиту миграции данных.
2) Требования к именованию сущностей в системе-приемнике
Требования к разработке алгоритмов именования сущностей в системе-приемнике должны разрабатываться в случае, если в целевой системе невозможно применить алгоритмы, используемые для именования сущностей в системе-источнике/ системах-источниках.
Алгоритмы именования и нумерации объектов данных должны быть разработаны в следующих случаях:
- - Если из двух систем-источников производится миграция объектов данных с одинаковым бизнес-смыслом, то в целевой системе для формирования их имен и номеров должен применяться общий алгоритм.
- - Если в системе-источнике для формирования номеров сущностей применялись алгоритмы, которые более не являются актуальными в силу изменившихся нормативных или организационно-распорядительных документов.
- - Если в системе-источнике для формирования номеров сущностей применялись алгоритмы, которые не удовлетворяют бизнес-правилам работы с сущностями в проектируемой системе.
Требования к алгоритмам формирования имен и номеров мигрированных сущностей должны быть зафиксированы в функциональной спецификации на утилиту миграции данных.
3) Требования к логированию миграции данных
Для отслеживания состояния процесса миграции данных утилита миграции должна поддерживать логирование загрузки данных в целевую систему. При этом в логе утилиты миграции должна отражаться информация обо всех произведенных логических проверках и удалении данных из набора данных для загрузки в целевую систему.
Требования к логу утилиты миграции должны быть зафиксированы в функциональной спецификации на утилиту миграции.
Лог утилиты миграции должен позволять отследить каждую операцию в рамках процесса загрузки данных в целевую систему.
Каждая запись лога миграции данных должна обладать как минимум следующим набором атрибутов:
- · Вид мигрируемого объекта данных;
- · Система-источник;
- · Уникальный идентификатор объекта данных в системе-источнике;
- · Уникальный идентификатор объекта данных в системе-приемнике;
- · Дата и время проведения загрузки для данного объекта данных;
- · Сформированное утилитой миграции имя/номер для данного объекта данных, в случае если для данного объекта данных был применен алгоритм формирования имен/ номеров сущностей;
- · Флаг: был ли объект данных мигрирован в систему-приемник или был исключен из загруженных данных;
- · Причина, по которой объект был исключен из загруженных данных - состав логических проверок и правил;
- · Описание ошибки, возникшей в ходе миграции объекта данных, если такая произошла.
В атрибуте «Описание ошибки» отражается параметризованное сообщение утилиты миграции данных, в случае если утилита миграции не смогла выполнить загрузку объекта данных в целевую систему.
В случае если для объекта данных выставлен флаг - объект удален из мигрируемых данных, то в атрибуте «Причина исключения удаления объекта данных» должно отражаться параметризованное сообщение, описывающее алгоритм очистки данных, в соответствии с которым из мигрируемых данных был удален данный объект.
Фрагмент лога утилиты миграции приведен в приложении 4 (Приложение 4 - Фрагмент лога утилиты миграции).
Проведение тестирования в рамках работ по миграции данных
Работы по тестированию состоит из следующих пакетов работ:
- 1. Первичное тестирование миграционного ПО на соответствие технической спецификации;
- 2. Бизнес-тестирование миграционного ПО на соответствие требованиям бизнеса к алгоритмам трансформации данных во время миграции;
- 4. Тестирование работы функциональности системы-приемника после размещения мигрируемых данных;
Ниже приведена последовательность шагов, которые должны быть предприняты проектной командой для проведения каждого из этапов тестирования.
Первичное тестирование миграционного ПО должно выявить и устранить технические сбои и дефекты разработанной утилиты миграции. Такое тестирование должно проводиться силами команды тестировщиков в соответствии с разработанными тест-кейсами. При этом после доработок ПО в случае выявленных ошибок обязательным является проведение регрессионного тестирования утилиты.
Бизнес-тестирование миграционного ПО на соответствие требования бизнеса и алгоритмам трансформации данных должно выполняться с использованием лога утилиты миграции для обеспечения полноты проверок и тестов. Порядок действий при бизнес-тестировании может быть следующим:
- 1. Определить по логу утилиты миграции игнорированные при загрузке объекты данных.
- 2. Убедиться, что эти объекты в системе-источнике удовлетворяли условиям применения логических проверок или механизмов трансформации.
- 3. В случае выявления несоответствия зафиксировать ошибку работы утилиты миграции.
Ошибки, зафиксированные в ходе тестирования, должны фиксироваться в таком виде, чтобы можно было однозначно определить источник их появления - алгоритм или правило, сработавшее неверно.
Для бизнес-тестирования утилиты миграции могут применяться автоматизированные средства тестирования. В случае их отсутствия набор юнит-тестов должен охватывать все возможные типы объектов данных, которые были мигрированы в целевую систему, а также все спроектированные для каждого типа проверки и механизмы трансформации.
Тестовая очистка и загрузка данных предполагает работы с данными, полученными после разработки пакета требований к профилю мигриуемых данных. Тестовая выгрузка должна быть инструментом для проверки следующих характеристик миграционного ПО:
- - Работа бизнес-алгоритмов, логических проверок и механизмов преобразования на реальных данных;
- - Работоспособность миграционного ПО на приближенных к продуктивным объемах данных.
Работа с тестовой выгрузкой - завершающий этап тестирования миграционного ПО. После обработки утилитой миграции тестовой выгрузки становится возможной оценка необходимого планового времени для загрузки всего массива мигрируемых данных. Успешное размещение тестовой выгрузки в системе-приемнике должно означать внутреннюю приемку утилиты миграции и возможность перехода к работам по загрузке промышленной - полной выгрузки из системы-источника в целевую систему.
Тестовая очистка и загрузка данных в систему-приемник предполагает выполнение всех необходимых для миграции данных в целевую систему операций, включая тестирование функциональности системы-приемника. Подробнее этот этап тестирования описан ниже.
Тестирование работы функциональности системы-приемника должно обеспечить возможность убедиться в том, что все функции системы, использующие мигрированный контент работают в штатном режиме. При этом такое тестирование может осуществляться в два этапа:
- 1. Тестирование работоспособности системы-приемника;
- 2. Детальное тестирование функциональности системы-приемника.
Для проведения тестирования работоспособности системы-приемника сразу после завершения загрузки должен быть составлен краткий сценарий тестирования, в котором указывается, что именно необходимо проверить на работоспособность, например:
- - перечень экранных форм, которые необходимо открыть,
- - количество объектов в справочниках (словарях), которое должно быть видно пользователю;
- - количество объектов в реестрах системы, которое должно быть видно пользователю,
- - перечень функций системы, которые должны быть запущены (построение отчетов, поисковые механизмы, доступ к мигрированным объектам данных).
Детальное тестирование функциональности системы-приемника предполагает запуск всех автоматизируемых бизнес-процессов, для которых входными данными являются мигрированные данные. В случае если в состав загруженных данных входит более одного типа объектов данных, то тестовые сценарии должны быть предусмотрены для каждого мигрированного типа данных. Результаты тестирования функциональности системы-приемника должны фиксироваться в журнале тестирования.
В соответствии со стандартом ANSI журнал (лог) тестирования миграции данных должен иметь следующую структуру:
- 1. Идентификатор тест-кейса;
- 2. Описание операции в рамках тест-кейса;
- 3. Описание ошибки во время выполнения операции в рамках тест-кейса;
- 4. Влияние ошибки на функциональность системы;
- 5. Влияние ошибки на связанные операции тестирования.
Описание операции в рамках тест-кейса в обязательном порядке должно включать:
a) Входящие данные для операции;
b) Ожидаемые результаты;
c) Полученные результаты;
d) Дата и время выполнения операции;
e) Количество попыток выполнения операции;
f) Ответственные за тестирование члены проектной команды;
g) Окружение операции в рамках тест-кейса.
Фрагмент журнала тестирования функциональности системы-приемника приведен в приложении 5 (Приложение 5 - Журнал тестирования результатов миграции).
Последнее обновление: 31.10.2015
Нередко возникает ситуация, когда модель меняется. Например, мы решили внести в нее новые свойства. Но при этом у нас уже имеется существующая база данных, в которой есть какие-то данные. И чтобы без потерь обновить базу данных ASP.NET MVC предлагает нам такой механизм как миграции. Например, у нас есть простая модель User:
Public class User { public int Id { get; set; } public string Name { get; set; } }
Соответсвенно есть контекст данных, через который мы работаем с бд:
И допустим, у нас есть вся инфраструктура для работы с этой моделью - представления, контроллеры, и у нас есть уже в базе данных несколько объектов данной модели. Но в какой-то момент мы решили изменить модельную базу приложения. Например, мы добавили еще одно поле в модель User:
Public class User { public int Id { get; set; } public string Name { get; set; } public int Age { get; set; } }
Кроме того, мы решили добавить еще одну модель, например:
Public class Company { public int Id { get; set; } public string Name { get; set; } }
Таким образом, контекст данных у нас уже меняется следующим образом:
Public class UserContext: DbContext
{
public UserContext() :
base("DefaultConnection")
{ }
public DbSet
Мы можем добавить в представления для модели User дополнительное поле для свойства Age, можем создать контроллер и представления для новой модели, но при попытке добавить новый объект в бд, мы будем получать ошибку:
Контекст данных изменился, и теперь нам надо провести миграцию от старой схемы базы данных к новой. И первым делом найдем внизу Visual Studio окно Package Manager Console, введем в нем команду: enable-migrations и нажмем Enter:
После выполнения этой команды Visual Studio в проекте будет создана папка Migrations, в которой можно найти файл Configuration.cs . Этот файл содержит объявление одноименного класса Configuration, который устанавливает настройки конфигурации:
Namespace MigrationApp.Migrations
{
using System;
using System.Data.Entity;
using System.Data.Entity.Migrations;
using System.Linq;
internal sealed class Configuration: DbMigrationsConfiguration
В методе Seed можно проинициализировать базу данных начальными данными. Теперь нам надо создать саму миграцию. Там же в консоли Package Manager Console введем команду:
PM> Add-Migration "MigrateDB"
После этого Visual Studio автоматически сгенерирует класс миграции:
Namespace MigrationApp.Migrations { using System; using System.Data.Entity.Migrations; public partial class MigrateDB: DbMigration { public override void Up() { CreateTable("dbo.Companies", c => new { Id = c.Int(nullable: false, identity: true), Name = c.String(), }) .PrimaryKey(t => t.Id); AddColumn("dbo.Users", "Age", c => c.Int(nullable: false)); } public override void Down() { DropColumn("dbo.Users", "Age"); DropTable("dbo.Companies"); } } }
В методе Up с помощью вызова метода CreateTable создается таблица "dbo.Companies" и производится ее настройка: создание столбцов, установка ключей. И также добавляется новый столбец Age в уже имеющуюся таблицу. Метод Down удаляет столбец и таблицу на случай, если они существуют. Фактически эти методы равнозначные выражению ALTER в языке SQL, которое меняет структуру базы данных и ее таблиц.
И в завершении чтобы выполнить миграцию, применим этот класс, набрав в той же консоли команду:
PM> Update-Database
После этого, если мы посмотрим на состав базы данных, то увидим, что к ней были применены изменения в соответствии с выполненной миграцией:
Итак, миграция выполнена, и мы можем уже использовать обновленные модели и контекст данных.