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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лейф Поулсен для InTech

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

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

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

Благодаря тщательному планированию, операционный риск может удерживаться на приемлемом уровне, кроме того, обеспечивается защита инвестиций и минимизируются расходы на протяжении жизненного цикла систем. Для типичной системы автоматизации или ИТ, лишь 20-40% инвестиций приходится на приобретение системы. Остальные 60-80% идут на поддержание ее высокой доступности и адаптацию к периодически меняющимся требованиям.

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

План долгосрочной миграции

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

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

Рис 1. Общий подход к созданию долгосрочного плана миграции.

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

Каждая архитектура может быть описана как ряд «слоев», служащих связующим звеном между бизнесом и технологией - как показано на рис. 1. Внимание необходимо уделять следующим «слоям»:

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

Разработка плана миграции

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

Часть II

Этап 1: Мобилизация

Основные цели:

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

• плановые встречи
• рабочий семинар, посвященный началу проекта

Результаты:

• детальный консультационный план
• общие цели
• обзор процесса

Этап 2: Анализ

Целью этапа анализа являются:

• анализ бизнес- и производственных процессов для того, чтобы:

Оценить готовность персонала, обслуживающего системы ИТ и автоматизации

Выяснить потребности в данных и функциональности для будущей архитектуры

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

• анализ существующей архитектуры

Определение существующих производственных процессов в их связи с системами автоматизации, сбором данных, системами управления производством

Определение существующих бизнес-процессов и их связей с системами автоматизации производства

Определение существующих приложений, данных, логической и физической инфраструктуры, а также услуг технической поддержки

Во время этого этапа осуществляются следующие активности:

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

Результаты:

• определение существующей инфраструктуры
• документация по анализу
• список идей по вызовам и возможностям новой архитектуры список идей по вызовам и возможностям новой архитектуры

Этап 3: Цель

Целью этого этапа является определение и описание потребностей, сформулированных на этапе анализа.

Решение, или целевая архитектура будет описывать:

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

Во время этого этапа осуществляются следующие активности:

• семинары и обсуждения, посвященные улучшению процессов
• семинары и обсуждения, посвященные улучшению архитектуры

Результаты:

• будущая архитектура (презентация)
• краткое описание типов приложений

Этап 4: Обоснование

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

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

Во время этого этапа осуществляются следующие активности:

• приблизительная оценка расходов и получаемых преимуществ
• первая версия презентации

Результаты:

• общие цели
• приоретизация бизнес-идей
• оценка необходимых ресурсов

Этап 5: План

Целью этого этапа является планирование проекта на основе приоритетов, ресурсов и зависимостей:

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

Во время этого этапа осуществляются следующие активности:

• разработка плана по внедрению
• разработка инвестиционного плана
• оценка рисков

Результаты:

• план по внедрению
• оценка нагрузки на персонал, задействованный в проекте
• оценка рисков проекта
• инвестиционный план (в первом приближении)
• финальная версия презентации проекта

Практический пример

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

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

Пример показан на рис. 2. Данные об установленных системах, также, содержатся в системном хранилище (или просто в Excel-файлах), и их можно использовать для дальнейшего анализа и планирования.

Рис 2. «Слой» автоматизации позволяет оценить существующие систем

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

1. Неуклонное и безошибочное соответствие регулятивным требованиям

2. Минимальные затраты времени для выхода на рынок, гибкость

3. Успешность, конкурентоспособность, операционное совершенство

4. Бескомпромиссное качество

5. Рост объемов производства

Данные цели необходимо превратить в более конкретные задачи, выполнение которых может быть количественно оценено.

Затем, мы должны выяснить, насколько хорошо существующие системы поддерживают текущие и будущие бизнес-процессы. Для этого мы используем стандартную референсную модель (основанную на серии стандартов ANSI/ISA-95). Она включает 19 высокоуровневых бизнес-процессов, детализированных в той степени, которая позволяет увидеть слабые места в их практической реализации и необходимость в переменах ради эффективного бизнеса.

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

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

Техническая оценка выявила необходимость в модернизации и замене ряда систем:

• АСУ ТП основываются на обычной, устаревшей РСУ и множестве различных ПЛК, ряд из которых уже «созрел» для замены.
• Система автоматизации здания основывается на более новой платформе, но, также требует модернизации для соответствия новым требованиям.
• Ряд второстепенных систем также требует модернизации, а то и замены.
• Инфраструктура, обслуживающая все системы, требует лучшей сегментации и защиты для соответствия современным требованиям безопасности.

