Этапы процесса миграции данных в проектах внедрения ис. Миграция и внедрение: о чём молчат провайдеры Миграция системы

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

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

С чего начать?

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

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

Что такое миграция?

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

С точки зрения пользователя, миграция - это: «Утром приходил админ, сказал, что теперь сервер не в его каморке, а в Европе. А так - всё, как обычно. Разве что добряче шустрее стало».

С точки зрения заказчика, миграция - это: «Чтобы всё работало, я за это деньги плачу!».

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

Соответственно, на основании собственного опыта мы сформировали алгоритмы того, как нужно делать миграцию - частичную или полную.

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

Частичная (постепенная) миграция - это тот путь, по которому идут более крупные компании. Он подразумевает более сложную миграцию достаточно разветвленной IT-инфраструктуры, которую за 1-2 дня перенести невозможно. И в этом случае мы составляем не просто план, а дорожную карту миграции. У нас есть и готовые типовые шаблоны миграции, и, если требуется, нетипичные решения, разработанные под конкретного заказчика в тесном с ним сотрудничестве.

Миграция на сервер

Заключая контракт, мы всегда оговариваем, каким должен быть результат (непрерывность рабочих процессов, подключение периферийных устройств или флэш-ключей, определённое быстродействие, обеспечение мобильности, информационной безопасности, быстрого доступа к ресурсам, экономические выгоды и т.п.). Это важно, потому что, узнав об этих целях, мы можем предложить те решения, которые у нас уже являются накатанными (лучшими). Кроме того, в нашей партнерской сети есть компании, которые специализируются на самых разных задачах: например, внедрении решений на базе «1С», разработке и внедрении систем электронного документооборота и т.д. И в тех случаях, когда мы хорошо понимаем задачу, мы можем не просто создать какую-то конфигурацию, но и порекомендовать лучшие наработанные практики для оптимизации миграции в облако и использования ресурсов. И опыт - наш и наших партнеров - в данном случае очень полезен. Зная поставленную задачу, мы понимаем, каким образом будет протекать миграция, чтобы получить от нее для компании максимальный эффект.

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

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

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

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

Судьба мигранта

Что происходит дальше? А дальше происходит «жизнь после жизни»: вы успешно мигрировали, попали в облако и дальше вам необходимо всем этим управлять. И здесь вы можете как управлять самостоятельно (у нас много удобных инструментов, предполагающих наличие базовых ИТ-знаний), так и поручать необходимые инфраструктурные работы нашей техподдержке, и тогда мы произведём нужные изменения самостоятельно.

Если у заказчика нет системного администратора и требуется, чтобы мы не только обеспечивали работу его инфраструктуры «снаружи» (работа виртуальных серверов, бэкап данных, работа сети, и т.п.), но и выполняли работы по обслуживанию «внутри» виртуальных машин (прикладное ПО, библиотеки, и т.п.), то мы прекрасно справляемся с этим в рамках дополнительного пакета услуг TuchaExpert, который предусматривает, что мы отвечаем и за обслуживание программного уровня инфраструктуры. Если системный администратор у компании уже есть, это также прекрасно, так как «местный» админ хорошо знает внутреннюю кухню компании и может заниматься дальнейшим ИТ-развитием компании. А мы всегда готовы в этом помогать и поддерживать.

Возникли вопросы или интересные задачи для нас? Не откладывайте их в долгий ящик. и получите грамотную поддержку уже сейчас!

Многое изменилось в мире информационных технологий за последние 32 года, с тех пор как Microsoft выпустила Windows 1.0. Единственное, что осталось прежним, - сложность процессов миграции, или перехода на новую версию операционной системы, и развертывания обновлений. Если спросить пользователей, чего они хотят от миграции, вы получите ответ: плавного перехода с минимальными простоями и привычного взаимодействия с рабочим столом. Некоторые заявят, что вообще против миграции, но таких обычно немного.

Для чего нужна миграция

