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

News and publications

Article
09.08.2022
IS in scarcity: a big transition strategy
News
01.08.2022
Linxdatacenter is in the TOP10 of the largest DC service providers
News
25.07.2022
Linxdatacenter launches its own PaaS tools
News
20.07.2022
St. Petersburg cloud Linxdatacenter passed the certification on ...
Article
30.06.2022
How we optimized customer data center management
News
27.06.2022
Linxdatacenter: Russian Cloud Market to Grow in 2022...
News
26.05.2022
Anna Malmi has been appointed the regional director of Linxdatacenter...
Article
20.05.2022
Cloud Edge: What's Happening in the Russian Market - Linxdatacenter
News
13.05.2022
The new CEO of Linxdatacenter is Andrei...
Article
03.05.2022
Unit per monoblock: the modular UPS revolution in data centers

You may also be interested in

Linx Outsourcing
Audit, upgrade and optimize your server capacities
read more
Data-center management outsourcing
Linx Network
Ensure network resiliency and uptime
read more
Network services
Linx DraaS
Protect your IT systems today!
read more
Disaster Recovery as a Service

Write to us

How we optimized customer data center management

Data center is a complex IT and engineering object, which requires professionalism at all levels of management: from managers to technical specialists and executors of maintenance works. Here's how we helped our client put operational management in corporate data centers in order.
 

Taras Chirkov, Head of Data Center in St. Petersburg  in St. Petersburg 

Konstantin Nagorny, chief engineer of data center in St. Petersburg.  in St. Petersburg 

Data center is a complex IT and engineering object, which requires professionalism at all levels of management: from managers to technical specialists and executors of maintenance works. Here's how we helped our client put operational management in corporate data centers in order.  

Management is in the lead 

The most advanced and expensive IT equipment will not bring the expected economic benefits if proper processes of engineering systems operation in the data center, where it is located, are not established.  

The role of reliable and productive data centers in today's economy is constantly growing along with the requirements for their uninterrupted operation. However, there is a big systemic problem on this front.  

A high level of "uptime" - failure-free operation of a data center without downtime - depends very much on the engineering team that manages the site. And there is no single formalized school of data center management.  

And there is no single formalized school of data center management.    

Nationwide  

In practice, the situation with the operation of data centers in Russia is as follows.  

Data centers in the commercial segment usually have certificates confirming their management competence. Not all of them do, but the very specifics of the business model, when a provider is responsible to the client for the quality of service, money and reputation in the market, obligates them to own the subject. 

The segment of corporate data centers that serve companies' own needs lags far behind commercial data centers in terms of operational quality. The internal customer is not treated as carefully as the external customer, not every company understands the potential of well-configured management processes. 

Finally, government departmental data centers - in this regard, they are often unknown territory due to their closed nature. An international audit of such facilities is understandably impossible. Russian state standards are just being developed.  

This all translates into a "who knows what" situation. "Diverse" composition of operation teams composed of specialists with different backgrounds, different approaches to the organization of corporate architecture, different views and requirements to IT departments.  

There are many factors that lead to this state of affairs, one of the most important is the lack of systematic documentation of operational processes. There are a couple of introductory articles by Uptime Institute which give an idea of the problem and how to overcome it. But then it's necessary to build the system by your own efforts. And not every business has enough resources and competence for that.  ⠀⠀  

Meanwhile, even a small systematization of management processes according to industry best practices always yields excellent results in terms of improving the resilience of engineering and IT systems.  

Case: through thorns to the relative order 

Let's illustrate by the example of an implemented project. A large international company with its own data center network approached us. The request was for help to optimize the management processes at three sites where IT systems and business-critical applications are deployed.  

The company had recently undergone an audit of its headquarters and received a list of inconsistencies with corporate standards with orders to eliminate them. We were brought in as a consultant for this as a bearer of industry competence: we have been developing our own data center management system and have been educating on the role of quality in operational processes for several years.  

Communication with the client's team began. The specialists wanted to get a well-established system of data center engineering systems operation, documented on the processes of monitoring, maintenance and troubleshooting. All this had to ensure optimization of the infrastructure component in terms of IT equipment continuity.  

And here began the most interesting part.  

Know thyself 

To assess the level of data centers in terms of compliance with standards, you need to know the exact requirements of the business to IT systems: what is the level of internal SLA, the allowable period of equipment downtime, etc.  

It became clear right away that the IT department did not know exactly what the business wanted. There were no internal criteria of service quality, no understanding of the logic of their own infrastructure.  

Colleagues simply had no idea what the permissible downtime for IT-related operations was, what the optimal system recovery time in case of a disaster was, or how the architecture of their own applications was structured. For example, we had to figure out whether a "crash" of one of the data centers would be critical to the application, or if there were no components affecting the application.  

Without knowing such things, it is impossible to calculate any specific operational requirements. The client recognized the problem and increased coordination between IT and the business to develop internal requirements and establish relationships to align operations.  

Once an understanding of the IT systems architecture was achieved, the team was able to summarize the requirements for operations, contractors, and equipment reliability levels.  

