миф 1

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

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

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

Миф 2

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

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

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

Миф 3

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

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

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

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

Миф 4

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

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

Сами сценарии миграции тоже заметно различаются. В одних случаях применяют подход «lift and shift», когда инфраструктуру переносят без изменения внутреннего устройства. В других одновременно меняют операционную систему, обновляют прикладное ПО или перестраивают архитектуру сервиса. Такие проекты выходят далеко за рамки простой конвертации.

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

Миф 5

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

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

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