Пасхалочки от строителей при развёртывании ЛВС, или зачем нужен технадзор

Когда поднимаешь сеть на только что отстроенном объекте, в идеальном мире строители уже подготовили для тебя помещения, протянули СКС, подвели питание и сделали всё что нужно. В реальности синхронизации между поднимающими сеть интеграторами и строителями не всегда придают должное значение. Что может пойти не так?

Расскажу вам об очень показательном кейсе такого рассинхрона. Я Сергей Шульгин, эксперт по сетевым технологиям ИТ-компании К2Тех. И этой историей я как бы намекаю, зачем в крупных проектах нужен технадзор и почему мудрые заказчики кровью вписывают его в договор с интеграторами.

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

Как всё начиналось

В начале 2023 года несколько компаний в составе одного крупного промышленного холдинга, всего около 1000 человек, решили съехаться из трёх офисов в один. Они обратились к нам за организацией в новом офисе локальной вычислительной сети и Wi-Fi.

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

Участники этой истории:

• Мы — К2Тех, интегратор. Мы спланировали архитектуру решения, а потом выполняли внедрение. С нашей стороны в этом участвовало 5 инженеров и технический менеджер.

• Строительная компания, которая ремонтировала помещения. Помимо красивых стен, ковролина, окон и дверей на них лежала подготовка помещений для кроссовых, прокладка LAN, подводка питания к помещениям, оборудованию и так далее.

• Заказчик — холдинг, который въезжает в новый офис.

План-капкан

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

Мы провели аудит имеющегося оборудования на предмет переиспользования. В основном у них было оборудование Cisco, и мы придумали, как переиспользовать его часть.

Для остального оборудования мы описали требования, чтобы заказчик мог самостоятельно его выбрать и закупить. Плюс к этому по критериям заказчика мы подобрали и рекомендовали конкретного вендора, доступного в России, с которым мы уже работали — Вектор Технологии. Нюанс — нам нужно было, чтобы вендор зарезервировал под проект оборудование на несколько десятков млн ₽ до момента сделки, то есть, на несколько месяцев. У нас доверительные отношения и с вендорами, и с заказчиком, поэтому такой договоренности удалось достичь.

Заказчик выбрал предложенного вендора. С учетом этого:

• LAN решили строить на коммутаторах доступа VA2100-48P (22 шт.), коммутаторах ядра VC6100-24X (2 шт.) и переиспользовать четыре старых коммутатора Cisco 9300.

• Беспроводная сеть предполагала 56 точек доступа VAP300-2X2i, 2 контроллера VNC-2000 в режиме кластеризации.

Наконец, мы описали в виде ТЗ все требования к строителям, чтобы обеспечить для оборудования место, электропитание, описали разводку оптоволокна и так далее. 

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

В мае подключить оборудование пригласили нас. Стройка была уже в разгаре. У нас был месяц, чтобы подготовиться к въезду жильцов. Чтобы уложиться, развёртывание ЛВС нужно было вести параллельно с завершением строительных работ. Ну да ладно, мы так уже делали. Оборудование, купленное по нашей наводке, начали завозить и складировать в самом отремонтированном и непыльном помещении — кухне.

Оказавшись в гуще стройки, мы поняли, что что-то пошло не так.

Как строители не получили наше ТЗ и что из этого вышло

Немного занимательной бюрократии. Заказчиком наших работ был ИТ-отдел, а строительных работ — хоз-отдел. Чтобы ТЗ попало к строителям, нужно было всего лишь, чтобы сотрудники ИТ и хоз-отдела были лучшими на свете друзьями и подставляли друг другу плечо в любой сложной ситуации. В реальности всё обстояло несколько иначе, и хоз-отдел написал строителям собственную версию ТЗ, никак не связанную с нашей. Так что за ковролин и кресла можно было не беспокоиться. 

Теперь расскажу, за что беспокоиться стоило.

Электропитание. Это, пожалуй, самая большая боль. В ТЗ по версии хоз-отдела не было заложено нужных мощностей под оборудование, они просто не были подведены в помещения. Чтобы решить эту проблему, мы собрали двухдневный консилиум со всеми ключевыми участниками и главным инженером управляющей компании здания. Решение нашли, но оно, разумеется, не было похоже на то, что мы спланировали. Нам пришлось за 2 недели перепроектировать все стойки, в этот раз в плотном синхроне со строителями.

На этом фоне была масса более мелких косяков вроде витой пары, уложенной в стойке так, что на 4 нижних юнита невозможно что-либо смонтировать (хотелось туда поставить ИБП).