Существует много причин в пользу миграции на уровне настольных компьютеров. Две основные - безопасность и стоимость эксплуатации. Разработчики Microsoft неуклонно повышали безопасность настольных операционных систем; список технологий обеспечения безопасности, которых не было в старых версиях, производит сильное впечатление. Угрозы становятся все более изощренными, и Microsoft пришлось добавить такие функции, как запуск на первом этапе загрузки антивредоносного решения ELAM (https://docs.microsoft.com/en-us/windows-hardware/drivers/install/early-launch-antimalware) и управляемый доступ к папкам (https://docs.microsoft.com/en-us/windows/threat-protection/windows-defender-exploit-guard/controlled-folders-exploit-guard), превосходный способ защиты от программ-шантажистов, сам по себе достаточный повод задуматься о миграции. Безопасность - особенно серьезная проблема для компаний, все еще работающих с версиями операционной системы Windows 7 (и даже Windows XP), поскольку с тех пор угрозы значительно изменились, и усовершенствования, внесенные в Windows 10, в некотором отношении представляют самый начальный и не всегда достаточный уровень безопасности.

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

Процесс миграции

На приведенном рисунке показана простая схема основных этапов процесса миграции.

Рисунок. Основные этапы процесса миграции

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

Инвентаризация среды

Многие компании располагают развитыми системами инвентаризации и управления, с помощью которых можно получить ответы на вопросы типа «как много активно используемых настольных компьютеров работает с Windows 8.1 с пакетом обновления 2?» или «сколько ноутбуков Dell XPS 13 имеется в наличии?» Системы управления, такие как System Center Configuration Manager (SCCM) и Microsoft Intune, можно задействовать для инвентаризации, если вы располагаете достаточными средствами и развернули их. В противном случае вам, возможно, придется прибегнуть к менее эффективным методам, например запросить отзывы пользователей, подготовить средство инвентаризации и продвигать его через групповую политику или вручную выполнить инвентаризацию и настроить параметры систем. Ключевое условие на данном этапе - получить точную модель существующих систем, чтобы правильно планировать нужное состояние.

Проектирование требуемого состояния

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

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

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

Приступаем к созданию прототипа

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

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

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

Пилотный этап

Во время проектирования нового самолета или ракеты инженеры планируют обширную программу испытательных полетов. У каждого испытательного полета есть конкретная цель, которая может быть простой (проверить выпускание и подъем шасси на разных скоростях) или сложной (маневрирование истребителей 2 на 2). Летчики-испытатели не импровизируют во время полетов, они строго следуют заданию на каждый полет, достигая поставленных целей. Ваш пилотный проект должен работать точно так же: укажите, что нужно доказать, протестировать или проверить, а затем позаботьтесь о том, чтобы все действия в пилотном проекте были ориентированы на достижение поставленной цели. Слишком часто пилотная программа на самом деле означает «выберите нескольких случайных пользователей и посмотрите, что испортится». Хорошая пилотная программа начинается со структурированного тестирования набора базовых функций - миграция одного пользователя, миграция группы пользователей, тестирование полученной в результате среды при выполнении повседневных задач, а затем переход к более сложным сценариям. Структурированное тестирование особенно важно, если вы переходите из традиционной настольной среды в «облако» или к виртуальным элементам. Потребуется время, чтобы научиться управлять «облачной» средой или гипервизором, в том числе получать поддержку поставщика в случае неполадок на пилотном этапе.

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

Развертывание

Основные события происходят на этапе полномасштабного развертывания. Этот этап миграции не сильно отличается от любого другого сложного технического проекта: вы определяете график миграции различных групп пользователей, а затем выполняете запланированные шаги, решая проблемы по мере их возникновения. Если этапы построения прототипа и пилотный проект выполнены грамотно, у вас не должно возникнуть серьезных новых проблем. Как правило, при проектировании данного этапа лучше проявлять осторожность; если вы планируете переносить 100 настольных компьютеров в неделю, а в действительности вам удается переносить 150, это лучше, чем планировать 150, а сделать 100. Не забудьте о праздниках, отпусках и других ограничениях, связанных с персоналом. Для успешного развертывания необходимо учитывать, что вы переносите среду, от которой зависит работа пользователей, поэтому делать это нужно так, чтобы они испытали как можно меньше неудобств.

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

Эксплуатация

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

Упрощение процесса

Правильный выбор инструментов позволит заметно упростить пилотный этап и выпуск в производство. Пользователи должны иметь возможность работать с минимальными неудобствами, и лучший способ удовлетворить эту потребность - продуманное проектирование, миграция профиля и управляемые решения разных компаний. Например, компания Liquidware предлагает пакет Workspace Environment Management, который поможет выполнить каждый этап миграции Windows, в том числе оценку и проектирование с использованием Stratusphere, и миграцию с помощью ProfileUnity User Management. Stratusphere обнаруживает установленные и используемые приложения и помогает оценить и подготовить оборудование для Windows 10. С помощью ProfileUnity можно без проблем переносить профили пользователей между любыми версиями Windows и значительно уменьшить трудоемкость миграции. Технология Profile Bridge, применяемая в ProfileUnity, позволяет поместить профили пользователей в контейнеры и без проблем работать с ними на разных версиях Windows, совместимых как в обратном, так и в прямом направлении. Благодаря функциональности ProfileUnity сокращается время перемещения и синхронизации, и вы можете выполнять развертывание на настольных компьютерах, ноутбуках, виртуальных и «облачных» системах, чтобы обеспечить пользователям привычную среду на всех устройствах одновременно.

В данной статье мы хотели бы систематизировать наш опыт проведения миграции данных в крупных корпоративных проектах, связанных с переходом Заказчиков на работу в конфигурациях «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 . В результате данной работы составляется и поддерживается реестр мэппинга таблиц. Данный подэтап необходим для следующего подэтапа мэппинга полей и для отслеживания общего состояния дел по мэппингу.

Группа шаблонов 1С	Наименование шаблона 1С	Наименование файла- источника	Правила формирования файла-источника	Ответственный	Статус	Примечание
НСИ	Шаблон_ Номенклатура	Номенк латура.xls	В системе N установить отбор . Сохранить в txt . Открыть в xls, колонки - текстовые . Первая строка - шапка . Кол-во столбцов - 15 . Сверить кол-во строк в txt и xls . Наименование листа всегда "Лист1"	Иванов И.И.	в работе

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

№пп

Кл. поле

Обязательный

Имя поля шаблона 1С «Шаблон_Номенклатура»

Описание

Имя поля «Номенклатура.xls»

Алгоритм заполнения

Код

Код элемента справочника

Код

Наименование

Наименование

Да

Это группа

Содержит одно из значений: . 1 - для групп . 0 - для элементов

Если длина кода=11 символов и последние 4 символа <> "0000", то это элемент - "0", иначе группа - "1".

Полное наименование

Наименование элемента справочника

Наименование

Если ЭтоГруппа =1 , То "", ИначеЕсли ЭтоГруппа=0, то Наименование.

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

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

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

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

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

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

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

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

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

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

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

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

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

Код сотрудника	Фамилия	Имя	Отчество	Дата рождения
2423	Иванов	Иван	Иванович	17.11.1992
1523	Петров	Василий	Александрович	04.02.1991
4363	Сидоров	Кирилл	Николаевич	01.05.1995
	Денисов	Денис	Денисович	01.01.1990

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

Списания

Код сотрудника	Дата	Сумма
2423	01.02.2014
1523	02.02.2014
4363	03.02.2014
	04.02.2014	100000
2423	05.02.2014
1523	06.02.2014
4363	07.02.2014	2356
	08.02.2014	140000
2423	09.02.2014
1523	10.02.2014
4363	11.02.2014	23523
	12.02.2014	80000

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

Код сотрудника	Дата	Сумма
	01.05.2004
	02.05.2004
	03.05.2004
	04.05.2004
2423Дата рождения	Сумма поступление	Сумма списание
Иванов Иван Иванович	2423	17.11.1992	1341234	1010
Петров Василий Александрович	1523	04.02.1991	245245
Денисов Денис Денисович		01.01.1990	380000	320000
Сидоров Кирилл Николаевич	4363	01.05.1995	613382	26336
ИТОГО:			2579861	347842

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

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

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

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

Рис. 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Зачем нужен перенос на SSD, и какие преимущества получает пользователь?

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

Отсюда напрашивается самый простой вывод: после того как будет выполнен перенос Windows 10 на SSD-накопитель, система станет работать намного быстрее, как принято говорить, «летать». На новый винчестер предполагается скопировать исключительно операционную систему , без всякого стороннего мусора. При всем этом, если отдать предпочтение некоторым специфичным программным продуктам по или предназначенных для переноса системы с HDD на SSD, в некоторых случаях можно скопировать только саму систему, клонировать Windows со всеми установленными в ней программами и пользовательскими файлами , даже сформировать образы со всеми пользовательскими настройками. Здесь, как уже понятно, основное условие - выбор соответствующей программы в зависимости от того, что нужно получить в итоге. Но обо всем по порядку.

Общие принципы переноса системы на SSD-накопитель

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

С помощью утилиты Winaero WEI tool можно произвести расчет производительности операционной системы. После переноса Виндовс 10, показатель «Primary Hard Drive » был увеличен с 5.6 до 7.95.

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

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

Для клонирования дисков есть специальные программы (например, Acronis или Paragon). В них маркетинговый фокус нередко делается именно на переносе системы с HDD на SSD, как и в заголовке этого руководства:) Однако можно решить эту задачу с помощью бесплатных средств Microsoft, обходясь без неприятных неожиданностей , причем мои инструкции применимы к любым типам дисков.

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

