20.04.2021

Мониторинг в ЦОДе: как мы меняли старую BMS на новую

В предыдущих частях мы рассказывали, как создавали и внедряли новую систему мониторинга ЦОД. В итоге у нас появился мощный механизм отслеживания и ведения статистики всех параметров ЦОДа, влияющих на доступность его ресурсов и показатели бесперебойной работы. Следующей задачей на пути развития системы стал вопрос ее настройки: как сделать так, чтобы работать с новой системой было удобно, а сама она была бы максимально информативной? Проблема здесь в том, что функционал системы позволяет включить множество аварийных оповещений и сигналов – при таких настройках персонал будет вынужден постоянно реагировать на них, отрабатывая соответствующие сценарии. Другой вариант: выставить недостаточное количество таких оповещений, создав риски для дежурных пропустить действительно важное событие. В этой части мы поделимся практическим опытом настройки нашей системы мониторинга работы ЦОДа. Немного теории «Собираемые системой SCADA переменные делятся на телесигнализацию и телеизмерения» –учили меня когда-то в институте. И на самом деле ничего не поменялось: телесигнализация – это состояние устройства, например, «нет аварии», «есть авария», «открыт», «закрыт» и т. д. А телеизмерение, как нетрудно догадаться, это цифровое значение какого-либо параметра, например «220 Вольт» или «10 Ампер». Состояние или значение, настроенное пользователем, при котором на экране появляется сообщение (авария), называется «уставкой». Можно настроить задержку до появления сообщения, то есть авария на экране появляется только через Х секунд (при условии, если аварийная ситуация не прекратилась раньше) или на «замораживание» сообщения на экране – в этом случае авария уже пропала, но сообщение о ней на экране сохраняется еще Х секунд. Аварии по показателю приоритетности обычно делятся на три основных типа: «Красная», «Желтая» и «Голубая». «Красные» аварии требуют немедленных действий сотрудников, «Желтые» о чем-то их предупреждают, «Голубые» чаще всего сообщают о каких-то некритичных событиях. Например, мы вывели «Голубые» аварии из сводки, которую видят дежурные, и используем их для мониторинга различных коммерческих параметров (превышение заказанной мощности). Отчеты по этим авариям направляются только менеджерам и не отвлекают дежурных. Для удобства настройки однотипного оборудования переменные в разных устройствах, но с одним именем (например, «OutputCurrent») имеют одинаковые настройки на всех устройствах системы. Если мы меняем уставку в одном месте – она меняется везде. Когда какое-то устройство требует индивидуальных настроек у требуемой переменной, мы применяем специальную отметку «Только для этого устройства». Теперь переменная стала индивидуальной для одного конкретного устройства, имеет свою уставку и не влияет на другие одноименные переменные. Дополнительно в самих устройствах есть собственные заводские уставки. Например, в PDU с завода настроено распознавание аварийной ситуации на превышение тока в 32А. В случае ее срабатывания от PDU поступит оповещение о типе аварии «Overload Alarm». И это совсем другая переменная, не связанная с переменной «OutputCurrent», настроенной в BMS. Пример заводских настроек уставок внутри PDU: Итак, мы перечислили основной функционал для настройки системы мониторинга. Как же правильно настроить это «пианино»? Давайте рассмотрим задачи по порядку. Чего мы хотим добиться Самая главная задача: любое аварийное сообщение на морде панели управления оборудования должно отображаться в системе мониторинга. Если на устройстве горит красная лампочка, а в мониторинге ничего нет, значит не все переменные включены в мониторинг или их уставки настроены неверно. Вторая задача – минимизировать ложные или неинформативные сообщения. Какие бы внимательные и ответственные дежурные у вас ни были, если перед их глазами постоянно что-то моргает, мигает и звонит, то либо они пропустят реальную аварию, утонув в море оповещений, либо отключат звук – и в итоге также пропустят оповещение об инциденте. Этап 1. Определение нужных и ненужных переменных у каждого устройства Обычно к каждому устройству идет так называемая «карта переменных», на основании которой инженером-наладчиком создается «драйвер». Его задача – «указать» системе мониторинга, в каком именно регистре получаемых данных находится нужная переменная. Например, в регистре 1 протокола опроса устройства находится информация о режиме работы двигателя «System_on_fun», а в регистре 2 – о режиме работы компрессора «Compressor_1». Количество переменных у одного устройства часто бывает больше 100. Сотрудник, изначально настраивающий систему (обычно это ИТ-инженер), не может сам решить, что здесь важно, а что нет. Как правило, все переменные добавляются в мониторинг по принципу «а вдруг пригодится». На первое время это допустимо – сотрудники службы эксплуатации могут посмотреть на реальные значения всех доступных переменных и понять, что на самом деле им нужно. Но если надолго оставить систему в этом состоянии, то мы получим следующие негативные эффекты: Лишние переменные загружают оперативную задачу системы мониторинга и увеличивают размер архива, система вынуждена обрабатывать и сохранять ненужные данные. Чем больше опрашивается переменных, тем выше вероятность сбоя опроса. Особенно это актуально для устройств, подключенных по шлейфу (например, через шлюз по протоколу MODBUS). Это приводит к получению состояний «нет данных (Н/Д)» или «обрыв связи», то есть фактически устройство периодически выпадает из мониторинга. Некоторые переменные – лишние «по умолчанию». Например, в вашей версии оборудования нет компрессора или датчика давления, но они прописаны в универсальном драйвере для всего модельного ряда оборудования и опрашиваются, добавляясь в архив, нагружая сеть и процессинг. На скриншотах приведена часть кода драйвера. Символами // указаны скрытые из опроса переменные. Также виден список переменных, отображаемых для пользователя при настройке уставок в самой BMS. Заводские уставки внутри устройств по нашему опыту на начальном этапе лучше не трогать (конечно, если они не сообщают вам уже об аварии). Однако на каждой тренировке по конкретному оборудованию следует напоминать сотрудникам о наличии уставок и в самом устройстве, и в BMS. Это в будущем поможет дежурным точно понимать, что именно является причиной аварийного сообщения. Лишние переменные в драйвере надо постепенно выявлять и скрывать из опроса, а оставшиеся разделить на те, к которым следует назначить уставки, и на те, которые сохраняются без уставок только для последующего анализа и статистики. Делать это должен не наладчик системы, а сотрудник, понимающий работу системы, которую контролирует система мониторинга, – желательно главный инженер или главный энергетик. Этап 2. Минимизация ложных и неинформативных сообщений Ложные срабатывания часто происходят из-за сбоев в опросе устройства. Если сетевая карта устройства не снабжена автономным питанием, то и сбой в опросе и реальное отключение питания будут отображаться как один тип аварии – «обрыв связи». В этом случае надо разделить оборудование на критическое (например, PDU) и обычное (например, щиты вентиляции «ЩУВ»). Для обычного оборудования можно установить задержку на сигнал «обрыв связи» (например, 300 секунд) – тогда большинство ложных обрывов будут игнорироваться. Понятно, что на критическое оборудование такую задержку ставить нельзя, поэтому если оно постоянно дает ложные сбои, то следует разбираться с физической сетью, количеством опрашиваемых переменных. Вполне возможно, что на один шлюз «повешено» очень много устройств и надо сегментировать сеть через добавление новых шлюзов. Неинформативные аварии чаще всего возникают при переходных процессах. Их нельзя назвать ложными – они на самом деле есть, но они «нормальны» при каком-то конкретном режиме работы оборудования. Самый очевидный пример – переход на ДГУ. В этом случае часть оборудования, запитанного без ИБП, «штатно» обесточивается и выдает ошибку «обрыв связи», а сами ИБП выдают целый «букет» сообщений – «нет питания на вводе», «нет питания на байпасе», «питание от АКБ» и т. п. Персонал сразу получает десятки сообщений. Для оптимизации количества сообщений при переходе на ДГУ следует: настроить на «штатно» появляющиеся во время перехода аварийные сигналы более длительные временные задержки, чем время появления питания от ДГУ. Например, установить задержку на сигнал «обрыв связи» щита вентиляции 300 секунд при штатном времени перехода на ДГУ 200 секунд. Тогда питание на ЩУВ появится раньше задержки уставки, и ситуация не будет распознана как аварийная. При это есть критически важные устройства, которые запитаны от ИБП и всегда должны быть на связи (например, PDU) – сообщения об их «дисконнекте» должны появляться без задержки. проанализировать сообщения от ИБП при переходе на ДГУ и разделить их на «нормальные» с присвоением им «желтого» типа (например, констатация факта «нет питания на вводе») и «ненормальные» («отключение батарейного автомата», которого быть не должно в любом режиме работы), с присвоением им «красного» типа. При этом отдельно записываем в инструкцию дежурным, что в случае перехода на ДГУ «желтые» аварии можно наблюдать и не квитировать (они пропадут сами после завершения штатного перехода), а «красные» немедленно устранять (их быть не должно). За один раз, полагаясь только на теорию, настроить уставки для этого «переходного» процесса очень сложно. Для успешной настройки надо несколько раз наблюдать за переходами на ДГУ в реальном времени. Например, нам потребовалось наблюдение за 4-5 переходами для приемлемой настройки новой BMS. Чтобы проанализировать внеплановый процесс перехода, мы делали запись экрана системы мониторинга, так как важно наблюдать аварийные сообщения не в архиве событий, а анализировать появление аварий в динамике оперативной сводки. Этап 3. Дополнительные советы из нашего опыта 1.На экранах дежурной смены не должно быть лишней индикации в цветах аварийных сообщений. Пример из реальной практики. Один ЦОД заказал карту температурных потоков в серверной. Это 3D модель потоков воздуха с множеством температурных данных с датчиков. Получился вид северной с потоками воздуха – где-то воздух был выделен зеленым, где-то – желтым и красным (от самого холодного к самому горячему). При этом температуры воздуха везде в пределах нормы, а цвета применены только для наглядности отображения разницы температур в разных точках. Далее этот «пестрый» вид вывели на один из мониторов в «дежурке». В итоге получилось, что инструмент, созданный для аналитики процессов, оказался перед глазами дежурных, которые «заточены» бежать к оборудованию при виде красного цвета и напрягаться при виде желтого. Наверное, дежурным объяснили, что на левом экране «красное/желтое» – это нормально, а на правом экране эти же цвета – сигнал к действию. Однако ясно, что такая практика очень серьезно увеличивает риск человеческого фактора. Логично убрать такие системы с мониторов в помещении дежурных, их должен наблюдать главный инженер для целей анализа тенденций – например, после каких-то изменений параметров воздушной среды в серверной или ввода в работу нового оборудования. 2. С осторожностью используйте SMS-оповещения. Несколько лет назад мы еще опасались плохого мобильного интернета и использовали SMS вместо мессенджеров. Один раз я случайно выставил неправильную уставку, она применилась ко всем одноименным в 100 устройствах, и подписанным на рассылку коллегам на телефоны пришло по 100 SMS-сообщений. С тех пор мы не используем SMS-рассылку. 3. Настраивайте дублирование сообщений об авариях через мессенджер. Это можно реализовать, например, через Microsoft Teams или Telegram. Сообщения об авариях будут приходить и вам, и дежурным, при этом телефон будет издавать звуки и вибрировать (чего нет при работе с системой через браузер). И не бойтесь, что сообщений будет много. По нашему опыту, за среднестатистический день работы ЦОДа приходит всего несколько десятков сообщений, и они не загружают телефоны сотрудников. То есть оборудование ЦОД и систему BMS можно настроить так, чтобы не получать сотни оповещений и при этом ничего важного не пропускать. Чтобы сообщений было меньше, включайте в рассылку только оповещения о возникновении «красных» и «желтых» аварий, то есть необходимый минимум, позволяющий держать руку на пульсе событий. 4. Группируйте сообщения в мессенджерах. Во время перехода на ДГУ или из-за комплексной аварии у вас будут запущены десятки активных аварийных ситуаций, телефон будет постоянно вибрировать от поступающих в мессенджер сообщений, не давая сделать важный звонок или открыть окно системы мониторинга. Можно настроить рассылку так, чтобы в мессенджер приходило одно общее сообщение с общим списком аварий, произошедших за последнюю минуту. На появление аварий в сводке системы BMS эта настройка не влияет (аварии появляются в сводке без задержки), а за 1 минуту задержки поступления сообщения на телефон вы ничего не пропустите, а вот сообщений на ваш телефон будет приходить в разы меньше. 5. Ярко выделяйте в интерфейсе сообщение о пропадание связи с сервером. Например, в помещении дежурных пропал интернет. Интерфейс пользователя не имеет связи с сервером и поэтому авария не появляется в сводке, тусклая надпись «сервер не доступен» может быть не замечена персоналом, сотрудники могут долго смотреть в «зеленую» панель BMS с числовыми параметрами, не подозревая о том, что она находится в офлайне. На скриншоте – пример индикации о пропадании связи с сервером BMS, при этом отображаются неактуальные параметры работы оборудования. 6.Подключайте к мониторингу как можно больше систем. Например, традиционно система пожарной сигнализации работает автономно, а ее панель висит на посту охраны. Да, по сигналу «ПОЖАР» срабатывают автоматические алгоритмы работы систем, запускается система оповещения, но о появлении сигналов «Неисправность» или «Внимание» сотрудник охраны сообщает дежурным голосом. Полноценно подключить к мониторингу такую систему очень сложно, но в такой системе легко настроить три релейных сигнала «неисправность», «внимание» и «пожар», а затем подключить их «сухими контактами» в модуль системы BMS. Тем самым снижается риск пресловутого человеческого фактора. Пример тестового сигнала «ПОЖАР» в системе BMS ЦОДа, подключенного через «сухие контакты». Подведем итоги нашей 4-серийной истории Система мониторинга дата-центра – это не просто «глаза и уши» для наблюдения за инженерными системами ЦОДа. Ее правильная работа позволяет достигать высочайшего уровня надежности через непрерывность работы площадки, а, значит, обеспечивает компании дополнительное конкурентное преимущество. Пройдя довольно трудный и длинный путь, мы получили: быструю и стабильную систему мониторинга, которая на данный момент контролирует более 2 500 устройств и обсчитывает около 10 000 виртуальных датчиков; резервирование системы на платформе облачных решений Linхdatacenter в Санкт-Петербурге и Москве; доступ к системе из любой точки мира через веб-интерфейс, с дополнительной отправкой сообщений из системы на любые мессенджеры, что позволило сократить максимальное время информирования персонала об аварии до 1 минуты; ощутимую экономию, так как система обошлась в разы дешевле аналогов, легко масштабируется и не требует платы за лицензии для устройств или пользователей; надежное решение, которое позволило нам не только улучшить собственные процессы, но и предложить новый коммерческий продукт нашим заказчикам – гибко настраиваемую и масштабируемую систему мониторинга

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

