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

Боязнь тестировать ДГУ на полную нагрузку ЦОД

В предыдущей статье мы подробно описывали причины, почему собственный ДГУ должен быть надежным источником электроснабжения ЦОД, постоянно готовым к работе любой длительности. Более того, отключение городской сети и переключение на ДГУ должны восприниматься дежурным персоналом ЦОД как рутинный, многократно отработанный переход на работу от другого источника энергии, а не экстремальная ситуация. В пункте 2.5 Uptime Institute Tier Standard: Topology это описано так: «Перебои в электрической сети (внешней – примечание автора) считаются не аварийной ситуацией, а ожидаемым рабочим условием, к которому площадка полностью подготовлена». Только если в процессе перехода какая-то система сработает «нештатно», ситуацию следует признать аварийной и требующей своевременного устранения.

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

К сожалению, в некоторых ЦОДах придерживаются принципа «а как бы чего не случилось» и либо тестируют ДГУ исключительно на нагрузочные модули (так называемые индивидуальные испытания), либо вообще запускают ДГУ только на холостом ходу.  В результате при первом реальном отключении выясняется, что либо ДГУ не готовы к полноценной работе на полную нагрузку ЦОД, либо другие критические системы (например холодоснабжение) не работают корректно во время и после перехода на ДГУ, либо персонал растерялся и не способен устранить даже элементарные сбои в процессе переключения.

Тестовые переключения ЦОД с основного источника на ДГУ должны выполняться регулярно на основании заранее утвержденного графика. Каких-либо нормативов на этот счет нет, мы выбрали для себя такой график – запуск ДГУ без нагрузки (так называемый «прогрев») один раз в неделю, полное переключение ЦОД на работу от ДГУ – раз в квартал.

Поделимся нашим лайфхаком по организации таких переключений. Как при наличии напряжения на основном вводе перейти на ДГУ, не переводя автоматику ГРЩ в «ручной режим» и тем самым сильно увеличивая вероятность человеческой ошибки? Для этого достаточно предусмотреть в ГРЩ режим под условным названием «принудительное отключение основного ввода». При повороте соответствующего тумблера со входа контроллера АВР ГРЩ будет отключаться сигнал наличия напряжения на основном вводе, что в свою очередь приведет к активации автоматического режима перехода на ДГУ. Данная функция также будет вам полезна, если напряжение (или частота) на основном вводе нестабильны, в результате чего ЦОД циклично переходит на ДГУ и обратно. Она позволит вам, оставаясь в автоматическом режиме, игнорировать появление и пропадание напряжения на основном вводе и получать стабильное электроснабжение от вашего ДГУ, пока внешний поставщик не исправит ситуацию с параметрами напряжения на основном вводе.

Отсутствие контроля за парными нагрузками и управления мощностями ЦОД

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

• комплекс ДГУ и городской ввод,

• ГРЩ А и B,

• ИБП А и B,

• щиты гарантированного питания А и B,

• шинопроводы А и B,

• PDU А и В,

• трассы холодоснабжения А и B (если система охлаждения имеет их).

Также нужно контролировать соблюдение лимита N для систем с резервированием N+1, чаще всего это:

• агрегаты ДГУ,

• чиллеры или градирни,

• фанкойлы или кондиционеры.

Процесс контроля парных нагрузок должен быть совмещен с процессом управления ресурсами, выделенными для ЦОД (например, сколько энергии куплено у города), и ресурсами, доступными для клиентов (например, сколько установлено ИБП и ДГУ). Так как ЦОД заполняется постепенно, на основании данных, полученных от отдела продаж, служба эксплуатации должна заранее заказывать у поставщиков и вводить в работу новые мощности технологического оборудования ЦОД, чтобы избежать ситуации, когда оборудование новых клиентов устанавливается за счет резервной мощности. Напомним еще раз - любая избыточность, заложенная для резервирования, позволяет потреблять больше ресурсов, но как только это случается, уровень резервирования превращается в N (то есть резерва нет).

Использование устаревших систем мониторинга

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

Основные черты систем мониторинга ЦОД были заложены в самом начале формирования индустрии ЦОД. Традиционно развитие шло по двум направлениям, с одной стороны стандартные «коробочные» версии от больших вендоров, с ограниченным функционалом не предполагающим кастомизации под ваши задачи, и с другой стороны, так как многие провайдеры ЦОДов вышли из телеком-операторов, применялись системы на базе инструментов мониторинга ИТ/телеком-инфраструктуры Zabbix и  Prometheus+Grafana. Реже применялись «самописные» решения на базе открытых SCADA систем, а иногда встречались и такие примитивные решения, как на фото ????.

Не все службы эксплуатации понимают, что за более чем 10 лет архитектура и функционал доступного программного обеспечения ушли далеко вперед и от системы мониторинга можно добиться много большей эффективности, мобильности, информативности и надежности. Возможно, это происходит в том числе из-за того, что на рынке до сих пор очень мало достойных систем мониторинга, действительно отличающихся от классических устаревших продуктов, а создание решений “с нуля” под свои требования сопряжено с большими сложностями и трудозатратами. Историю создания нашей БМС в 4-х частях можно почитать тут.

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

Низкий уровень коммуникаций с клиентами

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

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

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

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

• Предоставление клиентам документа (желательно оформленного как приложение к договору размещения оборудования) под условным названием «Руководство клиента ЦОД», в котором исчерпывающе изложены все вопросы, касающиеся размещения оборудования клиента в ЦОД. Именно на основании этого документа и создается вводный инструктаж.

• Наглядная агитация в серверных в виде обучающих плакатов и табличек, как на стенах помещений, так и внутри стоек.

• Мониторинг парных нагрузок в стойках средствами БМС ЦОД и информирование клиента о их превышении.

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

Боязнь аудитов и нежелание проходить их самостоятельно

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

• Большинство применимых отраслевых аудитов (Uptime Management and Operations, ISO, проверки Ростехнадзора, аудиты со стороны клиентов и т.д.) имеют множество действительно полезных и обоснованных требований, а главное большинство проверяемых вопросов схожи, хотя зачастую и звучат по-разному.

• Вполне реально создать систему («экосистему», как сейчас модно говорить) процессов и документации, удовлетворяющую всем требованиям различных аудитов, при этом не ведя «двойную» документацию под требования различных аудитов.

• Созданные процессы, документация и уровень осведомленности персонала службы эксплуатации могут и должны поддерживаться на уровне, позволяющем в любой момент пройти любой применимый аудит без специальной подготовки.

• Прохождение аудитов гарантированно повышает уровень процессов службы эксплуатации и помогает их совершенствовать, а боязнь аудитов наоборот не дает службе эксплуатации развиваться. Даже самый типовой аудит может поставить перед вами вопрос, который вы упустили в своих процессах. И это замечательно, ведь вам помогли найти уязвимость, и вы получили возможность устранить ее. Если аудитор обладает высокой квалификацией и четко понимает, почему он что-то требует, проходить аудит становится очень интересно и полезно.

Но как перестать бояться аудитов и начать говорить с аудиторами на одном языке? В одной статье это невозможно описать, поэтому наша команда готовит к изданию книгу, в которой подробно, с примерами и ссылками, описан процесс эксплуатации ЦОД с учетом требований обязательных норм и правил, отраслевых «best practice», философии MOP, SOP, EOP и опыта прохождения всевозможных аудитов, в том числе многократной аттестации Uptime Institute Management & Operations Stamp of Approval.