Как не «погореть» при переезде

Игорь Григорьев: «Очень важно на этапе предварительного обследования выявить алгоритм взаимодействия ИТ-систем и определить общий порядок их переезда» Источник: «Инфосистемы Джет»

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

— Что в вашей интерпретации означает переезд ИТ-системы?

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

Один из вариантов переезда — физическое перемещение в другой дата-центр или на другую площадку. Также возможен переезд со сменой платформы — как аппаратной, так и программной. Третья разновидность — так называемый «онлайн-переезд», при котором время остановки ИТ-сервисов минимизировано. В жизни зачастую встречается комбинация всех перечисленных типов миграции. Это самый сложный случай, поскольку процесс нужно организовывать так, чтобы потребители ИТ-услуг не заметили, что система вообще куда-то переехала. Исходя из опыта выполненных проектов мы разработали собственную методологию переноса корпоративных ИТ-систем.

— В чем состоит предложенная вами методология? С чего вообще нужно начинать переезд?

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

— Можно ли провести миграцию своими силами?

Зачастую сотрудники компании не знают, как подступиться к миграции, — не хватает практического опыта, нет целостного взгляда на свою ИТ-инфраструктуру. В больших организациях в миграции участвует несколько подразделений, которым порой сложно друг с другом договориться. Если задачу переезда поставить перед администраторами систем, каждый из них, скорее всего, попросит новое оборудование и постарается осуществить перенос с минимальным простоем, а это не всегда целесообразно. Интегратор в данном случае становится связующим звеном, единой точкой управления проектом. Мы добиваемся того, чтобы все участники проекта работали как единая кросс-функциональная команда, помогаем оптимизировать процесс миграции с учетом имеющихся целей, задач, сроков и бюджета. В нашей практике был случай, когда один из банков начал миграцию своими силами, но в итоге обратился к нам: переезд грозил растянуться на несколько лет, тогда как срок аренды ЦОД истекал через восемь месяцев. После того как мы классифицировали системы и определили тип переезда, удалось организовать работу «конвейерным методом». В результате уложились в отведенные сроки, осуществив миграцию около 400 виртуальных серверов.

— Всегда ли заказчика устраивает предложенная стоимость проекта?

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

— Какова степень детализации плана переезда?

Для типовых систем (например, инфраструктурных) пишется высокоуровневый план миграции, для сложных и сильно связанных между собой систем — более детальный. Фиксируются все инженерные операции, вплоть до того, какие данные ИТ-систем куда необходимо скопировать, по каким протоколам они будут переданы и т. д. Заранее определяется продолжительность этапов миграции (это особенно важно при онлайн-переезде). В случае необходимости проводится дополнительное обследование. Если перенос осуществляется через подменный фонд, решается, каким образом его нужно подготовить на новой площадке для успешного переноса данных и приложений. Редко бывает, когда первоначальные проработки реализуются без изменений. В большинстве случаев миграция — это стресс для заказчиков. Чтобы сократить продолжительность проекта и уменьшить риски, работы выполняются конвейерным способом. Проектируется переезд системы или группы систем, и затем отдается на реализацию. Таким образом, мы рационально используем свои ресурсы, а заказчик может планировать свою деятельность во время миграции. На этой же стадии определяются критерии, по которым будет принято решение об успешности каждого этапа. Для критичных или проблемных систем планируется тестовый переезд.

— Тестовый переезд позволяет предотвратить проблемы?

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

— Какая часть данных резервируется в процессе миграции?

Это зависит от проекта. Так, при переезде ИТ-систем «Голден Телеком» в ЦОД «ВымпелКома» мы провели миграцию 63 информационных систем, в том числе 250 серверов. Часть систем была переключена в режиме онлайн; примерно пятая часть всех данных компании полностью резервировалась. Если говорить о подменном оборудовании, у нас есть свой коммерческий виртуальный центр обработки данных, ресурсы которого мы можем предоставить заказчику, например, для резервного копирования данных. Это существенно сокращает время переезда, поскольку не нужно покупать и настраивать подменный фонд. Ведь поставка нового ИТ-оборудования может занять несколько недель. В подобных проектах мы всегда точно знаем, где находится копия критичных для бизнеса данных, которые можно немедленно восстановить.

— Каким образом заказчик контролирует ход проекта?

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