Следующей задачей на пути развития системы стал вопрос ее настройки: как сделать так, чтобы работать с новой системой было удобно, а сама она была бы максимально информативной? 

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

Другой вариант: выставить недостаточное количество таких оповещений, создав риски для дежурных пропустить действительно важное событие.

В этой части мы поделимся практическим опытом настройки нашей системы мониторинга работы ЦОДа.

Немного теории

 «Собираемые системой SCADA переменные делятся на телесигнализацию и телеизмерения» –учили меня когда-то в институте. И на самом деле ничего не поменялось: телесигнализация – это состояние устройства, например, «нет аварии», «есть авария», «открыт», «закрыт» и т. д.

А телеизмерение, как нетрудно догадаться, это цифровое значение какого-либо параметра, например «220 Вольт» или «10 Ампер».

Состояние или значение, настроенное пользователем, при котором на экране появляется сообщение (авария), называется «уставкой». Можно настроить задержку до появления сообщения, то есть авария на экране появляется только через Х секунд (при условии, если аварийная ситуация не прекратилась раньше) или на «замораживание» сообщения на экране – в этом случае авария уже пропала, но сообщение о ней на экране сохраняется еще Х секунд.

Аварии по показателю приоритетности обычно делятся на три основных типа: «Красная», «Желтая» и «Голубая».  «Красные» аварии требуют немедленных действий сотрудников, «Желтые» о чем-то их предупреждают, «Голубые» чаще всего сообщают о каких-то некритичных событиях. Например, мы вывели «Голубые» аварии из сводки, которую видят дежурные, и используем их для мониторинга различных коммерческих параметров (превышение заказанной мощности). Отчеты по этим авариям направляются только менеджерам и не отвлекают дежурных.