Сегодня в программе

Вам понадобятся…

Для начала давайте определимся с терминологией. Там, где вы видите фразы «установочный диск», «диск Windows PE», «диск восстановления», с равным успехом можно использовать как оптический диск (CD/DVD), так и съемный USB-диск (флэшку).

Итак, вам нужны:

1. Среда в любой форме. Это может быть:

• установочный диск Windows
• среда восстановления на диске восстановления, соответствующий операционной системе (см. инструкции для Windows 7 или для Windows 8 и выше)
• созданный вами диск Windows PE 3.1 или 4.0

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

Умение загружаться в Windows PE и определяться с буквами дисков .

Утилита imagex той же разрядности, что и среда Windows PE. Утилита может находиться где угодно, за исключением раздела, который вы клонируете.

Почему imagex и где взять утилиту

Здравствуйте друзья! Мне часто доводилось переносить и с простого жёсткого диска HDD на SSD. Применял в основном программы: , Paragon Migrate OS to SSD, Paragon Домашний Эксперт 12 и AOMEI Partition Assistant Home Edition. Самый долгий, но интересный, способ перенести Windows 7 с HDD на SSD с помощью встроенных в Windows средств.

1. Кому интересен процесс переноса программой Paragon Домашний Эксперт 12, переходите по ссылке и читайте статью.
2. Ещё вам будут интересны наши новые статьи
3. Если Вас заинтересовала статья, посетите специальный раздел , где собраны с одного накопителя информации на другой.

