Rambler's Top100
Статьи ИКС № 08-09 2013
Андрей ПАВЛОВ  Дмитрий БАСИСТЫЙ  Дмитрий КУСАКИН  03 сентября 2013

Управление проектом создания ЦОДа. Как сложить мозаику стандартов? Часть 1

На всех этапах проектирования и строительства дата-центра приходится руководствоваться стандартами и нормативами из разных областей.

Все ли вопросы закрывают существующие нормативные документы? Насколько они отражают специфику процесса создания ЦОДов?

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

Однако время от времени в ходе проекта возникают трения и недопонимание между основными сторонами процесса – заказчиком и исполнителем.

Как правило, причина трений – различное трактование нормативно-документального багажа, сопровождающего такой проект. Каждый раз, когда заказчику хочется индивидуального подхода, приходится заново решать (и обосновывать), что надо делать, кому, зачем и на основании чего. В этот момент и начинается поиск в дебрях нормативной документации подходящего к случаю стандарта или регламента, подтверждающего или опровергающего чей-то взгляд на ход проекта.

На различных этапах процесса создания ЦОДа применяются стандарты, нормативы и правила из множества областей: проектного управления, строительства, внедрения систем автоматизации и др. Они касаются не только технических решений, подготовка и реализация которых – суть процесса создания ЦОДа, но и схем взаимодействия, принятия решений, состава и детализации проектных документов.

Вопросы практики управления проектом мы рассматривали неоднократно, под разными углами (см., например, материалы Д. Кусакина, Д. Басистого и А. Павлова "Управление проектом создания ЦОДа: из российской практики" и "Бизнес-план и финансовая оценка создания ЦОДа высокого уровня надежности"). Сегодня очевидно, что пришло время национального стандарта, регламентирующего реализацию проектов создания корпоративных ЦОДов, определяющего участников проекта и их роли, этапы, процессы и документы, которые можно рекомендовать для достижения оптимального результата. В этой статье мы попытаемся проанализировать существующую нормативную документацию и стандарты, на которых базируется процесс создания ЦОДа, выявить их недостатки и ограничения, а также обсудим возможность консолидировать их в единый проектный стандарт.

Еще раз о проектном управлении

Необходимо признать, что процесс создания ЦОДа в каждом случае уникален. Нельзя написать четкую универсальную подробную инструкцию, следуя которой мы достигнем оптимального результата – с наилучшим качеством, минимальным бюджетом и желаемыми сроками. Эту работу каждый раз приходится проделывать заново, с учетом индивидуальных условий, особенностей и требований. Тем самым каждое такое предприятие определяется как проект, и мы, в лучшем случае, применяем к нему весь набор стандартов и методов управления. Безусловно, стандарты – это идеалы, к которым надо стремиться и которые, мягко говоря, не директивны, а имеют рекомендательный характер.

Область же нормативов и правил – это законы, обсуждать которые бессмысленно и противоправно, их просто надо соблюдать.

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

Традиционная схема процесса

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

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

Традиционно в процессе строительства ЦОДа выделяют следующие этапы.

  • Предпроектная подготовка – этап включает формирование бизнес-потребности, т.е. требований к будущему ЦОДу; подготовку техникоэкономического обоснования или бизнес-плана; предпроектное обследование и составление технического задания.
  • Разработка технических решений – важнейший этап формирования облика нового объекта, его технических и экономических характеристик, требований к организации и формированию службы эксплуатации, операционной устойчивости объекта.
  • Строительные работы – основной этап проекта создания ЦОДа, оказывающий большое влияние на дальнейшую судьбу объекта.
  • Испытания и ввод в эксплуатацию – наиважнейший этап проекта, который должен проводиться совместно с генеральным проектировщиком, генеральным подрядчиком, службой эксплуатации заказчика и представителями поставщиков оборудования.

Проблемы управления на этих этапах мы и рассмотрим более детально.

Предпроектная подготовка

Задачи этапа. Основная цель предпроектных работ – сбор и обработка сведений об организации и особенностях функционирования будущего объекта, включая данные о его взаимодействии с внешней средой и другими объектами.

Нормативы, стандарты, практики. Основной вопрос – как рассматривать ЦОД на данном этапе: как объект строительства (и использовать стандартные подходы строительной отрасли) либо как комплексный объект, для которого больше подходят стандарты создания автоматизированных систем (серия ГОСТ 341).