Часть III

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

Оценивается содержание технических работ и стоимость каждого проекта; для каждого проекта готовится краткое одностраничное резюме, которое может обсудить руководство. (См. рис. 3).

Рис. 3. Одностраничное описание потенциального проекта миграции

Для того, чтобы выбрать приоритетные проекты, оцениваются потенциальные результаты каждого из них. Результаты оцениваются с точки зрения бизнес-целей, а также, надежности АСУ ТП.

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

Рис. 7. Консолидированный обзор графика миграции

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

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

Рис. 8. Организация проектов миграции в шести различных потоках

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

Рис. 9. Оценка типичных рисков проектов миграции

Процессы для поддержки бизнеса

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

Лейф Поулсен (Leif Poulse n) ( ), ведущий специалист в области автоматизации и ИТ в NNE Pharmaplan. Обладает мастерской степенью в области управления технологическими процессами. В NNE Pharmaplan Поулсен отвечает за развитие технологий, методов и компетенций в области промышленной автоматизации и ИТ, и работает как старший бизнес-консультант.

В данной статье мы хотели бы систематизировать наш опыт проведения миграции данных в крупных корпоративных проектах, связанных с переходом Заказчиков на работу в конфигурациях «1С:Предприятие 8».

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

Термины и определения

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

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

Схема миграции в общем случае выглядит следующим образом:

Рис. 1

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

Система-приёмник - целевая система, произвольная конфигурация «1С:Предприятие 8».

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

Как современную альтернативу в качестве транспорта возможно рассматривать формат xml -файлов.

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

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

Данные для загрузки - данные, предназначенные для загрузки в систему-приёмник. В данной статье, так же как и исходные данные, рассматривается xls -формат.

Шаблоны данных для загрузки - описание таблиц данных для загрузки в целевую систему.

Этапы миграции

Рассмотрим поэтапно процесс подготовки и проведения миграции.

К организационным этапам миграции можно отнести следующие пункты:

· Определение стратегии миграции. На данном этапе Исполнитель и Заказчик договариваются о технологии проведения миграционных работ;

· Определение состава рабочей группы по миграции. В рабочую группу должны входить специалисты и Исполнителя и Заказчика, знакомые в достаточной степени с работой исторических систем (со стороны Заказчика) и целевой системы (со стороны Исполнителя);

· Предварительный план миграции. План миграции по ходу проекта будет неоднократно корректироваться;

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

· Состав данных, подлежащих миграции. Справочные данные, классификаторы, транзакционные данные, остатки, обороты и пр.;

· Вопросы проверки качества, корректности и целостности данных в процессе миграции и по итогам;

· Вопросы отката к предыдущему состоянию в случае сбоев.

Остановимся подробнее на технологических этапах миграции.

Рис. 2

1.Подготовка шаблонов загрузки данных

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

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

В шаблоне указывается:

· Описание всех полей xls -файла данных для загрузки, включая:

o Имя поля

o Признак обязательности заполнения поля

o Пример заполнения поля

o Примечание

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

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

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

2.Выявление источников данных

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

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

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

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

Тем не менее, на данном этапе нужно постараться выявить как можно больше необходимых данных.

3.Выгрузка исходных данных

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

Наиболее удобным вариантом представляется выгрузка в xls файлы. Многие старые IT -системы поддерживают такой вариант.

Также могут быть варианты выгрузки в csv формат, dbf , xml форматы и прочие.

Стоит отметить, что по тем или иным причинам (вопросы безопасности, например) Заказчик не всегда может предоставить выгрузки данных в полном объеме на этом этапе! Только структура данных и несколько тестовых позиций. Таким образом, может сложиться такая ситуация, что при тестовых и итоговой загрузках будут обнаруживаться некачественные данные в исходных таблицах, что будет приводить к незапланированным ошибкам.

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

4.Мэппинг данных

Мэппинг (data mapping ) - в общем случае процесс сопоставления данных исторических систем и системы-приемника. То есть, исходных данных и данных для загрузки.

Этап мэппинга - наиболее трудоёмкий этап и может занимать более 50% всех работ по задаче миграции.

На данном этапе в полной мере задействуется вся рабочая группа проекта по миграции.