Самый простой и удивительно быстрый способ перенести Windows 7 с HDD на SSD с помощью программы Paragon Migrate OS to SSD , с помощью этой программы я и предлагаю Вам сегодня осуществить перенос системы на SSD.

Программа платная, стоит целое состояние 390 рублей. Если у вас Windows 8, то для миграции подойдёт только последняя версия программы Paragon Migrate OS to SSD 3.0.

Сайт http://www.paragon.ru/home/migrate-OS-to-SSD

Важное примечание: Если у вас установлена программа Paragon Домашний Эксперт 12, то утилита Paragon Migrate OS to SSD входит в пакет этой программы.

Если вы хотите перенести Windows 7 с HDD на SSD с помощью Paragon Домашний Эксперт 12 перейдите в конец этой статьи, там есть небольшая инструкция.

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

Как перенести Windows 7 с HDD на SSD с помощью программы Paragon Migrate OS to SSD

Итак обратите внимание на окно Управления дисками моего компьютера, имеется жёсткий диск объёмом 250 ГБ, поделённый на два раздела, на одном из них - диске (C:) находится операционная система Windows 7, её и будем переносить на твердотельный накопитель SSD объём 120 ГБ, представляющий из себя нераспределённое пространство.

Запускаем программу Paragon Migrate OS to SSD. Next.