Для удобства настройки однотипного оборудования переменные в разных устройствах, но с одним именем (например, «OutputCurrent») имеют одинаковые настройки на всех устройствах системы. Если мы меняем уставку в одном месте – она меняется везде.

 

Когда какое-то устройство требует индивидуальных настроек у требуемой переменной, мы применяем специальную отметку «Только для этого устройства». Теперь переменная стала индивидуальной для одного конкретного устройства, имеет свою уставку и не влияет на другие одноименные переменные.

Дополнительно в самих устройствах есть собственные заводские уставки. Например, в PDU с завода настроено распознавание аварийной ситуации на превышение тока в 32А. В случае ее срабатывания от PDU поступит оповещение о типе аварии «Overload Alarm».  И это совсем другая переменная, не связанная с переменной «OutputCurrent», настроенной в BMS.

Пример заводских настроек уставок внутри PDU:

 

Итак, мы перечислили основной функционал для настройки системы мониторинга.

Как же правильно настроить это «пианино»? Давайте рассмотрим задачи по порядку.

Чего мы хотим добиться

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

Вторая задача – минимизировать ложные или неинформативные сообщения. Какие бы внимательные и ответственные дежурные у вас ни были, если перед их глазами постоянно что-то моргает, мигает и звонит, то либо они пропустят реальную аварию, утонув в море оповещений, либо отключат звук – и в итоге также пропустят оповещение об инциденте.

