Наряду с термином «ЦОД», ныне всем известным, определено понятие «корпоративный ЦОД международного уровня», и это не просто игра слов. В последнем случае речь идет о более совершенных требованиях к объекту, ином уровне использования международных стандартов при его создании и обязательной сертификации со стороны Uptime Institute, о совершенно ином подходе к организации работ.

ЦОД и современная ИТ-мода

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

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

Компания, которая претендует на международную известность и ведет бизнес не только в России, должна задуматься о том, что и ЦОД у нее должен соответствовать лучшим мировым практикам. Стандартных (и в то же время отчасти формальных) подходов к ЦОД как к одному из объектов ИТ-инфраструктуры в этом случае совершенно недостаточно. Мало того, стандартные подходы в этом случае могут и вовсе привести к отрицательным результатам.

Подходы и определения

Мы предлагаем вниманию читателя основные идеи, основанные на нашем опыте практической организации, подготовки и создания уникального пока еще для России объекта, сертифицированного на соответствие критериям Uptime Institute для центра обработки данных. Проект находится в стадии реализации, и, безусловно, подводить итоги преждевременно. Тем не менее накоплен определенный уникальный опыт, которым мы хотели бы поделиться.

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

  • на базе ЦОД функционируют ИТ‑системы класса mission critical;
  • ЦОД развивается в том числе и как важный актив, призванный увеличить реноме компании на рынке — как в глазах партнеров, так и в глазах клиентов;
  • ЦОД планируется сертифицировать на соответствие международным стандартам.

Стандарты и философия

ЦОД, который вы решили себе построить, находится под влиянием требований двух потоков нормативных документов: 1) международных и зарубежных стандартов и 2) отечественной нормативной базы.

Задача создания корпоративного ЦОД такого уровня уникальна с точки зрения «пересечения» применяемых стандартов. Создание вычислительных центров на территории России предполагает, как правило, обязательное выполнение требований разнообразных ГОСТ и СНиП в области инженерных систем и строительных конструкций. К сожалению, отечественную нормативную базу и практику ее применения не всегда можно однозначно отобразить на международные стандарты и наоборот.

Анализ реализованных в России проектов с заявленным уровнем надежности 3 или 4 по классификации Uptime Institute или по стандарту TIA 942 показывает, что такой уровень надежности в 99% случаев достигается не для всех подсистем. Например, система бесперебойного питания может быть построена по уровню 4, но система гарантированного электроснабжения — только по уровню 2. Почему? Ответ, как правило, следующий: заказчик не смог согласовать условия размещения или решил сэкономить капиталовложения.

Анализируя подобные ситуации, мы убедились, что один из факторов, препятствующих реализации решений более высокого уровня, кроме финансового, — несоответствие российской и международной нормативной базы. Например, стандарт TIA-942, который любят использовать для определения необходимых уровней надежности, вообще относится к телекоммуникационной отрасли США, и применять его к ЦОД в других отраслях, мягко говоря, некорректно.

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

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

Поставьте перед этой стадией проекта следующие цели.

  1. Убедиться в том, что требования классификаций и стандартов зарубежных стран и международных организаций не вступают в противоречие с действующими нормативными и регламентирующими документами Российской Федерации.
  2. Подготовить позицию исполнителя по доказыванию соответствия требований, включенных в техническое задание на создание ЦОД, требованиям различных нормативных документов.
  3. Подготовиться к разработке технического задания на создание ЦОД.

В рамках поставленных целей сформулируйте следующие задачи.

  1. Cформировать свод документов, содержащих требования к ЦОД и его подсистемам, требования к его проектированию, строительству, испытаниям и вводу в действие.
  2. Провести анализ применимости отдельных нормативных документов при разработке технического задания, проектирования, строительства и испытания ЦОД.
  3. Выполнить анализ отдельных требований на непротиворечивость и на соответствие российской нормативной базе.

Все документы, содержащие требования к ЦОД, можно разделить на четыре класса. Нумерация классов и порядок их перечисления соответствуют степени их важности и уровню системообразования:
1‑й класс. Высокоуровневые требования и классификации — к этому классу относится классификация Uptime Institute(1).
2‑й класс. Специализированные международные стандарты, требования и рекомендации международных организаций(2).
3‑й класс. Российские федеральные стандарты, правила, рекомендации — к этому классу документов могут быть отнесены все российские ГОСТы, СНиПы, СанПИНы, РД и прочие своды правил (например, ПУЭ), в которых содержатся требования к проектированию, реализации и испытанию оборудования подсистем, предполагаемых в составе проектируемого ЦОД.
4‑й класс. Отраслевые документы, внутренние регламентирующие документы заказчика, — этот класс документов содержит отраслевые и ведомственные регламентирующие документы.
Требования, которые могут быть высказаны полномочными представителями заказчика, следует относить к дополнительному, 5‑му классу и включать в предварительный список только в том случае, если они не будут противоречить требованиям документов предыдущих четырех классов.

