Мы видим множество совпадений, хотя и описанных по-разному, но имеющих одну суть. Кроме того, в обоих документах большое внимание уделено подготовке и допуску нового персонала к работе, что подчеркивает важность этого процесса. В отличие от стандарта 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] приложений.

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

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

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

Теперь Вам стала понятна важность определения уровня сервиса между ЦОД и клиентом. Для этого требуется составление и проведение формальных процедур принятия обеими сторонами документов, называемых SLA или OLA.

SLA (Service Level Agreement), соглашение об уровне услуг, – это документ, характерный прежде всего для ЦОД колокейшн-провайдера, заключаемый между заказчиком и исполнителем, описывающий параметры предоставляемой услуги или сервиса.

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

Также существует OLA (Operational Level Agreement), соглашение об уровне операционного обслуживания, – аналогичный SLA внутренний документ компании, определяющий параметры услуги, оказываемой друг другу внутренними подразделениями компании.

• При соотнесении требований этих документов важно учитывать три аспекта:

• требования к любым SLA должны быть более жесткими по сравнению c OLA;

• требования к SLA ваших подрядчиков и поставщиков услуг должны быть более жесткими или как минимум равными с SLA, заключенными вами с клиентом;

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

Если данные условия не соблюдаются, это может приводить к негативным событиям. Например, согласно SLA ваш поставщик услуг связи может допускать перерыв в предоставлении услуг на два часа в месяц без санкций, а по SLA с вашим клиентом допусти́м перерыв лишь в один час; это означает невозможность выполнения условий контракта с клиентом вашего ЦОД.