Этап 1. Определение нужных и ненужных переменных у каждого устройства

Обычно к каждому устройству идет так называемая «карта переменных», на основании которой инженером-наладчиком создается «драйвер». Его задача – «указать» системе мониторинга, в каком именно регистре получаемых данных находится нужная переменная. Например, в регистре 1 протокола опроса устройства находится информация о режиме работы двигателя «System_on_fun», а в регистре 2 – о режиме работы компрессора «Compressor_1».

Количество переменных у одного устройства часто бывает больше 100. Сотрудник, изначально настраивающий систему (обычно это ИТ-инженер), не может сам решить, что здесь важно, а что нет. Как правило, все переменные добавляются в мониторинг по принципу «а вдруг пригодится».

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

  • Лишние переменные загружают оперативную задачу системы мониторинга и увеличивают размер архива, система вынуждена обрабатывать и сохранять ненужные данные.
  • Чем больше опрашивается переменных, тем выше вероятность сбоя опроса. Особенно это актуально для устройств, подключенных по шлейфу (например, через шлюз по протоколу MODBUS). Это приводит к получению состояний «нет данных (Н/Д)» или «обрыв связи», то есть фактически устройство периодически выпадает из мониторинга.
  • Некоторые переменные – лишние «по умолчанию». Например, в вашей версии оборудования нет компрессора или датчика давления, но они прописаны в универсальном драйвере для всего модельного ряда оборудования и опрашиваются, добавляясь в архив, нагружая сеть и процессинг.

