Быстро и сердито
Сделав правильный выбор, можно сэкономить полгода-год при подготовке проекта. Но и этот процесс можно ускорить, выиграв еще пару-тройку месяцев.
Сотрудники российского офиса UI не устают напоминать о двух вещах. Во-первых, следует заранее — лучше за месяц — оповещать о том, что планируется передача в UI томов с чертежами. Это позволит избежать ожидания в очереди, так как рабочее время консультантов, занимающихся рассмотрением документации, распределяется заранее.
Во-вторых, у UI есть свой список представляемых документов, который отличается и по объему, и по составу от основной рабочей и проектной документации проекта. Обычно весь требуемый комплект не превышает 100 страниц, в то время как рабочая документация в переведенном варианте может занимать 500 листов и более.
Однако в большинстве случаев этим простым советам не следуют. Иначе говоря, в UI узнают о сдаче проекта день в день с поступлением документации, а последняя оказывается не адаптированной к требованиям сертификации, то есть предоставляется только перевод полной рабочей документации — как правило, минимум в пять раз больше, чем необходимо.
В общей сложности только из-за неправильной подготовки документации можно потерять три месяца и более.
Гост р 58811-2020 центры обработки данных. инженерная инфраструктура. стадии создания от 19 февраля 2020 –
ГОСТ Р 58811-2020
ОКС 01.040.35, 01.040.93
Дата введения 2020-08-01
1 РАЗРАБОТАН Некоммерческой организацией “Ассоциация участников отрасли центров обработки данных”.
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 120 “Центры обработки данных”.
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 19 февраля 2020 г. N 67-ст
4 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2021 г. N 162-ФЗ “О стандартизации в Российской Федерации”. Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе “Национальные стандарты”, а официальный текст изменений и поправок – в ежемесячном информационном указателе “Национальные стандарты”. В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя “Национальные стандарты”. Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования – на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Настоящий стандарт распространяется на инженерную инфраструктуру центров обработки данных различного назначения, создаваемых любыми организациями, действующими на территории Российской Федерации.
Стандарт устанавливает стадии создания инженерной инфраструктуры центров обработки данных, а также этапы внутри стадий и содержание работ на каждом этапе.
В настоящем стандарте использована нормативная ссылка на следующий документ:
СП 68.13330.2021 “СНиП 3.01.04-87 Приемка в эксплуатацию законченных строительством объектов. Основные положения”
Примечание – При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования – на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю “Национальные стандарты”, который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя “Национальные стандарты” за текущий год. Если заменен ссылочный документ, на который дана датированная ссылка, то рекомендуется использовать версию этого документа с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3.1 В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1.1 процесс создания инженерной инфраструктуры центра обработки данных: Совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых рекомендуется и достаточно для создания ИИ ЦОД, соответствующей заданным требованиям.
3.1.2 ввод в эксплуатацию: Процесс, во время которого системы (элементы) и оборудование ИИ ЦОД начинают функционировать и проверяется их соответствие проекту.
3.1.3 инженерная инфраструктура центра обработки данных: Комплекс систем и их оборудования, обеспечивающий бесперебойное функционирование систем и оборудования ИТ-инфраструктуры ЦОД.
Примечание – Состав инженерной инфраструктуры определяется требованиями к ее функционированию со стороны оборудования ИТ-инфраструктуры и требованиями к обеспечению безопасной работы всего ЦОД. Как правило, в состав инженерной инфраструктуры входят системы электроснабжения, поддержания климата, связи и управления, комплекс систем безопасности.
3.1.4 информационно-технологическая инфраструктура центра обработки данных; ИТ-инфраструктура; инфраструктура ИТ ЦОД: Совокупность комплексов аппаратных, программных и телекоммуникационных средств автоматизированных информационных систем, размещенных в центре обработки данных и обеспечивающих предоставление информационных, вычислительных и телекоммуникационных ресурсов, возможностей и услуг потребителям.
3.1.5 исполнительная документация: Комплект рабочих чертежей с надписями о соответствии выполненных в натуре работ этим чертежам или о внесенных в них по согласованию с проектировщиком изменениях, сделанных лицами, ответственными за производство монтажных работ.
3.1.6 предварительные технические решения: Описания объекта проектирования или его частей, необходимые и достаточные для определения дальнейшего направления проектирования.
3.1.7 сервисное обслуживание ИИ ЦОД: Комплекс регламентированных работ по поддержанию работоспособности или исправности ИИ ЦОД, предусмотренными в нормативно-технической или эксплуатационной документации с периодичностью и в объеме, установленными в ней, независимо от технического состояния изделия в момент начала технического обслуживания и выполняемых по договору уполномоченными представителями (сервисными компаниями) производителей оборудования и систем.
3.1.8 служба эксплуатации центра обработки данных: Организация или ее подразделение, в обязанности которой вменяется проведение работ по эксплуатации систем и оборудования центра обработки данных.
3.1.9 техническая концепция: Основные принципы и подходы к созданию ЦОД, а также его общая архитектура с учетом данных предпроектного обследования.
3.1.10 техническое задание на создание инженерной инфраструктуры центра обработки данных: Исходный технический документ для создания инженерной инфраструктуры центра обработки данных и документации на нее.
Примечание – Техническое задание на создание инженерной инфраструктуры центра обработки данных содержит общие сведения о ее создании, предъявляемые к ней требования и требования к самому процессу создания. Действие технического задания распространяется на все стадии создания.
3.1.11 техническое обслуживание ИИ ЦОД: Комплекс работ по поддержанию работоспособности или исправности ИИ ЦОД, выполняемых службой эксплуатации через установленные в эксплуатационной документации интервалы времени.
3.1.12 эксплуатация ИИ ЦОД: Комплекс работ по содержанию, обслуживанию и ремонту ИИ ЦОД для обеспечения нормального функционирования ИИ ЦОД в соответствии с функциональным назначением, запланированными эксплуатационными характеристиками в течение всего срока службы, без аварийной работы.
3.1.13 центр обработки данных; ЦОД: Специализированный объект, представляющий собой связанную систему ИТ-инфраструктуры и инженерной инфраструктуры, оборудование и части которых размещены в здании или помещении, подключенном к внешним сетям, как инженерным, так и телекоммуникационным.
Примечание – При необходимости здание ЦОД может иметь прилегающую территорию.
3.2 В настоящем стандарте применены следующие сокращения:
Процесс создания инженерной инфраструктуры центров обработки данных (ИИ ЦОД) представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых рекомендуется и достаточно для создания ИИ ЦОД, соответствующей заданным требованиям.
Процесс создания ИИ ЦОД является частью общего процесса строительства или реконструкции объектов капитального строительства для размещения центров обработки данных.
Вопросы архитектурно-строительной подготовки центров обработки данных в данном стандарте не рассматриваются.
Стадии создания ИИ ЦОД и этапы работ внутри стадий выделяются как части процесса создания по соображениям рационального планирования и организации работ, заканчивающихся заданным результатом.
Перечень рекомендуемых результатов отдельных этапов работ приведен в приложении А.
Работы по развитию (модернизации) ИИ ЦОД осуществляют по стадиям и этапам, применяемым для ее создания.
Состав и правила выполнения работ на установленных настоящим стандартом стадиях и этапах определяются действующей нормативно-технической документацией и документацией участников создания конкретных видов ИИ ЦОД.
Перечень участников отдельных этапов создания ИИ ЦОД приведен в приложении Б.
Состав участников, задействованных на конкретных этапах, приведен в приложении В.
Стадии и этапы создания ИИ ЦОД в общем случае приведены в таблице 1.
Таблица 1
Стадии и этапы, выполняемые участниками работ по созданию ИИ ЦОД, устанавливаются в договорах и техническом задании на ее создание на основе настоящего стандарта.
Допускается исключать стадию “Техническая концепция” и отдельные этапы работ на всех стадиях. В зависимости от специфики создаваемой ИИ ЦОД и условий ее создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, а также включать новые этапы работ.
6.1.1 Этап 1.1. Формирование требований
Цель этапа 1.1 заключается в формировании требований к ИИ ЦОД со стороны ИТ-инфраструктуры ЦОД.
На этапе 1.1 проводят:
1) сбор данных о характеристиках комплексов технических средств ИТ-инфраструктуры, планируемых к размещению в проектируемом центре обработки данных;
2) сбор данных о потребностях комплексов технических средств ИТ-инфраструктуры ЦОД в обеспечении условий для функционирования в создаваемом центре обработки данных с заданными параметрами;
3) формулирование требований к ИИ ЦОД.
6.1.2 Этап 1.2. Обследование площадки
Цель этапа 1.2 заключается в проведении обследования зданий, сооружений и площадок, на которых предполагается создание ЦОД.
На этапе 1.2 проводят сбор и изучение документов и информации о площадке (площадках), необходимых для подготовки заключения о пригодности исследуемых площадок для размещения ЦОД с заданными параметрами.
При необходимости в состав работ по этапу могут быть включены и другие виды обследований и изысканий, включая инженерные, результаты которых используются при подготовке отчета об обследовании и заключения по площадке. Результаты проведенных на этапе 1.2 инженерных изысканий также могут быть использованы на этапе 5.1 при разработке проектных решений для ИИ ЦОД.
Состав работ по обследованию устанавливается в договорах между заказчиком и исполнителем (исполнителями) работ по этапу на основе настоящего стандарта.
6.1.3 Этап 1.3. Оформление отчета об обследовании
Цель этапа 1.3 заключается в документировании результатов обследования площадки (площадок), предполагаемых для размещения ЦОД, и в подготовке заключений и рекомендаций для организации-заказчика
На этапе 1.3 проводят оформление отчета об обследовании, содержащего собранные в ходе работ по этапу 1.2 документы, материалы и информацию, а также заключения и рекомендации по выбору площадки для создания ЦОД.
От проекта к объекту
На данный момент для всех классов Tier предлагаются три вида дополняющих друг друга сертификаций:
- Design (проект);
- Facility (готовый объект);
- Operational Sustainability (организация процессов эксплуатации).
В России до недавнего времени большинство владельцев ЦОДов ограничивались сертификацией проекта, то есть на соответствие стандартам американской организации представлялась только проектная документация объекта.
Аттестация самого объекта за прошедшие годы была заказана лишь для 4 центров обработки данных из 18, получивших оценку проекта. Такая ситуация сложилась по двум причинам:
- за каждый вид сертификации нужно платить отдельно, что увеличивает расходы на сертификацию объекта как минимум в два раза;
- клиенты — арендаторы стоек не заостряли внимание на том, какой именно сертификат имеется у арендодателя («Uptime и есть Uptime»).
Но с начала 2021 года срок действия сертификата на проект был ограничен двумя годами с момента получения. Это время отводится на строительство центра обработки данных и получение сертификата на объект. Логика нововведения проста: даже по сертифицированным чертежам может быть построен ЦОД так, что его не удастся ввести в эксплуатацию, не говоря уже о соответствии своему классу Tier.
В конечном итоге эта мера выгодна как клиентам коммерческих ЦОДов, так и их владельцам. В ЦОДах, где размещается критическое оборудование, при заезде новых арендаторов обычно подписывается соглашение об уровне обслуживания (Service Level Agreement, SLA). В договоре фиксируются допустимое время простоя за год и сумма штрафа за каждую дополнительную минуту простоя.
Помимо оценки проекта и его реализации, UI проводит аттестацию операционной устойчивости — Operational Sustainability. Это новый вид сертификации, появившийся в 2021 году, в рамках которой оцениваются компетентность персонала и умение действовать в нештатных ситуациях.
По статистике, 60% отключений ЦОДов происходят по вине человека. Скажем, если кто-то уронит ключ на шинопровод в машзале, ничто не спасет от аварии даже ЦОД Tier IV. Кстати, в России всего три центра обработки данных имеют сертификат Operational Sustainability — это ЦОД Dataspace1 (компании Dataspace Partners), «Компрессор» (принадлежит компании «Крок») и Mega Data Center I (ЦОД Сбербанка).
Ошибки проектировщиков
Следующий этап — адаптация технического задания. С одной стороны, ТЗ должно соответствовать российским проектным реалиям, а с другой — в нем должны быть учтены требования UI. Это следует сделать до согласования бюджета и выделения необходимых средств.
Наиболее частой ошибкой является некорректное формулирование требований к инженерным системам, их резервированию и подбору оборудования. Например, могут быть неправильно указаны требования к оборудованию. Согласно UI, необходимо использовать экстремальные значения температуры для региона (за весь период наблюдений), где будет проходить строительство.
Скажем, в регионе зафиксированы температурные экстремумы –45 и 380C, а в ТЗ на основании СНиПов строительной климатологии указаны –35 и 320C. Охлаждающее оборудование, предназначенное для разных климатических условий, может очень сильно отличаться по производительности и цене.
Возможна и такая неточность: согласно требованиям UI, для ДГУ «номинальный режим» — «непрерывный» (continuous), а в ТЗ указан «дежурный» (stand by). Обычно это выясняется после замечаний UI, и тогда элементы системы энергоснабжения приходится подбирать заново.
Чтобы сразу выявить все шероховатости, в штате проектировщика должен быть специалист, который знает требования UI и будет рассматривать ТЗ именно с точки зрения последующей сертификации. Такой человек позволит проектной команде избежать массы проблем при реализации проектов госкорпораций («Аэрофлот», ВТБ, Сбербанк). Эти компании делают заказы через тендерные площадки, и изменить бюджет после конкурса очень сложно.
Подготовка к сертификации объекта
Сертификация объекта (Facility), как уже упоминалось выше, теперь неразрывно связана с сертификацией проекта (Design). И подготовка к этой процедуре также стартует в период проектных работ. Одним из самых важных этапов является правильное написание исполнительной документации, особенно той ее части, которая касается программ и методик испытания — как отдельных систем объекта, так и инфраструктуры в целом. ЦОД должен вводиться в эксплуатацию согласно этим документам.
Часто приходится сталкиваться с тем, что исполнительной документации уделяется мало внимания. Формально компания, заказывая подрядчику строительство ЦОДа, и не планировала оплачивать еще и дополнительный комплект документов. Стоимость же пусконаладочной документации может быть сопоставима со стоимостью части рабочей документации. Генподрядчик тоже не горит желанием заниматься лишней работой.
Написания инструкции и проведения испытаний обычно требуют от субподрядчиков, занятых монтажом оборудования, — им по штату положено продемонстрировать, что техника, которую они установили, работает. Все придерживаются нехитрой логики: если все системы по отдельности работают — значит, будут работать и вместе.
Поэтому ситуация, когда после официального введения в эксплуатацию ЦОД еще месяца три пытаются запустить — обыденность. Но представьте, если на официальную сдачу в эксплуатацию центра обработки данных пригласили сотрудников UI с целью сертификации объекта, — это однозначный «провал».
Рынок еще не до конца осознал, что сертификации проекта и объекта теперь составляют одно целое. Многие клиенты просят подготовить только проект, но тот, кто соглашается на это, обманывает заказчика. Не надо идти на поводу у сиюминутных интересов, следует объяснить клиенту новые правила Uptime Institute, с чем они связаны и чем грозит их несоблюдение.
Таким образом, мы выяснили, как сэкономить не менее года на стадии проекта при одновременной подготовке сертификации в UI. В следующей статье речь пойдет о собственно сертификации объекта.
Автор выражает признательность Алексею Солодовникову, управляющему директору Uptime Institute в России, за помощь в написании статьи.
Продолжение следует.
Максим Новиков — коммерческий директор компании «ГК Четыре стихии».
Проект — общее дело
В России достаточно много компаний проектируют центры обработки данных с прицелом на сертификацию в UI. При этом многие из них нередко допускают ошибки, которых можно было бы избежать, сохранив хорошие отношения с заказчиком, повысив прибыльность компании и маржинальность проекта.
Для заказчика строительство ЦОДа — непрофильный бизнес. Поэтому даже если ТЗ есть, его необходимо проверить. Поскольку заказывают ЦОДы крупные компании или инвесторы, решение о строительстве принимают сразу несколько подразделений, и зачастую они выдвигают противоречивые требования.
Поэтому нужно сразу провести совещание с участием руководителей финансовой, эксплуатационной и ИТ-служб. Проектной команде как модератору встречи следует озвучить следующие «ключевые» тезисы:
- сертификация страхует технологические риски компании и ответственность руководителей в случае нештатной ситуации;
- топология UI (Tier III–IV) позволяет не отключать критически важные бизнес-процессы на время сервисного обслуживания;
- сертификация повышает маркетинговую составляющую и позволяет привлекать в ЦОД клиентов с критически важными бизнес-процессами.
За столом переговоров представители заказчика смогут выработать единые требования к отказоустойчивости. В будущем это позволит избежать неожиданной смены приоритетов в проектировании, если сертификация окажется нужна. В 90% случаев сторона заказчика выбирает сертификацию Tier III, так как эта топология позволяет эксплуатировать ЦОД круглогодично и без остановок. Tier IV — это выбор в основном крупнейших банков и военных структур.
Процедура сертификации
Стандартно все три сертификации (Design, Facility, Operational Sustainability) проходят в два / два с половиной этапа: предпросмотр и два просмотра.
Стандарты uptime institute
Uptime Institute разработал стандарты как для строительства, так и для организации работы центров обработки данных. Основным критерием было обеспечение максимальной доступности, или времени доступности (uptime в англоязычной терминологии), ИТ-инфраструктуры.
Многие отраслевые регламенты, например ASHRAE TC 9.9 Thermal Guidelines for Data Processing Environments, содержат целевые показатели для ЦОДов, в частности по температурному режиму или влажности. В отличие от них, рекомендации Uptime Institute в большей степени касаются топологии инженерных систем и правил их размещения, в том числе с учетом расположения других систем.
В соответствии с классификацией UI центры обработки данных делятся на четыре различных класса, которые получили название Tier. Tier I — это центр обработки данных со всеми базовыми системами инженерной инфраструктуры, обеспечивающими его работоспособность.
К ним относятся электроснабжение, гарантированное и бесперебойное питание, холодоснабжение, вентиляция, теплоснабжение, структурированная кабельная система (СКС), система контроля и учета доступа (СКУД), водоснабжение, канализация, пожарная сигнализация, противопожарные системы.
По данным сайта компании UI, наиболее популярный класс ЦОДов среди заказчиков сертификации — Tier III. Столь высокий спрос обусловлен тем, что техническое обслуживание такого ЦОДа, включая замену любого узла инженерной инфраструктуры, можно проводить без остановки работы машинного зала (серверной).
Иначе говоря, при правильном обслуживании центр обработки данных способен работать круглый год, не останавливаясь ни на минуту. ЦОД Tier III подобен автомобилю, двигатель которого можно полностью перебрать на скорости 200 км/ч. Причем во время этого технического облуживания машина будет сохранять все свои эксплуатационные характеристики: управляемость, динамику разгона и т. д.
Цикл: экспертиза — ui — экспертиза
После начала проектирования одной из наиболее важных вех является прохождение экспертизы, которая нужна для получения разрешения на строительство — без него сертификат UI заказчику не понадобится. Отдавая приоритет этой задаче, многие компании забывают, что их проект должен соответствовать также требованиям UI, и попадают в своеобразный замкнутый круг.
Как уже отмечалось, очень важно сразу заявить UI о том, что проект делается в расчете на дальнейшую сертификацию. Кроме того, следует помнить, что проектировать надо с учетом требований как UI, так и экспертизы и отечественных норм. Попытка сделать все последовательно, то есть сначала согласовать проект в экспертизе, а потом адаптировать его для сертификации, может обернуться большими временными и денежными потерями.
Почему UI и экспертизу нужно проходить параллельно? Скажем, экспертиза проведена и далее документация направляется в UI на первый просмотр, по итогам которого приходит немало — до нескольких десятков — замечаний. Продолжим разбирать пример с дизелем и чиллерами и рассмотрим негативное развитие событий.
Вместо режима «дежурный» дизель должен работать в «непрерывном» режиме. Оборудования тех габаритов и той мощности, которое было указано в проекте, не нашлось, поэтому пришлось предусмотреть более производительное. Мощнее — значит, больше по габаритам и расходу топлива.
В результате придется менять монтажные рамы и геометрию помещения, а также увеличивать размер топливных баков, чтобы горючего хватило на 12 ч. С геометрией одного помещения меняется геометрия других. Весь проект придется переделывать, и он уже не будет соответствовать ранее одобренным планировкам. Повод идти в экспертизу, так как проект изменился.
Чиллеры были рассчитаны на неправильные экстремумы климатических условий: 32 и –350C вместо 38 и –450C. UI попросил заменить соответствующее оборудование, чтобы ЦОД гарантированно не перегрелся жарким летом. Оборудование на 38 и 320C разное. У первого больше и поверхность теплообмена, и габариты, и мощность потребляемой энергии, и размер труб для хладоносителя.
Замена оборудования приведет к перепроектированию монтажных рам и трасс хладагента. Из-за возросшего потребления не хватит мощности электропитания. Соответственно, потребуется увеличить квоты, а значит, снова придется идти в электросбытовую компанию и заново проходить экспертизу. По сути, проект надо будет начинать заново.
Ситуацию можно экстраполировать дальше. Поставив более дорогое оборудование, мы выйдем за рамки ранее оговоренного бюджета. Чтобы уложиться в целевую смету, проект будем корректировать и менять половину ЦОДа. Снова экспертиза, снова отправка документов в UI, но объект-то уже другой, поэтому за сертификацию придется платить еще раз.
Некоторые проекты на рынке крутятся в таком колесе два-три года, а на четвертый в стране уже совсем другая экономическая ситуация, да и цены на оборудование выросли. Попадание в «цикл» может поставить под угрозу саму возможность строительства даже очень важного объекта с хорошим финансированием.
Есть два способа пройти экспертизу в UI быстро:
- найти проектную команду, которая знает, как работать с «циклами», и уже научилась готовить документацию параллельно в соответствии с требованиями обеих организаций;
- нанять консультанта, который будет постоянно контролировать проектировщиков со стороны заказчика и проверять документацию, чтобы она соответствовала требованиям и UI, и экспертизы.
При таком подходе создание проекта, прохождение экспертизы и сертификация в UI занимают не более года.