Порядок применения стандарта

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

Для начала следует определиться с целевым уровнем 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 в таком проекте обеспечит максимально высокое качество построенной операционной модели.