На всех этапах проектирования и строительства дата-центра приходится руководствоваться стандартами и нормативами из разных областей. Нужно ли консолидировать разрозненные требования и рекомендации в серию национальных стандартов для ЦОДов? Что даст реализация этой идеи заказчикам, исполнителям проекта и владельцам?
Проектные работы. Решения для эксплуатации
Состав решений. Применительно к созданию ЦОДов мы в первую очередь имеем в виду эксплуатационную документацию: документы, которые определяют правила эксплуатации оборудования и систем и отражают сведения, удостоверяющие гарантированные значения основных параметров и характеристик, гарантии и сведения об эксплуатации оборудования в течение установленного срока службы.
Вместе с тем не стоит забывать о второй стороне процесса эксплуатации – организационной. Она рассматривается в документах, описывающих взаимодействие персонала службы эксплуатации и сервисных подрядчиков в ходе сопровождения, ремонта оборудования и ликвидации аварий. Эти процессы и процедуры должны быть описаны при разработке операционной модели эксплуатации ЦОДа – комплект процессной документации станет результатом ее разработки.
К сожалению, в обиходе отечественных создателей ЦОДов термин «операционная модель» пока не прижился. Однако нельзя утверждать, что в существующих подходах к эксплуатации ЦОДов нет никаких элементов операционных моделей. Отдельные такие элементы (процессы, технологии, документация и т.д.), как правило, создаются руками самих служб эксплуатации – в условиях работы ЦОДа в «боевом режиме».
Задачи этапа. Основная задача – разработать документальную базу будущей эксплуатации как совокупности работ по поддержанию заданных параметров функционирования оборудования и систем. Если рассматривать данный этап как два направления – подготовку эксплуатационной документации и разработку операционной модели эксплуатации, – то становится очевидным, что работы в этих направлениях должны проводиться последовательно. В первую очередь проектировщик и/или генподрядчик разрабатывает эксплуатационную документацию, а затем, пусть и с некоторым временным наложением (опережением), запускается процесс разработки и внедрения операционной модели.
Роли и участники. С точки зрения описанных выше задач уместно говорить о следующих проектных ролях: исполнитель – разработчик эксплуатационной документации (генпроектировщик и/или генподрядчик), заказчик (в лице службы эксплуатации) и подрядчик – разработчик операционной модели (эту роль может, вне всяких сомнений, сыграть и генподрядчик, и консультант).
Первый из них, исполнитель эксплуатационной документации, несет ответственность за проектные решения и, как следствие, ответственность за инструкции и руководства по эксплуатации оборудования и систем, вошедших в проект ЦОДа. Никто, надеемся, не будет спорить с тем, что инструкции и руководства не разрабатываются заказчиком? Если заказчик не знает об этом, не заказывает или не хочет платить за эту документацию, такую ситуацию сложно признать «хорошей практикой», не то что «лучшей».
Второй, заказчик в лице службы эксплуатации, на данном этапе выполняет функции согласования документации (на предмет ее полноты и качества), отвечает за подготовку персонала к приемке ЦОДа в эксплуатацию.
Третий, подрядчик по разработке операционной модели эксплуатации ЦОДа, отвечает за разработку и последующее внедрение операционной модели эксплуатации как абстрактного описания того, каким образом служба эксплуатации должна осуществлять свою деятельность, включая реализуемые процессы эксплуатации, с учетом используемых ресурсов и технологий (см. например, З. Алехин. «Операционная устойчивость ЦОДа: увлечение или реальная потребность?» «ИКС» № 1-2’2013).
Но описанная выше ролевая модель – это идеал, очень далекий от существующих реалий подготовки эксплуатационных решений для ЦОДов.
Нормативы, стандарты и практики. Упомянутая выше неидеальная практика определяется в первую очередь действующей нормативно-технической документацией, которая в массе своей неполна, противоречива, многозначна и, что самое прискорбное, не вполне пригодна для таких сложных, комплексных объектов, как дата-центры.
Если подходить к документации на ЦОД с точки зрения строительных норм и правил, то легко обнаружить отсутствие в них самого понятия «эксплуатационная документация». Более-менее четко границы понятия «исполнительная документация» (это, естественно, не то же самое, что «эксплуатационная документация») задаются в СНиП 12-01-2004 и СНиП 3.01.04-87, а вот стандартов по эксплуатационной документации в коллекции действующих строительных норм и правил не найти. Даже ПТЭЭП не дают ответа на вопрос о правильном содержании таких документов.
Предпринимаемые инициативными заказчиками единичные робкие попытки привлечь нормы Единой системы конструкторской документации к разработке эксплуатационной документации на инженерные системы ЦОДов, как правило, заканчиваются поражением инициаторов. Причина неудач, на наш взгляд, в том, что прямые ссылки на ГОСТ 2.601-2006 как на стандарт, определяющий состав эксплуатационной документации, достаточно бессмысленны: стандарт устанавливает обязательность выпуска только узкого круга малопригодных для нужд эксплуатации ЦОДа документов – паспорта или формуляра и… ведомости. Для остальных же необходимых службе эксплуатации документов – руководств, инструкций, норм расхода запчастей и материалов – этот стандарт оставляет за разработчиком (проектировщиком) право принимать решение о необходимости подготовки того или иного документа.
Примерно аналогичная ситуация складывается и с попытками привлечь нормативную базу из области информационных технологий – стандартов на создание автоматизированных систем (серия ГОСТ 34). Очевидно, что часть инженерных систем ЦОДов, относимых в проектной документации к разделу «Системы связи», могут и должны разрабатываться с учетом требований к автоматизированным системам, т. е. к ним должны применяться стандарты из ГОСТ 34 (например, ГОСТ 34.601-90 и 34.201-89) и связанные с ними методические указания с требованиями к содержанию документов. Вместе с тем традиционное отношение к ЦОДу прежде всего как к объекту строительства приводит к тому, что базой для подготовки документации становится Постановление правительства №87 «О составе разделов проектной документации...» со всеми вытекающими отсюда последствиями: положения стандартов серии ГОСТ 34 не используются, эксплуатационная документация либо вовсе не выпускается, либо вопрос формально закрывается предоставлением инструкций по работе с оборудованием из комплекта поставки производителя.
Таким образом, в действующей нормативной базе можно обнаружить – и использовать на практике – какие-то зачатки нормативов по эксплуатационной документации на инженерные системы ЦОДов, чего совершенно нельзя сказать о стандартах и нормативах на операционную модель эксплуатации дата-центра.
Операционная модель эксплуатации. ЦОД – это в первую очередь сложный комплекс инженерно-технических систем, тесно связанных между собой и нуждающихся в надежной эксплуатации. Одной эксплуатационной документации, устанавливающей правила сопровождения оборудования и систем, для этого недостаточно. Необходимы определенные, поставленные процессы управления и взаимодействия, адаптированные процессы обслуживания, квалифицированный персонал, адекватная организационная структура службы эксплуатации ЦОДа, а также технологии и инструменты. Все связанные с этим группы мероприятий составляют единое целое – операционную модель эксплуатации ЦОДа.
Очевидно, что за красивым термином «операционная модель» кроются известные элементы, реализуемые в рамках тех или иных стандартов сервисного обслуживания. Но если взглянуть на эту область со стороны стандартов и нормативных документов, нельзя не отметить их скудность и весьма относительную пригодность к решению комплексной задачи эксплуатации инженерных систем ЦОДа.
Обязанности и ответственность за эксплуатацию систем электроснабжения и систем микроклимата (по устоявшейся в цодостроении терминологии) определены в двух известных документах: Правилах технической эксплуатации электроустановок потребителей (ПТЭЭП) и Правилах технической эксплуатации тепловых энергоустановок (ПТЭТЭ). Кроме того, эти документы определяют правила приемки в эксплуатацию, требования к персоналу и их подготовке, общие требования к управлению, устанавливают общие правила контроля, управления и обслуживания оборудования.
На базе названных документов могут быть разработаны более подробные и детальные регламенты и инструкции, в том числе касающиеся взаимодействия персонала как внутри самой службы эксплуатации, так и с внешними сервисными организациями. Но, безусловно, положения этих двух сводов правил нуждаются в детализации и адаптации к условиям эксплуатации конкретного объекта, техническим решениям и оборудованию, которые использовались при создании ЦОДа. Эта задача полностью ложится на плечи заказчика и его службы эксплуатации.
Как правило, до ввода дата-центра в постоянную эксплуатацию персонал службы эксплуатации занят в пусконаладочных работах и приемке, у него нет времени на разработку регламентной документации. Поэтому общим правилом российской действительности является то, что регламентирование процессов эксплуатации – разработка операционной модели – либо выполняется силами собственного персонала ЦОДа в условиях уже работающего объекта (со всеми вытекающими из этого последствиями – сроками, качеством и глубиной проработки), либо откладывается «на потом».
В таких условиях очевидна роль подрядчика – разработчика операционной модели, о которой мы упоминали выше, когда говорили о ролях на этапе разработки решений для эксплуатации.
Подчеркнем еще раз, что нормативная база для операционной модели эксплуатации комплексов инженерных систем крайне скудна и нуждается в создании и адаптации к задачам эксплуатации ЦОДов.
Что в итоге? Абсолютной уверенности в непременной разработке эксплуатационной документации существующая нормативная база заказчику не дает. При использовании традиционного (и отчасти порочного) подхода к документации на ЦОД как на объект капитального строительства закономерно, что обязанность разработки эксплуатационной документации полностью игнорируется или исполняется формально, не выходя за рамки документов, предоставляемых производителем вместе с оборудованием.
В лексиконе отрасли цодостроения появился новый термин – «операционная модель эксплуатации ЦОДа», который, несмотря на определенное ощущение «хорошо забытого старого», требует легализации и отражения в новых нормативных документах, относящихся к строительству дата-центров.
Строительство
Задачи этапа. На этапе строительства проектные решения для всех частей и подсистем ЦОДа воплощаются в жизнь. Переоценить важность этого этапа невозможно: в отсутствие должного контроля и управления строительными процессами ошибки проектирования могут многократно увеличиться, а отклонения от проекта, снижение качества работ и нарушение их правильной последовательности могут оказать негативное влияние на надежность работы систем и в конечном счете на уровень надежности ЦОДа.
Безусловно, в проекте строительства должны быть предусмотрены механизмы регулярного контроля и мониторинга хода работ, проведение аудитов и проверок на объекте, механизмы финансового и административного воздействия.
Роли и участники. Главная роль на этом этапе отведена генеральному подрядчику. Согласно Градостроительному кодексу, организация генерального подрядчика проводит строительные, монтажные и пусконаладочные работы, отвечает за работу подрядчиков, ведет строительный контроль. Наряду с генподрядчиком на стадии строительства ЦОДа принято привлекать и другие стороны: проектную организацию, консультантов (технологических и процессных), службу заказчика.
Нормативы, стандарты и практики. Среди главных нормативов, определяющих организацию работ на этапе строительства, обязанности и права участников, можно выделить следующие: Градостроительный кодекс РФ, СНиП 12-01-2004 «Организация строительства», СП 11-110-99 «Авторский надзор за строительством зданий и сооружений».
Градостроительный кодекс РФ (ст. 53) устанавливает общие правила строительного контроля в процессе строительства и назначает ответственным за его осуществление лицо, осуществляющее строительство. Кроме того, Кодекс устанавливает обязанность проведения строительного контроля для застройщика (заказчика) либо его представителей – привлекаемых на договорной основе юридических или физических лиц.
Несмотря на то что данная норма законодательства позволяет реализовать на стадии строительства ЦОДа всевозможные аудиты и проверки с привлечением сторонних консультантов и экспертных организаций, на наш взгляд, эта сторона строительного контроля нуждается в некотором уточнении и детализации применительно к строительству ЦОДов. Например, если упомянутый свод правил СП 11-110-99 устанавливает рекомендации по организации и ведению авторского надзора на объектах строительства (цели надзора, порядок ведения журнала авторского надзора, права и обязанности участников надзора, основные формы отчетных документов), то для консультантов и экспертных организаций, представляющих интересы заказчика при строительстве, подобных норм и стандартов нет. Ставить же знак равенства между авторским и экспертным контролем неверно.
Конечно, заказчик, нанимающий консультантов, волен и обязан установить для них права, ответственность, место в общей ролевой модели проекта. Но зачастую такие организационные и правовые действия невозможны или затруднены юридической и договорной практикой. Если рассматривать консультантов и экспертные организации как неотъемлемую часть процесса создания ЦОДа, вероятно, было бы правильно отвести им в этом процессе определенную роль, поставить задачи, очертить круг ответственности. И это послужило бы во благо общему процессу.
Что в итоге? Из приведенного выше описания нормативов, применяемых при строительстве, видна определенная их недосказанность в части учета практики, принятой в строительстве сложных объектов, какими являются дата-центры. В первую очередь это касается вовлечения в процесс создания сложных решений для систем ЦОДов консультантов и экспертов, работающих на стороне заказчика.
Испытания и ввод в эксплуатацию
Задачи этапа. После выполнения генеральным подрядчиком строительно-монтажных работ обязательно следует этап пусконаладочных работ, которые включают в себя индивидуальные испытания всех инженерных систем ЦОДа, а также комплексное опробование оборудования. Необходимость данного шага обусловлена как здравым смыслом, так и рядом нормативных документов. Например, пункт 1.5 СНиП 3.01.04-87 призывает рабочие комиссии, назначаемые заказчиком, проверить соответствие объектов и смонтированного оборудования проектам, соответствие выполнения строительно-монтажных работ требованиям строительных норм и правил, результаты испытаний и комплексного опробования оборудования, подготовленность объектов к эксплуатации и выпуску продукции – и только после этого принять объекты в эксплуатацию.
Кроме того, упомянутые СНиП устанавливают, что результатом комплексного опробования оборудования на рабочих режимах по объектам должно быть оказание услуг, предусмотренных проектом, в объеме, соответствующем нормам освоения проектных мощностей в начальный период.
Кроме комплексного опробования оборудования должны проводиться испытания, ход и содержание которых определяются специальным проектным документом – программой и методикой испытаний (ПМИ).
Но, с другой стороны, возникает масса вопросов у представителей заказчиков и генеральных подрядчиков или проектировщиков: какой норматив применять? насколько правомерны все требования не строительных нормативов к строительному объекту, каким является ЦОД? И тут традиционно возникает ситуация, в которой важные детали испытаний инженерных систем упускаются из-за применения «зонтичного» строительного подхода: устанавливаем верховенство СНиП, забывая о функциональной сути ЦОДа, которую определяют не стены и перекрытия, а инженерные системы и автоматизированные системы (пусть и называемые «сетями связи»).
Роли и участники. Существенный момент при проведении приемочных испытаний ЦОДа – распределение ролей в этой процедуре и в создании программы будущих испытаний. В действующей нормативной документации это, например, подтверждается в СНиП 3.05.05-84, которые устанавливают, что «…комплексное опробование оборудования осуществляется эксплуатационным персоналом заказчика с участием инженерно-технических работников генерального подрядчика, проектных и субподрядных монтажных организаций, а при необходимости – и персонала предприятий – изготовителей оборудования».
Если заказчиком строительства ЦОДа выступает неискушенная в этой сфере организация, не обладающая достаточной компетенцией для качественной его приемки, может и должно появиться еще одно звено в цепочке заказчик – генеральный подрядчик. Это звено – технический заказчик (быть может, даже несколько заказчиков – по отдельным направлениям) или технический консультант. Помимо выполнения функции беспристрастной и независимой приемки объекта в его обязанности должна входить разработка программы и методики испытания на этапе проектных работ, совместно с генеральным проектировщиком. Эта практика стала фактически нормой в зарубежных проектах создания дата-центров, но пока не нашла должного распространения в российских условиях.
В отечественных нормативах также правомерно подмечено, что на этапе приемочных испытаний должна присутствовать уже сформированная служба эксплуатации ЦОДа, чего в российских реалиях зачастую не бывает.
Нормативы, стандарты и практики. Существует великое множество нормативной документации, регламентирующей порядок проведения индивидуальных испытаний и порой даже комплексных опробований той или иной инженерной системы ЦОДа. Это, например, Правила технической эксплуатации электроустановок потребителей, Правила технической эксплуатации тепловых установок потребителей, СНиП 3.05.05-84 «Технологическое оборудование и технологические трубопроводы», СНиП 3.05.01-85 «Внутренние санитарно-технические системы». Данные нормативы с той или иной степенью детализации описывают процедуры проведения испытаний конкретных систем и требования к ним. Но существенно, что ни в одном из перечисленных документов не регламентируется процедура создания программы комплексных испытаний строительного объекта целиком – комплекса инженерно-технических систем ЦОДа.
Что в итоге? Анализируя ситуацию с нормативной базой на этапе испытаний инженерных систем ЦОДа, можно сделать вывод, что этот аспект создания дата-центров регламентирован крайне слабо, а в имеющейся нормативной документации не отражены нюансы, возникающие при строительстве столь сложных инженерных объектов. Большинство нормативных документов устарело и не отражает новых технологических подходов в строительстве комплексных объектов. К сожалению, это проблема не столько ЦОДов, сколько российских регламентирующих документов в целом, и без ее решения будет довольно сложно повышать уровень строительства в нашей стране.
Что делать?
Для объектов капитального строительства, где заказчиком выступает либо подразделение, имеющее квалифицированных строительных экспертов, либо выполняющий его роль технический заказчик, а также где не столь велика степень автоматизации комплекса систем, описанная в статье не жестко организованная и связанная нормативно-методологическая картина, возможно, и приемлема.
Но при строительстве объекта с высокой степенью насыщенности техническими системами различных классов и типов, да еще учитывая, что заказчиком ЦОДа чаще всего выступает представитель ИТ-службы, слабо разбирающийся в тонкостях строительно-инженерных отношений, либо представитель чисто строительного департамента, не представляющий специфики инженерии ЦОДа, подобная ситуация может грозить тотальным непониманием между заказчиком и генеральным подрядчиком. А такого рода непонимание нередко приводит проект к краху.
Анализ – пусть даже не столь глубокий – ограничений и недостатков существующей нормативной базы для процесса создания ЦОДа позволяет сделать следующие выводы.
Перечисленные недостатки и ограничения могли бы быть устранены, если бы существовал российский национальный стандарт на процесс создания ЦОДов. Он должен быть аналогичен стандартам на строительство линейных объектов, в которых детально описана вся процедура проведения проектных и строительных работ, с детализированным перечнем этапов и способов реализации каждого этапа, описанием соответствующих каждому этапу документов, которые должны быть выпущены, основных участников процесса, их ролей и зоны ответственности. Было бы также полезно привнести в такой стандарт все лучшее и полезное из серии стандартов создания автоматизированных систем.
Авторы будут признательны коллегам по экспертному сообществу за обсуждение затронутой в статье проблематики и обмен мнениями. Мы ни в коей мере не претендуем на истину в последней инстанции – мы хотим инициировать дискуссию, в ходе которой экспертное сообщество могло бы понять: нужен ли ему российский национальный стандарт на процесс создания дата-центров.
Источник: журнал ИКС, №10 от 14 октября 2013 года
DataFloor