В процессе мэппинга данных необходимо выделить подэтапы мэппинга таблиц и мэппинга полей.

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

· Мэппинг полей - сопоставление полей таблиц в рамках уже определенного мэппинга таблиц. Результатом данной работы является реестр мэппинга полей.

В рамках данного этапа также следует провести возможные работы по нормализации данных.

5.Подготовка правил трансформации

В отличие от предыдущих этапов, данный этап - технический и предполагает работу разработчика Исполнителя.

На основании согласованных реестров мэппинга полей специалисты Исполнителя разрабатывают правила трансформации данных.

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

При этом требования к данной среде включают в себя:

· Удобство и быстрота разработки правил трансформации;

· Скорость конвертации данных. Файлы на входе и на выходе могут быть и в сотни тысяч строк!

· Возможность работать с несколькими входными файлами одновременно;

· Возможность сохранения правил трансформации в отдельные файлы.

Для своих проектов миграции мы разработали специализированное АРМ разработчика, взяв за основу стандартную обработку «Консоль запросов» 1С.

Обработка «Консоль запросов» была доработана для возможности делать прямые запросы к файлам xls .

Приведем пример объединения двух исходных xls -файлов Сотрудники. xls

и Операции. xls со страницами:

Списания

и Поступления :

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

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

С помощью языка запросов Access SQL (дающего существенные дополнительные возможности, по сравнению с языком запросов 1С) создается первоначальный запрос, извлекающий данные из файла xls в среду 1С. При этом уже на данном этапе возможны различные проверки и нормализации данных.

Технология доступа к данным ADO обеспечивает высокую скорость работы.

Рис. 3

2.Запрос на языке 1С - основной запрос, реализующий алгоритм мэппинга полей. А также: обогащение загружаемых данных данными из базы 1С, перегруппирование, объединение с результатами запросов к другим исходным xls -файлам и пр.

3.Постобработка результата запроса 1С при необходимости. Реализуется с помощью скрипта на языке 1С.

Для примера здесь реализуется добавление строки «ИТОГО» по колонкам сумм.

4.Запись итогового набора данных в xls -файл.

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

Также данный инструмент позволяет сохранять правила конвертации данных в отдельный xml файл:

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

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

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

· ошибки конвертации, ошибки загрузки данных

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

· по итогам тестовых миграций составляют/актуализируют план итоговой миграции

7.Выверка данных

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

· Совпадения итоговых сумм по остаткам, по документам;

· Количественные совпадения, например количество ОС;

· Корректность заполнения отдельных выборочных сущностей;

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

Например:

· Проверка на дубли по ключевым полям. Можно и нужно проводить еще на исходных данных;

· Приведение типов полей;

· Ссылочная целостность;

· Математические нестыковки. Например, проверка на незаполненные численные поля, на которые запланировано деление при трансформации;

· В целом, проверки обязательной заполненности полей;

· Замена некорректных символов. Например, английские символы в кириллических полях («о», «а», «е» и т.п.) Особенно актуально это для ключевых полей!

· Проверка значений строковых полей на соответствие типов системы-приемника (Ограничения по длине)

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

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

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

Заключение

В заключении хотелось бы отметить, что когда речь идёт о миграции больших транзакционных систем, к которым относятся и многие конфигурации «1С:Предприятия», переход на новую систему может быть весьма трудоёмким.

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

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

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

Терминология

Структура базы данных - совокупность всех объектов БД и статических данных. Пользовательские данные в понятие структуры БД не входят.

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

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

