Планирование миграции

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

Предварительные требования:план принятия миграции, посадочная зона Azure

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

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

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

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

Выбор пути миграции данных

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

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

2. Используйте VPN, если ExpressRoute недоступен. Выберите VPN, если требуется безопасная передача данных, но у вас нет ExpressRoute. VPN создает зашифрованный туннель через Интернет в Azure, хотя обычно это медленнее ExpressRoute. Перед началом работы убедитесь, что у вас есть VPN-шлюз, настроенный в Azure.

3. Используйте Azure Data Box для больших объемов данных. Data Box лучше всего подходит для автономной миграции с большим количеством данных. Microsoft отправляет вам физическое устройство, на которое вы копируете свои данные, а затем возвращаете его обратно. Этот параметр позволяет избежать использования сети, но занимает больше времени из-за доставки.

4. Используйте общедоступный Интернет для менее конфиденциальных данных. Этот параметр работает, если данные не требуют шифрования, и вы не можете использовать ExpressRoute или Data Box. Хотя этот метод доступен везде, это наименее безопасный и может замедлить другие действия в Интернете.

Определение последовательности миграции

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

Поиск зависимостей

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

2. Анализ типов зависимостей и критическости. Для различных типов зависимостей требуются различные подходы к миграции. Различие между этими категориями:

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

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

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

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

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

Устранение проблем в операциях с разделенной средой

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

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

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

Приоритизируйте рабочие нагрузки для миграции

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

   Priority	Ценность для бизнеса	Effort	Description
   High	High	Low	Быстрые достижения — миграция сначала для немедленного эффекта
   Средне-высокий	High	High	Стратегические инвестиции — тщательно планируйте с достаточными ресурсами
   Средне-низкий	Low	Low	Простые кандидаты — заполняют пробелы, возникающие между крупными миграциями
   Low	Low	High	Избегайте или откладывайте — сосредоточить ресурсы на возможностях с более высоким уровнем ценности

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

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

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

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

Создание подробного расписания миграции

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

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

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

Выбор метода миграции для каждой рабочей нагрузки

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

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

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

Определение плана отката

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

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

2. Автоматизация шагов отката в конвейерах CI/CD. Используйте такие средства, как Azure Pipelines или GitHub Actions , для автоматизации процессов отката. Например, настройте конвейеры для повторного развертывания предыдущей версии, если проверка работоспособности завершается ошибкой.

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

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

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

Привлечение заинтересованных лиц к плану миграции

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

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

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

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

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

5. Определите критерии успешности и проверьте контрольные точки. Задайте измеримые метрики, включая тесты производительности, проверку функциональности и условия принятия пользователем. Назначьте официальные точки проверки для принятия решений об одобрении или отклонении (go/no-go).

Следующий шаг