Подписаться
Читать в телеграм
Один переезд равен двум пожарам только тогда, когда вы беретесь за него на горячую голову
Грузовик или ракета?
Как бы компания ни относилась к ИТ-миграции, избежать ее в сегодняшних бизнес-условиях вряд ли получится. Рано или поздно неизбежны переезд в другое офисное здание или дата-центр (смена места дислокации ИТ-инфраструктуры), обновление или перенос на другую платформу критичных для компании информационных систем. И здесь возникает целый пул сложнейших вопросов: как обеспечить миграцию без простоя ИС или потери/кражи данных, что нужно учитывать при оценке стоимости подобного проекта и т.д. Необходимо тщательно планировать все этапы переезда, чтобы не потерпеть фиаско. В нашей статье мы рассмотрим разновидности миграции, нюансы и «рецепты» ее проведения, выверенные нами за годы работы.
Отметим, что переезжать могут как бизнес-, так и инфраструктурные системы. Первые представляют собой набор ПО и аппаратных средств, реализующих бизнес-функции компании (CRM, ERP, биллинг и т.п.). Вторые входят в зону ответственности ИТ-подразделения и отвечают за реализацию бизнес-процессов лишь опосредованно.
Наш опыт показывает, что существует три типа миграции. Первый мы условно называем «грузовиком»: это физическое перемещение существующего ИТ-комплекса в другой ЦОД «как есть».
Второй вариант подразумевает смену программной и (или) аппаратной платформы.
Последний тип наиболее сложный, это переезд с минимальным простоем прикладных систем, так сказать, «со скоростью ракеты» – в режиме онлайн.
В крупных компаниях чаще всего встречаются комбинации названных вариантов, предполагающие практически ювелирную работу со стороны интегратора. Ему необходимо спланировать и провести миграцию таким образом, чтобы для потребителей ИТ-сервисов «картина мира» осталась неизменной – переезд системы прошел незамеченным.
Как приготовить миграцию?
Проводя несколько десятков подобных проектов в год, мы разработали свою рецептуру переноса систем. Первый шаг – это установление целей миграции. Необходимо понять, чего именно хочет добиться компания: провести стандартизацию, вывести устаревшее оборудование из эксплуатации, повысить уровень поддержки, сократить CAPEX/OPEX, решить проблемы с нехваткой электропитания и т.п. Затем мы совместно с заказчиком определяем вид и принципы миграции. Отсюда возникает главный вопрос: как именно мы поедем? Каково количество исходных и целевых прощадок, число и степень критичности прикладных систем, которые планируется перенести, в чем заключаются текущие схемы резервирования, допустима ли для части ИТ-сервисов «грубая перевозка» в режиме «выключить–перевезти–включить», для каких систем время простоя должно быть минимальным и т.д.
Понятно, что можно пойти разными путями: создать новый центр обработки данных и переключиться на него, параллельно «погасив свет» в прежнем, или «закрыть на ключ» старый ЦОД, перевезти все ИТ-хозяйство в новый и провести его монтаж. Опыт показывает, что наиболее распространен промежуточный вариант: системы второго приоритета перевозят «грубо», с отключением, а критичные сервисы – в онлайн-режиме.
Первостепенно на стадии предварительного обследования определить схему взаимодействия прикладных систем и порядок их переезда. Это позволяет дать примерную оценку стоимости «миграционного» проекта (в том числе заложить расходы на формирование фонда подменного оборудования на случай выхода их строя имеющегося, на обеспечение дополнительных каналов связи между площадками и т.д.).
Рис. 1. Пример сценария миграции
Нужно также тщательно проработать вопрос рисков. Например, если мы уже на этапе экспресс-обследования понимаем, что вероятность возникновения бюджетных ограничений на закупку необходимого для переезда оборудования высока, то дополнительно рассматриваем и альтернативные варианты миграции. То же самое происходит и в случае риска нехватки места в серверных помещениях – мы ищем обходные пути решения проблемы.
В планирование работ по самой миграции входит определение ее основных этапов и желаемых результатов. При этом компания-заказчик может контролировать ход проекта с помощью отчетов, которые мы разрабатываем для каждого подобного кейса. Их формат зависит от требований CIO: мы можем предоставлять как стандартные регулярные отчеты с подробной детализацией, так и графики, передающие динамику проекта (число переехавших систем за определенное время). В результате заказчик четко представляет себе, как именно у него идет миграция.
Рис. 2. Пример отчетности, предоставляемой компании-заказчику
Вам нужны детали?
Мы хотим подробнее остановиться на нюансах составления плана миграции. Он может быть как высокоуровневым, так и детализированным, это зависит от степени критичности, сложности переезжающих систем, их связанности между собой и т.д.
Типовые системы (чаще всего инфраструктурные) не требуют досконально проработанного плана, в отличие от своих «сложносочиненных» собратьев. Последним необходима предельная детализация, то есть мы фиксируем все инженерные операции: какие данные ИТ-систем и куда именно нужно скопировать, по каким протоколам мы будем их передавать и т.п.
Также для бизнес-критичных систем мы часто предусматриваем проведение тестового переезда. Он позволяет в тренировочном режиме проверить правильность технического подхода к миграции. По его итогам компания-заказчик принимает решение о начале полноценного переезда или о корректировке способа миграции.
Кроме того, мы заблаговременно определяем хронометраж шагов миграции (эта информация имеет первостепенное значение при онлайн-переезде). При необходимости наши эксперты проведут дополнительное обследование. Например, если в миграции будет задействован подменный фонд, мы разработаем сценарий его инсталляции и настройки в новой серверной для успешного переноса приложений и данных.
Наш многолетний опыт показывает, что первоначальные проработки экспертов воплощаются в жизнь без изменений очень редко. Миграция для многих заказчиков несет с собой стресс, поскольку она завязана на жесткое планирование и грозит серьезными рисками. Для сокращения продолжительности проекта и нивелирования рисков мы применяем методику конвейера при выполнении работ. Что это означает: мы осуществляем проектирование переезда системы или группы систем и отдаем на реализацию. В результате наши ресурсы используются оптимально, а заказчик получает возможность планировать свою бизнес-деятельность на время осуществления миграции.
По каждой группе систем компании-заказчика мы:
- Готовим схему целевого решения, трансформаций и миграции
- Оцениваем возможный простой системы
- Формируем требования к каналам связи и подменному фонду
- Оцениваем риски и объем трудозатрат
Я б миграцию провел, пусть меня научат?
Зачастую специалисты компании-заказчика не знают, как подступиться к процессу миграции – им может не хватать для этого опыта, целостного представления о состоянии, физическом и логическом устройстве ИТ-инфраструктуры.
Вдобавок в крупных компаниях в «переезде» принимают участие сразу несколько подразделений, и порой им сложно прийти к консенсусу. Приведем пример: если задачу миграции поставить перед владельцами систем – администраторами, каждый из них с высокой долей вероятности попросит новое «железо» и постарается осуществить перенос с минимальным простоем, что далеко не всегда является целесообразным в общей перспективе. Интегратор здесь выступает в роли связующего звена, является точкой управления миграционным проектом. Мы ставим своей задачей обеспечение сплоченной работы всей команды, способствуем выстраиванию процесса с учетом поставленных целей, сроков и бюджета.
