Переезд ЦОДа: план был хорош. Реальность оказалась интереснее

Мы уже писали о том, как правильно смигрировать ЦОД: на что обратить внимание при планировании миграции и проектировании целевой архитектуры (тут и тут), как осуществить сам переезд максимально безболезненно (тут).

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

Предыстория

Крупная компания, субъект критической информационной инфраструктуры. Десятки ИТ-систем с требованием доступности 24/7. Два ЦОДа в Москве. Один из них перестал удовлетворять потребностям: старый, неудобное расположение, без возможности расширения, с накопившимися проблемами по надёжности.

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

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

Глава первая, в которой подбор ЦОДа занимает два года

Подготовка к переезду заняла больше времени, чем все ожидали. Нам предстояло найти новую площадку, которая соответствовала бы требованиям заказчика как субъекта КИИ: Tier III по инженерным системам, выделенная секция для размещения стоек с оборудованием с индивидуальным контролем доступа, газовое пожаротушение, охраняемая территория, резервирование питания и охлаждения. И отдельное требование — транспортная доступность: от офиса компании не более 40 минут. Большинство подмосковных площадок отпало сразу.

Мы объездили десятки площадок. Работали так: сначала запрос документации по электронной почте, потом обязательный выезд инженеров и аудит вживую. Часть ЦОДов отсеялась как раз из-за несоответствия описания на бумаге действительности. Маркетинг и реальность — разные вещи. Это не новость, но каждый раз немного удивляет.

Выбор площадок совпал с уходом западных производителей из РФ, что усложняло работу: нужно было учитывать, на каком оборудовании работают инженерные системы ЦОД, и есть ли возможность получения запчастей и сервиса.

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

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

Это был хороший урок на будущее. Когда тебе говорят «мы строим, всё будет готово точно в срок» — закладывай сценарий, при котором не будет.

На следующий год все заново — снова выезды и аудит площадок, снова конкурс. На этот раз в финал вышел ЦОД, который всем сразу понравился: современная инженерная база, полное соответствие всем требованиям, честные ответы на неудобные вопросы. Несмотря на то, что эта площадка была дороже конкурентов, заказчик выбрал её: опыт предыдущего года показал, во что может обойтись экономия на надёжности.

Глава вторая, в которой мы готовим новую площадку к переезду

После выбора площадки предстояло ее оснастить всем необходимым и подготовить к работу. В новом ЦОД заказчику было выделено огороженное пространство для размещения там 34 стоек с оборудованием. Выгородка была оснащена СКУД, системой видеонаблюдения, доступ – только для ограниченного числа сотрудников.

Далее нужно было смонтировать стойки, развести СКС — оптику и медь, установить патч-панели, навесить управляемые PDU. 

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

Кстати, эта система – наша разработка – расскажем о ней в следующих статьях. Напишите в коментах, если хотите статью на этот счет.

Подготовка площадки тоже не прошла идеально гладко. Во время работ обнаружили, что часть кабелей в поставке оказались «битыми». К счастью, производитель оперативно отреагировал – проверили и заменили бракованную партию. Неприятный момент, но в сроки уложились, и площадка была готова.

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

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

Глава третья, в которой выясняется, что план — это только начало

Итак, площадка готова. Сеть построена. Начинаем планировать физический переезд.

На первый взгляд, логика простая: составляем список оборудования, определяем очерёдность, формируем партии, едем по расписанию.

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

При этом сроки были ограничены: заказчик готов был оплачивать аренду старого ЦОД не более, чем в течение 2 месяцев. Соответственно, весь переезд мы должны были закончить за это время.

Мы составляли план переезда, а потом обновляли его. Потом что-то менялось – мы снова обновляли. Потом обновляли то, что уже обновляли. 

В таких проектах нужно планировать итеративно — зафиксировал очерёдность, получил подтверждение готовности от заказчика, скорректировал партию, поехал. И так каждую неделю.

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

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

Глава четвёртая, про изобретения

Не обошлось в проекте без «инноваций».

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

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

Жесткая упаковка и обрешетка на то количество оборудования, которое мы должны были перевести, по предварительной оценке, обошлась бы примерно в 500 тысяч рублей. 

Мы начали думать, как выполнить переезд с меньшими тратами.

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

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

Мы потратили на эту историю 50 тысяч рублей и несколько часов коллективного разочарования. Зато теперь точно знаем, что это не работает. 

Рабочее решение оказалось простым: тяжёлое оборудование размещали на паллеты с пеноплексом под основание, всё оборачивали в несколько слоев пупырчатой плёнки и стрейча. 
Итог – экономия в 3-4 раза. 

Глава пятая, в которой мы учимся смирению

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

Первая партия оборудования переехала. Включаем. Что-то не запускается.

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

Cтандартная ситуация, которую почему-то каждый раз воспринимаешь как неожиданность. Согласование «сверху» и реальная экспертиза «снизу» — разные вещи. Хорошо, когда удается увидеть расхождения в начале пути.

Решили вопрос так: с определённого момента коммутацию взяли на себя инженеры заказчика. Мы привозили оборудование, монтировали, передавали актуальную таблицу подключений. Они коммутировали так, как должно быть, и отражали изменения в таблице. Далее мы запускали оборудование и проверяли, что все работает. Не идеально с точки зрения разделения ответственности, зато работало.

Была ещё одна история с PDU — уже в новом ЦОДе. Мы перевозили часть PDU со старой площадки, поэтому каждый раз нужно было вызывать электриков ЦОДа, чтобы подключить новую стойку. У электриков свой график – иногда приходилось ждать их визита до следующего дня. Поставленное железо стояло без питания, запуск откладывался.

Это не претензия к ЦОДу. В следующий раз будем закладывать дополнительный буфер на ожидание в плане работ, чтобы не удивляться потом.

И последнее – из разряда неожиданных открытий. Для переезда могут потребоваться сильные инженеры не только в плане знаний, но и физически. Часть оборудования весом под 120 кг нужно было установить в стойки на высоте уровня глаз. Почему было решено разместить его именно так – загадка. Но команда справилась. Отзывы о процессе воспроизводить не будем.

Чем закончилось

Переезд завершили в срок. Ни одного незапланированного простоя отмечено не было. Ни один инженер не пострадал. Заказчик поставил проекту оценку 5 из 5.

Наша команда состояла из 6 человек: руководитель проекта, ГИП, четыре инженера. Два месяца физической миграции, четыре месяца с учётом проектирования. А до этого — два года выбора площадки, оснащения и подготовки.

Мы реализовали проект полностью: аудит и выбор нового ЦОДа, оснащение площадки, модернизацию сетевой архитектуры, планирование и проведение миграции, пусконаладку, поддержку после переезда. 

Для заказчика большой плюс, когда весь проект ведет один подрядчик – меньше меньше шансов, что что-то потеряется при передаче между этапами, и увеличатся сроки.

Из того, что стоит запомнить — не из учебника, а из этого конкретного проекта:

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

Если у вас похожая задача или есть вопросы — пишите в комментарии.