Для проведения анализа необходимо привлечь экспертов по следующим направлениям:

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

Полезной и продуктивной представляется такая схема работы на этой стадии: каждый эксперт работает в своей предметной области и выполняет следующую последовательность действий.

  1. Изучает состав документов 1‑го класса и при необходимости дополняет этот список.
  2. Выделяет в документах 1‑го класса требования, относящиеся к его предметной области.
  3. Изучает состав документов 2‑го класса и при необходимости дополняет этот список.
  4. Выделяет в документах 2‑го класса требования, относящиеся к его предметной области.
  5. Сопоставляет требования документов 1‑го класса с требованиями документов 2‑го класса. Формирует список требований по своей системе, содержащихся в документах 2‑го класса. Делает заключение о непротиворечивости, выполнимости и т. д. конкретных требований.
  6. Формирует список документов 3‑го класса по своей предметной области.
  7. Проводит анализ требований документов 1‑го класса и 2‑го класса на соответствие требованиям документов 3‑го класса. Делает заключение о непротиворечивости, выполнимости, законности и т. д. конкретных требований.
  8. Формирует запрос к заказчику на предоставление документов 4‑го класса по своей предметной области.
  9. Анализирует предоставленные документы 4‑го класса по своей предметной области. Сопоставляет требования документов 4‑го класса с требованиями документов 1‑го, 2‑го и 3‑го классов. Делает заключение о непротиворечивости, выполнимости, законности и т. д. конкретных требований.
  10. Проводит работу с представителями заказчика для формирования особых, специальных требований к подсистеме ЦОД своей предметной области. Анализирует эти особые требования на предмет соответствия требованиям документов предыдущих классов (1‑го, 2‑го, 3‑го и 4‑го).
  11. Подготавливает свой раздел в общий отчет. В этом разделе должно быть следующее:
    а) список документов, содержащих требования к подсистеме;
    б) описание результатов анализа системы документов;
    в) укрупненное описание основных, принци­пиальных функциональных требований к подсистеме.

В результате вы получите полный свод требований к ЦОД заданного уровня надежности и сложности, который будет не только отвечать вашим задачам, но и в полной мере соответствовать всем необходимым нормативным документам. Если вы строите обычный ЦОД, то вполне можно и опустить вышеописанную стадию анализа нормативной базы, и такой подход имеет право на существование. Но если ваш будущий ЦОД вы определяете как «корпоративный ЦОД международного класса», то это — не ваш выбор.

Сертификация ЦОД по версии Uptime Institute

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

Сертификация вашего ЦОД на соответствие требованиям классификации Uptime Institute — задача нетривиальная. Стоит отметить, что Uptime Institute никому (никому!) не доверяет, не делегирует право сертификации от его имени, сертификация проводится только самим Uptime Institute.

Процедура сертификации ЦОД по версии Uptime Institute состоит из двух последовательных этапов, на каждом из которых проверяется соответствие требованиям Uptime Institute и, что самое важное, их идеологии:

  1. сертификация проекта.
  2. сертификация реализованных решений.

Первый этап — сертификация проекта. Чтобы обеспечить сертификацию проекта на соответствие требованиям Uptime Institute для инфраструктуры центров обработки данных, необходимо, разрабатывая проектную документацию, предусмотреть передачу организации, отвечающей за экспертное сопровождение проекта создания, промежуточных версий документации, соответствующих 30%-ной готовности (уровень документации эскизного проекта, Concept/Schematic Design в терминологии Uptime Institute) и 60%-ной готовности (уровень проектной документации, Detailed Design в терминологии Uptime Institute).

На каждой из стадий проектирования в Uptime Institute высылаются документы проекта (на английском языке), а в ответ приходят рецензии с указанием на ошибки и несоответствия требованиям Uptime Institute. Замечания и рекомендации, сделанные Uptime Institute, необходимо учесть в финальной версии проектной документации. В результате этого процесса, когда уже готов весь комплект проектной документации, Uptime Institute делает заключение о том, какому уровню безопасности соответствует проектное решение (Tier I, II, III или IV). После принятия решения о сертификации Uptime Institute направляет счастливому владельцу проекта ЦОД специальный сертификат и заносит (при желании клиента) его объект в список ЦОД с сертифицированным проектным решением. Это дополнительный бонус и международная реклама для компании.