В этом смысле термин миграция, похоже, используется во многих источниках (особенно этому поспособствовали миграции из gem"а Active Record, входящего в состав Ruby on Rails). Однако при использовании этого термина возникает двусмысленность: человек, который не знает контекста, скорее подумает, что речь идет о переносе базы данных с одной СУБД на другую (MySQL => Oracle), а то и вовсе о миграции процессов/данных между нодами кластера. Поэтому предлагаю в случаях, когда контекст неочевиден, использовать более точный термин: версионная миграция баз данных.

Зачем это нужно?

Версия базы данных должна соответствовать версии приложения

1. Изменить тип поля на nullable:

ALTER myTable CHANGE COLUMN myField myField VARCHAR (255) NULL DEFAULT NULL ;

UPDATE myTable SET myField = NULL WHERE myField = "" ;

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

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

Так ли это просто?

Тут снова обратимся к живому примеру. Допустим, программисты в процессе разработки записывают свои изменения структуры и данных БД в отдельный файл в виде SQL-запросов (как DDL -, так и DML -запросов). А при каждом деплое последней версии приложения вы одновременно обновляете до последней версии и базу данных, выполняя запросы из того самого SQL-файла… Но погодите, с какой версии вы обновляете БД до последней версии? «С прошлой»? Но так ли хорошо вы помните, что конкретно из себя представляла прошлая версия (её выпустили 2 месяца назад)? Если нет, то как вы собрались её обновлять? Ведь без точной информации о состоянии структуры и данных выполнить корректную миграцию невозможно: если вы непредумышленно выполните запросы, которые уже когда-то выполнялись, это может привести к потере данных или нарушению их целостности.
Простой пример - замена паролей на их MD5-суммы. Если повторно выполнить такой запрос, то данные можно будет восстановить только из бэкапа. Да и вообще, любые UPDATE "ы, DELETE "ы, и даже INSERT "ы, выполненные повторно, могут привести к крайне нежелательным последствиям. Не говоря уже о несвоевременных TRUNCATE "ах и DROP "ах (хотя такие случаи намного менее вероятны).
Кстати говоря, с этой точки зрения, недовыполнить - не меньшая опасность для работоспособности приложения, чем перевыполнить.

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

Общие принципы версионной миграции

• единоразовое выполнение каждого изменения (SQL-запроса);
• строго предустановленный порядок изменений.

• чтобы любую версию базы данных можно было обновить до любой (обычно, самой последней) версии;
• чтобы набор SQL-запросов, реализующих миграцию между любыми двумя версиями, можно было получить как можно быстрее и проще;
• чтобы всегда можно было создать с нуля базу данных со структурой самой последней версии. Это очень полезно как в процессе разработки и тестирования, так и при развертывании нового продакшн-сервера;
• чтобы, в случае работы над разными ветками, при последующем их слиянии ручное редактирование файлов БД было сведено к минимуму;
• чтобы откатить БД на более раннюю версию было так же просто, как и обновить на более новую.

Основание миграции

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

Метод инкрементных изменений

Структура файлов

Database
|- Baseline.sql
|- 0001.03 .01.sql
|- 0002.03 .01.sql
|- 0003.03 .01.sql
|- 0004.03 .02.sql
|- 0005.03 .02.sql
|- 0006.03 .02.sql
"- 0007.03 .02.sql

В любом случае, самый первый файл, который появится в такой папке, - основание (Baseline.sql). После этого любое изменение в БД сабмиттится в репозиторий в виде нового файла-миграции с именем вида [номер файла].[версия].[подверсия].sql .

Фактически, в этом примере в имени файла содержится полный номер версии БД. То есть после выполнения файла-миграции с именем 0006 .03.02.sql база данных обновится с состояния, соответствующего версии 03.02.0005 , до версии 03.02.0006 .

Хранение истории версий

CREATE TABLE MigrationHistory
Id INT ,
MajorVersion VARCHAR (2),
MinorVersion VARCHAR (2),
FileNumber VARCHAR (4),
Comment VARCHAR (255),
DateApplied DATETIME ,

PRIMARY KEY (Id)
)

В файле Baseline.sql в эту таблицу нужно будет добавить первую запись:

INSERT INTO
MigrationHistory (MajorVersion, MinorVersion, FileNumber, Comment, DateApplied)
VALUES ("03" , "01" , "0000" , "Baseline" , NOW())

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

Выполнять миграцию БД автоматически довольно просто, т.к. номер последней выполненной миграции можно получить из таблицы MigrationHistory, а после этого остается только применить все файлы с бо́льшими номерами. Сортировать файлы можно по номеру, поэтому с порядком выполнения миграций проблем не будет.

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

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

Плюсы, минусы, выводы

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

Метод идемпотентных изменений

Под идемпотентностью понимается свойство объекта оставаться неизменным при повторной попытке его изменить.
В тему вспоминается смешная сцена из «Друзей»:)

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

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

CREATE TABLE IF NOT EXISTS myTable
id INT (10) NOT NULL ,

PRIMARY KEY (id)
);

IF NOT EXISTS
SELECT *
FROM information_schema.tables
WHERE table_name = "myTable"
AND table_schema = "myDb"
THEN
CREATE TABLE myTable
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
PRIMARY KEY (id)
);
END IF ;

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

