Классика миграции

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

Это, что называется, классика жанра, и не только в ИТ, как покажет пример, который я приведу ниже.

Классический метод миграции

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

В случае применения классического подхода к миграции обычно преследуются следующие цели:

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

Для успеха мероприятия необходим план (как говорил Б.Франклин: if you fail to plan, you are planning to fail). В общих чертах в плане указываются следующие этапы:

1. Проведение инвентаризации и аудита (бо́льшая часть всех проблем при миграции связаны с неучтенными нюансами существующей структуры системы). На этом этапе также определяются проблемы существующей структуры; уточняются задачи обновленной системы. 
2. Разработка новой структуры системы. На этом этапе принимаются решения по исправлению проблем, избавляются от ненужных сервисов, добавляют новые. Причем желательно все проверить в лабораторных условиях. 
3. Создание новой структуры системы. От документирования до построения новой "пустой" системы. 
4. Непосредственно сама миграция - перенос сервисов и данных. Обычно миграцию проводят в два прохода: вначале тестовая, затем "боевая". После окончательной миграции какое-то время еще поддерживают старую систему, пока не убедятся, что все сервисы работают так, как нужно, и ничего не потерялось при переходе. Затем ее разбирают. 

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

Типичные проблемы миграции

В жизни, на первом этапе очень часто забывают учесть все нюансы, от чего на четвертом этапе "это что-то" надо как-то заставить работать в новой системе.

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

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

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


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

А, во-вторых... Слушая новости, я обнаружил очень интересную аналогию.


Аналоги миграции вне мира ИТ

Мы сейчас можем наблюдать пример интересной миграции. Из милиции в полицию.
Теперь пойдет профессиональный сленг.

По задаче:

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

Неправда ли похоже?


Смотрим, что там по этапам?
Конечно, сложно оценивать снаружи такую закрытую инфраструктуру, но попробуем.

1. Проводился ли аудит системы? Скорее всего - да (отчеты президенту и т.п.). Вопросы только к качеству аудита. Слишком много там было баг-юзанья и использования недокументированных возможностей. Все ли учли? Все ли зависимости прописали?

2. Подготовили [законо]проект. Более того - привлекли к обсуждению проекта даже конечных пользователей системы.
В лаборатории ничего не проверяли, но ссылались периодически на различные best-practice.

3. Создали систему. Правда, как обычно, еще не все закуплено, смонтировано, установлено; а уже перешли к самому процессу миграции. Более того, похоже, что в данном случае третий и четветый этапы пришлось объединить.

4. Миграция началась. Но без предварительного тестового переноса всех систем. Процедура выглядит так:

1. Выбирают часть сервисов; 
2. Тестируют; 
3. Прошедшие тест мигрируют в новую систему. 

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


Интересно, как миграцию закончат, кейс напишут?