V prvej časti sme sa zmienili o tom, prečo sme sa rozhodli vymeniť starý systém BMS v našich dátových centrách za nový. A nie len ho vymeniť, ale vyvinúť ho od nuly podľa našich požiadaviek. V druhej časti sa podelíme o to, ako sme to realizovali.
Analýza trhu
S prihliadnutím na uvedené v požiadavkách a rozhodnutí vzdať sa aktualizácie existujúceho systému sme napísali technické zadanie na hľadanie riešenia na trhu a zaslali sme dopyty niekoľkým veľkým spoločnostiam, ktoré sa zaoberajú iba vytváraním priemyselných systémov SCADA.
Prvé odpovede od nich ukázali, že lídri trhu monitorovacích systémov prevažne naďalej pracujú na fyzických serveroch, hoci proces migrácie do cloudu v tomto segmente už začal. Pokiaľ ide o zálohovanie virtuálnych strojov – túto možnosť nikto nepodporoval. Navyše sa zdalo, že žiadny z významných vývojárov na trhu ani neprezentoval pochopenie potreby zálohovania: "veď cloud predsa neklesá" bol najčastejší odpoveď. Fakticky nám ponúkali umiestniť monitoring dátového centra v cloude, ktorý sa fyzicky nachádzal v tomto istom dátovom centre.
Je potrebné urobiť malé odbočenie k procesu výberu dodávateľa. Cena, samozrejme, má význam, avšak počas akéhokoľvek tendra na realizáciu komplexného projektu, v štádiu dialógu s dodávateľmi, začneš cítiť, ktorý z kandidátov je viac zainteresovaný a schopný ho zrealizovať.
To je obzvlášť viditeľné pri komplexných projektoch.
Na základe povahy upresňujúcich otázok k technickému zadaniu môžeme dodávateľov rozdeliť na tých, ktorí majú záujem len predávať (pocit štandardného tlaku predajného manažéra) a na tých, ktorých zaujíma vyvinúť produkt, vypočuť a pochopiť zákazníka, vykonať konštruktívne úpravy v technickom zadaní ešte pred konečným výberom (aj napriek skutočnému riziku zlepšiť cudzie technické zadanie a prehrať tender), a nakoniec sú jednoducho pripravení prijať profesionálnu výzvu a vytvoriť kvalitný produkt.
To všetko nás prinútilo venovať pozornosť relatívne malému lokálnemu vývojárovi – skupine spoločností „Sanline“, ktorá reagovala na väčšinu našich požiadaviek ihneď a bola pripravená realizovať všetky potreby týkajúce sa nového systému BMS.
Riziká
Kým sa veľkí hráči snažili pochopiť, čo vlastne chceme, a viedli s nami pomalú korešpondenciu s prítomnosťou špecialistov na úrovni presale, miestny developer zorganizoval stretnutie v našej kancelárii s účasťou svojho technického tímu. Na tomto stretnutí dodávateľ ešte raz demonštroval ochotu zúčastniť sa projektu a – čo je najdôležitejšie – vysvetlil, ako bude požadovaný systém realizovaný.
Pred stretnutím sme identifikovali dva riziká spojené s prácou tímu, ktorý nemá za sebou zdroje veľkej národnej alebo medzinárodnej spoločnosti:
- Odborníci mohli preceňovať svoje schopnosti a v dôsledku toho sa jednoducho nezvládnu, napríklad by mohli používať zložitý softvér alebo navrhnúť nevykonateľné algoritmy zálohovania.
- Po realizácii projektu sa projektový tím môže rozpadnúť a, tým pádom, podpora produktu bude ohrozená.
Aby sme minimalizovali tieto riziká, pozvali sme na stretnutie našich vlastných odborníkov na vývoj. Zamestnanci potenciálneho dodávateľa boli dôkladne vyšetrovaní na tému, na čom je systém založený, ako sa plánuje realizovať zálohovanie a na iné otázky, v ktorých my, ako prevádzková služba, nie sme dostatočne kompetentní.
Verdikt bol pozitívny: architektúra existujúcej platformy BMS je moderná, jednoduchá a spoľahlivá, môže byť doplnená, navrhnutý plán zálohovania a synchronizácie je logický a funkčný.
S prvým rizikom sme sa vysporiadali. Druhé sme vylúčili, keď sme od dodávateľa dostali potvrdenie o ochote odovzdať nám zdrojové kódy systému a dokumentáciu, a tiež výber programovacieho jazyka Python, ktorý je našim odborníkom veľmi známy. To nám zaručilo možnosť udržiavať systém vlastnými silami bez akýchkoľvek ťažkostí a dlhého obdobia školenia zamestnancov v prípade, že by spoločnosť vyvíjajúca softvér opustila trh.
Ďalšou výhodou platformy bolo to, že bola implementovaná v Docker kontajneroch: v tomto prostredí fungujú jadro, webové rozhranie a databáza produktu. Takýto prístup prináša množstvo výhod, vrátane prednastavenia nastavení pre maximálnu rýchlosť nasadenia riešenia v porovnaní s "klasikou" a jednoduchého pridávania nových zariadení do systému. Princíp „všetko spolu“ maximálne zjednodušuje zavedenie systému: stačí rozbaliť systém a môžete ho okamžite prevádzkovať.
S takýmto riešením je jednoduchšie robiť kópie systému, a jeho vylepšovanie a realizácia aktualizácií je možné v samostatnom prostredí, bez zastavenia chodu riešenia ako celku.
Po tom, ako boli minimalizované oba riziká, dodávateľ predstavil cenovú ponuku. V tej boli prebrané všetky najdôležitejšie parametre systému BMS, ktoré nás zaujímali.
Zálohovanie
Nový systém BMS mal byť umiestnený v cloude, na virtuálnom stroji.
Žiadny hardvér, žiadne servery a všetky s týmto modelom nasadenia spojené nepríjemnosti a riziká – cloudové riešenie nám umožnilo zbaviť sa ich navždy. Bolo rozhodnuté, že systém bude fungovať v našom cloude na dvoch lokalitách dátového centra v Petrohrade a Moskve. Ide o dve plne funkčné systémy pracujúce v režime active standby s prístupom pre všetkých autorizovaných špecialistov.
Oba systémy sa vzájomne poistia, poskytujúc plnú rezervu ako na výpočtových kapacitách, tak aj na prenosových kanáloch. Taktiež sú nastavené ďalšie bezpečnostné opatrenia, vrátane zálohovania dát a kanálov, systémov, virtuálnych strojov ako celku, a samostatného mesačného zálohovania databázy (najcennejší zdroj z pohľadu správy a analýzy).
Je dôležité poznamenať, že zálohovanie ako možnosť BMS riešenia bolo vyvinuté špeciálne na našu žiadosť. Samotná schéma zálohovania vyzerala takto:
Podpora
Najdôležitejší aspekt pre efektívnu prevádzku BMS riešenia – technická podpora.
Tu je to jednoduché: nový systém by nás z tohto pohľadu stál 35 000 rubľov mesačne za SLA „reakcia do 8 hodín“, teda 35 000 x 12 / 80 = $5 250 ročne. Prvý rok – zdarma.
Na porovnanie: podpora starej BMS od dodávateľa stála 18 000 dolárov ročne, pričom sa suma zvyšovala s každým novým pridaným zariadením! Spoločnosť však neposkytla žiadneho produktového manažéra, všetka komunikácia prebiehala cez obchodného manažéra, ktorý mal záujem o nás ako o potenciálneho zákazníka s príslušným dôrazom na spracovanie žiadostí.
Za nižšie peniaze sme získali komplexnú podporu produktu s účtom manažéra, ktorý by sa podieľal na vývoji produktu, so zjednoteným kontaktným miestom atď. Podpora sa stala podstatne flexibilnejšou - vďaka priamemu prístupu k vývojárom na rýchle úpravy akýchkoľvek aspektov fungovania systému, integrácii cez API atď.
Aktualizácie
Podľa navrhnutého rozpočtu v novej BMS sú všetky aktualizácie zahrnuté v cene podpory, t.j. nevyžadujú dodatočnú platbu. Výnimku tvorí vývoj dodatočnej funkčnosti nad rámec toho, čo je uvedené v technickej špecifikácii.
Predchádzajúci systém predpokladal platbu za aktualizáciu zabudovaného bezplatného softvéru (napríklad Java), ako aj za opravu chýb. Odmietnuť to nebolo možné, bez aktualizácií sa systém celkovo "spomaľoval" kvôli starým verziám interných komponentov.
A, samozrejme, nebolo možné aktualizovať softvér bez zakúpenia podporného balíka.
Flexibilný prístup
Ďalšou zásadnou požiadavkou sa týkala rozhrania. Chceli sme zabezpečiť prístup k nemu cez webový prehliadač z akéhokoľvek miesta, bez nutnej prítomnosti inžiniera na území dátového centra. Okrem toho sme sa snažili vytvoriť animované rozhranie, aby bola dynamika fungovania infraštruktúry jasnejšia pre dispečerov.
Rovnako v novom systéme bolo potrebné zabezpečiť podporu vzorcov na výpočet práce virtuálnych snímačov v inžinierskych systémoch – napríklad na optimálne rozdelenie elektrických výkonov medzi stojanmi s vybavením. Na to je potrebné mať k dispozícii všetky známe matematické operácie použiteľné na ukazovatele snímačov.
Ďalej bol potrebný prístup k databáze SQL, aby sme mohli získavať potrebné údaje o prevádzke zariadení – konkrétne všetky záznamy o monitorovaní dvoch tisíc zariadení a dvoch tisíc virtuálnych senzorov, generujúcich približne 20 tisíc premenných.
Potrebný bol aj modul sledovania zariadení v stojane, ktorý poskytoval grafické znázornenie umiestnenia zariadení v každej jednotke s počítaním celkovej hmotnosti «hardvéru», vedením knižnice zariadení a podrobnými informáciami o každom prvku.
Schválenie technickej správy a podpis zmluvy
V čase, keď bolo potrebné začať pracovať na novom systéme, bola komunikácia s "veľkými" spoločnosťami stále veľmi ďaleko od diskusie o cenách ich ponúk, preto sme porovnali prijatú cenovú ponuku so nákladmi na aktualizáciu starej BMS (pozri ), a nakoniec sa ukázalo, že je cenovo atraktívnejšia a vyhovuje našim požiadavkám.
Voľba bola urobená.
Po výbere dodávateľa začali právnici pripravovať zmluvu, zatiaľ čo technické tímy z oboch strán zdokonaľovali technickú správu. Ako je známe, podrobná a správna technická správa je základom úspechu akýchkoľvek prác. Čím viac konkrétnosti v technickej správe, tým menej sklamania ako „my sme to nechceli takto“.
Uvediem dva príklady úrovne detailnosti požiadaviek v technickej správe:
- Dohľadové dátové centrá majú pravomoci pridávať do BMS nové zariadenia, najčastejšie ide o PDU. V starej BMS to bol úroveň „administrátora“, umožňujúca okrem iného aj zmenu nastavení premenných všetkých zariadení, a rozdelenie funkcií nebolo možné. To nás neuspokojovalo. V existujúcej základnej verzii novej platformy bola schéma podobná. Okamžite sme uviedli v technickej správe, že chceme tieto role rozdeliť: nastavenia by mal meniť iba oprávnený zamestnanec, ale dohľadní by mali aj naďalej mať možnosť pridávať zariadenia. Táto schéma bola prijatá na realizáciu.
- V každej štandardnej BMS existujú tri typové kategórie upozornení: ČERVENÁ – je potrebné okamžite reagovať, ŽLTÁ – je možné sledovať, MODRÁ – „Informačná“. Tradične sme využívali „modré“ upozornenia na monitorovanie prekročenia obchodných parametrov, napríklad prekročenie limitu výkonu stojana klienta. Tento typ upozornení bol určený pre manažérov a nebol zaujímavý pre prevádzkovú službu, ale v starej BMS pravidelne zanášal zoznam aktívnych incidentov a narúšal operatívnu prácu. Samú logiku a farebnú diferenciáciu upozornení sme považovali za úspešnú a zachovali sme ju, avšak v technickej špecifikácii sme špeciálne uviedli, že „modré“ upozornenia by mali, aby neodvádzali pozornosť dozorujúceho, bezhlučne „kvapkať“ do samostatnej sekcie, kde sa im budú venovať obchodní špecialisti.
S rovnakou miera podrobností boli definované formáty vytvárania grafov a výstupov správ, obrysy rozhraní, zoznam prístrojov, ktoré sa mali monitorovať, a množstvo ďalších vecí.
To bola naozaj tvorivá práca troch pracovných skupín – služba zákazníka, ktorá diktovala svoje požiadavky a podmienky; technickí odborníci z oboch strán, ktorých úlohou bolo premeniť tieto podmienky na technickú dokumentáciu; tím programátorov dodávateľa, ktorí realizovali požiadavky zákazníka podľa vypracovanej technickej dokumentácie… Nakoniec sme niektoré z našich nedôležitých požiadaviek prispôsobili funkcionalite už existujúcej platformy, niečo dodávateľ sľúbil dopísať pre nás.
Paralelné fungovanie dvoch systémov
Prišiel čas realizácie. V praxi to znamenalo, že dávame dodávateľovi možnosť nasadiť prototyp BMS v našej virtuálnej cloudovej službe a poskytujeme sieťový prístup ku všetkým zariadeniam, ktoré vyžadujú monitorovanie.
Nový systém však ešte nebol pripravený na prevádzku. V tejto fáze bolo pre nás dôležité zachovať monitorovanie v starom systéme a zároveň poskytnúť prístup k zariadeniam novému systému. Nie je možné normálne postaviť systém, ak v ňom nevidíte zariadenia, ktoré zároveň nemožno odpojiť od monitorovania starým systémom.
Bolo nejasné, či zariadenia zvládnu súčasné dotazovanie dvoma systémami bez reálnych testov. Existovala možnosť, že dvojité súčasné dotazovanie povedie k častým zlyhaniam odpovedí zo strany zariadení, čo by mohlo spôsobiť množstvo chýb v dosiahnuteľnosti zariadení, a tým zablokovať fungovanie starého monitora.
Sieťové oddelenie prepojilo virtuálne trasy od prototypu novej BMS, nasadeného v oblaku, k zariadeniam, a získali sme výsledky:
- zariadenia pripojené prostredníctvom protokolu SNMP takmer nevypadávali z pripojenia kvôli súčasným požiadavkám,
- zariadenia pripojené cez brány podľa protokolov modbus-TCP mali problémy, ktoré sa vyriešili rozumným znížením frekvencie ich dotazovania.
A potom sme začali pozorovať, ako sa pred našimi očami buduje nový systém, v ktorom sa objavujú nám už známe zariadenia, ale v inom rozhraní – pohodlnom, rýchlom, dostupnom aj z telefónu.
O tom, čo sa nakoniec podarilo, sa podelíme v tretej časti nášho článku.
Zdroj: habr.com