Программа автоматически нашла мой диск SSD и готова к переносу операционной системы. Обратите внимание на пункт «Use all available space for the partition with OS», поставьте здесь обязательно галочку и всё пространство твердотельного накопителя будет отведено для создания одного нового диска (C:) с перенесённой Windows. Ведь твердотельные накопители и используются в основном только для установки операционной системы.
Если нажать на «Please select what folders should be copied», то вы можете выбрать нужные для копирования папки. Мне нужна вся Windows целиком, поэтому я оставлю всё как есть.

Жмём на кнопку Copy.

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

Мне невольно вспомнился старый добрый Acronis True Image, где нужно было создать образ операционной системы, затем развернуть его на SSD, хотя Acronis работает и безупречно, но времени занимает в несколько раз больше.

Пока мы с вами вели речь про Acronis, программа Paragon Migrate OS to SSD уже перенесла нашу Windows 7 на SSD. Финальное окно, в котором нам предлагают загрузиться уже с твердотельного накопителя SSD. Перезагружаемся.

Теперь нужно войти в БИОС и выставить загрузку с SSD. Выбираем Меню загрузки (F8).

С помощью стрелок на клавиатуре выбираем наш твердотельный накопитель и жмём Enter. Происходит загрузка компьютера с SSD.

Примечание: Чем мне нравится БИОС UEFI, так это наличием собственного загрузчика, который вмещает в себя все имеющиеся загрузчики и никогда в них не запутается. БИОС UEFI помнит последнюю загруженную Вами операционку и в следующий раз загрузит именно её. Переключение между операционными системами (сколько бы у вас их не было установлено) происходит просто, быстро и безошибочно.

Если у вас обычный БИОС, то перенос должен произойти тоже без проблем. Единственное что вам нужно сделать, то найти в нём параметр ответственный за главенство жёстких дисков Hard Disk Drives (AMI BIOS) или Hard Disk Boot Priority (AWARD BIOS) и выставить первым устройством ваш SSD. Как найти эти параметры, можно узнать в.

Требования к компьютеру

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

Сравнить параметры вашего компьютера с указанными выше характеристиками можно с помощью окна «О системе». Оно отображает правильные данные о главных аппаратных и программных компонентах девайса:

Рис.2 – окно просмотра параметров Windows и компьютера

Используем встроенные возможности Виндоус

Следуйте инструкции, чтобы выполнить перенос операционной системы на флеш-устройство:

• Откройте окно «Управление дисками». Для этого в окне выполнить пропишите команду diskmgmt.msc и подтвердите действие;

Рис.3 – запуск средства управления дисками

• Теперь нужно уменьшить объем ОС на диске. Выполнить действие можно с помощью функции «Сжать том». Все данные останутся в прежнем состоянии, только занимаемое место на HDD уменьшится. Кликните правой клавишей на раздел «System», а затем на «Сжать том»;

Рис.4 – Сжатие тома

• После успешного уменьшения объема ОС, в схеме диска появится свободный раздел. Это означает, что всё было сделано правильно;
• Подключите накопитель к компьютеру и перезагрузите окно «Управление дисками»;
• Теперь кликните на вкладке «Мастер» и в списке выберите «Перенос OS SSD»;

Рис.5 -вкладка «Мастер»

• Откроется стандартная утилита для клонирования операционной системы. Нажмите на клавишу «Далее», чтобы перейти к настройкам;
• Кликните на пункт «Незанятое пространство» и перейдите в следующее окно;

Рис.6 – выбор дискового пространства

• Теперь вы можете самостоятельно изменить размер будущего диска или же оставить все параметры без изменений;

Рис.7 – изменение размера раздела диска

• После нажатия на клавишу «Далее» мастер начнёт перемещение системы. После завершения действия вы сможете выключить компьютер и при следующей загрузке выбрать ту ОС, которая находится на SSD.

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

Рис.8 – результат успешного перемещения Виндоус

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

Рис.9 - применение изменений

Инструкция для SSD от Samsung

Выпустила официальную утилиту, которая позволяет быстро переместить ОС из жесткого диска на приобретённый флеш-накопитель. Утилита называется Samsung Data Migration. Загрузить её можно бесплатно с официального сайта компании (раздел «Память»-«SSD») или с помощью диска, который есть в комплектации устройства.

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

