Ми продовжуємо нашу розповідь про те, як ми змінювали BMS-систему в наших ЦОДах (, ). При цьому ми не просто змінили рішення одного вендора на іншого, а розробили систему з нуля під свої вимоги. На закінчення нашої історії ділимося підсумками виконаної роботи та цікавими рішеннями, які можуть бути вам корисні.
Новий інтерфейс
Тут, як кажуть, краще один раз побачити.
Стійки.
Розберемо відмінності.
- По-перше, це красиво зручно. Зверніть увагу, як легко почало відстежувати навантаження на модулі («Banks» або просто «Банки») PDU та суму паралельних навантажень парних модулів. На моделі стійки з нової BMS ми відразу бачимо, що нижні парні модулі PDU перевантажені (сумарний струм вище за допустимі 16А – «синє» повідомлення), а верхні недовантажені. У разі відключення одного з вводів все навантаження перейде на другий, і нижній модуль, що залишився під напругою, відключиться через перевантаження. Щоб не допустити такого, служба підтримки ЦОД заздалегідь попередить клієнта та надішле рекомендацію, як перерозподілити навантаження.
- Просте додавання обладнання. У новій BMS віртуальні датчики сум струмів модулів та потужності стійки вже додані до шаблонів типових стійок і створюються автоматично після додавання до стійки PDU. У старій BMS їх доводилося створювати вручну, а потім перетягувати на карту, що підвищувало ймовірність помилки через людський фактор.
- Необмежений простір для творчості. Тепер ми не маємо обмежень при створенні віртуальних датчиків. Можна будувати будь-які математичні моделі будь-яких змінних. Це означає, що ми маємо можливість створювати складні віртуальні датчики (раніше можна було лише складати значення) і краще аналізувати статистику та тенденції роботи інженерних систем. Це підвищує якість прийнятих рішень щодо настроювання систем, заміни обладнання та управління ресурсами.
- Зрозумілий інтерфейс. У новому інтерфейсі немає нагромадження значків, вентилятори крутяться, вимикачі "клацають". І найзручніше – це можливість індикації стану PDU Line A/B усередині стійок. Ми пробували зробити щось подібне в старій BMS, але кількість значків, що зливаються, на квадратний сантиметр карти змусило нас від цього відмовитися.
Тепер оку приємно дивитися:
Серверні.
Фрагмент ГРЩ.
Щит керування вентиляцією.
А ще нову BMS можна прикрасити на Новий рік 🙂
One page – порозуміння з напівслова та без ТЗ
Ми дуже давно хотіли реалізувати ще одну фішку в BMS: скомпонувати на одній сторінці основні параметри ЦОД, щоб одного погляду на екран було достатньо для оцінки стану основних систем. Однак ми не до кінця розуміли, як вона має виглядати.
Ще до початку розробки нової BMS ми з екскурсіями відвідали десяток ЦОДів у Нідерландах. Однією із цілей було побачити приклади реалізації такої сторінки.
І в жодному ЦОД нам її не показали – десь її не було, десь «прямо зараз розробляли», десь це була «велика комерційна таємниця». Тому в нашому ТЗ на створення нової BMS точного опису цієї дуже важливої для нас сторінки не було.
У результаті ми її вигадали буквально «на ходу». Саме тоді довелося віддалено консультувати колег у ЦОДі. Перегортати сторінки BMS у телефоні у пошуках розрізнених даних було дуже незручно, і фактично на серветці було накинуто першу версію Одна сторінка. Її й реалізували розробники з фото.
Наслідуючи обережні голландські колеги, не будемо демонструвати підсумковий варіант нашої головної сторінки, тим більше що кожен ЦОД унікальний і копіювати сенсу немає. Але опишемо два основні принципи її формування:
- Це таблиця, зверстана під формат вертикально розташованого екрану смартфона (або монітора, але зі збереженням вертикального розташування), з виведенням усієї важливої інформації на один екран. Над таблицею наводиться «зведення» активних інцидентів, тому розміщувати їх разом найзручніше виявилося у вертикальному форматі.
- Розташування осередків у таблиці повторює архітектуру ЦОДу (фізичну чи логічну). Ми відмовилися від розташування систем за абеткою, як хочеться на перший погляд. Послідовність відображає зорові асоціації персоналу дата-центру – начебто вони фізично моніторять усі приміщення та системи. Це полегшує пошук інформації.
По суті, тепер абсолютно всі ключові характеристики ЦОДу згруповані та представлені на одному екрані смартфона/монітора відповідального інженера та керівника, при цьому реалізовано прив'язку до фізичної та логічної топографії ЦОДу.
Ось фото тієї самої першої чернетки, хоча, звичайно, потім ця версія була переосмислена і доопрацьована.
Квітування та зведення інцидентів
Розкажемо про ще одне нове для нас поняття, яке з'явилося в результаті проекту з оновлення системи моніторингу.
Квітування - термін, що досить рідко зустрічається, який запропонував використовувати розробник нової 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