Rambler's Top100
Статьи ИКС № 03 2013
Заурбек АЛЕХИН  12 марта 2013

Операционная устойчивость ЦОДа: новое увлечение или реальная потребность?

Окончание. Начало см. «ИКС» № 1-2’2012, с. 76. Чтобы быть уверенным в высоком качестве функционирования ЦОДа, стандарт Tier Standard: Operational Sustainability необходимо применять последовательно и грамотно.

Заурбек АЛЕХИН, независимый консультантПорядок применения стандарта

Конечно, каждый сам может решить, как именно применять Стандарт операционной устойчивости для ЦОДов. И это будет отчасти верно. Мы же остановимся на «авторском» варианте применения стандарта.

Для начала следует определиться с целевым уровнем Tier. В целом Tier – это ожидания качества функционирования дата-центра. Например, по статистике Uptime Institute, дата-центр, соответствующий Tier II, по причинам, связанным с необходимостью обслуживания и ремонта инженерных систем, в среднем недоступен не более 22 часов в год. Аналогичное значение для Tier III – 1,6 часа. Кстати, раньше эти цифры явно указывались в Стандарте на топологию, но версия документа 2012 г. их уже не содержит.

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

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

Итак, объект построен, и с ним что-то надо делать. Делать у нас принято так: назначить ответственного за эксплуатацию, и пусть он сам со всем разбирается – разрабатывает предложения по организации, защищает бюджет, формирует структуру команды, набирает персонал и ищет сервисных подрядчиков. Знакомая картина, не так ли?

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

Можно посоветовать следующий порядок действий, по существу являющийся высокоуровневым планом проекта:

1. Уточнить ожидаемые параметры обслуживания, убедиться, что они соответствуют заявленному Tier. Если это не так, дальнейшие шаги могут оказаться бессмысленны.

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

3. Выяснить, как правильно выполнять обслуживание и ремонт: разработать или получить иным способом технологические карты и описания операций обслуживания по всем системам и их компонентам.

4. Обеспечить надежное хранение и доступность всей документации по дата-центру, включая упоминаемую в п. 2.

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

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

7. Организовать обеспечение реальными ресурсами: инициировать поиск и прием персонала, а также подбор подрядчиков.

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

9. Принять решение о правилах взаимодействия с подрядчиками: подготовить соответствующие документы, договоры, SLA.

10. Построить систему управления обслуживанием: внедрить автоматизированную или чисто организационную систему контроля и управления исполнением операций обслуживания, обеспечить мониторинг основных параметров функционирования систем.

11. Сформулировать и зафиксировать правила поведения на объекте, порядок доступа, перемещения, размещения бытового оборудования, упаковки и т.д.

12. Обеспечить исполнение иных вспомогательных процессов и процедур: разработать и внедрить процессы управления финансами, мощностями, политики и процедуры функционирования объекта в целом.

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

14. Осуществить корректировку модели по итогам ее «опытной эксплуатации»: после того, как модель «притрется» и докажет свою работоспособность (на это может потребоваться более полугода), доработать ее с учетом внесенных практикой изменений и уточнений.

15. Сертифицировать операционную модель: провести аудит построенной операционной модели и ее реализации, получить сертификат Uptime Institute.

Этот план довольно объемный, но все же понятный и вполне реализуемый. Закономерны вопросы: каковы условия его успешности, возможные сроки, иные ограничения? Поскольку примеров построения такого рода модели в России пока нет, оценки попытаемся сделать на основании зарубежных проектов и практик. Итак, каким образом такого рода проект реализуется «там», в чем отличия и особенности?

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

Подводные камни внедрения

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

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

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

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

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

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

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

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

Дата-центры, сертифицированные по операционной устойчивости

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

Информация о дата-центрах, успешно прошедших сертификацию на соответствие требованиям операционной устойчивости, размещена на сайте Uptime Institute. На момент написания статьи их было пять: один – уровня Tier IV (дата-центр провинции Онтарио, Канада) и еще четыре – уровня Tier III (коммерческий дата-центр Fujitsu Services в Великобритании и три корпоративных ЦОДа: один – UnitedHealth Group и два – Target Corporation, все в США).

Напомним, ранее мы сделали предположение, что дата-центр имеет некоторый подтвержденный специальным сертификатом Uptime Institute уровень Tier. Это, безусловно, существенно сужает перечень потенциально заинтересованных в применении стандарта операционной устойчивости. В то же время многие положения стандарта будут полезны и при отсутствии у ЦОДа означенного сертификата. И хотя применять изложенные в стандарте идеи не возбраняется никому, но получить подтверждение правильности их применения без доброй воли Uptime Institute будет невозможно.

Понимая проблему, Uptime Institute совместно с представителями различных индустрий разработал отдельную специальную схему сертификации – Management and Operations Approval, предназначенную для оценки операционной модели действующих критичных дата-центров, не имеющих сертификата уровня Tier. Суть ее в следующем: в ходе сертификационного аудита оценивается только операционная модель действующего дата-центра, в то время как по иным направлениям (характеристики здания и местоположение площадки) оценка не проводится. Выдаваемый в случае успеха по этой модели сертификат действует в течение двух лет. Действующий сертификат Management and Operations Approval на момент написания статьи имели восемь организаций – три в Великобритании (шесть площадок), три в США (три площадки) и две во Франции (восемь площадок).

Применимость стандарта для российских компаний

Как и всякое новое веяние, операционная устойчивость не может быть оценена однозначно. У нее будут как энтузиасты, так и критики. И кто победит, сказать сейчас трудно. В то же время не вызывает сомнения, что стандарт содержит действительно полезные идеи, которыми можно воспользоваться.

Будучи по сути документом отдельной коммерческой компании, стандарт не претендует на обязательность и не может быть в этом ключе рекомендован для применения на государственном уровне. Решение о его использовании и тем более – о необходимости сертификации на соответствие ему остается за менеджерами и владельцами конкретного дата-центра. С другой стороны, всё это не помешало получить фактическое признание стандарту Tier Standard: Topology. Поскольку Tier Standard: Operational Sustainability является его обоснованным продолжением, затрагивающим фазу эксплуатации дата-центра, без которой в целом теряется смысл усилий по строительству, логично предположить, что в ближайшей перспективе он также будет принят и признан за рубежом. А это, в свою очередь, позволяет надеяться, что в скором будущем мы станем свидетелями успешного применения стандарта Tier Standard: Operational Sustainability и в нашей стране.  

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