Вроде бы и там и там есть стены, дверь, крыша – но возьмись школьник, успешно колотящий полезные домики для птиц, построить коттедж, шансов на успех у него было бы совсем немного. Безусловно, мы утрируем, сравнивая скворечники и ЦОДы, но именно такое уничижительное сравнение позволит наиболее полно оценить разницу в сложности проектирования ЦОДа на 50 стоек и ЦОДа на 1000 стоек.
Год от года увеличивая масштаб наших комплексных проектов ЦОДов, мы сталкивались с разными сложностями. Некоторые проблемы и ошибки мы обнаружили, выступая в качестве субподрядчиков процесса проектирования, и теперь хотим рассказать о тех моментах, которые могут повлиять на процесс проектирования наиболее существенным образом.
Исходные данные
Техническое задание как краеугольный камень
Проектирование
Разработка проектной документации для серверных помещений и инженерных систем
> Выnолненные nроекты
S
общ
1
3
5
0
3
0
МВт
общ
1
5
1
Проблемы с проектированием крупного ЦОДа могут начаться в момент составления технического задания. Зачастую в его разработке участвуют все мыслимые и немыслимые подразделения заказчика: служба эксплуатации самого заказчика, служба эксплуатации здания (если оно в аренде), технический директор заказчика, сотрудники генерального подрядчика и проектировщика, ИТ-служба заказчика и многие другие нужные и ненужные для формирования требований к ЦОДу службы.
Отсутствие координации между участниками процесса может привести к появлению технических решений с избыточной надежностью или лишней функциональностью, что в процессе строительства выльется в рост капитальных вложений либо, что существенно хуже, к усложнению эксплуатации объекта.
Пример: при строительстве ЦОДа строительное подразделение заказчика заложило в техническое задание собственное видение защиты здания от протечек воды, а инженерные службы потребовали создать саркофаг из сэндвич-панелей. В результате заказчик получил тройной эффект: саркофаг из сэндвича, дополнительную защитную кровлю из профлиста и свежую отремонтированную кровлю здания. Зачем?
Еще один неприятный случай: служба эксплуатации ЦОДа внесла в техническое задание требования к системе кондиционирования внутренних плат для мониторинга системы, ИТ-служба захотела видеть в проекте выносные дисплеи, технический директор прописал свое видение диспетчерского управления, а отдел закупки сошел от всего этого с ума и не проверил скрупулезно предложения от поставщика, имевшего, естественно, собственное представление о необходимых опциях. В итоге заказчик получил задублированную систему с потрясающе излишним функционалом и загроможденную экранами комнату диспетчерской службы.
Во избежание подобных проблем разработку технического задания необходимо проводить консолидированно, с перекрестной проверкой каждого раздела всеми заинтересованными службами, и имея единого технического специалиста, отвечающего за выпуск финального документа, – архитектора решения. Важно также до начала составления технического задания четко разграничить зоны компетенции всех подразделений – авторов документа.
Старый конь борозды не испортит
Немаловажную роль в успехе всего проекта играет уровень стандартности решений, описываемых в техническом задании. Стремление к нетрадиционным решениям характерно для строительства крупных объектов – кому придет в голову использовать уникальные или редкие инженерные приемы в серверных или небольших ЦОДах.
При строительстве масштабного дата-центра появляется простор для творчества (пропорциональный, кстати, «простору» бюджета), и заказчики готовы на эксперименты ради возможной экономии или энергоэффективности. Но тяга к экспериментам может вылиться в необходимость проведения НИОКР для расчета ряда систем, чаще всего систем холодоснабжения.
Случается, что, казалось бы, логичное, но крайне индивидуальное техническое решение (например, создание камеры смешения воздуха в имеющихся строительных конструкциях с непростой геометрией помещений) может оказаться непосильной задачей для проектных организаций и даже для солидных проектных институтов. И дело даже не в невозможности справиться с задачей, а в ее новизне и нежелании подрядчика взять на себя ответственность за результаты расчета. А нет ответственного – нет приемлемого результата. Поэтому при выборе технических решений требуется взвешенно подходить к поиску компромисса между их новизной и традиционными, проверенными годами подходами.
Коллизии в нормативно-технической базе
При проектировании инженерных систем ЦОДа необходимо обратить особое внимание на коллизии, возникающие при применении международных и российских нормативных актов в рамках одного технического задания. Например, в одном из нормативов может быть прописан достаточно широкий диапазон применения тех или иных технических решений: использование медных или стальных шин заземления либо требования к сечению заземляющего проводника. В то же время другой норматив может быть существенно жестче в отношении данного требования. И если в случае небольшого объекта такие коллизии не сыграют решающей роли в проектировании (в конечном счете определяющими будут российские нормативные акты), то при создании крупного ЦОДа, когда для сертификации объекта может быть привлечена сторонняя международная организация, возможно, придется заменить некоторые технические решения в пользу международных нормативов.
Учитывая риск подобной ситуации, следует более внимательно относиться к списку нормативов, на базе требований которых будет проводиться проектирование, а также обязать проектную организацию принимать во внимание требования всех нормативных актов, упомянутых в техническом задании, – естественно, международных тоже.
Согласование исходных данных: семь раз отмерь
И наконец хотелось бы остановиться на важности получения согласованных заказчиком и всеми заинтересованными сторонами исходных данных для проектирования (к примеру, системы энергоснабжения), в том числе технических условий на подключение, планировочных решений, смежных систем, требующих электроснабжения от проектируемой энергоустановки, перечень согласованных вендоров оборудования.
Если в проекте дата-центра на 100 стоек изменение одного из упомянутых документов с исходными данными вероятнее всего будет означать обозримый объем изменений в документации, то переработка лишь одного раздела проекта крупного ЦОДа (например, в результате увеличения мощности энергопотребителей или изменения планировки) может стать катастрофой для проекта, приводя к нелинейным сдвигам сроков сдачи документации и лавинообразному росту технических ошибок.
Именно поэтому и заказчик, и генеральный подрядчик должны осознавать всю важность исходных данных и всеми силами стараться исключить такие понятия, как «предварительные технические условия», «аналогичный производитель», «промежуточные планировочные решения» и т. д. Четкость, точность, определенность – только так.
Проектирование
Так ли важна организация проектной деятельности?
Экономный генеральный проектировщик, который не удосужился выделить ресурсы на роль главного инженера проекта, либо совместил функции ГИПа, руководителя проекта, секретаря проекта и делопроизводителя («он же все это умеет и сделает все сам?»), либо недостаточно детально описал в уставе проекта процесс взаимодействия между субподрядчиками в договоре, рискует тем, что между смежниками не будет должного информационного взаимодействия, зато будет перманентная конфликтная ситуация.Второй и не менее важный аспект успешного создания проектной документации – правильная организация самого процесса проектирования. Часто то, что не вызывает особых трудностей при проектировании небольших объектов, например взаимодействие в команде и с подрядными организациями, может вылиться в огромные проблемы для большого проекта.
Пример из реальной жизни: нарушение процесса составления и выдачи заданий для смежной подрядной организации. Исходными данными для инженера-энергетика всегда являются данные о потреблении оборудования систем кондиционирования, безопасности, слаботочных систем и пр. В нашей практике случалось, что ГИП генерального проектировщика самоустранялся из процесса обмена информацией между подрядчиками, а остальные смежники просто-напросто отказывались выдавать частные технические задания для энергетика в оговоренной заранее табличной форме: ссылаясь на занятость, они заявляли: «Читайте проекты – в них все есть!». Естественно, это существенно осложнило жизнь проектировщику, который потратил много времени на сбор необходимой информации.
Где вы, системы 3D-проектирования?
Еще один нюанс, с которым мы сталкиваемся при проектировании больших дата-центров, это неготовность российских проектных организаций работать в 3D-системах САПР. В последние годы все более очевидно, что в проектах таких сложных и насыщенных коммуникациями объектов, как ЦОДы, просто необходимо применять технологии и средства 3D-проектирования во избежание пересечения трасс многочисленных инженерных систем и дополнительных затрат на устранение этих коллизий в процессе строительства.
Если невозможно выполнить весь проектный объем своими силами, генеральный проектировщик просто вынужден привлекать на какие-то части работ субподрядные организации. Но, к сожалению, пока немногие компании во всех нюансах освоили 3D-технологии проектирования. Мы сталкивались с ситуациями, когда организации приходилось проектировать в 2D-системах САПР, а потом привлекать внешние ресурсы для перевода рабочей документации в 3D-модель.
Только представьте себе эту потрясающую процедуру с бесчисленным количеством итераций по поиску коллизий, исправления 3D-модели, перевода ее в 2D-чертежи и т. д. И, к сожалению, на этапе планирования проектирования никто не закладывает дополнительное время на данные манипуляции.
Изменениями надо управлять – или изменения убьют тебя
Еще одна давно известная, но от этого не теряющая актуальности рекомендация при выполнении больших проектов – внедрить процесс управления изменениями проектной документации. Трудно даже представить, сколько раз мы обнаруживали, что уже месяц проектируем инженерные системы «на старой планировке», которую нам выдают конструкторы и архитекторы. Ситуация еще более усугубляется при использовании внешних подрядчиков и фрилансеров (как правило, все они предпочитают работать удаленно).
Избежать таких проблем можно, применяя парадигму единого рабочего пространства, созданного на основе современных облачных технологий, в том числе предоставляемых производителями программного обеспечения САПР, а также внедрив правила коллективной работы. Даже ручное управление изменениями и общий ресурс для обмена файлами не дадут нужного эффекта в момент максимального накала страстей, когда по прошествии 70% срока проектирования обновленные чертежи лавиной польются от участников проекта. Кто может выстоять против лавины? Так или иначе участники проекта станут уходить от изначальной структуры организации информации, и неизбежно начнут появляться ошибки.
Кроме того, часто в силу отсутствия опыта у проектной организации не учитываются риски сдвига сроков проекта и вынужденных изменений технических решений. Эта «детская болезнь» приводит к увеличению запланированных бюджетов.
Мал золотник да дорог
Ничто не должно ускользать от внимания проектировщика. Хороший пример – такие разделы проектной документации, как «Охрана окружающей среды» и «Мероприятия по обеспечению пожарной безопасности», которые на небольших объектах выполняются нечасто. Случается, что для их выполнения требуется установить шумопоглощающие экраны, которые защитят близлежащие жилые постройки от шума внешних блоков системы кондиционирования или дизель-генераторных установок. Кроме того, могут потребоваться дополнительные глушители на ДГУ или ДИБП. Или же вследствие превышения предельно допустимой концентрации (ПДК) загрязняющих веществ от ДГУ встанет вопрос об установке дорогостоящих катализаторов. Масса вопросов может возникнуть с местами установки и пожарной безопасностью топливохранилищ, а также площадками топливозаправщиков. А это снова затраты на изменение проекта, сдвиги сроков, бюджета строительства.
Внешняя среда: агрессивная или стимулирующая?
Кроме внутренних трудностей процесса проектирования, существуют и внешние негативные факторы, которые могут повлиять на сроки, качество и бюджет проекта.
Возьмемся за руки
Решающим среди них является отсутствие координации с заказчиком и четкой регламентированной процедуры сдачи работ. К примеру, заказчик, в силу недостатков внутреннего взаимодействия и разветвленной организационной структуры, может с запозданием привлечь некоторые подразделения к обсуждению проектных решений. За проект может отвечать условный технический департамент, а подразделения безопасности и эксплуатации фактически подключатся лишь на поздних этапах разработки. И, естественно, у них может быть свое видение технических решений, что повлечет за собой лавину новых замечаний, не исключено, что даже противоречащих согласованному техническому заданию. А все это приведет к дополнительным, не всегда оплачиваемым, работам и к очередному сдвигу сроков сдачи проекта.
Кроме привлечения всех заинтересованных лиц к обсуждению проектных решений, заказчику, согласно теории управления проектами, следует назначить куратора (спонсора) проекта, который бы придавал дополнительную мотивацию тем подразделениям, которые не выдерживают регламенты согласования проектных решений. Эта проблема может показаться очевидной, но она не так очевидно решается: к примеру, мы столкнулись с этим на реальном проекте в виде вечно занятого главного инженера холодильного оборудования службы эксплуатации заказчика, от которого можно было неделями ждать замечаний по очередной версии проекта.
Выбор – это конкурс или?
В больших проектах ЦОДов на этапе проработки вариантов технических решений заказчику, в силу наличия внутренних процедур, может потребоваться провести конкурсы по выбору производителя оборудования для проектируемых систем ЦОДа, чтобы в дальнейшем использовать в проекте параметры конкретных марок и моделей оборудования.
Безусловно, эта процедура имеет место быть в практике строительства дата-центров, но ее следует детально регламентировать еще на этапе подписания подрядного договора, указав четкие сроки проведения тендерных процедур на стороне заказчика, и/или добавить в план-график проекта конкретные вехи, от дат которых будет рассчитываться срок завершения работ подрядчика и всего проекта.
Все органы нужны, все органы важны
Кроме внутренних большие проекты гораздо чаще требуют и внешних согласований, например, в Ростехнадзоре. Если у проектной организации или заказчика отсутствует опыт подобных согласований, мы рекомендуем не ориентироваться на официальные сроки этой процедуры, описанные в нормативах ведомств, – они почти всегда разительно отличаются от действительности. Лучше воспользоваться рекомендациями коллег, имеющих личный опыт прохождения этой процедуры, и тогда шансы уложиться в срок существенно возрастут. Эта рекомендация относится отнюдь не только к строительству дата-центров.
Если проект предполагается сертифицировать в международных экспертных организациях и при этом заказчику очевидна необходимость прохождения государственной экспертизы, мы бы рекомендовали в первую очередь запустить и провести процедуру международной сертификации и лишь после этого идти в российскую экспертизу. Ни в коем случае не наоборот и не параллельно. Требования международных сертифицирующих компаний могут затронуть всю архитектуру дата-центра, и изменения в проекте будут означать для государственной экспертизы фактически выпуск нового проекта, требующего повторного согласования. В то же время замечания госэкспертизы при выполнении проекта согласно требованиям российских нормативов с большей долей вероятности будут менее критичны для международных сертифицирующих организаций.
Бумага все стерпит? Да, но деньги вперед
При согласовании договоров с заказчиком не стоит забывать четко указывать количество экземпляров и объем проектной документации, предоставляемой подрядчиком в бумажной форме. Не менее полезно зафиксировать в договоре стоимость печати дополнительных экземпляров документации. У заказчика периодически возникают просьбы (требования) распечатать еще один-два экземпляра сверх согласованных в договоре (потому что службе безопасности и эксплуатации «неудобно проверять с экрана»). Человек, впервые столкнувшийся с созданием проектной документации крупного объекта, может быть неприятно удивлен тем, что печать документации – уже не такая незаметная в финансовом и ресурсном отношении процедура, как на небольших объектах, и затраты на реализацию капризов заказчика могут исчисляться сотнями тысяч рублей. Кроме того, эти расходы имеет смысл в явном виде включить в себестоимость проекта, предварительно запросив стоимость печати и прошивки документации в типографии.
Вам шашечки или ехать?
В своей работе мы периодически сталкиваемся с нарушением принципов разумной логики в приоритетах функциональности и дизайна объекта. Важно понимать, что архитектурные и ландшафтные изыски должны идти следом за основной функцией ЦОДа: он должен в первую очередь быть надежным, удобным и работоспособным, а уже во вторую – быть оформленным в стиле art deco. Поэтому проектирование следует вести в той парадигме, что ЦОД в первую очередь – технический объект, и сначала надо уделять внимание компоновке инженерных систем, а потом вписывать «зеленые насаждения» в ландшафтный дизайн и красить стены в оранжевый цвет.
О нежелательных строительных последствиях
Мы не будем здесь долго и нудно излагать, к чему могут привести технические ошибки в проектной документации, – это вещи достаточно очевидные. Но ряд «допущений» в проектной документации крупного ЦОДа могут повлечь за собой существенное увеличение затрат на строительство и сроков реализации проекта. Причем на небольших объектах такие «допущения» гораздо меньше влияют на параметры проекта.
нужно еще и организовать
В первую очередь хотелось бы обратить внимание на важность разделов «Проект организации строительства» (ПОС) и «Проект производства работ» (ППР) для создания масштабного дата-центра. Любой строитель, который реализовывал большие строительные объекты, понимает, что эти разделы не менее важны для успеха, чем любой из строительных или инженерных разделов в проектной документации.
К сожалению, выполнение раздела ПОС часто сводится к созданию формального документа, основанного на имеющихся старых шаблонах, который никак не может облегчить жизнь строителям. А между тем отсутствие в ПОС, например, проработанной логистики складирования может повлечь за собой существенный рост расходов на доставку и такелажные работы, порчу оборудования и материалов из-за их бесконечной ротации по строительной площадке. Нужно помнить, что хотя ЦОД и является телекоммуникационным объектом, находящимся на стыке строительных знаний и ИТ, но в конечном счете это просто большая «стройка», со всеми вытекающими требованиями.
Расчеты и еще раз расчеты
Приведем пример «допущения», которое делают инженеры-электрики при проектировании небольших объектов: это замена комплексных расчетов переходных режимов в электрических сетях собственным опытом. Изо дня в день инженеры выполняют проекты небольших объектов и привыкли использовать эмпирические знания о типовых технических решениях, рассчитанных когда-то давно: сечения кабеля, номиналы и селективность автоматов могут подбираться «на глазок», исходя из предыдущей практики. На больших объектах этот фокус уже не пройдет, и такая методология проектирования может иметь опасные последствия при эксплуатации энергоустановки. Важно требовать от проектантов обязательного наличия в проектной документации детальных расчетов параметров энергоустановки и описание методики подбора всех ее компонентов. Впрочем, расчеты нужны для всех систем ЦОДа. Это тоже важно помнить.
* * *
Все описанное нами – лишь небольшая часть проблем, с которыми может столкнуться в процессе проектирования генеральный проектировщик и заказчик, впервые приступающий к реализации крупного дата-центра. Мы надеемся, что наши рекомендации покажут читателям, где стоят те «грабли», на которые нам и нашим коллегам довелось наступать в ходе реализации проектов.
Источник: журнал ИКС, №3-4 от 25 апреля 2017 года
DataFloor