На скриншотах приведена часть кода драйвера. Символами // указаны скрытые из опроса переменные. Также виден список переменных, отображаемых для пользователя при настройке уставок в самой BMS.

 

Заводские уставки внутри устройств по нашему опыту на начальном этапе лучше не трогать (конечно, если они не сообщают вам уже об аварии). Однако на каждой тренировке по конкретному оборудованию следует напоминать сотрудникам о наличии уставок и в самом устройстве, и в BMS. Это в будущем поможет дежурным точно понимать, что именно является причиной аварийного сообщения.

Лишние переменные в драйвере надо постепенно выявлять и скрывать из опроса, а оставшиеся разделить на те, к которым следует назначить уставки, и на те, которые сохраняются без уставок только для последующего анализа и статистики.

Делать это должен не наладчик системы, а сотрудник, понимающий работу системы, которую контролирует система мониторинга, – желательно главный инженер или главный энергетик.

Этап 2. Минимизация ложных и неинформативных сообщений

Ложные срабатывания часто происходят из-за сбоев в опросе устройства. Если сетевая карта устройства не снабжена автономным питанием, то и сбой в опросе и реальное отключение питания будут отображаться как один тип аварии – «обрыв связи».

В этом случае надо разделить оборудование на критическое (например, PDU) и обычное (например, щиты вентиляции «ЩУВ»). Для обычного оборудования можно установить задержку на сигнал «обрыв связи» (например, 300 секунд) – тогда большинство ложных обрывов будут игнорироваться.

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

Неинформативные аварии чаще всего возникают при переходных процессах. Их нельзя назвать ложными – они на самом деле есть, но они «нормальны» при каком-то конкретном режиме работы оборудования. Самый очевидный пример – переход на ДГУ.

В этом случае часть оборудования, запитанного без ИБП, «штатно» обесточивается и выдает ошибку «обрыв связи», а сами ИБП выдают целый «букет» сообщений – «нет питания на вводе», «нет питания на байпасе», «питание от АКБ» и т. п. Персонал сразу получает десятки сообщений.

