Миграция данных: преимущества, ограничения и правила

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

На вопросы издания ответил Сергей Головашов, начальник центра компетенций DevOps/DevSecOps, Bell Integrator. 

Вопрос 1. В каких случаях перенос данных, действительно, необходим? И как убедить в этом руководство?

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

Вопрос 2. Основные подходы к миграции данных, используемые сегодня

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

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

Вопрос 3. Какие проблемы могут появиться при переходе с одной базы данных на другую? И как с ними справиться?

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

В целом существуют несколько проблем миграции.

У нас возникает проблема остановки сервера для обновления, если сервер простой. А если сложный, включающий в себя микросервисы, то добавляется еще и проблема обновления версии сервера с зависимостями.

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

Но если что-то пойдет не так, то возникает третья проблема – отказ от новой версии сервера с зависимостями приводит к цепной реакции. Нам придется откатиться полностью.

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

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

Вопрос 4. Какие шаги может предпринять системный администратор, чтобы упростить процедуру миграции для себя и компании?

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

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

Довольно хорошо процессы тестирования и миграции показаны в документации про Blue-green deployment, canary release, которые очень хорошо позволяют и проработать процесс перехода, и в последствии совершить миграцию без проблем и технического останова. Простым языком, blue-green deployment – это способ развертывания, который позволяет обновлять приложения, не отклоняя ни одного запроса, без остановок.

Вопрос 5. Какие сейчас существуют решения на ИТ-рынке по автоматизации миграции?

Решений для автоматизации на рынке нет. Ситуация довольно классическая и похожа на анекдот «Приборы! Сто! Что сто?! А что приборы?!».

Вопросы миграции настолько объемны, что их невозможно объять каким-то одним решением. Если, с одной стороны, достаточно сделать клон сервера и развернуть в другом ЦОД такой же, но после поменять ему ip-адресацию и все заработает, то с крупными корпоративными системами (особенно legacy) это уже не сработает. И тут приходится очень долго и нудно заниматься планированием и попыткой учесть все возможные риски. Поэтому мое мнение однозначное – таких систем нет и не будет, потому что в целом процесс миграции уникален для каждой отдельной инфраструктуры.

Вопрос 6. Как обеспечить безопасность данных при миграции?

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

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

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

Полную версию статьи читайте здесь