Az első részben elmondtuk, miért döntöttünk úgy, hogy a régi BMS rendszert újra cseréljük az adatközpontjainkban. És nem csupán cserélni, hanem nulláról fejleszteni az igényeinknek megfelelően. A második részben pedig arról beszélünk, hogyan kezdtük el ezt a folyamatot.
Piacelemzés
Figyelembe véve a fent említett kéréseket és a meglévő rendszer frissítésének elvetését, elkészítettük a piaci megoldások keresésére vonatkozó műszaki követelményeket, és kérdéseket küldtünk több nagyobb cégnek, amelyek kizárólag ipari SCADA rendszerek fejlesztésével foglalkoznak.
Az első válaszokból kiderült, hogy a vezető monitoring rendszerek a piacon túlnyomórészt továbbra is fizikai szervereken működnek, habár a felhőbe való migráció folyamata már megkezdődött ezen a területen. Ami a virtuális gépek tartaléképítését illeti – ezt senki nem támogatta. Sőt, az az érzésünk támadt, hogy a piacon jelentős szereplők közül senki sem mutatta be a tartaléképítés szükségességének megértését: a leggyakoribb válasz az volt, hogy „a felhő nem omlik össze”. Valójában azt ajánlották, hogy a monitoringot egy felhőben helyezzük el, amely fizikailag ugyanabban az adatközpontban található.
Itt érdemes egy kis kitérőt tenni a kiválasztási folyamatról. Az ár természetesen fontos, de bármilyen összetett projekt megvalósítása során, a beszállítókkal folytatott párbeszéd során kezdi érezni az ember, hogy ki az, aki jobban érdekelt és képes a megvalósításra.
Ez különösen szemmel látható összetett projekteknél.
A műszaki követelményekhez feltett tisztázó kérdések jellege alapján a vállalkozókat a csupán értékesítésre érdeklődők (jellemzően a standard értékesítési vezető nyomása érzékelhető) és a termék fejlesztésére érdeklődők közé lehet sorolni, akik meghallgatják és értik az ügyfelet, konstruktív módosításokat javasolnak a műszaki követelményekben még a végső választás előtt (még a reális kockázat ellenére is, hogy javítanak egy másik ajánlatán és elbukják a tendert), végül pedig készek lesznek elfogadni a professzionális kihívást és jó terméket készíteni.
Mindez arra ösztönzött minket, hogy figyelmet fordítsunk egy viszonylag kis helyi fejlesztőre – a „Szanlaj” cégcsoportra, akik azonnal reagáltak a legtöbb igényünkre, és készen álltak, hogy megvalósítsák az új BMS-re vonatkozó szükségleteinket.
Kockázatok
Míg a nagy szereplők próbálták megérteni, hogy mit is akarunk, és lassú levelezésbe bonyolódtak presales szakemberekkel, a helyi fejlesztő találkozót szervezett az irodánkban a műszaki csapatának részvételével. Ezen a találkozón a vállalkozó újra megmutatta, hogy részt kíván venni a projektben, és - ami a legfontosabb - elmagyarázta, hogyan fogják megvalósítani a kívánt rendszert.
A találkozó előtt két kockázatot láttunk, amely munkánk során egy olyan csapattal merülhetett fel, amely mögött nincs nagy nemzeti vagy nemzetközi cég erőforrása:
- A szakemberek túlértékelhették a képességeiket, és ennek következtében egyszerűen nem tudják végrehajtani az elképzeléseket, például bonyolult szoftvereket használnak, vagy kivitelezhetetlen foglalási algoritmusokat terveznek.
- A projekt megvalósítása után a projektcsapat széteshet, így a termék támogatása veszélybe kerülhet.
Ezeknek a kockázatoknak a minimalizálása érdekében meghívtuk a találkozóra a saját fejlesztő szakembereinket. A potenciális alvállalkozó munkatársait alaposan megkérdeztük arról, hogy mire épül a rendszer, hogyan tervezik a foglalások megvalósítását, valamint más kérdésekről, melyekben mi, mint üzemeltetési szolgáltatás, nem vagyunk eléggé kompetensek.
Az ítélet pozitív volt: a már meglévő BMS platform architektúrája modern, egyszerű és megbízható, továbbfejleszthető, a javasolt foglalási és szinkronizálási séma logikus és működőképes.
Az első kockázatot megoldottuk. A másodikat kizártuk, mivel az alvállalkozótól megerősítést kaptunk a kód eredeti forrása és a dokumentáció átadásának készségéről, valamint a Python programozási nyelv kiválasztásával, amely jól ismert a szakembereink számára. Ez garantálta számunkra a rendszer saját erőforrásainkkal való fenntartásának lehetőségét, anélkül, hogy bármilyen nehézségbe ütköznénk, és hosszú tanulási időszakra lenne szükség, ha a fejlesztő cég elhagyja a piacot.
A platform's additional advantage was that it was implemented in Docker containers: in this environment, the core, web interface, and database of the product function. This approach offers numerous benefits, including pre-configuration settings for the highest deployment speed compared to the 'classic' method and easy addition of new devices to the system. The 'all together' principle simplifies system implementation to the maximum: it's enough to unpack the system, and it can be used immediately.
With such a solution, it is easier to make system backups, and improvements and upgrades can be implemented in a separate environment without stopping the overall operation of the solution.
After both risks were minimized, the contractor provided a commercial proposal. It detailed all the most important parameters of the BMS system for us.
Kölcsönzés
The new BMS system was to be located in the cloud, on a virtual machine.
No hardware, no servers, and all the inconveniences and risks associated with this deployment model— the cloud solution allowed us to eliminate them forever. It was decided that the system would operate in our cloud across two data center sites in Saint Petersburg and Moscow. These are two fully functional systems working in active standby mode with access for all authorized specialists.
The two systems back each other up, ensuring complete redundancy both in computing power and data transmission channels. Additional security measures are also configured, including data and channel backups, overall virtual machine backups, and separate monthly backups of the database (the most valuable resource for management and analytics).
It should be noted that redundancy as an option for the BMS solution was specifically developed at our request. The backup scheme looked like this:
Támogatás
A critical aspect for the effective operation of the BMS solution is technical support.
It's simple here: the new system would cost us 35,000 rubles a month for SLA 'response within 8 hours', which means 35,000 x 12 / 80 = $5,250 per year. The first year is free.
Összehasonlításképpen: a régi BMS támogatása a beszállítótól évente 18 000 dollárba került, és minden újonnan hozzáadott eszköznél növekedett az összeg! Ezenkívül a cég nem biztosított dedikált menedzsert, minden interakció az értékesítési menedzserrel zajlott, aki érdeklődött irántunk, mint potenciális vásárlóra tekintettel az igények feldolgozásában.
Kevesebb pénzért teljes körű terméktámogatást kaptunk, egy olyan account managerrel, aki részt vett a termék fejlesztésében, egyetlen belépési ponttal stb. A támogatás lényegesen rugalmasabbá vált – közvetlen hozzáféréssel a fejlesztőkhöz, hogy azonnali korrekciókat végezhessünk a rendszer működésének bármely aspektusában, API integráción keresztül stb.
Frissítések
Az új BMS-ben a javasolt ajánlatban minden frissítés benne van a támogatási árcsomagban, tehát nem igényelnek külön díjat. Kivételt képez az új funkcionálás fejlesztése, amely a műszaki specifikációban szereplőn kívül esik.
A régi rendszer a beépített ingyenes szoftverek (mint például a Java) frissítéseként és a hibák javításaként is díjat számolt fel. Erről nem lehetett lemondani, frissítések hiányában a rendszer alapból "lassúbbá" vált a belső komponensek régi verziói miatt.
Természetesen nem lehetett frissíteni a szoftvert a támogatási csomag megvásárlása nélkül.
Rugalmas megközelítés
Egy másik alapvető követelmény az interfészt érintette. Azt akartuk elérni, hogy a web böngészőn keresztül bármely pontból elérhető legyen, anélkül, hogy mérnöknek kötelezően a adatközpont területén jelen kellene lennie. Ezen kívül arra törekedtünk, hogy animált interfészt hozzunk létre, hogy az infrastruktúra működésének dinamikája ábrázolhatóbb legyen a felügyelő mérnökök számára.
Az új rendszerben támogatni kellett a virtuális érzékelők működéséhez szükséges képleteket az mérnöki rendszerekben – például az elektromos teljesítmények optimális elosztása érdekében a berendezésekkel ellátott állványok között. Ehhez minden megszokott matematikai műveletet rendelkezésre kell bocsátani, amely alkalmazható az érzékelők mutatóira.
Ezután szükség volt egy SQL adatbázis elérésére, amely lehetővé teszi az eszközök működésével kapcsolatos adatok lekérdezését – nevezetesen, minden nyilvántartásra a kétezer eszköz és kétezer virtuális érzékelő monitorozásáról, amelyek körülbelül 20 ezer változót generálnak.
Szükség volt egy berendezésnyilvántartó modulra is, amely grafikai ábrázolást ad a készülékek elhelyezkedéséről minden egységben, összesítve a „vas” összsúlyát, kezelve az eszközök könyvtárát, és részletes tájékoztatást adva minden elemről.
A műszaki követelmények összehangolása és a szerződés aláírása
Abban az időben, amikor el kellett kezdeni a munkát az új rendszeren, a „nagy” cégekkel folytatott levelezés még messze volt az ajánlataik költségeinek tárgyalásától, ezért összehasonlítottuk az elkészített ajánlatot a régi BMS frissítési költségeivel (lásd. ), és ennek eredményeképpen az ajánlat árban vonzóbbnak bizonyult, és megfelelt az igényeinknek.
A választás megtörtént.
A kiválasztott vállalkozó után az ügyvédek elkezdték megfogalmazni a szerződést, míg mindkét fél technikai csapatai finomították a műszaki követelményeket. Közismert, hogy egy részletes és jól kidolgozott műszaki követelmény a bármilyen munka sikerének alapja. Minél konkrétabb a műszaki követelmény, annál kevesebb csalódás érhet, mint például az, hogy „mi nem így akartuk”.
Két példát hozok a műszaki követelmények részletével kapcsolatban:
- A felügyeleti adatközpontok jogosultsággal bírnak új eszközök hozzáadására a BMS-hez, leggyakrabban PDU-kat. A régi BMS-ben ez egy „adminisztrátori” szint volt, amely lehetővé tette az összes eszköz változóinak beállítását is, és a funkciók megosztása lehetetlen volt. Ez számunkra nem volt elfogadható. Az új platform alapváltozatában a séma hasonló volt. Azonnal jeleztük a műszaki követelményekben, hogy szeretnénk ezeket a szerepeket elkülöníteni: a beállításokat csak egy felhatalmazott munkatárs módosíthatja, de a felügyeleti csapatnak továbbra is lehetősége van az eszközök hozzáadására. Ezt a sémát fogadták el megvalósításra.
- Bármely standard BMS-ben három típikus értesítési kategória létezik: PIROS – sürgősen reagálni kell, SÁRGA – figyelemmel kísérhető, KÉK – „Információs”. Hagyományosan a „kék” értesítéseket a kereskedelmi paraméterek túllépésének figyelésére használtuk, például a kliens állvány maximális teljesítményének túllépése. Ez a típusú értesítés a mi esetünkben a menedzserek számára készült, és nem volt érdekes a üzemeltetési szolgáltatás számára, azonban a régi BMS rendszeresen elhárította az aktív események listáját, ami megnehezítette az operatív munkát. Magát a logikát és a figyelmeztetések színbeli megkülönböztetését sikeresnek találtuk és megtartottuk, azonban a műszaki leírásban kifejezetten megadtuk, hogy a „kék” értesítéseknek, anélkül, hogy a diszpécsereket elvonják, hangtalanul „szóródniuk” kell egy külön szekcióba, ahol a kereskedelmi szakemberek foglalkoznak velük.
Hasonló részletességgel írták le a grafikonok felépítési formátumait és a jelentések kiadását, a felhasználói felületek körvonalait, a megfigyelendő eszközök listáját és még sok más dolgot.
Ez egy igazán kreatív munka volt három munkacsoport részvételével – a megrendelői szolgálat, amely megfogalmazta saját követelményeit és feltételeit; mindkét fél technikai szakemberei, akiknek feladata volt e feltételek technikai dokumentációvá való átalakítása; a vállalat programozó csapata, akik a megrendelői követelményeket a kidolgozott technikai dokumentáció szerint hajtották végre… Végül néhány nem elvont követelményünket alkalmazkodtattunk a már meglévő platform funkcióihoz, míg a kivitelező egyes követelményeket kötelezően átírt a számunkra.
Két rendszer párhuzamos működése
Elérkezett a megvalósítás ideje. A gyakorlatban ez azt jelentette, hogy lehetőséget adunk a kivitelezőnek, hogy lebontja a BMS prototípusát a virtuális felhőnkben, és hálózati hozzáférést biztosítunk az összes megfigyelésre szoruló eszközhöz.
Mindeközben az új rendszer még nem volt kész a munkára. Ebben a szakaszban számunkra fontos volt a monitorozás fenntartása a régi rendszerben, és egyidejűleg hozzáférést biztosítani az eszközökhöz az új rendszer számára. Nem lehet normálisan felépíteni egy rendszert, ha nem látjuk benne az eszközöket, amelyek viszont nem választhatók le a régi rendszer megfigyeléséről.
A berendezések képesek-e egyidejűleg két rendszer általi lekérdezésre, valós tesztek nélkül nem volt világos. Volt esély arra, hogy a kettős egyidejű lekérdezés gyakori válaszhibákhoz vezet az eszközöktől, ami rengeteg elérhetetlenségi hibaüzenetet eredményez, ami viszont blokkolja a régi monitorozó rendszer működését.
A hálózati részleg virtuális útvonalakat hozott létre az új BMS prototípusa, amely a felhőben lett telepítve, és az eszközökhöz, és megkaptuk az eredményeket:
- az SNMP protokollal csatlakoztatott eszközök gyakorlatilag nem estek ki a kapcsolatból az egyidejű lekérdezések miatt,
- a modbus-TCP protokollal csatlakoztatott eszközök problémákkal küzdöttek, amelyeket a lekérdezési frekvencia ésszerű csökkentésével oldottunk meg.
Ezután elkezdtük megfigyelni, ahogy a szemünk előtt épül fel az új rendszer, amelyben már ismerős eszközök jelennek meg, de egy másik felületen – kényelmesen, gyorsan, akár telefonról is elérhetően.
Arról, hogy mi lett a végeredmény, a cikkünk harmadik részében fogunk beszámolni.
Forrás: habr.com