Для оптимизации количества сообщений при переходе на ДГУ следует:

  • настроить на «штатно» появляющиеся во время перехода аварийные сигналы более длительные временные задержки, чем время появления питания от ДГУ. Например, установить задержку на сигнал «обрыв связи» щита вентиляции 300 секунд при штатном времени перехода на ДГУ 200 секунд.

Тогда питание на ЩУВ появится раньше задержки уставки, и ситуация не будет распознана как аварийная. При это есть критически важные устройства, которые запитаны от ИБП и всегда должны быть на связи (например, PDU) – сообщения об их «дисконнекте» должны появляться без задержки.

  • проанализировать сообщения от ИБП при переходе на ДГУ и разделить их на «нормальные» с присвоением им «желтого» типа (например, констатация факта «нет питания на вводе») и «ненормальные» («отключение батарейного автомата», которого быть не должно в любом режиме работы), с присвоением им «красного» типа.

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

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

Например, нам потребовалось наблюдение за 4-5 переходами для приемлемой настройки новой BMS.  Чтобы проанализировать внеплановый процесс перехода, мы делали запись экрана системы мониторинга, так как важно наблюдать аварийные сообщения не в архиве событий, а анализировать появление аварий в динамике оперативной сводки.

Этап 3. Дополнительные советы из нашего опыта

1.На экранах дежурной смены не должно быть лишней индикации в цветах аварийных сообщений. 

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

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

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

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

2. С осторожностью используйте SMS-оповещения. 

Несколько лет назад мы еще опасались плохого мобильного интернета и использовали SMS вместо мессенджеров. Один раз я случайно выставил неправильную уставку, она применилась ко всем одноименным в 100 устройствах, и подписанным на рассылку коллегам на телефоны пришло по 100 SMS-сообщений. С тех пор мы не используем SMS-рассылку.

3. Настраивайте дублирование сообщений об авариях через мессенджер. 

Это можно реализовать, например, через Microsoft Teams или Telegram. Сообщения об авариях будут приходить и вам, и дежурным, при этом телефон будет издавать звуки и вибрировать (чего нет при работе с системой через браузер).

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

Чтобы сообщений было меньше, включайте в рассылку только оповещения о возникновении «красных» и «желтых» аварий, то есть необходимый минимум, позволяющий держать руку на пульсе событий.

4. Группируйте сообщения в мессенджерах. 

Во время перехода на ДГУ или из-за комплексной аварии у вас будут запущены десятки активных аварийных ситуаций, телефон будет постоянно вибрировать от поступающих в мессенджер сообщений, не давая сделать важный звонок или открыть окно системы мониторинга.

Можно настроить рассылку так, чтобы в мессенджер приходило одно общее сообщение с общим списком аварий, произошедших за последнюю минуту. На появление аварий в сводке системы BMS эта настройка не влияет (аварии появляются в сводке без задержки), а за 1 минуту задержки поступления сообщения на телефон вы ничего не пропустите, а вот сообщений на ваш телефон будет приходить в разы меньше.

5. Ярко выделяйте в интерфейсе сообщение о пропадание связи с сервером.

Например, в помещении дежурных пропал интернет. Интерфейс пользователя не имеет связи с сервером и поэтому авария не появляется в сводке, тусклая надпись «сервер не доступен» может быть не замечена персоналом, сотрудники могут долго смотреть в «зеленую» панель BMS с числовыми параметрами, не подозревая о том, что она находится в офлайне.

На скриншоте – пример индикации о пропадании связи с сервером BMS, при этом отображаются неактуальные параметры работы оборудования.

 

 

6.Подключайте к мониторингу как можно больше систем.

Например, традиционно система пожарной сигнализации работает автономно, а ее панель висит на посту охраны.

Да, по сигналу «ПОЖАР» срабатывают автоматические алгоритмы работы систем, запускается система оповещения, но о появлении сигналов «Неисправность» или «Внимание» сотрудник охраны сообщает дежурным голосом.

Полноценно подключить к мониторингу такую систему очень сложно, но в такой системе легко настроить три релейных сигнала «неисправность», «внимание» и «пожар», а затем подключить их «сухими контактами» в модуль системы BMS.

Тем самым снижается риск пресловутого человеческого фактора.  Пример тестового сигнала «ПОЖАР» в системе BMS ЦОДа, подключенного через «сухие контакты».

 