Improvements in the process 

Our specialists traveled to sites to assess infrastructure, read existing documentation, and checked the level of compliance of data center projects with actual implementation.  

Interviews with the responsible employees and their managers became a separate area of focus. They told what and how they do in different work situations, how the key processes of engineering systems' operation are arranged.  

After starting the work and getting acquainted with the specifics of the task the client "gave up" a little: we heard the request "just to write all the necessary documentation", quickly and without deep diving into the processes.  

However, proper optimization of data center "engineering" management implies the task to teach people to properly assess the processes and write unique documentation for them based on the specifics of the object.  

It is impossible to come up with a working document for a specific maintenance area manager - unless you work with him at the site continuously for several months. Therefore this approach was rejected: We found local leaders who were willing to learn themselves and lead their subordinates.  

Having explained the algorithm of documents creation, requirements to their contents and principles of instructions ecosystem organization, for the next six months we controlled the process of detailed writing of documentation and step-by-step transition of the personnel to work in a new way. 

This was followed by a phase of initial support for work on the updated regulations, which lasted one year in a remote format. Then we moved on to training and drills - the only way to put the new material into practice.  

What's been done 

In the process, we were able to resolve several serious issues.  

First of all, we avoided double documentation, which the client's employees feared. To this end, we combined in the new regulations the regulatory requirements applied to various engineering systems as standard (electrics, cooling, access control), with industry best practices, creating a transparent documentation structure with simple and logical navigation.   

The principle of "easy to find, easy to understand, easy to remember" was complemented by the fact that the new information was linked to the old experience and knowledge of the employees. 

Next, we reshuffled the staff of service engineers: several people turned out to be completely unprepared for the change. The resistance of some was successfully overcome in the course of the project through the demonstration of benefits, but a certain percentage of employees turned out to be untrained and unresponsive to new things.  

But we were surprised by the company's frivolous attitude to its IT infrastructure: from the lack of redundancy of critical systems to the chaos in the structure and management.  

In 1.5 years the engineering systems management processes have been pumped up to the level that allowed the company's specialists to successfully report "for quality" to the auditors from the headquarters.  

With the support of the operating component development pace the company will be able to pass any existing certification of data centers from leading international agencies.  

Summary 

In general, the prospects of consulting in the field of operational management of data centers, in our opinion, are the brightest.  

The process of digitalization of the economy and the public sector is in full swing. Yes, there will be a lot of adjustments in the launch of new projects and plans for the development of old ones, but this will not change the essence - the operation should be improved at least to improve the efficiency of already built sites.  

The main problem here: many managers do not understand what thin ice they are walking on, not paying proper attention to this point. The human factor is still the main source of the most unpleasant accidents and failures. And it needs to be explained.  

Government data center projects are also becoming more relevant now and require increased attention in terms of operations: the scope of government IT systems is growing. Here, too, the development and introduction of a system of standardization and certification of sites will be required.  

When the requirements to public data centers in Russia at the level of legislation will be reduced to a standard, it can be applied to commercial data centers, including for the placement of public IT resources.  

The work in this area is ongoing, we are participating in this process in consultation with the Ministry of Digital and by building competencies for teaching courses on data center operation at the ANO Data Center. There is not much experience on such tasks in Russia, and we believe that we should share it with colleagues and clients. 

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

BEST, money transfer and payments operator

business challenge

The customer faced a technical issue with a persistent BGP session flag with Linxdatacenter hardware. We examined the problem and found out that one of customer’s hosts was under a DDoS attack.

Because of the distributed nature of the attack, traffic couldn’t be filtered effectively, and disconnecting the host from the external network wasn’t an option. The attack stopped after changes in the server configuration, but resumed the day after. A 5.5 Gbps attack overloaded the junctions with internet providers, affecting other Linx Cloud users. To mitigate the effects of the attack, we employed a dedicated DDoS protection service.

Solution

To ensure the continuous availability of resources hosted in Linx Cloud, we rerouted all the customer’s traffic through StormWall Anti-DDoS system. The attack was stopped within half an hour. To prevent future cyberattacks, we organized all connections to the customer’s resources through the StormWall network.

client:

BEST, money transfer and payments operator

business challenge

The customer faced a technical issue with a persistent BGP session flag with Linxdatacenter hardware. We examined the problem and found out that one of customer’s hosts was under a DDoS attack.

Because of the distributed nature of the attack, traffic couldn’t be filtered effectively, and disconnecting the host from the external network wasn’t an option. The attack stopped after changes in the server configuration, but resumed the day after. A 5.5 Gbps attack overloaded the junctions with internet providers, affecting other Linx Cloud users. To mitigate the effects of the attack, we employed a dedicated DDoS protection service.

Solution

To ensure the continuous availability of resources hosted in Linx Cloud, we rerouted all the customer’s traffic through StormWall Anti-DDoS system. The attack was stopped within half an hour. To prevent future cyberattacks, we organized all connections to the customer’s resources through the StormWall network.

Thank you for your inquiry, we will get back to you shortly!