Вопросы формирования общих требований к будущему ЦОДу лежат вне нормативного поля строительной отрасли – требования к ЦОДу как к объекту ИТинфраструктуры не являются частью процессов разработки проектных решений. Не так давно, с отменой СНиП 11-01-952, перестало быть обязательным требование подготовки и согласования технико-экономического обоснования. Безусловно, теперь подготовка такого документа – забота самого заказчика. Но отсутствие стандартов и нормативов на состав и содержание ТЭО допускает множественность подходов к этой задаче, и, к сожалению, не всегда плюрализм в этом вопросе идет на пользу конечной цели – построению надежного ЦОДа.

С техническим заданием на создание ЦОДа дела, как нам представляется, обстоят ровно таким же образом: прямых норм для разработки документа с требованиями к комплексу систем дата-центра не существует. Строительная практика предполагает разработку заданий на проектирование, но это совсем не то, что полноценное и детальное техническое задание на такой сложный объект, как ЦОД. Кроме того, задание на проектирование не позволяет сформировать комплекс требований ко всем этапам создания ЦОДа: проектированию, строительству, приемке, вводу в эксплуатацию.

Стандарты, применяемые при создании автоматизированных систем (например, ГОСТ 34.601-90 и другие документы этой серии), как нам видится, позволяют более правильно подойти к процессу создания ЦОДа, корректнее выстроить цепочку стадий этого процесса, с большей детализацией сформулировать требования к проектным документам и приемосдаточным испытаниям.

Стоит также отметить, что «предпроектное обследование», упомянутое в контексте данной стадии, как правило, состоит из двух потоков работ: а) обследования площадки и/или здания для размещения ЦОДа (инженерные изыскания) и б) исследования ИТ потребностей заказчика (формирование исходных требований к ЦОДу как к объекту ИТ-инфраструктуры).

Результаты обоих потоков должны попасть в техническое задание на создание дата-центра: в требования к строительной и инженерной части и требования со стороны ИТ-систем к отдельным параметрам ЦОДа и его комплексным параметрам.

Отдельного упоминания заслуживает недавно принятый стандарт ГОСТ Р 54869-2011 Проектный менеджмент. Требования к управлению проектом. Он устанавливает требования к управлению проектом от его старта до завершения, при этом предметом стандартизации являются только обязательные выходы (результаты) процессов управления проектом. Стандарт, как ему и положено, не содержит требований, которые могут считаться обязательными лишь для определенного вида проектов, требований к методам реализации процессов управления проектами, а также требований к предпроектной и послепроектной деятельности. Но его использование в процессе создания дата-центров представляется нам весьма полезным.

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

Проектные работы. Технические решения

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

Роли и участники. В проектных работах есть две главные стороны: заказчик и генеральный проектировщик. Традиционная за рубежом схема привлечения к проектным работам внешних консультантов (процессных или технологических) в российской практике пока встречается не часто. Современная нормативная база строительных работ не содержит упоминания такой роли, как консультант: заказчик есть, проектировщик есть, контролирующие органы есть, а консультанта нет.

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

Нормативы, стандарты, практики. Основными результатами этого этапа являются два комплекта документации – проектной и рабочей. Поскольку создание ЦОДа – это в первую очередь строительство, то принято считать, что состав проектной документации регулируется известным постановлением правительства РФ № 873. А требования к оформлению чертежей, схем и текстовых документов прописаны в ГОСТ 21.1101-20094, который, в свою очередь, ссылается на целый ряд документов по проектированию и оформлению строительных чертежей и конструкторских документов.

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

С нашей точки зрения, эта схема не совсем адекватна уровню сложности и ответственности таких объектов, как ЦОДы. Рассмотрение, сопоставление, анализ, выбор и обоснование решений для ряда ключевых инженерных систем дата-центра в высшей степени вредно переносить на этап подготовки проектной документации. Хорошим тоном при создании ЦОДа является дополнительный проектный этап – разработка эскизного проекта или концепции. Но повсеместному внедрению этого опыта отчасти препятствует отсутствие четких норм на подготовку эскизных проектов или концепций ЦОДа – в первую очередь на комплекс инженерных систем.

Надо отметить, что практика эскизного проектирования и разработки концепций присутствует в стандарте на разработку автоматизированных систем. На этот счет в серии ГОСТ 34 есть вполне детальные и понятные стандарты и документы, например, ГОСТ 34.201-89 и РД 50-34.698-905. На каком этапе проводить эскизное проектирование или разрабатывать концепцию – вопрос дискуссионный, ответ на него в значительной степени может зависеть от планирования процесса создания ЦОДа. По нашему мнению, концептуальное, эскизное проектирование вполне может быть отнесено к предпроектной стадии и выполнено вне зоны ответственности проектной организации, например, организациями-консультантами, которые ведут подготовку проектного этапа работ.