Подведем итоги нашей 4-серийной истории 

Система мониторинга дата-центра – это не просто «глаза и уши» для наблюдения за инженерными системами ЦОДа. Ее правильная работа позволяет достигать высочайшего уровня надежности через непрерывность работы площадки, а, значит, обеспечивает компании дополнительное конкурентное преимущество.

Пройдя довольно трудный и длинный путь, мы получили:

  • быструю и стабильную систему мониторинга, которая на данный момент контролирует более 2 500 устройств и обсчитывает около 10 000 виртуальных датчиков;
  • резервирование системы на платформе облачных решений Linхdatacenter в Санкт-Петербурге и Москве;
  • доступ к системе из любой точки мира через веб-интерфейс, с дополнительной отправкой сообщений из системы на любые мессенджеры, что позволило сократить максимальное время информирования персонала об аварии до 1 минуты;
  • ощутимую экономию, так как система обошлась в разы дешевле аналогов, легко масштабируется и не требует платы за лицензии для устройств или пользователей;
  • надежное решение, которое позволило нам не только улучшить собственные процессы, но и предложить новый коммерческий продукт нашим заказчикам – гибко настраиваемую и масштабируемую систему мониторинга.

Другие новости и публикации

Статья
09.08.2022
ИБ в условиях дефицита: стратегия большого перехода
Новость
01.08.2022
Linxdatacenter – в топ-10 крупнейших поставщиков услуг ЦОД
Новость
25.07.2022
Linxdatacenter запускает собственные PaaS-инструменты
Новость
20.07.2022
Петербургское облако Linxdatacenter прошло аттестацию по ...
Статья
30.06.2022
Как мы оптимизировали управление ЦОДами клиента
Новость
27.06.2022
Linxdatacenter: рынок российских облаков вырастет в 2022 ...
Новость
26.05.2022
Анна Мальми назначена региональным директором Linxdatacen...
Статья
20.05.2022
Облачный край: что происходит на российском рынке
Новость
13.05.2022
Новым генеральным директором Linxdatacenter назначен Андр...
Статья
03.05.2022
Блок на моноблок: модульная ИБП-революция в ЦОДах

Вас также могут заинтересовать

Linx Outsourcing
Аудит, модернизация и оптимизация ваших серверных мощностей
Подробнее
Аутсорсинг управления дата-центром
Linx Network
Обеспечьте отказоустойчивость и бесперебойную работу сети
Подробнее
Сетевые услуги
Linx DraaS
Аварийное восстановление ИТ-инфраструктуры. Защитите ИТ-системы уже сегодня!
Подробнее
Аварийное восстановление DRaaS

Напишите нам

Как мы оптимизировали управление ЦОДами клиента

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

Тарас Чирков, руководитель ЦОД Linxdatacenter в Санкт-Петербурге 

Константин Нагорный, главный инженер ЦОД Linxdatacenter в Санкт-Петербурге 

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

В главной роли – управление 

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

Роль надежных и производительных дата-центров в современной экономике постоянно растет вместе с требованиями к их бесперебойной работе. Однако на этом направлении существует большая системная проблема.  

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

Нет какого-то сводного канона с правилами, применимыми для любого дата-центра. Есть стандарты международной отраслевой организации Uptime Institute, но они устанавливают рамки и вектор развития, к каждому конкретному дата-центру они будут применяться по-разному.  

В масштабах страны  

На практике в России ситуация с эксплуатацией ЦОДов выглядит так.  

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

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

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

Все это выливается в ситуацию «кто во что горазд». «Разношерстный» состав команд эксплуатации из специалистов с разным бэкграундом, различные подходы к организации корпоративной архитектуры, взгляды и требования в отношении ИТ-департаментов.  

Факторов, приводящих к такому положению дел, много, один из главных – отсутствие систематизированной документации по выстраиванию эксплуатационных процессов. Есть пара вводных статей Uptime Institute, которые дают представление о проблеме и путях ее преодоления. Но дальше необходимо выстраивать систему своими силами. А на это ресурсов и компетенций хватит далеко не у каждого бизнеса.  

Между тем, даже небольшая систематизация процессов управления по лучшим отраслевым практикам всегда дает отличный результат в том, что касается повышения отказоустойчивости инженерных и ИТ-систем.  

Кейс: через тернии к относительному порядку 

