В 90-е годы, на заре развития рынка ЦОДов, мало кто представлял, как нужно строить такие объекты. Переплетение нескольких десятков инженерных систем, необходимых для поддержки ИТ-оборудования, при недальновидном проектировании приводило к появлению сотен и тысяч потенциальных точек отказа. В результате простои оборудования могли случаться каждую неделю, и техническим специалистам приходилось тратить долгие часы, выявляя и устраняя неисправности. Клиенты коммерческих ЦОДов, сдававших площади в аренду (colocation), отказывались от таких некачественных услуг, что приводило к банкротству провайдеров.
Однако, помимо неудачных проектов, были и успешные. Так, ЦОДы, построенные в соответствии с рекомендациями организации Uptime Institute, оказывались надежнее — время простоя по техническим причинам было незначительным. Такие результаты не могли не понравиться рынку. Сначала компании приобретали у Uptime Institute услуги консалтинга при проектировании и строительстве своих ЦОДов, а в начале 2000-х встал вопрос о сертификации. К этому моменту предложенные спецификации получили одобрение многих игроков рынка, и при размещении серверов клиенты все чаще стали интересоваться у владельцев центров обработки данных, построен ли их ЦОД в соответствии с рекомендациями Uptime Institute (далее для краткости будет использоваться аббревиатура UI, в зависимости от контекста обозначающая либо сам институт, либо разработанные им стандарты). Чтобы явным образом подтвердить это, крупные американские компании попросили разработать процедуру сертификации, и в 2006 году UI начал сертифицировать как документацию, так и ЦОДы своих клиентов.
Консалтинг UI является сегодня чрезвычайно востребованной услугой при проектировании ЦОДов, нацеленных на бесперебойную работу. Справедливости ради стоит отметить, что на этом рынке есть определенная конкуренция. Так, компании IBM и HP тоже сертифицируют ЦОДы на отказоустойчивость, но только если в них установлено произведенное ими серверное оборудование. Кроме того, сертификацией специалистов по проектированию ЦОДов занимается некоммерческая организация BICSI, которая достаточно хорошо известна в мире, но в России у нее не реализовано пока ни одного проекта. Львиная доля заказчиков предпочитает сертификацию UI по двум причинам:
- эта организация широко известна и уважаема;
- заказчик, как правило, не уверен в том, что парк оборудования в машинном зале будет однородным (от одного поставщика), поэтому не хочет оказаться в зависимости от какого-либо вендора.
СТАНДАРТЫ UPTIME INSTITUTE
Uptime Institute разработал стандарты как для строительства, так и для организации работы центров обработки данных. Основным критерием было обеспечение максимальной доступности, или времени доступности (uptime в англоязычной терминологии), ИТ-инфраструктуры. Многие отраслевые регламенты, например ASHRAE TC 9.9 Thermal Guidelines for Data Processing Environments, содержат целевые показатели для ЦОДов, в частности по температурному режиму или влажности. В отличие от них, рекомендации Uptime Institute в большей степени касаются топологии инженерных систем и правил их размещения, в том числе с учетом расположения других систем. Такой подход обеспечивает лучшую предсказуемость результатов по отказоустойчивости. В результате центры обработки данных, при создании которых учитывались эти стандарты, являются более надежными, чем в среднем по отрасли.
В соответствии с классификацией UI центры обработки данных делятся на четыре различных класса, которые получили название Tier. Tier I — это центр обработки данных со всеми базовыми системами инженерной инфраструктуры, обеспечивающими его работоспособность. К ним относятся электроснабжение, гарантированное и бесперебойное питание, холодоснабжение, вентиляция, теплоснабжение, структурированная кабельная система (СКС), система контроля и учета доступа (СКУД), водоснабжение, канализация, пожарная сигнализация, противопожарные системы. ЦОДы Tier II–IV не только содержат все перечисленные системы, но и гарантируют определенный уровень доступности — в частности, ЦОД Tier IV может «пережить» отказ любого узла инженерной инфраструктуры в автоматическом режиме (без участия человека).
По данным сайта компании UI, наиболее популярный класс ЦОДов среди заказчиков сертификации — Tier III. Столь высокий спрос обусловлен тем, что техническое обслуживание такого ЦОДа, включая замену любого узла инженерной инфраструктуры, можно проводить без остановки работы машинного зала (серверной). Иначе говоря, при правильном обслуживании центр обработки данных способен работать круглый год, не останавливаясь ни на минуту. ЦОД Tier III подобен автомобилю, двигатель которого можно полностью перебрать на скорости 200 км/ч. Причем во время этого технического облуживания машина будет сохранять все свои эксплуатационные характеристики: управляемость, динамику разгона и т. д.
ОТ ПРОЕКТА К ОБЪЕКТУ
На данный момент для всех классов Tier предлагаются три вида дополняющих друг друга сертификаций:
- Design (проект);
- Facility (готовый объект);
- Operational Sustainability (организация процессов эксплуатации).
В России до недавнего времени большинство владельцев ЦОДов ограничивались сертификацией проекта, то есть на соответствие стандартам американской организации представлялась только проектная документация объекта.
Аттестация самого объекта за прошедшие годы была заказана лишь для 4 центров обработки данных из 18, получивших оценку проекта. Такая ситуация сложилась по двум причинам:
- за каждый вид сертификации нужно платить отдельно, что увеличивает расходы на сертификацию объекта как минимум в два раза;
- клиенты — арендаторы стоек не заостряли внимание на том, какой именно сертификат имеется у арендодателя («Uptime и есть Uptime»).
Но с начала 2014 года срок действия сертификата на проект был ограничен двумя годами с момента получения. Это время отводится на строительство центра обработки данных и получение сертификата на объект. Логика нововведения проста: даже по сертифицированным чертежам может быть построен ЦОД так, что его не удастся ввести в эксплуатацию, не говоря уже о соответствии своему классу Tier.
В конечном итоге эта мера выгодна как клиентам коммерческих ЦОДов, так и их владельцам. В ЦОДах, где размещается критическое оборудование, при заезде новых арендаторов обычно подписывается соглашение об уровне обслуживания (Service Level Agreement, SLA). В договоре фиксируются допустимое время простоя за год и сумма штрафа за каждую дополнительную минуту простоя.
Помимо оценки проекта и его реализации, UI проводит аттестацию операционной устойчивости — Operational Sustainability. Это новый вид сертификации, появившийся в 2010 году, в рамках которой оцениваются компетентность персонала и умение действовать в нештатных ситуациях. По статистике, 60% отключений ЦОДов происходят по вине человека. Скажем, если кто-то уронит ключ на шинопровод в машзале, ничто не спасет от аварии даже ЦОД Tier IV. Кстати, в России всего три центра обработки данных имеют сертификат Operational Sustainability — это ЦОД Dataspace1 (компании Dataspace Partners), «Компрессор» (принадлежит компании «Крок») и Mega Data Center I (ЦОД Сбербанка).
ПРОЦЕДУРА СЕРТИФИКАЦИИ
Стандартно все три сертификации (Design, Facility, Operational Sustainability) проходят в два / два с половиной этапа: предпросмотр и два просмотра.
Предпросмотр предполагает, что при готовности объекта или проекта к сертификации на 50% можно выслать чертежи и документы в UI, чтобы убедиться в том, что работа идет в правильном направлении. В случае отклонений, по мнению UI, от их рекомендаций, высылаются комментарии, учет которых позволяет вернуться в нужное русло.
Если все в порядке, то по мере готовности надо перевести на английский язык документы из обязательного списка и выслать в UI для просмотра. Консультанты UI проверят, учтены ли в проекте все рекомендации, изложенные в основном документе UI, после чего проект в случае Design или объект в случае Facility и Operational Sustainability проходит сертификацию. При наличии нареканий составляется перечень замечаний, после проработки которых документы можно подавать еще раз. Если за два просмотра большинство замечаний не удалось устранить, сертификация считается непроведенной. Следующую попытку можно повторить за те же деньги.
В российском офисе UI советуют еще на нулевом этапе, как только возникла задача проведения сертификации, сообщить об этом намерении, чтобы заранее разработать рекомендации, выслать инструкции и облегчить подготовку документации и объекта к просмотру. Однако в реальной жизни мы видим, что наши заказчики и коллеги поступают иначе. И напрасно тратят ресурсы.
ПРОЕКТ — ОБЩЕЕ ДЕЛО
В России достаточно много компаний проектируют центры обработки данных с прицелом на сертификацию в UI. При этом многие из них нередко допускают ошибки, которых можно было бы избежать, сохранив хорошие отношения с заказчиком, повысив прибыльность компании и маржинальность проекта.
Для заказчика строительство ЦОДа — непрофильный бизнес. Поэтому даже если ТЗ есть, его необходимо проверить. Поскольку заказывают ЦОДы крупные компании или инвесторы, решение о строительстве принимают сразу несколько подразделений, и зачастую они выдвигают противоречивые требования. Например, ИТ-департамент всегда старается заложить в проект максимально возможное количество стоек — на вырост, а финдиректор прилагает все усилия, чтобы это количество «урезать».
Поэтому нужно сразу провести совещание с участием руководителей финансовой, эксплуатационной и ИТ-служб. Проектной команде как модератору встречи следует озвучить следующие «ключевые» тезисы:
- сертификация страхует технологические риски компании и ответственность руководителей в случае нештатной ситуации;
- топология UI (Tier III–IV) позволяет не отключать критически важные бизнес-процессы на время сервисного обслуживания;
- сертификация повышает маркетинговую составляющую и позволяет привлекать в ЦОД клиентов с критически важными бизнес-процессами.
За столом переговоров представители заказчика смогут выработать единые требования к отказоустойчивости. В будущем это позволит избежать неожиданной смены приоритетов в проектировании, если сертификация окажется нужна. В 90% случаев сторона заказчика выбирает сертификацию Tier III, так как эта топология позволяет эксплуатировать ЦОД круглогодично и без остановок. Tier IV — это выбор в основном крупнейших банков и военных структур.
ОШИБКИ ПРОЕКТИРОВЩИКОВ
Следующий этап — адаптация технического задания. С одной стороны, ТЗ должно соответствовать российским проектным реалиям, а с другой — в нем должны быть учтены требования UI. Это следует сделать до согласования бюджета и выделения необходимых средств. Мы часто встречали ТЗ, которые, хотя и были написаны с участием дорогостоящих специалистов и ориентированы на топологию UI, содержали неточности, исключающие успешное прохождение сертификации.
Наиболее частой ошибкой является некорректное формулирование требований к инженерным системам, их резервированию и подбору оборудования. Например, могут быть неправильно указаны требования к оборудованию. Согласно UI, необходимо использовать экстремальные значения температуры для региона (за весь период наблюдений), где будет проходить строительство. Скажем, в регионе зафиксированы температурные экстремумы –45 и +380C, а в ТЗ на основании СНиПов строительной климатологии указаны –35 и +320C. Охлаждающее оборудование, предназначенное для разных климатических условий, может очень сильно отличаться по производительности и цене. Для ЦОДа, рассчитанного на +380C, либо потребуется больше чиллеров (для поддержания работоспособности устройств в указанных условиях), либо придется выбирать чрезмерно дорогие модели.
Возможна и такая неточность: согласно требованиям UI, для ДГУ «номинальный режим» — «непрерывный» (continuous), а в ТЗ указан «дежурный» (stand by). Обычно это выясняется после замечаний UI, и тогда элементы системы энергоснабжения приходится подбирать заново. Надо ли говорить, что времени потребуется больше? Кроме того, всегда есть риск не найти оборудование, подходящее по габаритам или бюджету, и поставить под угрозу экспертное заключение по проекту.
Чтобы сразу выявить все шероховатости, в штате проектировщика должен быть специалист, который знает требования UI и будет рассматривать ТЗ именно с точки зрения последующей сертификации. Такой человек позволит проектной команде избежать массы проблем при реализации проектов госкорпораций («Аэрофлот», ВТБ, Сбербанк). Эти компании делают заказы через тендерные площадки, и изменить бюджет после конкурса очень сложно.
ЦИКЛ: ЭКСПЕРТИЗА — UI — ЭКСПЕРТИЗА
После начала проектирования одной из наиболее важных вех является прохождение экспертизы, которая нужна для получения разрешения на строительство — без него сертификат UI заказчику не понадобится. Отдавая приоритет этой задаче, многие компании забывают, что их проект должен соответствовать также требованиям UI, и попадают в своеобразный замкнутый круг.
Как уже отмечалось, очень важно сразу заявить UI о том, что проект делается в расчете на дальнейшую сертификацию. Кроме того, следует помнить, что проектировать надо с учетом требований как UI, так и экспертизы и отечественных норм. Попытка сделать все последовательно, то есть сначала согласовать проект в экспертизе, а потом адаптировать его для сертификации, может обернуться большими временными и денежными потерями.
Почему UI и экспертизу нужно проходить параллельно? Скажем, экспертиза проведена и далее документация направляется в UI на первый просмотр, по итогам которого приходит немало — до нескольких десятков — замечаний. Продолжим разбирать пример с дизелем и чиллерами и рассмотрим негативное развитие событий.
Вместо режима «дежурный» дизель должен работать в «непрерывном» режиме. Оборудования тех габаритов и той мощности, которое было указано в проекте, не нашлось, поэтому пришлось предусмотреть более производительное. Мощнее — значит, больше по габаритам и расходу топлива. В результате придется менять монтажные рамы и геометрию помещения, а также увеличивать размер топливных баков, чтобы горючего хватило на 12 ч. С геометрией одного помещения меняется геометрия других. Весь проект придется переделывать, и он уже не будет соответствовать ранее одобренным планировкам. Повод идти в экспертизу, так как проект изменился.
Чиллеры были рассчитаны на неправильные экстремумы климатических условий: +32 и –350C вместо +38 и –450C. UI попросил заменить соответствующее оборудование, чтобы ЦОД гарантированно не перегрелся жарким летом. Оборудование на 38 и 320C разное. У первого больше и поверхность теплообмена, и габариты, и мощность потребляемой энергии, и размер труб для хладоносителя. Замена оборудования приведет к перепроектированию монтажных рам и трасс хладагента. Из-за возросшего потребления не хватит мощности электропитания. Соответственно, потребуется увеличить квоты, а значит, снова придется идти в электросбытовую компанию и заново проходить экспертизу. По сути, проект надо будет начинать заново.
Ситуацию можно экстраполировать дальше. Поставив более дорогое оборудование, мы выйдем за рамки ранее оговоренного бюджета. Чтобы уложиться в целевую смету, проект будем корректировать и менять половину ЦОДа. Снова экспертиза, снова отправка документов в UI, но объект-то уже другой, поэтому за сертификацию придется платить еще раз. К нему уже возникают другие вопросы. Снова изменение проекта и т. д. В конце концов заказчик приходит к мысли о смене проектной команды, а новая команда может снова попасть в «цикл» и т. д.
Некоторые проекты на рынке крутятся в таком колесе два-три года, а на четвертый в стране уже совсем другая экономическая ситуация, да и цены на оборудование выросли. Попадание в «цикл» может поставить под угрозу саму возможность строительства даже очень важного объекта с хорошим финансированием.
Есть два способа пройти экспертизу в UI быстро:
- найти проектную команду, которая знает, как работать с «циклами», и уже научилась готовить документацию параллельно в соответствии с требованиями обеих организаций;
- нанять консультанта, который будет постоянно контролировать проектировщиков со стороны заказчика и проверять документацию, чтобы она соответствовала требованиям и UI, и экспертизы.
При таком подходе создание проекта, прохождение экспертизы и сертификация в UI занимают не более года.
БЫСТРО И СЕРДИТО
Сделав правильный выбор, можно сэкономить полгода-год при подготовке проекта. Но и этот процесс можно ускорить, выиграв еще пару-тройку месяцев.
Сотрудники российского офиса UI не устают напоминать о двух вещах. Во-первых, следует заранее — лучше за месяц — оповещать о том, что планируется передача в UI томов с чертежами. Это позволит избежать ожидания в очереди, так как рабочее время консультантов, занимающихся рассмотрением документации, распределяется заранее.
Во-вторых, у UI есть свой список представляемых документов, который отличается и по объему, и по составу от основной рабочей и проектной документации проекта. Обычно весь требуемый комплект не превышает 100 страниц, в то время как рабочая документация в переведенном варианте может занимать 500 листов и более. Подготовка комплекта чертежей обычно проходит легко, если в компании есть человек, который следит за соблюдением рекомендаций UI при проектировании и в процессе инженерной работы отбирает документы, необходимые для сертификации.
Однако в большинстве случаев этим простым советам не следуют. Иначе говоря, в UI узнают о сдаче проекта день в день с поступлением документации, а последняя оказывается не адаптированной к требованиям сертификации, то есть предоставляется только перевод полной рабочей документации — как правило, минимум в пять раз больше, чем необходимо. А вместе с объемом пропорционально возрастает количество вопросов, не говоря уже о том, что в этой кипе бумаг часто отсутствуют важные спецификации и чертежи. Впоследствии их все равно приходится досылать.
В общей сложности только из-за неправильной подготовки документации можно потерять три месяца и более.
ПОДГОТОВКА К СЕРТИФИКАЦИИ ОБЪЕКТА
Сертификация объекта (Facility), как уже упоминалось выше, теперь неразрывно связана с сертификацией проекта (Design). И подготовка к этой процедуре также стартует в период проектных работ. Одним из самых важных этапов является правильное написание исполнительной документации, особенно той ее части, которая касается программ и методик испытания — как отдельных систем объекта, так и инфраструктуры в целом. ЦОД должен вводиться в эксплуатацию согласно этим документам.
Часто приходится сталкиваться с тем, что исполнительной документации уделяется мало внимания. Формально компания, заказывая подрядчику строительство ЦОДа, и не планировала оплачивать еще и дополнительный комплект документов. Стоимость же пусконаладочной документации может быть сопоставима со стоимостью части рабочей документации. Генподрядчик тоже не горит желанием заниматься лишней работой.
Написания инструкции и проведения испытаний обычно требуют от субподрядчиков, занятых монтажом оборудования, — им по штату положено продемонстрировать, что техника, которую они установили, работает. Все придерживаются нехитрой логики: если все системы по отдельности работают — значит, будут работать и вместе. Но возьмем автомобиль: он собран, к двигателю претензий нет, а вполне исправная коробка передач установлена задом наперед — машина не поедет. В ЦОДах такие вещи встречаются довольно часто в первые месяцы после сдачи.
Поэтому ситуация, когда после официального введения в эксплуатацию ЦОД еще месяца три пытаются запустить — обыденность. Но представьте, если на официальную сдачу в эксплуатацию центра обработки данных пригласили сотрудников UI с целью сертификации объекта, — это однозначный «провал».
Рынок еще не до конца осознал, что сертификации проекта и объекта теперь составляют одно целое. Многие клиенты просят подготовить только проект, но тот, кто соглашается на это, обманывает заказчика. Не надо идти на поводу у сиюминутных интересов, следует объяснить клиенту новые правила Uptime Institute, с чем они связаны и чем грозит их несоблюдение. Рано или поздно все равно станет понятно, что если нужна классификация Tier от UI, то понадобятся и сертификация объекта, и исполнительная документация. В противном случае будут зря потрачены деньги и время.
Таким образом, мы выяснили, как сэкономить не менее года на стадии проекта при одновременной подготовке сертификации в UI. В следующей статье речь пойдет о собственно сертификации объекта.
Автор выражает признательность Алексею Солодовникову, управляющему директору Uptime Institute в России, за помощь в написании статьи.
Продолжение следует.
Максим Новиков — коммерческий директор компании «ГК Четыре стихии».