Экспертиза проектных решений. Согласно существующему порядку, проектная документация на объекты нового строительства проходит государственную строительную экспертизу. Исчерпывающая информация о порядке реализации этой процедуры изложена в Градостроительном кодексе Российской Федерации6 (ст. 49). Но всем известно, что главная задача госэкспертизы – вынести заключение о соответствии проектных решений нормам безопасности в строительстве; на инженерные же системы, а тем более системы вспомогательные (связь, безопасность, управление и другие) госэкспертиза смотрит как на «черные ящики» или «бантики»: есть они, ну и ладно.

Безусловно, заказчик волен заказать специальную экспертизу всего проекта либо его части у любой организации, компетенция и репутация которой ему покажутся достаточными для независимого и ответственного заключения. Но необходимо отметить, что российских нормативов или стандартов для проведения такого рода экспертизы не существует: каждый консультант, выступающий в роли эксперта-рецензента, разрабатывает и использует свою собственную методику и систему оценки. Существование зарубежных экспертных организаций (BICSI, Data Centre Alliance, Uptime Institute и других) не сильно влияет на ситуацию на российском рынке независимых экспертиз.

Согласование проектной документации. Такая простая, казалось бы, задача, как согласование заказчиком проектной документации, может вылиться в огромную проблему. Ни в одной из систем действующих российских нормативов (ЕСКД, СПДС, ГОСТ 34 и других) этому вопросу не уделено достаточно внимания. Считается, что согласование – это процедурный вопрос, и решать его должны сообща заказчик и исполнитель. Но нельзя не отметить, что отсутствие стандартов и лучших практик в этом вопросе ведет к перекосам и злоупотреблениям своим положением со стороны как заказчика, так и проектной организации.

Состав и содержание документации. Конечно, состав и содержание документов никак нельзя считать неотъемлемой частью проектного управления при создании ЦОДа. Но тем не менее нельзя не признать, что определенные пробелы в нормативной базе могут приводить (и приводят!) к возникновению конфликтных ситуаций, снижению качества проектных решений и в результате отражаются на надежности функционирования ЦОДа. Кроме того, вопрос качества работ – обязательная часть управления процессом создания ЦОДа.

В настоящий момент главным документом, определяющим состав проектной документации, считается постановление правительства РФ №87: как правило, именно на него ссылаются в заданиях на проектирование. Но при этом зачастую игнорируются (нередко – намеренно) задачи разработки документации по другим, вспомогательным, но не становящимся от этого второстепенными системам – тем, которые постановление №87 относит к разделу «Сети связи». Необязательность этого раздела и договорные условия его проработки (как об этом говорит Градостроительный кодекс) никоим образом не служат повышению уровня надежности ЦОДа.

В связи с этим нам видится – и проверено на опыте, – что стоит формировать требования к составу и содержанию документации в техническом задании на создание ЦОДа, заменяющем (расширяющем) традиционное, несколько ограниченное по форме и составу задание на проектирование. Поэтому так важны выводы, которые были сделаны выше, при рассмотрении проблемы предпроектной подготовки.

Что в итоге? ЦОД – это сложный объект, состоящий из десятков узлов, решений, компонентов, многие из которых должны проектироваться на базе требований нормативных документов разных систем – ЕСКД, СПДС, ГОСТ 34 и других. Попытки вести проектирование (разрабатывать проектную документацию) только на базе строительных нормативов – путь в никуда.

Экспертиза решений для инженерных систем и систем связи находится вне сферы регулирования действующей российской нормативной базы. Стандарты же и методики зарубежных организаций и использование их услуг для экспертизы – дорогое и не всегда уместное удовольствие.

О задачах, ролях и стандартах на этапах строительства и ввода в эксплуатацию – и о том, что со всем этим делать, читайте в следующем номере «ИКС».

__________________________________

1ГОСТ 34 Информационная технология. Комплекс стандартов на автоматизированные системы. В серию входят: ГОСТ 34.601-90 Автоматизированные системы. Стадии создания; ГОСТ 34.201-89 Виды, комплектность и обозначение документов при создании автоматизированных систем; ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы; ГОСТ 34.603-92 Виды испытаний автоматизированных систем.

2СНиП 11-01-95 Инструкция о порядке разработки, согласования, утверждения и составе проектной документации на строительство предприятий,

3Постановление Правительства Российской Федерации от 16 февраля 2008 г. № 87 «О составе разделов проектной документации и требованиях к их содержанию».

4ГОСТ Р 21.1101-2009 Система проектной документации для строительства. Основные требования к проектной и рабочей документации.

5ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем; РД 50-34.698-90 Автоматизированные системы. Требования к содержанию документов.

6Федеральный закон от 29 декабря 2004 г. № 190-ФЗ «Градостроительный кодекс Российской Федерации».

Поделиться:
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!