Рис.10 – окно утилиты Samsung Data Migration

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

Рис.11 – анализ диска с установленной копией Windows

После анализа программа автоматически определит присоединённый к компьютеру SSD и покажет его на экране:

Рис.12 – сверка исходного и конечного диска

Если место, которое занимает Windows на HDD не превышает доступное место на SSD, вы можете сразу приступать к переносу, нажав на клавишу «Начать». Начнётся автоматическое перемещение всех компонентов. Процедура может занять от 30 минут до 1.5 часов, в зависимости от используемой версии Windows.

Рис.13 - успешный перенос системы

В результате, вы получите уведомление об успешном клонировании операционной системы на флеш-накопитель. Закройте окно и удалите все данные о Windows из HDD.

Плюс использования Samsung Data Migration заключается в простом интерфейсе. Программа сделает всю работу за вас и максимально снизит вероятность появления ошибок или багов после переноса ОС.

Что делать, если на этапе анализа вы обнаружили, что места для ОС не хватает на SSD? В таком случае, необходимо очистить Windows от неиспользуемых данных и приложений. Сделать это можно прямо в окне утилиты Samsung Data Migration.

Рис.14 – Ошибка. Недостаточно места на SSD

После появления текста ошибки (подсвечен красным цветом) нажмите на кнопку «Далее» и в новом окне удалите все файлы библиотеки, которые захламляют систему. Проводите очистку ОС до тех пор, пока в главном окне утилиты не появится текст «Готово к клонированию на SSD».

Рис.15 – успешная очистка лишних файлов

Утилита Acronis True Image

Рис.16 – главное окно приложения Acroins

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

Рис.17 - выбор режима клонирования

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

Рис.18 – процесс копирования

Утилита Seagate DiscWizard

Утилита полностью повторяет интерфейс Acronis. Её нужно использовать в том случае, если на вашем ПК есть хотя бы один жесткий диск от производителя Seagate. Для клонирования следует выполнить те же действия, которые были описаны в предыдущем пункте статьи.

Рис.19 – главное окно Seagate Disc Wizard

Изменение конфигурации загрузчика

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

• Не удаляя первоначальную копию с HDD, протестируйте работу Windows на HDD. Бывают случаи, когда система начинает тормозить, ухудшается производительность. Это происходит крайне редко и зависит исключительно от выбранного SSD. Пока первая копия не удалена, у вас всегда будет возможность вернуться к её использованию и удалить ОС с SSD;
• Измените настройки загрузчика системы.

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

Сразу после клонирования в диспетчере будут показаны две системы с идентичными названиями – первоначальная и скопированная. В случае нормальной работы Windows на SSD, нужно удалить ту версию, которая осталась на жестком диске компьютера. Следуйте инструкции:

• Перезагрузите ПК и запустите ту версию, которая перемещена на флеш-накопитель;
• Откройте командную строку Windows;
• Введите указанную на рисунке ниже команду, задав копии ОС на SSD уникальное имя;

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

О тонкостях процесса миграции нам рассказал Владимир Лебедев, директор по развитию бизнеса Stack Group .

Требования законодательства

В 2006 году был принят 152-ФЗ «О персональных данных» , который призван защитить физических лиц при автоматизированной обработке персональных данных. В прошлом году вступил в силу пакет поправок о локализации персональных данных на территории России, что, по мнению авторов, должно повысить уровень информационной безопасности внутри государства и простимулировать российский рынок технологических решений и рынок информационной безопасности.

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

Для кого закон?

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

В план проверок Роскомнадзора на 2016 год вошли: крупнейшие софтверные компании, международные банки, сетевые торговые компании и интернет-магазины.

Сложности переноса персональных данных для международных компаний

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

Виртуализация

Переехать в облачную среду менее затратно, чем покупать и монтировать оборудование. В конце 2014 года цены на российские облака были в среднем на 15–30% выше, чем на европейские, а в конце 2015 года, наоборот, наши цены стали на 20–30% ниже: изменился валютный курс и относительная стоимость размещения в российских дата-центрах.

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

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

Риски, возникающие при миграции систем хранения данных

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

Этапы миграции в облако

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

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

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