Проиллюстрируем на примере реализованного проекта. К нам обратилась крупная международная компания с сетью собственных дата-центров. Запрос был на помощь в оптимизации процессов управления тремя площадками, где на серверах развернуты ИТ-системы и приложения, абсолютно критичные для бизнеса.  

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

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

И здесь началось самое интересное.  

Познай себя 

Чтобы оценить уровень работы ЦОДов с точки зрения соответствия стандартам, нужно знать точные требования бизнеса к ИТ-системам: каков уровень внутренних SLA, допустимый период простоя оборудования и т.д.  

Сразу же выяснилось – ИТ-департамент не знает, что именно хочет бизнес. Не было внутренних критериев качества сервиса, не было и понимания логики устройства собственной инфраструктуры.  

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

Не зная таких вещей, рассчитать какие-то конкретные требования к эксплуатации невозможно. Клиент осознал проблему и усилил координацию между ИТ и бизнесом, чтобы выработать внутренние требования и наладить взаимосвязи для выстраивания работы.  

Когда было достигнуто понимание архитектуры ИТ-систем, команда смогла суммировать требования к службе эксплуатации, подрядчикам и к уровню надежности оборудования.  

Улучшения в процессе 

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

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

После начала работ и знакомства со спецификой задачи клиент немного «сдал назад»: мы услышали просьбу «просто написать всю необходимую документацию», по-быстрому и без глубокого погружения в процессы.  

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

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

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

Далее последовал этап первичной поддержки работ по обновленным регламентам, который в удаленном формате продолжался один год. Затем мы перешли к тренингам и учениям – единственный путь закрепления нового материала на практике.  

Что сделано 

В процессе работ нам удалось решить несколько серьезных вопросов.  

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

Принцип «просто найти, просто понять, легко запомнить» дополнился тем, что новая информация привязывается к старому опыту и знаниям сотрудников. 

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

Но нас удивило легкомысленное отношение компании к своей ИТ-инфраструктуре: от отсутствия резервирования критичных систем до хаоса в структуре и управлении.  

За 1,5 года процессы управления инженерными системами были прокачаны до уровня, который позволил специалистам компании успешно отчитаться «за качество» перед аудиторами из головного офиса.  

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

Выводы 

В целом перспективы консалтинга в сфере операционного управления дата-центрами, по нашему мнению, самые яркие.  

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

Главная проблема здесь: многие руководители не понимают, по какому тонкому льду они идут, не уделяя этому моменту должного внимания. Человеческий фактор по-прежнему остается главным источником самых неприятных аварий и сбоев. И это нужно объяснять.  

Государственные проекты в сфере дата-центров также становятся более актуальны сейчас и требуют повышенного внимания с точки зрения эксплуатации: сфера государственных ИТ-систем растет. Здесь также потребуется разработка и ввод системы стандартизации и сертификации площадок.  

Когда требования к государственным ЦОДам в РФ на уровне законодательного акта будут сведены в стандарт, его можно будет применять и для коммерческих дата-центров, в том числе и для размещения государственных ИТ-ресурсов.  

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

Мониторинг в ЦОДе: как мы меняли старую BMS на новую

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Клиент:

БЭСТ, оператор системы денежных переводов и платежей.

Бизнес-вызов

Компания столкнулась с проблемой постоянного флага BGP-сессии с оборудованием Linxdatacenter. После изучения проблемы стало ясно, что на один из хостов в его сети происходила DDoS-атака.

Из-за распределенного характера атаки отфильтровать трафик было невозможно. Инженеры предложили решение, связанное с сокрытием хоста от внешней сети, но этот вариант не подходил заказчику. Атака прекратилась после внесения изменений в конфигурацию сервера, однако возобновилась на следующий день. Ее мощность достигла 5,5 Гбит/с, из-за чего перегружались «стыки» с интернет-провайдерами, что сказывалось на других пользователях облака Linxdatacenter. Чтобы обеспечить стабильную работу, было решено обратиться к надежному поставщику защиты от DDoS.

Решение

Чтобы обеспечить непрерывную доступность ресурсов, размещенных в облаке Linxdatacenter, весь трафик клиента был направлен через систему antiDDoS от StormWall. Атаку удалось погасить в течение получаса. Для предотвращения дальнейших кибератак все соединения сервисов клиента с интернетом были организованы через сеть StormWall.

Спасибо за ваш запрос, мы свяжемся с вами в ближайшее время!