Эксплуатация ЦОД. Практическое руководство

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

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

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

• стажировку в дневные часы под контролем опытного сотрудника[16 - В англоязычной литературе для такой формы стажировки часто используют название On-the-Job Training, OJT.];

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

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

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

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

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

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

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

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

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

• Не зная требований к непрерывности, мы не можем понять требования к подрядчикам по обслуживанию сложных и критических узлов инженерной инфраструктуры, установить сроки реагирования на неисправности, установить количество необходимого ЗИП[19 - ЗИП – запасные части, инструменты и принадлежности. Согласно п. 75 ГОСТ 27.102–2021 «Надежность в технике»: «Совокупность запасов материальных средств, сформированная в зависимости от назначения и особенностей использования объекта и предназначенная для его функционирования, технического обслуживания и ремонта».] на складе.

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

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

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

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

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

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

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

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

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

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

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

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

Например: для корпоративного ЦОД планировалась установка сетевого оборудования одного из вендоров. Выяснилось, что данному оборудованию присущи технологические особенности, а именно – подача охлаждающего воздуха к нему осуществляется от одной боковой стороны к другой, а также низкая температурная устойчивость: при 35 °C уже фиксировался перегрев. Эксплуатационной команде ЦОД пришлось не только демонтировать все боковые стенки уже установленных стоек холодных коридоров, но и понижать температуру подаваемого холодного воздуха до минимально возможной в 16 °C, чтобы сохранить температуру в пределах рабочего диапазона этого сетевого оборудования.

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

В контексте данной книги мы не будем рассматривать все составляющие SLA между клиентом и ЦОД, так как это в основном коммерческие вопросы. В любом случае в SLA будут присутствовать требования о непрерывности подачи электроэнергии в каком-либо виде, допустимые диапазоны температуры и влажности. Так как это коммерчески значимая информация, все цифры должны иметь различные инструментальные источники подтверждения параметров, указанных в SLA (BMS[20 - BMS (Building Management System) (англ.) – система управления зданием. Прикладная система, позволяющая собирать и анализировать сигналы о состоянии различных инженерных систем здания.], поверенные средства измерения и т. д.).

Основные параметры SLA для ЦОД

Обрисуем параметры SLA по отдельности.

1. Подача электроэнергии

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

Например: в одном из крупных ЦОД были установлены слишком широкие параметры ИБП по допустимому диапазону частоты (50 ± 4 Гц). Это не было отслежено на этапе ПНР, и в итоге при частоте ниже 47 Гц у клиентов стало перезапускаться оборудование при сохранении электропитания в стойке. Сложность выявления этой проблемы заключалась в том, что не все оборудование реагировало на изменения частоты, что не позволяло однозначно идентифицировать проблему на стороне инженерной инфраструктуры ЦОД.