Второй этап — сертификация реализованных решений. Этот этап начинается тогда, когда подходят к своему завершению пусконаладочные работы. Этот этап сертификации проходит при личном участии экспертов Uptime Institute, выезжающих на строительную площадку. При правильном планировании комплекса испытаний выезд экспертов Uptime Institute приходится на этап приемочных испытаний. Безусловно, существует определенный риск, что демонстрация соответствия реализованных решений требованиям Uptime Institute может дать сбой. Но за счет многоступенчатых испытаний и с привлечением внешней контролирующей экспертной организации эти риски могут быть минимизированы.

Важно понимать, что для проведения сертификации реализованного решения в обязательном порядке необходима сертификация проектного решения. Существует также прямая зависимость между уровнем классификации Uptime Institute, которому соответствует проектное решение, и уровнем, соответствующим реализованному решению. Чудес не бывает: если ваш проект был сертифицирован на Tier III, то не стоит ждать сертификации решения на Tier IV.

Стоит отметить, что в классификации Uptime Institute существует ровно четыре уровня (tier) и нет никаких промежуточных классов (например, 3+ или 4-). Кроме этого, необходимо принимать во внимание, что все компоненты ЦОД должны соответствовать требованиям одного и того же уровня классификации. Будет совершенно неестественно строить ЦОД, претендующий на сертификацию по уровню не ниже Tier III, в составе которого есть решения по электроснабжению, отвечающие требованиям класса Tier II, в то время как система безопасности вашего объекта отвечает требованиям класса Tier IV. К сожалению, такое положение дел весьма распространено в условиях нашей действительности и демонстрирует соотношение долей затрат на реализацию различных подсистем ЦОД: системы безопасности — менее затратные системы, чем системы электроснабжения, микроклимата и т.п.

Напомним, что требования системы классификации Uptime Institute чрезвычайно просты и концептуальны. Процедуры сертификации обоих этапов (проект и решение) носят дискуссионно-оппонентный характер: вы защищаете свои решения, демонстрируя их соответствие концепции классификации Uptime Institute.

Изюминка сертификации реализованных решений в том, что вместе с присвоением вашему ЦОД того или иного уровня по классификации Uptime Institute вы получаете заключение о так называемой «операционной устойчивости» (operational sustainability) — важной части сертификата вашего ЦОД(3).

Основная идея такого подхода следующая — общая устойчивость созданного ЦОД складывается из комбинации надежности реализованной топологии решений и операционной устойчивости. Операционная устойчивость включает в себя все возможные условия, влияющие на созданную инфраструктуру: физическая безопасность объекта, окружающие природные условия (например, возможность затопления или землетрясения), влияние потенциально возможных ошибок персонала на устойчивость системы в целом и другие факторы. Как утверждается, в реальности только 30% всех отказов зависят от ошибочно разработанной топологии или плохо реализованных решений, а 70% отказов обусловлены как раз факторами операционной устойчивости.

Надо понимать, чем опасно недостаточное внимание к ряду нетехнологических аспектов построения ЦОД (например, модель эксплуатации, концепция физической безопасности объекта). Может случиться так, что технологические (инженерные) решения вашего ЦОД будут сертифицированы Uptime Institute на желаемый вами уровень безопасности и надежности, но ваш объект получит заключение, в котором будет указано на низкий уровень его «операционной устойчивости». Безусловно, последнее — продукт для внутреннего употребления, но будет ли вам комфортно знать, что в работе вашего корпоративного ЦОД возможны проблемы, ведущие к авариям и ката­строфам?

В следующей статье мы рассмотрим ряд вопросов, более тесно привязанных к конкретным этапам работ по созданию корпоративного ЦОД.

(1) Tier Classifications Define Site Infrastructure Performance (авторы — W. Pitt Turner IV, P. E., John H. Seader, P. E., Vince Renaud, P. E., and Kenneth G.Brill, 2008; работа находится в свободном доступе на сайте Uptime Institute Inc.).

(2) Пример документов этого класса: Стандарт ANSI/TIA‑942‑2005 Telecommunications Infrastructure Standard for Data Centers, Прило­жение G (ANNEX G. DATA CENTER INFRASTRUCTURE TIERS).

(3) Позиция Uptime Institute по данному вопросу изложена в документе «Operational Sustainability and Its Impact on Data Center Uptime Performance, Investment Value, Energy Efficiency and Resiliency» (http://wwww.wcai.com/images/pdf/2008/green_greentech.pdf).