Продължаваме разказа си за това как сменихме BMS системата в нашите ЦОД (, ). Не просто сменихме решението на един вендор с друго, а разработихме система от нулата по нашите изисквания. В заключение на нашата история споделяме резултатите от извършената работа и интересни решения, които могат да ви бъдат полезни.
Нов интерфейс
Тук, както казват, по-добре е да видиш веднъж.
Рейки.
Нека разгледаме разликите.
- Първо, това е красиво удобно. Обърнете внимание колко лесно стана да се следят натоварванията на модулите („Banks“ или просто „Банки“) PDU и общата сума на паралелните натоварвания на двойните модули. На модела на стелажите от новата BMS веднага виждаме, че долните двойни модули PDU са пренатоварени (общият ток над допуснатите 16А – „синьо“ известие), а горните са недонапрегнати. В случай на изключване на едно от входовете, цялото натоварване ще премине на второто, а останалият под напрежение долен модул ще се изключи поради пренатоварване. За да предотвратят това, техническата поддръжка на ЦОД предварително предупреждава клиента и изпраща препоръка за преравняване на натоварването.
- Лесно добавяне на оборудване. В новата BMS виртуалните сензори за суми на токове на модулите и мощността на стелажа вече са добавени в шаблоните на типичните стелажи и се създават автоматично след добавяне в стелажа PDU. В старата BMS те трябваше да се създават ръчно и след това да се прехвърлят на картата, което увеличаваше вероятността за грешка поради „човешкия фактор“.
- Неограничено пространство за творчество. Сега нямаме ограничения при създаването на виртуални сензори. Можем да изграждаме абсолютно всякакви математически модели на всякакви променливи. Това означава, че имаме възможност да създаваме сложни виртуални сензори (преди можехме само да сумираме стойности) и да анализираме по-добре статистиката и тенденциите в работата на инженерните системи. Това повишава качеството на вземаните решения относно настройването на системите, замяната на оборудване и управлението на ресурсите.
- Понятен интерфейс. В новия интерфейс няма претрупване с икони, вентилаторите се въртят, превключвателите „щракат“. Най-удобното е възможността за индикация на състоянието на PDU Line A/B в стелажите. Опитахме да направим нещо подобно в старата BMS, но количеството сливащи се икони на квадратен сантиметър карта ни накара да се откажем от това.
Сега е приятно за окото да се гледа:
Сървърни.
Фрагмент на ГРЩ.
Щит за управление на вентилацията.
А новата BMS може да бъде украсена за Нова година 🙂
One page – разбиране от полуслово и без ТЗ
Отдавна искахме да реализираме още една „фишка“ в BMS: да компилираме на една страница основните параметри на ЦОД, така че един поглед на екрана да е достатъчен, за да оценим състоянието на основните системи. Въпреки това, не разбирахме напълно как трябва да изглежда.
Още преди да започнем разработката на новата BMS, посетихме десетина ЦОД в Нидерландия с екскурзии. Една от целите беше да видим примери на такава страница.
И в нито един ЦОД не ни я показаха – някъде я нямаше, някъде „в момента я разработваха“, някъде това беше „голяма търговска тайна“. Затова в нашето ТЗ за създаването на новата BMS, точното описание на тази много важна за нас страница отсъстваше.
В крайна сметка я измислихме буквално „на ходу“. Точно в този момент се налагаше да консултираме дистанционно колеги от ЦОД. Прелистването на страниците на BMS на телефона в търсене на разрознени данни беше много неудобно, и всъщност на салфетка беше начертано първото предложение. One page. Така я реализираха разработчиците по снимка.
Следвайки примера на предпазливите холандски колеги, няма да демонстрираме крайния вариант на нашата главна страница, особено след като всеки ЦОД е уникален и няма смисъл от копиране. Но ще опишем два основни принципа за нейното формиране:
- Това е таблица, форматирана за вертикално разположен екран на смартфон (или монитор, но с запазване на вертикалното разположение), с показване на цялата важна информация на един екран. Над таблицата се представя „резюме“ на активните инциденти, затова е най-удобно да се разместят в вертикален формат.
- Разположението на клетките в таблицата повтаря архитектурата на ЦОД (физическа или логическа). Отказахме се от подреждането на системите по азбучен ред, както би се искало на пръв поглед. Последователността отразява визуалните асоциации на персонала на дата-центъра – все едно те физически наблюдават всички помещения и системи. Това опростява търсенето на информация.
Всъщност, сега всички ключови характеристики на ЦОД-а са групирани и представени на един екран на смартфона/монитора на отговорния инженер и ръководител, като е реализирана връзка с физическата и логическа топология на ЦОД-а.
Ето снимка на същия първи черновик, макар че след това тази версия беше преосмислена и доработена.
Квитиране и резюме на инциденти
Ще разкажем за още един нов за нас термин, появил се в резултат на проекта за обновление на системата за мониторинг.
Квитиране – сравнително рядко срещан термин, който предложи да се използва разработчикът на новата BMS. Той означава потвърждение, че операторът е видял инцидента, потвърдил го е и поел отговорност за неговото решаване.
Думата се наложи и сега ние "квитиране" на инциденти.
Алгоритъмът, заложен в базовата версия на новата BMS, не ни удовлетворяваше. На практика това бяха коментари към дневника на събитията, тоест отстранените инциденти не изчезваха от дневника, а приетите ("квитирани") не се разграничават от новите.
В крайна сметка беше разработено прозорче, наречено "резюме", в което:
- Се показват само активни инциденти и устройства в сервизен режим (без търговски "сини" уведомления).
- Ясно се разграничават НОВИ и ПРИЕТИ инциденти.
- Посочено е кой е приел инцидента.
Алгоритъмът на работа на дежурните в новата BMS е следният:
- Новите инциденти попадат в резюмето и чакат квитиране. Те не могат да остават в този раздел дълго, дежурният, отговорен за оборудването, трябва веднага да поеме инцидента.
- Служителят поема инцидента, като натисне отметката вдясно. Тъй като всичките служители имат уникални акаунти – автоматично се показва кой е поел инцидента. При необходимост може да се остави коментар.
- Инцидентът преминава в раздела "Квитирани", останалите дежурни и ръководителят разбират, че инцидентът се обработва от отговорния служител.
Пример на прозореца за резюме с ново и вече квитирано съобщение.
Свързвайки прозореца за резюме с таблицата One page, получихме пълноценен главен екран на системата BMS, на който веднага може да се види:
- състоянието на основните системи на ЦОД-а;
- наличието на нови необработени инциденти;
- наличието на приети инциденти и данни за това кой конкретно ги решава.
Достъп през браузър и известия на телефона
Уеб интерфейсът, достъпен от всяко устройство от всяка точка на света, е силен контраст с «дебелия» клиент, напълно затворен за външни потребители.
Старият подход носеше със себе си комплекс от неудобства, от проблеми в организацията на дистанционната работа на служителите по мониторинг до необходимостта от инсталиране на «дебели» клиенти от дистрибуции на работните места на персонала в ЦОД.
Сега всяка страница в BMS има уникален адрес, което позволява споделяне не само на директния адрес на страницата или устройството, но и на връзки към уникални графики/отчети.
Достъпът до системата сега се осъществява чрез LDAP аутентикация през Active Directory, което увеличава нейното ниво на защита.
Мобилността днес е ключов фактор за качествената работа на дежурните инженери. Освен контрол на мониторинга в помещението на дежурната смяна, инженерите извършват обходи, изпълняват текущи задачи извън «дежурката» и, благодарение на оптимизирания за мобилен екран главен екран на BMS, не губят контрол над случващото се в машинните зали нито за миг.
Качеството на контрола се повишава и благодарение на функционалността на работните чатове. Те ускоряват работните процеси, позволявайки «прикачване» на кореспонденцията на дежурните инженери към BMS. Например, ние използваме приложението Teams, което позволява да водим вътрешна кореспонденция и да получаваме на телефона си всички съобщения от BMS под формата на изскачащи Push известия, което освобождава дежурния от необходимостта постоянно да гледа в екрана на телефона.
Push известие на екрана на смартфона.
Така известията изглеждат в приложението Teams.
В същото време изскачащите известия са настроени само за съобщения за възникнали инциденти, като по този начин се минимизира разсейващият фактор. Персоналът знае: ако на екрана на смартфона се появи Push известие от Teams, трябва да се влезе в страницата на BMS и да се приеме инцидента. Съобщенията за разрешаване на инциденти се проследяват вече на страницата на BMS.
На снимката е интерфейсът на BMS в смартфона.
В обобщение
При цена за обновление на BMS от нашия стар доставчик, която е сравнима с разработването на нова система от нулата (около $100 000), разликата в функционалността на продуктите се оказа колосална. Получихме гъвкава система, оптимизирана за нашите бизнес нужди и процеси. Също така постигнахме значителни икономии в текущите разходи за поддръжка и ъпгрейд на системата.
Но, разбира се, имаше и трудности.
- На първо място, недооценихме обема на измененията, които трябваше да бъдат направени в основната версия на новата BMS и не успяхме да се вместим в предварително договорените срокове. За нас това не представляваше критичен проблем, тъй като до последно се опасявахме и работехме на старата система, а процесът беше творчески, сложен и поради това понякога протичаше по-бавно от очакваното. Освен това винаги виждахме, че нашият разработчик полага максимални усилия за постигане на най-добрия резултат. Но всъщност историята се оказа много дълга и нашите ключови специалисти вложиха значително повече усилия и време, отколкото бяха планирали.
- На второ място, ни бяха необходими няколко етапа на тестване, за да отстраним алгоритъма за резервиране на виртуални машини и канали за комуникация. Първоначално имаше проблеми и от страна на системата BMS, и от страна на настройката на виртуалните машини и мрежата. Тази отладка също отне време. За щастие, на изпълнителя беше предоставена тестова площадка под формата на облачен сервиз, където първоначално бяха тествани всички настройки и нововъведения.
- На трето място, крайната система се оказа по-сложна за редактиране от крайния потребител. Ако преди картата представляваше подложка (графичен файл) и значки, които беше лесно да се променят или преместят, сега това е сложен графичен интерфейс с анимация, изискващ определени умения за редактиране.
Радикалното обновление на нашата система BMS вече днес може да се нарече един от най-важните проекти на миналата година, който сериозно ще повлияе на качеството на оперативното управление на нашите площадки в бъдеще.
Старият желязен сървър не беше изхвърлен, а „облегчен“: почистихме го от хилядите „търговски“ виртуални датчици и PDU и оставихме в него само няколко десетки от най-критичните устройства, като ДГУ, ИБП, климатици, помпи, датчици за течове и температура. В такъв режим скоростта му се възвърна и той може да служи като „резерв на резервите“. Между другото, след премахването на PDU от старото BMS освободихме около 1000 вече ненужни лиценза, случайно не знаете какво да правим с тях?
Източник: habr.com
