Правила по охране труда при эксплуатации электроустановок (ПОТЭЭ)

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

В процессе нашей работы мы проходили множество внутренних и внешних аудитов, как международных сертификаций, так и проверок локальными инспекторами Ростехнадзора, и в результате отметили много общего в требованиях различных документов. Хотя они сформулированы несколько по-разному, но суть того, что хотят увидеть аудиторы, – одна. Мы пришли к выводу, что было бы очень удобно создать одну универсальную экосистему документации, позволяющую проходить любые применимые аудиты, от Ростехнадзора до Uptime Institute. Как это возможно? Мы приведем пример далее, разбирая, насколько схожи требования Uptime Institute и ПТЭЭП\ПОТЭЭ.

Соответствие Tier Standard: Operational Sustainability и Правил технической эксплуатации электроустановок потребителей (ПТЭЭП)

Как мы уже упомянули выше, требования действующих в России норм и правил часто полностью совпадают с требованиями сторонних стандартов. В большинстве случаев их можно объединить и выполнить одновременно.

На некоторые критические системы ЦОД нормы не распространяются (так называемые неподназдорные системы). Несмотря на это, в ЦОД огромный объем действительно критических факторов для обеспечения непрерывности оборудования. Поэтому далее по тексту книги мы будем постоянно переносить требования норм к электрооборудованию на все критическое оборудование, например на системы охлаждения.

Давайте осмыслим, адаптируем и применим такие требования ко всем критическим системам ЦОД.

Например, по ПТЭЭП (пункт 1.4.5.2) для допуска нового дежурного электрика к работе ему необходимо пройти:

• вводный/первичный инструктаж;

• стажировку в дневные часы под контролем опытного сотрудника^[16];

• дублирование функций дежурного в смену под контролем опытного дежурного;

• проверку знаний (аттестацию) и получение допуска к самостоятельной работе;

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

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

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

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

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

Потребители (клиенты) услуг ЦОД и уровень SLA

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

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

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

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

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

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

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

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

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

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

Соглашение об уровне обслуживания (SLA) и его важность

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

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

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

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

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

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

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

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

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

Отделы внутри компании также взаимозависимы и используют внутренние сервисы, параметры которых должны быть описаны. Важность наличия внутренних задокументированных взаимоотношений с разными отделами трудно переоценить. Несмотря на этот, казалось бы, формализм подхода, у вас будут четкие критерии того объема работы и уровня сервиса, который вы предоставляете другим. Информация не останется на уровне «договоренностей в почтовой переписке» между сотрудниками компании, которые могут ее покинуть и не оставить следов договоренностей. Также, опираясь на задокументированные условия OLA, можно обосновать те или иные затраты на резервирование и уровень обслуживания вашей инфраструктуры.

Например: