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

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

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

Это важный вопрос для определения концепции будущего ЦОД и, следовательно, принципов построения службы эксплуатации.

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

В рамках консультационной практики у нас был пример, когда одна финансовая организация, не рассматривающая перемещение мощностей своих ЦОД на коммерческую площадку, хотела организовать внутренние процессы по стандарту TS: OS – Tier Standard: Operational Sustainability[17].

В ходе первичных консультаций при определении объемов задач и текущей ситуации в организации выяснилось, что внутренние требования к ЦОД своих же внутренних клиентов – ИТ-отдела – никак не зафиксированы и даже не определены, а существуют на уровне «должно работать». Более того, люди, которым поставлена задача привести эксплуатацию ЦОД в соответствие со стандартом TS: OS, слабо ориентируются в подразделениях компании, являющихся их внутренними заказчиками. Соответственно, оказалось невозможным как выстроить концепцию функционирования ЦОД и службы эксплуатации, так и определить объем и квалификацию персонала, который требовался для работы ЦОД.

Какие из этого проистекают проблемы для проектировщиков и службы эксплуатации:

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

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

• Мы не можем понять, какая численность службы эксплуатации требуется, так как непонятно, нужно ли держать инженеров на объектах 24 × 7.

• Не зная требований к непрерывности, мы не можем понять требования к подрядчикам по обслуживанию сложных и критических узлов инженерной инфраструктуры, установить сроки реагирования на неисправности, установить количество необходимого ЗИП[19] на складе.

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