Перенос данных с одного сервиса на другой при нарушении некоторых процессов сопряжен с потерей важнейших данных о хозяйственных операциях компании, простоями и другими проблемами. В данной статье приведем перечень рекомендаций, которые позволят выполнить процедуру с минимальными рисками.
Когда требуется перенос данных?
Создавать новы базы данных, реестры и регистры современным компаниям приходится по ряду причин, в том числе при:
- Обновлении норм и требований законодательства;
- Смене руководителя проекта или приобретении прав на стартап третьим лицом;
- Полной смене архитектуры системы хранения данных;
- Внедрении инновационных технологий или замене морально устаревших программных решений;
- Использование преднастроенных облачных решений;
- Снижении или повышении скорости обработки информации.
Этапы проведения процедуры
Перемещение данных о финансовой и хозяйственной деятельности компании в облачный сервис – сложный процесс, состоящий из четырех последовательных этапов, каждый из которых должен осуществляться согласно установленным требованиям.
Этап 1: проведение инвентаризации перед миграцией данных
Если перенос данных осуществляется сторонней организацией, приглашенные специалисты должны понять, какую информацию необходимо мигрировать и в каких сервисах она хранится на данный момент. Крупные корпорации часто используют сразу несколько серверов, СУБД, файловых и документных хранилищ, внедряют серверы кэширования. Это сильно усложняет задачу, поскольку необходимо обработать огромный объем данных из разных источников.
Первоочередной задачей на данном этапе является разработка плана переноса информации. Специалисты вычленяют главные источники, систематизируют основные справочники и регистры. Для удобства весь объем работ можно свести в таблицу, в которой будут указываться следующие критерии планирования:
- типы данных;
- определенные направления документооборота компании, требующие переноса в другой сервис 1С;
- пути к файлам для облегчения поиска нужных справочников и регистров;
- объем хранимых данных (далеко не всегда специалисты могут точно определить размеры переносимой информации из-за частого обновления системы хранения);
- регулярность обновления данных;
- важность данных для обеспечу печенья бесперебойной работы компании;
- частота совершения бекапов;
- оценка степени критичности данных в разрезе рисков, наступающих при их потере. Нередки ситуации, когда данные, хранящиеся на одной СУБД, могут использоваться только при наличии данных в другой СУБД. В таком случае специалисты удаляют данные из первой базы, а потом восстанавливают их при работе со второй базой.
Внимание! При переносе данных следует следить за тем, чтобы у всей важной информации были бекапы. Если в компании не распространена практика их создания, до переноса данных в сервис необходимо внедрить инструменты резервного копирования.
Следующий этап переноса данных может осуществляться столько после проведения полной инвентаризации и при необходимости резервного копирования всех документов и файлов, которые являются критически важными для компании.
Этап 2: Планирование процедуры
Создание вышеописанной таблицы - лишь 1 первый шаг в планировании всех процессов по переносу данных. Чтобы определить объем необходимых работ, специалисты ранжируют все источники информации по важности. Первыми мигрируют самые важные данные.
Если компания использует разные источники хранения информации, для каждого из них необходимо внедрить инструмент миграции. В качестве такого инструмента могут выступать различные файлы с командами для выполнения на сервере или сложные системы, позволяющий автоматизировать развертывания. Важнейшим требованием при разработке инструмента является его документальное оформление.
Инструменты миграции необходимы для в случае, когда перенос и копирование данных требует неоднократного повторения процедур. Как правило, резервное копирование приходится использовать, когда на определенных этапах переброса данных выявляется ошибка.
Если ходе переноса данных требуется смена архитектуры, ответственные за проведение процедуры лица должны подготовить тесты для систем, для которых будут внедряться инновационные продукты. Ниже приведен перечень таких случаев:
- перенос данных с дисков серверов на хранение в S3-хранилище. При выполнении данной операции некоторые файлы могут повредиться и стать недоступными.
- При смене типа СУБД. Специалистам необходимо проверить не только корректность вставки и удаления всех записей в БД, но и проконтролировать скорость работы коннектов в базу под нагрузкой. Объем нагрузок зависит от того, как много запускается копий приложений.
Тесты помогают выявить нарушения на основных компонентах приложений. Однако следует понимать, что после смены архитектуры повторные дополнительные проверки данных должны входить в перечень обязательных процедур.
Этап 3: Тестовая миграция данных
Тестовую миграцию данных необходимо проводить для выявления возможных нарушений в процессе переноса данных от одного провайдера к другому. Для этого используются тестовые серверы. В ходе выполнение работы специалист должен убедиться в правильной и эффективной работе всех инструментов, корректности отображения данных в новых базах, высокой скорости открытия файлов, точности загрузки записей.
Перенос данных далеко не всегда может выполняться правильно. В ходе процедуры некоторые файлы повреждаются, обнаруживаются несовпадения в версиях баз данных, падает качество работы скриптов и настроек.
Внимание! В тестовом режиме можно переносить не все данные, достаточно произвести выборку иммигрировать только те данные, которые попали в тестовую группу. Если в системе сохранено огромное количество записей, для тестового переноса можно использовать только 1% используемой в компании информации.
Этап 4: Миграция данных
Если этап тестового переноса данных завершился без каких-либо нарушений, можно приступать к настоящей миграции:
- Специалисты информируют заказчиков о начале технических работ;
- Все серверы и сервисы выключаются, чтобы избежать появления новых данных в системе. Если выключить определенные источники не представляются возможным, миграция проходит в горячем режиме;
- Создаются необходимые бекап и всей информации;
- Осуществляется непосредственный перенос данных согласно разработанному ранее плану с использованием только зато задокументированных инструментов миграции;
- Система обновляется для дальнейшей работы с новыми данными;
- Все необходимые для работы компании приложения и сервисы запускаются и тестируются для проверки на наличие ошибок в загрузках файлов;
- После окончания тестового режима сервисы запускаются в стандартном варианте, устанавливаются необходимые пароли и входы для пользователей.
На практике распространены случаи самостоятельного переноса данных внутренними специалистами компании. Чтобы минимизировать риски рекомендуется запрашивать помощь у внешних консультантов. Например, облачные провайдеры предоставляют консультационную помощь в миграции инфраструктуры. Также в распоряжении пользователей есть автоматический платформы для миграции серверов, приложений и данных.
Почему компании все чаще используют облачных провайдеров?
Использование облачных хранилищ существенно упрощает процесс миграции. Райдеры используют гибкие инструменты для работы с облачными хранилищами, создают все необходимые программные решения для автоматизации процессов создания и хранения резервных копий для популярных СУБД. К тому же, процесс создания тестовых стендов для проверки работоспособности процедуры переноса существенно упрощается облаке. Тестовое окружение можно завести буквально пару действий.