Intelligent Enterprise: Пожалуйста, немного о себе. Была ли ваша деятельность изначально связана с ИТ?
Питт Тернер: Я никогда не работал в сфере ИТ. Моя специальность по бакалавриату — инжене-механик, и я магистр в области делового администрирования. У меня двадцатилетний опыт работы в коммерческом секторе, связанный с управлением и эксплуатацией коммерческой недвижимости; на пике карьеры я отвечал за эксплуатацию более шестисот зданий в Калифорнии.
Однако со временем мне пришлось заниматься и строительством центров обработки данных. Началом деятельности на этом поприще стал ЦОД телекоммуникационной компании Pacific Bell площадью около тысячи квадратных метров. Но никакого опыта у нас не было. И чтобы выполнить эту работу с высоким качеством, мы провели анкетирование представителей почти сорока ЦОДов, стремясь накопить необходимые для построения объекта знания.
После выполнения этого проекта я решил сменить сферу деятельности и заняться консультированием, присоединившись к команде Uptime Institute. Там и работаю вот уже 23 года.
Как рождались стандарты, которые мы сейчас знаем под именем TIER?
Запрос на этот стандарт был связан с одной компанией, которая активно расширялась, в том числе поглощая другие. И они столкнулись с тем, что у них полностью отсутствуют какие бы то ни было критерии для оценки помещений, где предполагалось размещать серверное и телекоммуникационное оборудование. Точнее, единственным критерием пригодности тогда было наличие фальшпола.
Представитель этой компании обратился в Uptime Institute с предложением разработать некую скоринговую модель для оценки таких помещений. Ведь наличия фальшпола явно недостаточно для этой цели. И такая модель была разработана. Было это в 1996 году.
Уже тогда стало ясно, что разработанная модель является универсальной и ее может применять не только наш заказчик, но и вся индустрия. Поэтому мы взяли разрешение развивать её и использовать в дальнейшем.
И процесс совершенствования продолжается. В 2009-м мы внесли очередные изменения в стандарт инженерной инфраструктуры ЦОДов TIER Topology. Мы сделали всё, чтобы убрать оттуда наши субъективные и во многом эмоциональные оценки.
Некоторые стандарты существовали и раньше, например американский правительственный FIPS 94. Были свои наработки и у крупных корпораций, и у ИТ-консультантов. Однако мы их не использовали, поскольку все они касались только требований к ИТ-оборудованию и его конфигурированию. Многие из них были усложнены. Скажем, на результат могло влиять использование «не тех» шкафов-стоек. Мы же ориентировались на конечный результат и не ограничивались направленностью исключительно на рынок США. Наш стандарт используют в 160 странах мира.
Всегда необходимо помнить, что любой бизнес прежде всего интересуется функционированием прикладных систем, которые тоже иногда простаивают. А причины этих простоев могут быть связаны с работой оборудования, а могут и не быть. Тем не менее заказчику, очевидно, следует предлагать инфраструктурные решения, надежность которых обоснована всеми возможными факторами…
В прежних версиях нашего стандарта была таблица, в которой приводилось допустимое время простоя для разных уровней TIER. Мы от нее давно отказались, но ее до сих пор можно встретить в литературе, в периодике и в Интернете. Да и раньше мы ее приводили лишь как ориентир, а не в качестве пункта соглашения об уровне сервиса.
Моя же точка зрения такова, что коэффициент доступности ЦОДа независимо от уровня TIER должен составлять 100%. За исключением аварий или плановых остановок. Так что вопрос состоит в том, как минимизировать это время. Вот простои и рассматриваются при оценке эксплуатационной устойчивости объекта. Уровень TIER III и более высокие просто исключают полную остановку инженерных систем для профилактики или ремонта. Тем самым автоматически выполняется пожелание абсолютно всех ИТ-директоров, которые очень не хотят, чтобы оборудование отключалось по причинам, так или иначе связанным с работой систем ЦОДа.
Однако не все простои связаны с работой инженерных систем. У любых приложений, как системных, так и прикладных, есть определенное окно простоя, связанное с их обслуживанием, например, обновлением или установкой патчей. Таких систем и платформ в одном ЦОДе могут быть сотни тысяч. И наверняка какая-то из них обновляется, переносится на новое оборудование или в новую виртуальную машину, а значит, не работает. Но доступность ЦОДа должна быть выше, чем у приложений, развернутых на его базе.
Хотя многое зависит и от потребностей бизнеса. Для обеспечения работы сайта-визитки вполне достаточно и уровня TIER I. То же самое и в том случае, если компания производит какой-то абсолютно уникальный товар, который невозможно купить у кого бы то ни было еще. Клиенты, что называется, никуда не исчезнут и все равно купят, пусть и чуть позже. Однако в целом применительно к интернет-торговле работает «правило десяти секунд», согласно которому загрузка сайта не должна превышать заданный интервал. Иначе потенциальный покупатель уйдет к конкуренту. То же самое и с поставщиками услуг связи. Для многих задержка в десять миллисекунд уже неприемлема, так как это ведет к задержкам при работе приложений. А есть и такие системы, которые не должны отключаться никогда. Например, связанные с управлением движением денежных средств на уровне целой страны. Такие системы нельзя останавливать даже в праздничные и выходные дни, поскольку они в разных странах не совпадают. Ненамного отличаются требования к кассовым системам в крупных розничных сетях или к биллингу операторов мобильной связи. Тут даже секундный простой ведет к огромным убыткам. В торговых системах сбой приводит к ситуации, когда деньги получены, но товар не продается. А это уже состав преступления и необоснованное обогащение. Хотя следует различать транзакционные системы и те, в которых происходит выставление счетов на регулярной основе за довольно продолжительный период — неделю, месяц, а то и год. В последнем случае задержки, в том числе по вине ИТ-систем, не являются критичными.
Для тех, у кого высока цена простоя, базовым уровнем надежности систем ЦОДа является TIER III. Именно на них приходится наибольший объем по сертификации. Следующий — TIER IV. А вот низкие уровни — TIER I и TIER II — занимают незначительный процент.
Некоторое время назад, на острой фазе кризиса 2007–2009 годов, довольно широкое распространение получили так называемые трэш-ЦОДы, где инженерные системы практически отсутствовали. Дожили ли они до наших дней?
Это явление появилось раньше, на волне интернет-бума конца 90-х и начала 2000-х. Тогда было большое количество стартапов, у которых было много амбиций, но недостаточно денег для того, чтобы развернуть ИТ-инфраструктуру, по крайней мере на первое время. Немалую роль играло и желание как можно быстрее выпустить продукт на рынок. После краха доткомов о таких ЦОДах забыли, но вспомнили, когда наступила острая фаза кризиса. Сейчас это направление снова сходит на нет, в чем мы видим и наше влияние. Наши стандарты позволяют проводить непредвзятое сравнение между объектами с разным уровнем инженерной топологии. Да, впервые стандарты TIER были опубликованы в период интернет-бума, но тогда это мало кто заметил. Теперь же их признали. Да и рынок коммерческих ЦОДов изменился. Раньше шла ориентация на наиболее непритязательных клиентов, сейчас их все чаще используют крупнейшие компании и корпорации. Да, до сих пор существует плаcт коммерческих ЦОДов, не сертифицированных нами, но это, скажем так, своеобразные компании, интересные весьма узкому кругу заказчиков.
Есть ли принципиальная разница между сертификацией корпоративного и коммерческого ЦОДа?
Такой разницы в процессе сертификации нет. Стандарт один и тот же, критерии соответствия его нормам абсолютно одинаковы. Равно и те и другие получают независимое подтверждение того, что их ЦОД соответствует всем требованиям по надежности. А мнение извне всегда ценится выше. Мне это в период работы в коммерческой компании казалось обидным.
Но коммерческим ЦОДам сертификация дает целый ряд конкурентных преимуществ. Например, заметно сокращаются работы по установке оборудования заказчика, что ЦОДу выгодно. Кроме того, сертификат TIER III гарантирует соблюдение целого ряда важных требований потенциального заказчика к площадке.
Есть ли какието специфические для России проблемы, связанные с созданием и сертификацией ЦОДов?
Главная проблема, главный барьер состоит в том, что компании нечетко сознают свои потребности. Когда такое осознание приходит, то выбор необходимой топологии тривиален.
Вторая проблема связана с последовательным подходом к проектированию объекта. Например, предложен проект системы электроснабжения. Сложный, но позволяющий добиться высокой надежности. При этом система охлаждения на примитивном уровне. Налицо явная несогласованность в разработке инженерных систем, а значит, как минимум имеет место недопонимание потребностей бизнеса.
Среди типовых ошибок проектов, которые подаются на сертификацию, хочется отметить также несоответствие температурного режима, предполагаемого в ходе проекта, тому, что рекомендует поставщик оборудования.
Нередко имеет место и проектирование в ЦОДе некритичных систем, самим фактом своего существования подрывающих модель надежности, которую мы пытались построить. Таких примеров масса. Тут можно посоветовать максимально «отвязывать» критически важные системы от некритичных, чтобы исключить их взаимное влияние друг на друга.
И наконец, проект может быть очень хорошим, но в ходе строительства в него вносится множество изменений и в итоге получается нечто совсем другое.
Иногда поднимают вопрос специфического российского климата, якобы влияющего на развертывание инженерных систем. Я не стал бы тут драматизировать ситуацию. В США, поверьте, проблем не меньше. Например, встает вопрос государственного регулирования. В любой стране есть свои строительные нормы. В России они очень подробные и хорошо проработанные. В них прописаны вопросы геологии, гидрологии, температурного режима, ветровой нагрузки и много чего еще. Все эти моменты всегда необходимо иметь в виду и строить объекты в соответствии со СНиП. Тем более, что эти нормы ни в коей мере не противоречат разработанным нами методологиям.
Много говорят о том, что в России не слишком качественное энергоснабжение. Но потеря внешнего электропитания с точки зрения нашего стандарта даже не является нештатной ситуацией! Да, это более выгодный с финансовой точки зрения источник электроэнергии, но он не должен быть единственным. На объекте необходим свой источник энергоснабжения, за которым надо следить и работоспособность которого поддерживать. Это может быть дизель-генератор, газовая турбина или что-то еще. Существует несколько типов решений, но ни одно из них не является универсальным, одинаково хорошо подходящим для условий любого мирового региона. Выбирать всегда нужно самому. Например, газовая турбина будет неплохим вариантом для России или другой страны, богатой природным газом, но совершенно не подойдёт Южной Корее или Японии, которые газ импортируют.
В целом же отставание в развитии рынка ЦОДов в России успешно преодолевается. В 2006 году, когда я впервые посетил вашу страну, рынок коммерческих ЦОДов здесь практически отсутствовал. Сейчас мы сертифицировали 16 объектов, которые полностью соответствуют требованиям, предъявляемым на американском рынке. А таких объектов, как DataSpace, аттестованных по уровню Tier III Operational Sustainability — Gold, во всем мире всего пять.
Не стоит, однако, забывать об остальном объеме рынка, где может сохраняться отставание. Тут нужно выяснять причину, но скорее всего она состоит в том, что те, кто предлагает услуги ЦОДа, нечетко сознают потребности потенциальных потребителей.
Стандарт как двигатель рынка
Александр АНОСОВ, директор департамента интеграции решений подразделения IT Business компании Schneider Electric
Появление стандарта Uptime Institute в России и СНГ коренным образом повлияло на представление игроков рынка о том, какими должны быть инженерные системы центров обработки данных. До этого приходилось создавать ЦОДы, находясь в некотором вакууме, оперируя сложившимися, но устаревшими российскими стандартами. Отечественные стандарты существуют и сейчас, но касаются они в основном строительных норм и правил, пожарной безопасности и т. п. Стандарт Uptime Institute впервые регламентировал логику построения инженерных систем и принципы их функционирования, позволил сравнивать различные варианты исполнения.
Появление стандарта совершило революцию в умах. В конце «нулевых» начался бум, рынок стал активно впитывать новые знания. Многие заинтересовались возможностью обучения и получения сертификатов в Uptime Institute. Однако из-за существования похожих по наименованию стандартов и уровней классификации возникла некоторая неразбериха, и институту стоило серьезных усилий объяснить коренные отличия своего стандарта от остальных (в частности, только он позволяет получить сертификат соответствия). Компания Schneider Electric как проектировщик и партнер активно вела и продолжает вести просветительскую работу в этом направлении.
Основная проблема, с которой сталкивается наша компания сегодня в России, — необходимость повышать компетенцию заказчика, поскольку далеко не все клиенты понимают, какой уровень надежности им необходим. Остальное — чисто технические задачи, решения которых известны.
Наличие собственного инженерного бюро помогает нам выявлять потребности заказчика. Ежегодно мы работаем с огромным количеством проектов инженерных систем ЦОДов, и когда к нам приходит клиент, мы уже знаем ответы на большинство его вопросов. Собственные базы наработок — локальная и международная — позволяют еще при построении концепции центра обработки данных перевести бизнес-требования заказчика в технические.
Schneider Electric тесно сотрудничает с Uptime Institute. Несколько наших специалистов имеют сертификаты в этой организации. Мы не только проектируем ЦОДы в соответствии с требованиями, принятыми в Uptime Institute, но и помогаем получить сертификаты соответствия тем клиентам, которые в этом нуждаются, — а это в первую очередь коммерческие площадки. Кроме того, мы работаем над тем, чтобы популяризировать в России этот правильный, структурированный подход к созданию дата-центров.
Стандартизация цода — это уровень понимания проблемы
Павел КОЛМЫЧЕК, руководитель сети дата-центров компании КРОК
КРОК уже более полутора десятилетий строит ЦОДы для корпоративных заказчиков и свыше пяти лет является провайдером услуг своей сети коммерческих дата-центров. Поэтому мы не понаслышке знаем про Uptime Institute и стандарт TIER Topology.
Зачастую первое обращение КРОКа совместно с заказчиком к этому стандарту связано с принятием решения о строительстве или аренде ЦОДа. Если заказчик понимает необходимость TIER III для бизнеса, то стандарт Uptime Institute лучше прочих стандартов и доводов позволяет объяснить, что строить свой ЦОД на тридцать стоек с надежностью TIER III — не самое экономически верное решение.
Здесь мы полностью согласны с мнением Питта Тернера, который утверждает, что заказчик должен сначала осознать для себя важность ЦОДа с надежностью столь высокого класса. Но в России на сегодняшний день заказчики, у которых такое понимание есть, чаще всего принадлежат к двум отраслям. Это банки и, как ни странно, ритейл. У всех остальных подобное понимание только формируется. Как подтверждение тому — пятилетний опыт продаж наших коммерческих ЦОДов. При общении с сотней заказчиков можно встретить лишь единицы тех, кто может назвать конкретную стоимость часа простоя ЦОДа для компании. Другие в лучшем случае оперируют терминами «очень критично», «достаточно важно» или «нужен резервный ЦОД».
Особенность российского рынка, которую стоит отметить, заключается в наличии значительного количества сертификатов уровня TIER III Design при очень небольшом количестве TIER III Facility. К сожалению, имеют место случаи, когда владельцы ЦОДов проводят сертификацию Design «для галочки», не предполагая именно так строить ЦОД, и об этой разнице пишет Питт, только в более безобидном ключе. Мы же призываем внимательнее относиться к типу сертификации. Только Facility даст уверенность в реальной технологической надежности ЦОДа, а Operational Sustainability — в зрелости и качестве работы службы эксплуатации.
