Русский
Русский
English
Статистика
Реклама

Успеть за 24 часа история переезда оборудования между ЦОДами

Переезд сродни пожару. Накал страстей нужно умножить на 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 минут после начала переезда. Точкой отсчета для нас стал момент, когда наших инженеров подпустили к отключенному оборудованию. Потом еще в течение недели шла тонкая донастройка работы нового дата-центра. В одних случаях модифицировали коммутацию, некоторые устройства требовали обслуживания. Происходило сопровождение переехавшего ЦОДа. И если с подключением оборудования мы расправились на выходных, то еще до среды отлаживали нюансы, чтобы весь комплекс оборудования работал оптимально.

Такие проекты сложны из-за высокой нервной нагрузки. Я не спала сутки, и вся команда понимала, что права на ошибку нет. Но оно того стоило. Для сотрудников и клиентов банка переезд дата-центра так и остался незамеченным. Все было перевезено и запущено за выходной, и для нас это стало лучшей наградой.

Драгоценная мораль

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

  1. При переезде нужно думать за себя и того парня. По возможности нужно наладить сквозную проверку документации между всеми участниками: и теми, кто проектирует, и теми, кто внедряет. Это можно организовать, например, во время совместного осмотра площадки.

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

  3. На подобный переезд нужно закладывать дополнительные ресурсы. Во-первых, должно быть как минимум два менеджера. Один человека может энергетически не вытянуть разруливание проблем все 24 часа, если планы начнут сыпаться, как костяшки домино.Во-вторых, нужно предусмотреть скамейку запасных из исполнителей, если работы выйдут за рамки плана и основному составу нужно будет экстренно дать отдых.

  4. Качественная подготовка к переезду прекрасный повод для ревизии имеющегося ИТ-хозяйства. На этом проекте мы сэкономили массу времени и сил, отказавшись от перевоза старых серверов.

  5. Ночные смены = увеличенная нагрузка. К ночным работам стоит относится аккуратнее вдвойне и команды менять вовремя, не рассчитывая на переработки.

  6. Нужен почасовой план с пошаговым описанием действий всех участников. Да, сражение никогда не идет по плану, но, если у вас нет плана вы точно проиграете. Поэтому очень помогает предварительно прогнать всю схему с участниками процесса в настольном режиме и заложить дополнительные резервы на случай сбоев. А еще, готовя такой план, не стоит попадать в ловушку сознания: если я пробегаю 100 метров за 10 секунд, то с марафоном за управлюсь меньше, чем за 1,5 часа. Это не так. Усталость сильно влияет на скорость работ, и это тоже нужно брать в расчет.

А вы участвовали в подобных ИТ-переездах? Какие выводы оказались самыми ценными для вас?

Автор: Нина Пушкарь, менеджер проектов Инфосистемы Джет



Источник: habr.com
К списку статей
Опубликовано: 29.03.2021 10:21:19
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании инфосистемы джет

Анализ и проектирование систем

Читальный зал

Переезд

Цод

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru