Это не про пути миграции перелетных птиц и не про плюсы и минусы зимовки в Тайланде (хотя сезон близится). Сосредоточимся на важном, но не всегда прозрачном процессе – миграции ИТ-инфраструктуры в облако. Если с преимуществами миграции все ясно, то сам «переезд» часто вызывает вопросы, особенно у тех, кто переезжает в облако впервые. Мы собрали наиболее частые и отвечаем на них максимально практично и просто.
С чего начинается процесс миграции?
Со встречи представителя заказчика и наших специалистов. На ней мы договариваемся о плане взаимодействия. Дальнейшие шаги зависят от «багажа данных», который есть у клиента. Если заказчик знает, какие системы и на каком оборудовании у него работают, какую нагрузку они генерируют и каковы его требования к облаку, мы предлагаем ему соответствующую конфигурацию и помощь в миграции.
Если же какой-то информации не хватает, ее нужно проверить или клиент затрудняется сформулировать требования, необходима наша экспертная консультация. Мы проводим аудит информационных систем заказчика, после чего разрабатываем для него предложение по конфигурации.
И в том, и в другом случае клиент получает от нас описание оптимальной конфигурации под его потребности и «дорожную карту», как строить процесс миграции. Одной из важнейших составляющих плана является согласование расписания даунтаймов – времени, на которое ИТ-сервисы будут недоступны. Здесь надо учитывать и особенности бизнеса компании-заказчика, и сложность переносимых информационных систем, и многое другое. Но варианты решения мы обязательно найдем.
Можно ли обойтись без перерыва в работе?
Можно, но не всегда. Все зависит от того, какие информационные системы и оборудование использует заказчик на момент начала проекта. Если речь идет о древней и запутанной ИТ-инфраструктуре, обойтись без даунтайма вряд ли возможно. Наши компетенции позволяют сделать миграцию «бесшовной», но в некоторых случаях даунтайм необходим для того, чтобы данные не были потеряны.
Мы делаем все, чтобы минимизировать простои даже в самых сложных проектах: всегда стараемся приблизиться к идеальному варианту миграции, при котором конечные пользователи абсолютно не замечают перемен и в их ежедневной работе ничего не меняется.
Какова «классическая» схема миграции?
«Классических» схем больше, чем одна. Выбор варианта зависит от вводных. Например, если ИТ-инфраструктура клиента работает на решениях VMware, то для переноса базы данных в облако, также работающее на VMware (в нашей платформе СБКлауд есть такой сегмент, а также ряд сервисов на основе решений VMware - например, Виртуальный ЦОД), можно использовать специализированное ПО. Процесс пройдет быстро, просто и бесшовно.
Другая схема позволяет осуществить миграцию через резервное копирование – конечно, если копии делают. Это, пожалуй, один из самых простых вариантов: резервные копии всех виртуальных машин «затягиваются» в облако, устанавливаются приложения, заказчик проверяет, все ли хорошо установилось, и начинает работать. Для резервных копий можно использовать наши сервисы: "Облачное хранилище для бизнеса" подойдет для данных и документов небольшой компании, а "Объектное хранилище S3" с доступом по протоколу Amazon S3 - для проектов, связанных с неограниченным масштабированием и географическим распределением объектов и данных.
Есть и другие варианты миграции. К примеру, бывает необходимо провести оптимизацию и преобразование архитектуры информационных систем – это задача требует других подходов и схем. Но в каждом случае мы выбираем модель миграции, которая оптимальна по отношению к потребностям заказчика и текущему состоянию его ИТ-инфраструктуры.
С какими сложностями могут столкнуться компании при переносе инфраструктуры в облако?
Зачастую сложности возникают, если заказчик использует информационные системы, которые взаимодействуют через интернет или имеют сложную сетевую топологию. Информационные системы, как и виртуальные машины, обмениваются друг с другом информацией через сеть. Если в облако переносится часть инфраструктуры, возникает необходимость настраивать новые сетевые маршруты, чтобы старые информационные системы «знали», куда переехала новая. А это не всегда просто. Однако проблема решаема: наш опыт и компетенции в этом процессе играют важную роль.
Также сложности могут появиться, если в компании никто не знает, как работают древние информационные системы, какое «железо» (а иногда и где) установлено. Аудит инфраструктуры, который мы делаем на начальном этапе, позволяет эту сложность минимизировать.
Какие специалисты заказчика должны быть задействованы в процессе миграции?
Всегда в процесс должен быть вовлечен тот сотрудник, который отвечает за то ПО, которое мигрирует в облако – он может помочь и рассказать о нюансах его работы. Без такого специалиста осуществить миграцию сложнее. Специалист, который отвечал за администрирование на стороне заказчика и знает, что и как устроено в ИТ-инфраструктуре, очень важен для успешной миграции.
Подчеркну: речь не о топ-менеджерах, которые отвечают за стратегические процессы. Процесс миграции не должен их затрагивать, как и рядовых пользователей. .
Какими должны быть результаты миграции?
Самый важный результат – чтобы бизнес работал без изменений, не заметив переезда в облако. Если ни одна информационная система не сбоит, все нужные данные сохранены и доступны пользователям – значит, миграция прошла успешно. Правильно проведенная миграция - та, которой пользователи не заметили.