Миграция данных в проектах внедрения КИС

Цели и стратегия процесса миграции данных в проектах внедрения ИС

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

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

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

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

При решении перечисленных выше задач необходимо определить стратегию миграции, руководствуясь принципами которой, будут проводиться работы по миграции данных. Эксперты Oracle [3] определяют два типа стратегий: стратегия «большого взрыва» (big bang) и стратегия плавной миграции (trickle migration).

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

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

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

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

2. Риски тестирования.

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

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

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

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

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