• оформление всего вышеперечисленного приказами.

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

Следовательно, к этим сотрудникам применимы аналогичные процессы предоставления допуска к самостоятельной работе. При этом в отношении электрика мы выполняем требования и норм, и стандартов, в отношении остальных – только требования стандартов.

Такой подход мы применяем к любым системам ЦОД. Читаем нормы и заменяем в них «электрооборудование» на «критическое оборудование». В итоге, во-первых, решается важная задача: пропадает необходимость ведения двойной документации – одной для Uptime Institute, второй для Ростехнадзора и пр.; во-вторых, применяется единый подход для всех остальных подразделений службы эксплуатации.

Давайте сравним, насколько похожи требования современного международного стандарта TS: OS от Uptime Institute и отечественных, вроде бы несовременных, существующих со времен СССР правил ПТЭЭП и ПОТЭЭ (Таблица 1). Для нас было удивительно при пошаговом сравнении увидеть столько совпадений.

Таблица 1

Сравнение требований современного международного стандарта TS: OS от Uptime Institute и отечественных правил ПТЭЭП и ПОТЭЭ

Мы видим множество совпадений, хотя и описанных по-разному, но имеющих одну суть. Кроме того, в обоих документах большое внимание уделено подготовке и допуску нового персонала к работе, что подчеркивает важность этого процесса. В отличие от стандарта TS: OS, в пунктах ПТЭЭП (1.4.11 и 1.4.14) указаны конкретные сроки подготовки, например четкие цифры длительности стажировок персонала. Процесс дублирования и стажировки в итоге занимает в сумме от 4 до 26 смен (стажировка 2–14 смен, дублирование 2–12 смен). При сменном режиме работы сутки через трое обучение нового сотрудника может занимать до 3 месяцев, хотя мы и не советуем так делать ввиду длительности процесса. В спорных ситуациях, например при аудитах и сертификации, рекомендуем использовать эти данные.

Также ПТЭЭП уделяет особое внимание разделу документации, повторяя эти требования почти в каждом разделе.

Основные отличия TS: OS от ПТЭЭП состоят в рассмотрении клининга и финансовых процессов, что обуславливается ориентацией первого из документов на ЦОД.

В целом, как видно из таблицы, ПТЭЭП практически совпадает в требованиях с TS: OS, что говорит о единстве требований в мировой практике. Мы рекомендуем рассматривать требования норм и проверку Ростехнадзора как одну из разновидностей сертификации и аудита, критически важную для ЦОД, но не противоречащую мировым практикам. Как мы писали выше, локальные нормы и правила должны стать базой для создания документации по лучшим практикам.

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

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

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

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

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

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

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

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

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

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