DELIMITER $$

CREATE PROCEDURE sp_tmp() BEGIN

IF NOT EXISTS
--
-- Условие.
--
THEN
--
-- Запрос, изменяющий структуру БД.
--
END IF ;

END ;
$$

CALL sp_tmp();

DROP PROCEDURE sp_tmp;

Что за птица такая - information_schema?

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

Пример использования

Пример того, как в этом случае может выглядеть папка с sql-файлами:

Database
|- 3.01
| |- Baseline.sql
| "- Changes.sql
"- 3.02
|- Baseline.sql
"- Changes.sql

Предположим, в процессе разработки в разное время программистам понадобились следующие изменения в БД:
a) создать таблицу myTable;
b) добавить в нее поле newfield;
c) добавить в таблицу myTable какие-то данные.

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

К примеру, один из разработчиков создал на своей локальной копии БД таблицу myTable, записал изменение a) в хранящийся в общем репозитории кода файл Changes.sql, и на какое-то время забыл о нём. Теперь, если он выполнит этот файл на своей локальной БД, изменение a) будет проигнорировано, а изменения b) и c) будут применены.

Плюсы, минусы, выводы

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

Метод уподобления структуры БД исходному коду

Основная идея этого метода отражена в заголовке: структура БД - такой же исходный код, как код PHP, C# или HTML. Следовательно, вместо того, чтобы хранить в репозитории кода файлы-миграции (с запросами, изменяющими структуру БД), нужно хранить только актуальную структуру базы данных - в декларативной форме.

Пример реализации

В файле CreateDatabase.sql будут храниться команды CREATE TABLE , CREATE PROCEDURE , и т.д., которые создают всю базу данных с нуля. При необходимости изменений структуры таблиц, эти изменения вносятся непосредственно в существующие DDL-запросы создания таблиц. То же касается изменений в хранимых процедурах, триггерах, и т.д.

К примеру, в текущей версии репозитория уже есть таблица myTable, и в файле CreateDatabase.sql она выглядит следующим образом:

CREATE TABLE myTable
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
PRIMARY KEY (id)
);

CREATE TABLE myTable
id INT (10) NOT NULL ,
myField VARCHAR (255) NULL ,
newfield INT(4) NOT NULL ,
PRIMARY KEY (id)
);

Выполнение миграций между версиями

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

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

В большинстве случаев миграция данных требует индивидуального подхода и определённого опыта.

• Необходимо заранее заранее определить стратегию миграции данных. Слабое понимание процесса и не достаток опыта не повод относиться халатно к миграции данных;
• Обязательно должен быть составлен план миграции данных и назначены ответственные сотрудникам и ключевые пользователи;
• Определить какие основные данные (материалы, контрагенты, банки, и пр.) и какие транзакционнные данные (заказы, открытые позиции и пр.) будет участвовать в миграции данных;
• Определить периоды и объемы данных;
• Подготовить регламенты и методики миграции данных;
• Нормализация и структуризация данных. Так же очень важный шаг при миграции данных. Не бывает такого, чтобы было слишком рано начинать очистку данных от мусора (дубли, не полные и не однозначные записи). Пропуская этот шаг помните, что мусорные данные приведут к проблемам в эксплуатации SAP и могут стоить компаниями намного дороже, чем во время сделанная очистка данных;
• При миграции данных должны быть обязательно разработаны понятные шаблоны сбора и загрузки данных. Это так же ответственный шаг, ключевые пользователи должны однозначно понимать что и как заполнять в шаблоне;
• Разработать средства загрузки данных. Средства должны быть понятны и удобны для сотрудников НСИ, а так же содержать проверки и защиту от человеческого фактора. А так же загрузчики данных должны уметь быстро загружать данные. За частую процесс загрузки готовых шаблонов с данными занимает не более 5 дней;
• Контроль процесса миграции данных должен производиться на всех этапах, как во время тестовой миграции данных, так во время пилотного запуска и продуктивной загрузки данных.
• Заключительный этап, после продуктивной миграции данных, это проверка качества загруженных данных. Помните, что исправить все проще на ранних стадиях. По этому только убедившись в 100% качестве загруженных данных следует начинать продуктивную эксплуатацию системы.

Мы специализируемся на комплексном подходе к миграции основных данных и справочников НСИ.

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