Как правило, для миграции используется утилита VMware converter , которая эффективно работает при переносе ОС семейства Microsoft Windows (но у миграции работающих в этих ОС служб есть свои нюансы). А вот из-за особенностей файловых систем Linux примерно в 40% случаев после окончания работы VMware converter виртуальная машина может не запуститься. Если в Linux используется LVM, то надо развернуть в виртуальной среде новый экземпляр ОС из шаблона провайдера и затем перенести данные, программные продукты и внутренние службы.

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

Миграция ADDS и MS SQL без остановки сервисов

Практически всегда для бизнеса необходимо, чтобы ряд сервисов оставался доступным в ходе миграции. При этом зачастую миграция без остановки сервиса рекомендуется как самая надежная. Поэтому рассмотрим особенности миграции без остановки наиболее популярных служб ОС Microsoft: Active Directory Domain Services (ADDS или AD) и Microsoft SQL (MS SQL). Для миграции Active Directory без остановки службы применяется следующий алгоритм:

• Формируется сетевая связность между физическим оборудованием и виртуализированной средой. Как правило, это site-to-site VPN - он создает логическую сеть поверх другой сети. При этом трафик может быть защищен шифрованием по протоколам IPsec.
• В облаке разворачиваем новые виртуальные машины из шаблона, где настраиваем контроллеры домена AD с добавлением их в лес.
• Базу данных Active Directory реплицируем по сети через VPN с работающих контроллеров на стороне физического оборудования в облачные.
• После репликации данных переназначаем мастеры ролей операций на облачные контроллеры и убираем роли контроллеров домена с серверов.
• Затем проверяем работу сервисов и отключаем учетные записи старых контроллеров и физическое оборудование.

Алгоритм миграции MS SQL более сложен, так как MS SQL обычно применятся в многоуровневом сервисе в качестве бэкенда. В записях DNS в приложениях, использующих базы данных (в клиентах MS SQL), приходится вручную указывать новое расположение базы данных. Поэтому совсем исключить простой нельзя, но его можно свести к минимуму. Существуют механизмы и безостановочной миграции MS SQL, к ним относятся Mirroring и AlwaysOn , но их применение не всегда оправданно. AlwaysOn доступен только в дорогих редакциях Enterprise-уровня, а Mirroring должен поддерживаться клиентами MS SQL. К тому же для применения механизмов Mirroring нужна дополнительная настройка всех клиентов MS SQL.
Рассмотрим наиболее частый вариант миграции MS SQL в облако:

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

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

Информационная безопасность

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

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

Требования к хранению персональных данных

Требования к технической защите конфиденциальной информации и предоставлению услуг по защите информации достаточно четко сформулированы. Инструменты их реализации многообразны. В частности, это могут быть сетевые экраны, системы обнаружения вторжений, средства анализа защищенности, антивирусной защиты, средства защиты сред виртуализации. На рынке представлен широкий спектр средств защиты информации - и российских, и зарубежных вендоров. Есть уже правоприменительная практика, так как закон действует с 2007 года. В целом подход к регулированию в России отличается от, например, европейского подхода. Так, в России неисполнение предписанных требований по информационной безопасности ведет к возникновению ответственности. А на Западе компания может самостоятельно определять, каким способом выполнять требования, и ответственность наступает, только если совершены неправомерные действия с персональными данными.

Требования к инфраструктуре

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

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

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

INFO

В Китае полная копия персональных данных должна храниться на территории страны, а любые банковские данные вообще запрещено передавать за ее пределы.

Прогноз на перенос

Довольно сложно подсчитать, сколько точно данных подлежат переносу в Россию, но, исходя из заполняемости рынка ЦОД, можно сказать, что мощностей вполне достаточно для локализации данных в соответствии с законом. Например, на рынке Московского региона наблюдается переизбыток мощностей: общая емкость составляет около 27 тысяч стоек , и почти 40% из них свободны. Многие дата-центры имеют площади высокой степени готовности. Нужно учесть и что плотность данных в одной стойке может различаться в зависимости от оборудования. Сегодня один юнит серверной стойки обрабатывает значительно больше информации, чем несколько лет назад.

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