[Анализ и проектирование систем, Читальный зал] Успеть за 24 часа: история переезда оборудования между ЦОДами

Автор Сообщение
news_bot ®

Стаж: 6 лет 7 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
29-Мар-2021 12:33


Переезд сродни пожару. Накал страстей нужно умножить на 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 часа. Это не так. Усталость сильно влияет на скорость работ, и это тоже нужно брать в расчет.
А вы участвовали в подобных ИТ-переездах? Какие выводы оказались самыми ценными для вас?Автор: Нина Пушкарь, менеджер проектов «Инфосистемы Джет»
===========
Источник:
habr.com
===========

Похожие новости: Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_chitalnyj_zal (Читальный зал), #_pereezd (переезд), #_tsod (цод), #_blog_kompanii_infosistemy_dzhet (
Блог компании Инфосистемы Джет
)
, #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
)
, #_chitalnyj_zal (
Читальный зал
)
Профиль  ЛС 
Показать сообщения:     

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 28-Сен 05:25
Часовой пояс: UTC + 5