У першій частині ми розповіли, чому вирішили поміняти стару BMS-систему в наших ЦОДах на нову. І не просто змінити, а розробити з нуля під свої вимоги. У другій частині розповідаємо, як ми це робили.
Аналіз ринку
З урахуванням описаних у побажань та рішення відмовитися від оновлення існуючої системи ми написали ТЗ для пошуку рішення на ринку та зробили запити до кількох великих компаній, які займаються лише створенням промислових систем SCADA.
Перші ж відповіді від них показали, що лідери ринку систем моніторингу переважно продовжують працювати на залізних серверах, хоча процес міграції до хмар у цьому сегменті вже розпочався. Щодо резервування віртуальних машин – цю опцію не підтримував ніхто. Більше того, складалося відчуття, що ніхто з помітних на ринку розробників не продемонстрував навіть розуміння необхідності резервування: «хмара не падає» була найчастіша відповідь. Фактично нам пропонували розмістити моніторинг ЦОДу у хмарі, що фізично перебуває у цьому ж ЦОДі.
Тут треба зробити невеликий відступ про процес вибору підрядника. Ціна, звичайно, має значення, але під час будь-якого тендеру на реалізацію складного проекту, на стадії діалогу з постачальниками ти починаєш відчувати, хто з кандидатів більш зацікавлений та здатний його реалізувати.
Це особливо помітно на складних проектах.
За характером уточнюючих питань до ТЗ можна розділити підрядників на зацікавлених просто продати (відчувається стандартний натиск менеджера з продажу) та на зацікавлених у тому, щоб розробити продукт, почувши та зрозумівши замовника, внести конструктивні правки до ТЗ ще до фінального вибору (навіть попри реальний ризик покращити чуже ТЗ і програти тендер), зрештою просто готові прийняти професійний виклик і зробити хороший продукт.
Все це змусило нас звернути увагу на відносно невеликого локального розробника – групу компаній «Санлайн», котрий відгукнувся на більшість наших вимог одразу і був готовий реалізувати всі потреби щодо нової BMS.
Ризики
Поки великі гравці намагалися зрозуміти, що ми хочемо, і вели з нами неквапливу листування із залученням фахівців рівня пресейл, локальний девелопер призначив зустріч у нашому офісі за участю своєї технічної команди. На цій зустрічі підрядник ще раз продемонстрував бажання брати участь у проекті та – головне – пояснив, як необхідна система буде реалізована.
Перед зустріччю ми бачили два ризики роботи з командою, яка не має за спиною ресурсу великої національної чи міжнародної компанії:
- Фахівці могли переоцінити свої можливості і в результаті просто не впоратися, наприклад, використовуватимуть складний софт або спроектують нездійсненні алгоритми резервування.
- Після реалізації проекту команда проекту може розпастись і, отже, підтримка продукту опиниться під загрозою.
Щоб мінімізувати ці ризики, ми запросили на зустріч своїх фахівців з розробки. Співробітники потенційного підрядника були ретельно опитані щодо того, на чому будується система, як планується реалізовувати резервування і з інших питань, у яких ми, як служба експлуатації, недостатньо компетентні.
Вердикт був позитивним: архітектура наявної вже платформи BMS сучасна, проста і надійна, може бути доопрацьована, запропонована схема резервування та синхронізації є логічною і працездатною.
З першим ризиком упоралися. Другий виключили, отримавши від підрядника підтвердження про готовність передати нам вихідні коди системи та документації, а також обравши мову програмування Python, добре знайому нашим фахівцям. Це гарантувало нам можливість підтримувати систему самотужки без будь-яких труднощів та тривалого періоду навчання співробітників у разі відходу компанії-розробника з ринку.
Додатковим плюсом платформи було те, що вона була реалізована в контейнерах Docker: в цьому середовищі функціонують ядро, веб-інтерфейс і БД продукту. Такий підхід дає безліч переваг, включаючи попереднє встановлення налаштувань для високої швидкості розгортання рішення в порівнянні з «класикою» і просте додавання в систему нових пристроїв. Принцип «все разом» максимально полегшує використання системи: досить розпакувати систему і можна відразу її експлуатувати.
З таким рішенням простіше робити копії системи, а вдосконалити її та реалізовувати апгрейди можна в окремому середовищі, без зупинення роботи рішення загалом.
Після того, як обидва ризики були мінімізовані, підрядник надав КП. У ньому були опрацьовані всі найважливіші нам параметри системи BMS.
Резервування
Нова BMS-система повинна була знаходитись у хмарі, на віртуальній машині.
Жодного заліза, жодних серверів і всіх пов'язаних з цією моделлю розгортання незручностей та ризиків – хмарне рішення дозволяло нам позбутися їх назавжди. Було вирішено, що система працюватиме в нашій хмарі на двох майданчиках ЦОД у Санкт-Петербурзі та Москві. Це дві повністю функціональні системи, що працюють у режимі active standby з доступом для всіх авторизованих спеціалістів.
Дві системи страхують одна одну, забезпечуючи повний резерв і за обчислювальними потужностями, і каналами передачі даних. Також налаштовані додаткові заходи безпеки, включаючи резервне копіювання даних та каналів, систем, віртуальних машин загалом, та окреме резервне копіювання БД раз на місяць (найцінніший ресурс у перспективі управління та аналізу).
Зазначимо, що резервування як опція BMS-рішення було розроблено спеціально для нашого запиту. Сама схема резервування виглядала так:
Підтримка
Найважливіший момент для ефективної експлуатації BMS-рішення – техпідтримка.
Тут все просто: нова система коштувала б нам за цим показником 35 000 руб. на місяць за SLA «реакція протягом 8 годин», тобто 35 000 х 12/80 = $5 250 на рік. Перший рік – безкоштовно.
Для порівняння: підтримка старої BMS від вендора коштувала $18 000 доларів на рік зі збільшенням суми за кожен новий доданий пристрій! При цьому виділеного менеджера компанія не надавала, вся взаємодія відбувалася через менеджера з продажу, який зацікавлений у нас як потенційного покупця з відповідним акцентом в обробці запитів.
За менші гроші ми отримали повноцінну підтримку продукту, з аккаунт-менеджером, який брав участь у розробці продукту, з єдиною точкою входу тощо. Підтримка ставала значно гнучкішою – завдяки прямому доступу до розробників для оперативних коригувань з будь-яких аспектів роботи системи, інтеграції через API тощо.
Оновлення
За запропонованим КП у новій BMS всі оновлення включені у вартість підтримки, тобто. не вимагають додаткової оплати. Виняток становить розробка додаткової функціональності, понад ту, що вказана у ТЗ.
Стара система передбачала оплату як оновлення вбудованого безкоштовного ПЗ (типу Java), і за виправлення помилок. Відмовитися від цього було не можна, за відсутності оновлень система загалом «гальмувала» через старі версії внутрішніх компонентів.
І, само собою, не можна було оновити програмне забезпечення без покупки пакета підтримки.
Гнучкий підхід
Ще одна важлива вимога стосувалася інтерфейсу. Ми хотіли забезпечити доступ до нього через веб-браузер з будь-якої точки без обов'язкової присутності інженера на території ЦОДу. Крім того, ми прагнули створити анімований інтерфейс, щоб динаміка функціонування інфраструктури була наочнішою для чергових інженерів.
Також у новій системі потрібно було забезпечити підтримку формул для розрахунку роботи віртуальних датчиків в інженерних системах – наприклад, для оптимального розподілу електричних потужностей по стійках з обладнанням. Для цього потрібно мати у своєму розпорядженні всі звичні математичні операції, які застосовуються до показників датчиків.
Далі, був потрібний доступ до бази даних SQL з можливістю брати з неї потрібні дані про роботу обладнання - а саме, всі записи про моніторинг двох тисяч пристроїв і дві тисячі віртуальних датчиків, що генерують приблизно 20 тисяч змінних.
Потрібен був також модуль обліку обладнання у стійці, що дає графічне уявлення розташування пристроїв у кожному юніті з підрахунком загальної ваги «заліза», веденням бібліотеки пристроїв та детальною інформацією про кожен елемент.
Погодження ТЗ та підписання договору
На той момент, коли було необхідно розпочинати роботу над новою системою, листування з «великими» компаніями все ще було дуже далеким від обговорення вартості їхніх пропозицій, тому ми порівняли отримане КП із витратами на оновлення старої БМС (див. ), і в результаті воно виявилося більш привабливим за ціною та відповідним нашим вимогам.
Вибір було зроблено.
Після вибору підрядника юристи почали укладати договір, а технічні команди з обох боків шліфувати ТЗ. Як відомо, докладне та грамотне ТЗ – це основа успіху будь-яких робіт. Що більше конкретики у ТЗ, то менше розчарувань на кшталт «а ми хотіли не так».
Наведу два приклади рівня деталізації вимог у ТЗ:
- Чергові ЦОД наділені повноваженнями додавати до BMS нові пристрої, найчастіше це PDU. У старій BMS це був рівень «адміністратора», що дозволяв навіть змінювати уставки змінних всіх пристроїв, і розділити функції було неможливо. Нас це не влаштовувало. У базовій версії нової платформи схема була аналогічною. Ми одразу вказали у ТЗ, що хочемо розділити ці ролі: уставки має змінювати лише уповноважений співробітник, але чергові повинні й надалі мати можливість додавати пристрої. Ця схема і була прийнята до реалізації.
- У будь-якій стандартній BMS є три типові категорії сповіщень: ЧЕРВОНА – треба негайно реагувати, ЖОВТА – можна спостерігати, СИНЯ – «Інформаційна». Ми традиційно використовували "сині" повідомлення для моніторингу перевищення комерційних параметрів, наприклад, перевищення ліміту потужності стійки клієнта. Цей тип повідомлень у нашому випадку був призначений для менеджерів і не був цікавий службі експлуатації, але у старій BMS регулярно засмічував список активних інцидентів та заважав оперативній роботі. Саму логіку та колірну диференціацію штанів повідомлень ми порахували вдалою та зберегли, однак у ТЗ спеціально вказали, що «сині» повідомлення мають, не відволікаючи чергових, беззвучно «сипатися» в окремий розділ, де ними займатимуться комерційні фахівці.
З аналогічним ступенем деталізації були прописані формати побудови графіків та виведення звітів, обриси інтерфейсів, перелік пристроїв, які треба було моніторити та ще багато інших речей.
Це була по-справжньому творча робота трьох робочих груп – служби замовника, яка диктувала свої вимоги та умови; технічних фахівців з обох сторін, завдання яких входило перетворення цих умов на технічну документацію; команди програмістів підрядника, які реалізовували вимоги замовника щодо розробленої технічної документації… У результаті щось із наших непринципових вимог ми адаптували під функціонал платформи, що вже є, щось підрядник зобов'язався дописати під нас.
Паралельна робота двох систем
Настав час реалізації. На практиці це означало, що ми даємо підряднику можливість розгорнути прототип BMS у нашій віртуальній хмарі та надаємо мережевий доступ до всіх пристроїв, які потребують моніторингу.
У цьому нова система ще була готова до роботи. На даному етапі для нас було важливо зберегти моніторинг у старій системі та одночасно дати доступ до пристроїв нової системи. Неможливо нормально побудувати систему, не бачачи у ній пристроїв, які у свою чергу не можна відключити від моніторингу старою системою.
Чи витримають пристрої одночасне опитування двома системами, було очевидно без реальних випробувань. Існувала ймовірність, що подвійне одночасне опитування призведе до частих відмов у відповідях від пристроїв і ми отримаємо безліч помилок щодо недоступності пристроїв, що заблокує роботу старої системи моніторингу.
Мережевий відділ прокинув віртуальні маршрути від прототипу нової BMS, розгорнутої у хмарі, до пристроїв, і ми отримали результати:
- пристрої, підключені за протоколом SNMP, практично не випадали в дисконнект із-за одночасних звернень,
- пристрої, підключені через шлюзи за протоколами modbas-TCP, мали проблеми, вирішені розумним зниженням частоти їх опитування.
А далі ми почали спостерігати, як на наших очах будується нова система, в ній з'являються вже знайомі нам пристрої, але в іншому інтерфейсі - зручному, швидкому, навіть з телефону.
Про те, що вийшло, ми розповімо в третій частині нашої статті.
Джерело: habr.com