Когда поднимаешь сеть на только что отстроенном объекте, в идеальном мире строители уже подготовили для тебя помещения, протянули СКС, подвели питание и сделали всё что нужно. В реальности синхронизации между поднимающими сеть интеграторами и строителями не всегда придают должное значение. Что может пойти не так?
Расскажу вам об очень показательном кейсе такого рассинхрона. Я Сергей Шульгин, эксперт по сетевым технологиям ИТ-компании К2Тех. И этой историей я как бы намекаю, зачем в крупных проектах нужен технадзор и почему мудрые заказчики кровью вписывают его в договор с интеграторами.
В этой истории всё кончится хорошо, потому что мы неплохо тушим пожары и импровизируем в моменте. А потом делаем выводы. Подобные истории учат нас строить процессы иначе и видеть подводные камни заранее. Надеюсь, вам эта история поможет избежать некоторых организационных ошибок без необходимости учиться на собственном опыте.
Как всё начиналось
В начале 2023 года несколько компаний в составе одного крупного промышленного холдинга, всего около 1000 человек, решили съехаться из трёх офисов в один. Они обратились к нам за организацией в новом офисе локальной вычислительной сети и Wi-Fi.
Сотрудников разных компаний холдинга планировали посадить вперемешку, на одних коммутаторах. При этом ИТ-службы компаний работали по-разному, задействовали разные сетевые конфигурации. ЛВС должна была поддержать такую возможность.
Участники этой истории:
Мы — К2Тех, интегратор. Мы спланировали архитектуру решения, а потом выполняли внедрение. С нашей стороны в этом участвовало 5 инженеров и технический менеджер.
Строительная компания, которая ремонтировала помещения. Помимо красивых стен, ковролина, окон и дверей на них лежала подготовка помещений для кроссовых, прокладка LAN, подводка питания к помещениям, оборудованию и так далее.
Заказчик — холдинг, который въезжает в новый офис.
План-капкан
Сначала холдинг обратился к нам не для самого развертывания сети, а для его планирования. Мы выполнили эту работу в довольно спокойном режиме, за месяц.
Мы провели аудит имеющегося оборудования на предмет переиспользования. В основном у них было оборудование Cisco, и мы придумали, как переиспользовать его часть.
Для остального оборудования мы описали требования, чтобы заказчик мог самостоятельно его выбрать и закупить. Плюс к этому по критериям заказчика мы подобрали и рекомендовали конкретного вендора, доступного в России, с которым мы уже работали — Вектор Технологии. Нюанс — нам нужно было, чтобы вендор зарезервировал под проект оборудование на несколько десятков млн ₽ до момента сделки, то есть, на несколько месяцев. У нас доверительные отношения и с вендорами, и с заказчиком, поэтому такой договоренности удалось достичь.
Заказчик выбрал предложенного вендора. С учетом этого:
LAN решили строить на коммутаторах доступа VA2100-48P (22 шт.), коммутаторах ядра VC6100-24X (2 шт.) и переиспользовать четыре старых коммутатора Cisco 9300.
Беспроводная сеть предполагала 56 точек доступа VAP300-2X2i, 2 контроллера VNC-2000 в режиме кластеризации.
О нашем опыте с вендором «Вектор Технологии» С их оборудованием мы уже имели дело на других проектах и оно хорошо прошло испытания в нашей тестовой лаборатории. Так что для нас это была хорошая «рабочая лошадка». Функционально оборудование хорошо себя показывает в части и беспроводной сети, и коммутаторов ЛВС. Нам нравится проактивная позиция вендора: инженеры подключаются удалённо, при необходимости выезжают на площадки, когда надо что-то протестировать, воспроизвести или настроить. При необходимости дорабатывают продукт. Для наших клиентов особенно важно, что вендор имеет доступную русскоязычную поддержку. Команда физически находятся в Москве, отвечают на почту и телефон, ездят на площадки. В Москве есть ЗИП с хорошим запасом оборудования. Из неочевидных ограничений вендорского оборудования — если в стеке более 4 коммутаторов и при этом у вас бывают блэкауты, перезагрузка стека начинает затягиваться. Это лечат хорошие ИБП либо архитектура, в которой больших стеков просто не нужно. |
Наконец, мы описали в виде ТЗ все требования к строителям, чтобы обеспечить для оборудования место, электропитание, описали разводку оптоволокна и так далее.
Всю эту документацию мы разработали за месяц, передали её заказчику и разошлись. С конца апреля шла интенсивная подготовка площадки и ремонтные работы. Мы не были в это вовлечены, просто радовались за тех, кто будет подключать оборудование — ребята придут на всё готовенькое, правда?
В мае подключить оборудование пригласили нас. Стройка была уже в разгаре. У нас был месяц, чтобы подготовиться к въезду жильцов. Чтобы уложиться, развёртывание ЛВС нужно было вести параллельно с завершением строительных работ. Ну да ладно, мы так уже делали. Оборудование, купленное по нашей наводке, начали завозить и складировать в самом отремонтированном и непыльном помещении — кухне.
Оказавшись в гуще стройки, мы поняли, что что-то пошло не так.
Как строители не получили наше ТЗ и что из этого вышло
Немного занимательной бюрократии. Заказчиком наших работ был ИТ-отдел, а строительных работ — хоз-отдел. Чтобы ТЗ попало к строителям, нужно было всего лишь, чтобы сотрудники ИТ и хоз-отдела были лучшими на свете друзьями и подставляли друг другу плечо в любой сложной ситуации. В реальности всё обстояло несколько иначе, и хоз-отдел написал строителям собственную версию ТЗ, никак не связанную с нашей. Так что за ковролин и кресла можно было не беспокоиться.
Теперь расскажу, за что беспокоиться стоило.
Электропитание. Это, пожалуй, самая большая боль. В ТЗ по версии хоз-отдела не было заложено нужных мощностей под оборудование, они просто не были подведены в помещения. Чтобы решить эту проблему, мы собрали двухдневный консилиум со всеми ключевыми участниками и главным инженером управляющей компании здания. Решение нашли, но оно, разумеется, не было похоже на то, что мы спланировали. Нам пришлось за 2 недели перепроектировать все стойки, в этот раз в плотном синхроне со строителями.
На этом фоне была масса более мелких косяков вроде витой пары, уложенной в стойке так, что на 4 нижних юнита невозможно что-либо смонтировать (хотелось туда поставить ИБП).
Кроссировка. По плану кабели от рабочих мест должны были сходиться в 5 кроссовых помещений. По плану нам нужно было просто запустить в кроссовых коммутаторы и подключить к ним порты короткими кабелями. Но строители решили воспользоваться лазейкой в формулировках в ТЗ и сэкономить усилия. Часть разводки LAN досталась помещению в наследство от прошлых его обитателей. Строители подумали, почему бы не отдать нам их? В итоге для части кабелей мы не понимали, какие пользователи сидят на каких портах. Пришлось заниматься их прозвоном.
Ну а в части помещений LAN просто не был подведён. Так что в офисе временно возникало такое:
Документацию на реально проложенную LAN строители передали нам за день до въезда сотрудников в новый офис. Так что большую часть подготовительных работ мы проводили наощупь, без документации.
Wi-Fi. Прелесть беспроводных сетей в том, что строители не могут криво их проложить — проводов-то нет. Но зато хоз-отдел не заложил в ТЗ кронштейны под точки доступа. На одном из этажей, по счастливой случайности, кронштейны остались от прошлых обитателей помещения. На других этажах крепления делали мы сами: в срок, дёшево, без СМС и регистрации. Чем только не приходится заниматься ИТ-интегратору!
Ну а для части точек доступа строители просто забыли прокинуть кабели вопреки документации. Так что мы не могли их повесить и придумывали, как сохранить покрытие другими способами, например, за счёт тюнинга мощности сигнала других точек.
Была ещё масса мелких досадных моментов, вплоть до обломанных ключей в личинке стойки. Но если всё это обобщить, нас пригласили поставить оборудование в условиях, в которых это было невозможно из-за ошибок на уровне строительства. Чтобы срочно подогнать реальность под наше ТЗ, нам попытались придать надзорные функции. Только было уже слишком поздно. Наши полномочия не были оговорены и регламентированы. Большие проблемы приходилось решать через всеобщие собрания всех. Проблемы поменьше решались за счёт нашей смекалки, несгибаемого оптимизма и готовности делать не свою работу, потому что без нас это просто не взлетит.
Долго ли, коротко ли, но к дедлайну мы развернули LAN и беспроводную сеть, для которой добились отличного покрытия сигнала.
Заезд и дружеские шутки
Заезд сотрудников длился 1.5 недели. В части данных и приложений инфраструктура заказчика была в облаке, так что миграция подразумевала только переезд самих рабочих мест.
С вечера сотрудники в старом офисе паковали вещи, по ночам заказчик привозил их, а утром сотрудники уже приходили в новый офис. В основном схемы рассадки заранее не были установлены, так что большинство сотрудников мы подключали в режиме живого потока.
После переезда мы исправляли возникающие мелкие сбои. Наша любимая история: в какой-то прекрасный момент в сети возникла петля. Мы нашли сегмент сети, в котором это происходит. Ребята из команды заказчика дошли туда ногами. И вот что они обнаружили:
Зачем? Мы так и не знаем. Хочется верить, что кто-то просто решил сыграть над нами добрую дружескую шутку.
Технадзор, прописанный в контракте
В итоге всё получилось, и заказчик пришел к нам с новым проектом — похожим новым зданием, в котором надо развернуть сеть. В плане оборудования решили снова строить сеть на Вектор Технологии.
В плане всего, что в прошлый раз пошло не так, мы вместе с заказчиком устроили разбор полётов. Главный урок — несогласованная между подрядчиками работа создаёт серьёзные риски и может ограничить возможности ИТ-инфраструктуры.
При этом создавать аврал и связанные с ним риски — вообще типичная история для крупных заказчиков. Они задают временные рамки, в которых строительные и инфраструктурные работы приходится вести параллельно (иногда также параллельно с оформлением договоров). Можно на это злиться, осуждать, проклинать — но вряд ли это когда-нибудь изменится. Я отношусь к этому по-философски: если безобразие нельзя остановить, его надо возглавить.
Так что в этот раз мы выступим техническим заказчиком строительных работ в части, которая обеспечивает ввод оборудования в эксплуатацию. Мы транслируем требования заказчика к ИТ-инфраструктуре в требования к помещениям, прокладке кабелей, подводке электропитания и так далее, и эти требования передаются другим подрядчикам. Далее мы выполняем технадзор — контроль и плотный контакт с другими подрядчиками, их синхронизацию. Функция технического заказчика и наши полномочия по технадзору теперь прописаны в договоре между нами и заказчиком.
Ну а в плане времени, теперь на синхронизацию у нас не 2 недели, а несколько месяцев.
Бесценный жизненный опыт
Результат конкретного внедрения, в каком-то смысле, скучный: проект завершился успешно, в срок, заказчик остался доволен. Но теперь вы знаете, сколько всего пришлось сделать под капотом, чтобы это произошло.
С точки зрения жизненного опыта мы вместе с заказчиком поучаствовали в поучительном иммерсивном шоу о рассинхроне между подрядчиками. Заказчик узнал, почему подрядчиков нельзя оставлять во взаимной изоляции, и проникся пониманием ценности технадзора (особенно когда он рискует не справиться с этой функцией при сжатых сроках проекта) Да, причиной проблем была недо-коммуникация между ИТ- и хоз-отделом заказчика. Но функция технадзора позволяет обнаруживать такие сложности заранее и искать решение совместно.
Расскажите в комментариях, были ли у вас похожие проблемы в синхронизации с другими подрядчиками. А если хотите ещё почитать про развертывание сетей на стройке и про авральное вендорозамещение, то посмотрите, как мы на лету заменяли Huawei на Maipu.