Кроссировка. По плану кабели от рабочих мест должны были сходиться в 5 кроссовых помещений. По плану нам нужно было просто запустить в кроссовых коммутаторы и подключить к ним порты короткими кабелями. Но строители решили воспользоваться лазейкой в формулировках в ТЗ и сэкономить усилия. Часть разводки LAN досталась помещению в наследство от прошлых его обитателей. Строители подумали, почему бы не отдать нам их? В итоге для части кабелей мы не понимали, какие пользователи сидят на каких портах. Пришлось заниматься их прозвоном.

Ну а в части помещений LAN просто не был подведён. Так что в офисе временно  возникало такое:

Документацию на реально проложенную LAN строители передали нам за день до въезда сотрудников в новый офис. Так что большую часть подготовительных работ мы проводили наощупь, без документации.

Wi-Fi. Прелесть беспроводных сетей в том, что строители не могут криво их проложить — проводов-то нет. Но зато хоз-отдел не заложил в ТЗ кронштейны под точки доступа. На одном из этажей, по счастливой случайности, кронштейны остались от прошлых обитателей помещения. На других этажах крепления делали мы сами: в срок, дёшево, без СМС и регистрации. Чем только не приходится заниматься ИТ-интегратору!

Ну а для части точек доступа строители просто забыли прокинуть кабели вопреки документации. Так что мы не могли их повесить и придумывали, как сохранить покрытие другими способами, например, за счёт тюнинга мощности сигнала других точек.

Была ещё масса мелких досадных моментов, вплоть до обломанных ключей в личинке стойки. Но если всё это обобщить, нас пригласили поставить оборудование в условиях, в которых это было невозможно из-за ошибок на уровне строительства. Чтобы срочно подогнать реальность под наше ТЗ, нам попытались придать надзорные функции. Только было уже слишком поздно. Наши полномочия не были оговорены и регламентированы. Большие проблемы приходилось решать через всеобщие собрания всех. Проблемы поменьше решались за счёт нашей смекалки, несгибаемого оптимизма и готовности делать не свою работу, потому что без нас это просто не взлетит.

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

Заезд и дружеские шутки

Заезд сотрудников длился 1.5 недели. В части данных и приложений инфраструктура заказчика была в облаке, так что миграция подразумевала только переезд самих рабочих мест.

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

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

Зачем? Мы так и не знаем. Хочется верить, что кто-то просто решил сыграть над нами добрую дружескую шутку.

Технадзор, прописанный в контракте

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

В плане всего, что в прошлый раз пошло не так, мы вместе с заказчиком устроили разбор полётов. Главный урок — несогласованная между подрядчиками работа создаёт серьёзные риски и может ограничить возможности ИТ-инфраструктуры.

При этом создавать аврал и связанные с ним риски — вообще типичная история для крупных заказчиков. Они задают временные рамки, в которых строительные и инфраструктурные работы приходится вести параллельно (иногда также параллельно с оформлением договоров). Можно на это злиться, осуждать, проклинать — но вряд ли это когда-нибудь изменится. Я отношусь к этому по-философски: если безобразие нельзя остановить, его надо возглавить. 

Так что в этот раз мы выступим техническим заказчиком строительных работ в части, которая обеспечивает ввод оборудования в эксплуатацию. Мы транслируем требования заказчика к ИТ-инфраструктуре в требования к помещениям, прокладке кабелей, подводке электропитания и так далее, и эти требования передаются другим подрядчикам. Далее мы выполняем технадзор — контроль и плотный контакт с другими подрядчиками, их синхронизацию. Функция технического заказчика и наши полномочия по технадзору теперь прописаны в договоре между нами и заказчиком.

Ну а в плане времени, теперь на синхронизацию у нас не 2 недели, а несколько месяцев.

Бесценный жизненный опыт

Результат конкретного внедрения, в каком-то смысле, скучный: проект завершился успешно, в срок, заказчик остался доволен. Но теперь вы знаете, сколько всего пришлось сделать под капотом, чтобы это произошло. 

С точки зрения жизненного опыта мы вместе с заказчиком поучаствовали в поучительном иммерсивном шоу о рассинхроне между подрядчиками. Заказчик узнал, почему подрядчиков нельзя оставлять во взаимной изоляции, и проникся пониманием ценности технадзора (особенно когда он рискует не справиться с этой функцией при сжатых сроках проекта) Да, причиной проблем была недо-коммуникация между ИТ- и хоз-отделом заказчика. Но функция технадзора позволяет обнаруживать такие сложности заранее и искать решение совместно.

Расскажите в комментариях, были ли у вас похожие проблемы в синхронизации с другими подрядчиками. А если хотите ещё почитать про развертывание сетей на стройке и про авральное вендорозамещение, то посмотрите, как мы на лету заменяли Huawei на Maipu.