Переезд сродни пожару. Накал страстей нужно умножить на 10, когда речь идет о перевозке целого ЦОДа крупного банка. Сомневаетесь, что за 24 часа можно перевести 25 стоек, которые содержали 150 единиц оборудования, включая СХД, высокопроизводительные серверы HP Superdome и целый набор разных систем от Sun, Huawei, Lenovo, Quantum и IBM? Берите попкорн, кота на колени, вязание (нужное подчеркнуть), а мы расскажем, как это было и поделимся лайфхаками, как пережить подобные проекты.
Наш клиент — крупный банк, — готовился к строительству нового ЦОД. Старый дата-центр ждал полный демонтаж, а на его месте должен был быть возведен новый. И пока проектировался новый центр обработки данных, возникла необходимость оперативно перевезти оборудование на временную площадку.
Заказчик обозначил идеальный план — переехать за 24 часа. По факту же задача состояла в том, чтобы минимизировать время простоя критически важных систем и не прервать работу банка. Но мы решили попробовать организовать переезд в течение астрономических суток.
Хорошая подготовка — половина успеха
Работали мы вместе с командой заказчика, куда входили специалисты по направлению СХД, виртуализации и серверов — всего больше 10 человек. Это были руководитель и администратор проекта, а также эксперты по сопровождению инженерных систем ЦОД, сетевой инфраструктуре, системам процессинга и другим специализированным банковским системам, телефонии, СУДБ, системам виртуализации, управлению инцидентами, поддержке СХД и СРК и прочие. Специалисты заказчика отвечали за прикладную часть, и поначалу на наших плечах лежала только демонтаж, перевозка железа, монтаж и настройка инфраструктурного софта.
Вместе с заказчиком мы проводили аудиты исходной и целевой площадок. Нам нужно было продумать и просчитать переезд до минут, предусмотреть различные корнер-кейсы, а также коммутировать оборудование на новом месте. Этим занимались сетевики заказчика, которые должны были в день переезда предоставить нам схему подключения оборудования.
Позитивным побочным эффектом переезда стала ревизия имеющихся активов. Так выяснилось, что часть оборудования логичнее вывести из эксплуатации, чем перевозить. С одной стороны, заказчик сбросил с себя балласт из устаревших серверов, с другой — у нас уменьшилось число оборудования, которое нужно было перевозить и запускать.
Тем более, что в основном энергии требовала организация работы всех участников. Понятно, что никто не может работать без потери качества 24 часа подряд. Поэтому для переезда были организованы 3 смены по 8 часов — всего почти 40 человек. В состав команд вошли инженеры-монтажники, профильные инженеры для присутствующих классов оборудования и грузчики. Таким образом, в каждой команде были люди, которые демонтируют, раскомутируют, перевозят, монтируют, коммутируют и настраивают.
Все были подготовлены и ориентированы на 8 утра, чтобы приступить к разборке техники для последующей перевозки. На этом идеальная часть проекта закончилась…
Три. Начинаем разбирать
Закон Мёрфи гласит: «Если что-то может пойти не так, оно пойдет не так». Практика такова, что чем масштабнее проект и экстремальнее сроки, тем больше вероятность возникновения «сюрпризов». Когда мы прибыли на площадку, далеко не все оборудование было готово к вывозу. Отключение и вывод систем из продуктива занял больше времени, и нам пришлось ждать старта.
Мы быстро адаптировались к ситуации и сперва наперво переориентировали грузчиков, сказав им «пока не приезжайте». Остальным инженерам мы продлили смену, потому что заменить их было некем, а отпустить их «еще отдохнуть» было нельзя — непонятно, сколько именно времени пришлось бы ждать подготовки оборудования.
Два. Переезжаем
Отставание от графика уже перевалило 5 часов, когда оборудование было готово. Начали работать. Нужно было погрузить 25 стоек со 150 единицами оборудования. Чтобы уложить переезд в сутки, мы выставили приоритеты, разделив системы на 3 категории. Сначала перевозились наиболее критичные системы, потом — средней важности и наименее приоритетные.
В числе переезжавших устройств оказались не только серверы — переселялось также хранилище high-end класса Huawei Ocean Store и уникальная для России система защиты Hitachi Protection Platform. Это оборудование курировали профильные специалисты с соответствующей сертификацией. Тонкость заключалась в том, что нам нужно было подобрать по 3 инженера на каждый вид специализированного оборудования, чтобы в каждую смену кто-то «знающий» отвечал за соответствующие устройства.
Высококлассные инженеры — «бриллианты» в нашей команде. В проекте они работали вместе с помощниками, которые стали и дополнительными руками, и совершали простые операции под руководством монтажников. Они ставили салазки для серверов, переносили оборудование, крутили болты, упаковывали коробки и так далее.
Один. Собираем и запускаем
Несмотря на все сложности, мы укладывались в график и — даже! — привезли оборудование на площадку вовремя. И тут снова начались сюрпризы... Оказалось, что переданная нам схема коммутации расходится с реальной по отдельным точкам. Где-то не хватало кабеля, где-то не было нужных портов, а несколько серверов и вовсе не вошли на предполагаемые места в стойках по количеству юнитов.
К счастью, в каждой смене у нас были крутые сетевики, и бОльшая часть проблем решалась на месте. Парни быстро разработали дополнения и изменения к схеме коммутации. А там, где это было нужно, серверы просто поменяли местами, переставили и добавили необходимые соединения.
К подключению сложных устройств мы тщательно подготовились заранее и вовлекли в проект вендоров. Например, для отключения и подключения HP Superdome приехал инженер HPE. Hitachi Protection Platform мы запускали на новом месте при поддержке российского представительства. То же самое касалось и Huawei Oceanstor — нам потребовалось практически непрерывно поддерживать связь с техподдержкой производителя, пока шла настройка и конфигурирование на целевой площадке.
Можно ли успеть за 24 часа?
В результате мы действительно сдали собранный ЦОД через 23 часа 20 минут после начала переезда. Точкой отсчета для нас стал момент, когда наших инженеров подпустили к отключенному оборудованию. Потом еще в течение недели шла тонкая донастройка работы нового дата-центра. В одних случаях модифицировали коммутацию, некоторые устройства требовали обслуживания. Происходило сопровождение переехавшего ЦОДа. И если с подключением оборудования мы расправились на выходных, то еще до среды отлаживали нюансы, чтобы весь комплекс оборудования работал оптимально.
Такие проекты сложны из-за высокой нервной нагрузки. Я не спала сутки, и вся команда понимала, что права на ошибку нет. Но оно того стоило. Для сотрудников и клиентов банка переезд дата-центра так и остался незамеченным. Все было перевезено и запущено за выходной, и для нас это стало лучшей наградой.
Драгоценная мораль
Этот напряженный проект заставил меня еще раз проинспектировать мой личный список «Важно помнить», который меня выручает в подобных кейсах. Делюсь своей скрижалью.
При переезде нужно «думать за себя и того парня». По возможности нужно наладить сквозную проверку документации между всеми участниками: и теми, кто проектирует, и теми, кто внедряет. Это можно организовать, например, во время совместного осмотра площадки.
К работе с уникальным оборудованием обязательно нужно привлекать вендора. Стоит заранее делать запрос вендору, потому что нужный специалист может оказаться занят на время проекта.
На подобный переезд нужно закладывать дополнительные ресурсы. Во-первых, должно быть как минимум два менеджера. Один человека может энергетически не вытянуть разруливание проблем все 24 часа, если планы начнут сыпаться, как костяшки домино. Во-вторых, нужно предусмотреть скамейку запасных из исполнителей, если работы выйдут за рамки плана и основному составу нужно будет экстренно дать отдых.
Качественная подготовка к переезду — прекрасный повод для ревизии имеющегося ИТ-хозяйства. На этом проекте мы сэкономили массу времени и сил, отказавшись от перевоза старых серверов.
Ночные смены = увеличенная нагрузка. К ночным работам стоит относится аккуратнее вдвойне и команды менять вовремя, не рассчитывая на переработки.
Нужен почасовой план с пошаговым описанием действий всех участников. Да, сражение никогда не идет по плану, но, если у вас нет плана — вы точно проиграете. Поэтому очень помогает предварительно прогнать всю схему с участниками процесса в «настольном» режиме и заложить дополнительные резервы на случай сбоев. А еще, готовя такой план, не стоит попадать в ловушку сознания: если я пробегаю 100 метров за 10 секунд, то с марафоном за управлюсь меньше, чем за 1,5 часа. Это не так. Усталость сильно влияет на скорость работ, и это тоже нужно брать в расчет.
А вы участвовали в подобных ИТ-переездах? Какие выводы оказались самыми ценными для вас?
Автор: Нина Пушкарь, менеджер проектов «Инфосистемы Джет»
