Esimese osa jooksul rääkisime sellest, miks otsustasime vahetada meie andmekeskustes vana BMS-süsteemi uue vastu. Ja mitte lihtsalt vahetada, vaid arendada see algusest peale vastavalt meie nõudmistele. Teises osas räägime, kuidas me seda tegime.
Turuanalüüs
Arvesse võttes ülaltoodud soove ja otsust loobuda olemasoleva süsteemi uuendamisest, koostasime tehnilise ülesande turu lahenduste leidmiseks ning esitasime päringud mitmele suurele ettevõttele, mis tegelevad ainult tööstuslike SCADA-süsteemide loomisega.
Esimeste vastuste põhjal selgus, et turuliidrid jälgimis- ja haldussüsteemide valdkonnas töötavad peamiselt endiselt raudserveritel, kuigi selle segmendi pilve rändamine on juba alanud. Mis puutub virtuaalmasinate varundamise võimalusse, siis ei toetanud seda keegi. Veelgi enam, tundus, et keegi tuntud arendajatest ei näidanud isegi arusaama varundamise vajadusest: „pilv ei kuku ju” oli kõige levinum vastus. Tegelikult pakuti meile ettepanekut paigutada andmekeskuse jälgimine pilvesse, mis asub füüsiliselt samas andmekeskuses.
Siin tuleb teha väike kõrvalpõige alltöövõtja valimise protsessi kohta. Muidugi on hind oluline, kuid iga keerulise projekti elluviimise hankemenetluse käigus, tarnijatega dialooge pidades, hakkad tundma, kes kandidaatidest on rohkem huvitatud ja suudab selle ellu viia.
See on eriti märgatav keerulistel projektidel.
Selguse huvides võib alltöövõtjad jagada nende küsimuste iseloomu järgi: on neid, kes on lihtsalt huvitatud müügist (tunded nagu müügihalduri standardne rünnak) ja neid, kes on huvitatud toote väljatöötamisest, kuuldes ja mõistes tellijat, tehes konstruktiivseid muudatusi spetsifikatsioonis veel enne lõpliku valiku tegemist (isegi vaatamata reaalsele riskile parandada kellegi teise spetsifikatsiooni ja kaotada hankemenetlus), ning lõpuks ka neid, kes on lihtsalt valmis professionaalsele väljakutsele vastu astuma ja tegema head toodet.
Kõik see pani meid tähelepanu pöörama suhteliselt väikesesse kohaliku arendaja gruppi – ettevõtete grupp „Sanline”, kes reageeris enamikele meie nõudmistele koheselt ja oli valmis rahuldama kõik vajadused seoses uue BMS-iga.
Riskid
Samas kui suured mängijad püüdsid mõista, mida me soovime, ja viivad meiega aeglast kirjavahetust, määras kohalik arendaja meie kontoris kohtumise oma tehnilise meeskonnaga. Sellel kohtumisel näitas alltöövõtja veel kord oma soovi osaleda projektis ja - mis kõige tähtsam - selgitas, kuidas nõutav süsteem rakendatakse.
Enne kohtumist nägime kahte riski töötades meeskonnaga, kellel ei ole suure rahvusliku või rahvusvahelise ettevõtte tuge:
- Spetsialistid võisid üle hinnata oma võimalused ja seetõttu ei pruugi nad lihtsalt hakkama saada, näiteks kasutavad nad keerulist tarkvara või kavandavad teostatamatuid broneerimisalgoritme.
- Pärast projekti elluviimist võib projekti meeskond laguneda ja seega on toote tugi ohus.
Nende riskide minimeerimiseks kutsusime kohtumisele oma arenduseksperdid. Potentsiaalse alltöövõtja töötajaid küsitleti hoolikalt, et selgitada, millest süsteem koosneb, kuidas planeeritakse varundamist teostada ja teistes küsimustes, milles meie, kui tööde teostamise teenus, ei ole piisavalt pädevad.
Hinnang oli positiivne: olemasoleva BMS platvormi arhitektuur on kaasaegne, lihtne ja usaldusväärne, see võib olla täiendatud, pakutud varundamise ja sünkroonimise skeem on loogiline ja toimiv.
Esimese riskiga saime hakkama. Teise kõrvaldame, saades alltöövõtjalt kinnituse koodi allikate ja dokumentatsiooni edastamise valmiduse kohta ning valides programmeerimiskeele Python, millega meie spetsialistid on hästi tuttavad. See tagas meile võimaluse süsteemi ise toetada ilma raskusteta ja pika koolitusperioodita, kui arendaja ettevõte turult välja tõmbub.
Platvormi täiendav eelis oli see, et see viidi ellu Docker konteinerites: selles keskkonnas toimivad toote tuum, veebiliides ja andmebaas. Selline lähenemine toob kaasa palju eeliseid, sealhulgas seadistuste eelinstallimise, mis tagab lahenduse kõrgeima juurutamise kiiruse võrreldes "klassikaga" ning uute seadmete lihtsa lisamise süsteemi. Printsiip "kõik koos" lihtsustab süsteemi rakendamist maksimaalselt: piisab, kui süsteem lahti pakkida, ja seda saab kohe kasutada.
Sellise lahendusega on lihtsam teha süsteemi varukoopiaid, samuti saab seda täiustada ja uuendusi ellu viia eraldi keskkonnas, peatamata lahenduse tööd tervikuna.
Pärast seda, kui mõlemad riskid olid minimeeritud, esitas alltöövõtja pakkumise. Selles töödeldi kõiki meie jaoks kõige olulisemaid BMS-süsteemi parameetreid.
Varu
Uus BMS-süsteem pidi olema pilves, virtuaalses masinas.
Ei mingit riistvara, ei serverite ja selle mudeli juurutamisega seotud ebamugavusi ega riske – pilvelahendus võimaldas meil neist igaveseks vabaneda. Otsustati, et süsteem töötab meie pilves kahes andmekeskuse asukohas Peterburis ja Moskvas. Need on kaks täisfunktsionaalset süsteemi, mis töötavad active standby režiimis, andes ligipääsu kõigile volitatud spetsialistidele.
Kaks süsteemi kindlustavad üksteist, tagades täieliku varu nii arvutusvõimsustes kui ka andmeedastuskanalites. Samuti on seadistatud täiendavad turvameetmed, sealhulgas andmete ja kanalite varundamine, süsteemide, virtuaalmasinate kogum, ning eraldi andmebaasi varundamine kord kuus (kõige väärtuslikum ressurss tuleviku juhtimise ja analüüsi perspektiivis).
Tähtis on märkida, et varundamine kui BMS-lahenduse valik oli arendatud spetsiaalselt meie soovi järgi. Varundamisskeem nägi välja järgmiselt:
Toetamine
Tähtsaim punkt BMS-lahenduse tõhusaks kasutamiseks on tehniline tugi.
Siin on kõik lihtne: uus süsteem maksaks meile selle näitaja põhjal 35 000 rubla kuus SLA puhul „reaktsioon 8 tunni jooksul”, mis tähendab 35 000 x 12 / 80 = 5 250 dollarit aastas. Esimene aastakäik – tasuta.
Võrdluseks: vana BMS-i toeta maksti müüja eest 18 000 dollarit aastas, kusjuures iga uue seadme lisamine tõi kaasa summa suurenemise! Samal ajal ei pakkunud ettevõte eraldi juhti, kogu suhtlus toimus müügijuhiga, kes oli meie suhtes nagu potentsiaalne ostja ja seetõttu suunas oma lähenemist vastustele.
Paremate hindadega saime täieliku toote toe, koos konto-juhiga, kes osaleb toote arenduses, ühtse sisenemispunktiga jne. Tugi muutus oluliselt paindlikumaks – tänu otsesele juurdepääsule arendajatele operatiivsete muudatuste tegemiseks süsteemi töö, API integreerimise jne igas aspektis.
Uuendused
Vastavalt esitatud pakkumisele sisaldab uus BMS kõiki uuendusi toe hinna sees, st need ei nõua täiendavat tasu. Erandiks on täiendava funktsionaalsuse arendamine, mis ületab tehnilises ülesandes näidatud.
Vana süsteem eeldas tasu nii sisseehitatud tasuta tarkvara (nt Java) uuendamise kui ka vigade parandamise eest. Selle lõpetamine ei olnud võimalik; uuenduste puudumisel 'tõmbas' süsteem üldiselt vanade sisekomponentide tõttu.
Ja loomulikult ei saanud tarkvara uuendada ilma toe paketi ostmiseta.
Paindlik lähenemine
Teine põhinõue puudutas liidest. Soovisime tagada sellele juurdepääsu veebibrauseri kaudu igast kohast, ilma et insener peaks olema andmekeskuses kohal. Lisaks püüdsime luua animatsiooni liidese, et infrastruktuuri toimimise dünaamika oleks jadereinseneride jaoks selgem.
Uues süsteemis pidi samuti olema toe pakkumine valemitele, et arvutada virtuaalsete andurite töö insenerisüsteemides — näiteks, et optimeerida elektrienergia jaotust seadmete rackidel. Selleks peab olema kõik harjumuspärased matemaatilised operatsioonid, mida saab kasutada andurite näitude puhul.
Edasi, oli vajalik juurdepääs SQL andmebaasile, mille kaudu oli võimalik võtta vajalikud andmed seadmete töö kohta — nimelt, kõik kirjed kahe tuhande seadme ja kahe tuhande virtuaalse anduri jälgimisest, mis genereerivad umbes 20 tuhat muutujat.
Samuti oli vajalik seadmete arvestuse moodul rackis, mis annab visuaalse ülevaate seadmete asukohast iga üksuses koos «raudvara» kogukaalu arvestusega, seadmete raamatukogu pidamise ja põhjaliku teabe igas elemendis.
Tehnilise ülesande kooskõlastamine ja lepingu sõlmimine
Käesoleval ajal, mil oli vaja alustada uue süsteemi arendamist, polnud suhtlemine suurte ettevõtetega veel väga kaugel nende pakkumiste hindade arutamisest, seega võrreldes saadud pakkumisi vanade BMS-i uuendamise kuludega (vt. ), selgus, et see oli soodsam ja vastas meie nõudmistele.
Valik langetati.
Pärast hankija valimist hakkasid juristid koostama lepingut ning tehnilised meeskonnad mõlemalt poolt lihvima tehnilist spetsifikatsiooni. Nagu teada, on detailne ja õigesti koostatud tehniline spetsifikatsioon iga töö edu aluseks. Mida rohkem konkreetsust tehnilises spetsifikatsioonis, seda vähem pettumusi nagu „me ei tahtnud nii”.
Toon kaks näidet nõudmiste detailituse tasemest tehnilises spetsifikatsioonis:
- Juhatavad andmekeskused on volitatud lisama BMS-i uusi seadmeid, enamasti PDU-sid. Vanas BMS-is oli see «administraatori» tasemel, mis lubas muu hulgas muuta kõigi seadmete parameetreid, ning funktsioonide jagamine ei olnud võimalik. See ei olnud meile vastuvõetav. Uue platvormi olemasolevas baasversioonis oli skeem sarnane. Me täpsustasime kohe projektis, et soovime neid rolle eraldada: parameetreid peaks muutma vaid volitatud töötaja, kuid vahetuste töötajad peaksid endiselt saama seadmeid lisada. See skeem võeti ellu.
- Igas tavapärases BMS-is on kolm tüüpilist teavitamise kategooriat: KUIDAS – sellele tuleb reageerida viivitamatult, KOLLANE – seda saab jälgida, SININE – „Infoteade“. Oleme traditsiooniliselt kasutanud „siniseid“ teateid kaubanduslike parameetrite ületamise jälgimiseks, näiteks kliendi serveri võimsuse ülempiiri ületamine. See teavitamise tüüp oli meie puhul mõeldud juhatajale ja ei huvitanud teenindusmeeskonda, kuid vanas BMS-is ummestas see pidevalt aktiivsete sündmuste nimekirja ja segas operatiivset tööd. Teatavate teavituste loogikat ja värvilist diferentseerimist peame edukaks ja oleme seda säilitanud, kuid tehnilises ülesandes oleme selgelt märkinud, et „sinised“ teavitused peavad, ilma valvepersonalile häirimata, vaikselt „langema“ eraldi jao, kus nendega tegelevad kaubanduseksperdid.
Sama detailitasemega on olnud kirja pandud graafikute koostamise ja aruannete koostamise vormid, liideste joonised, seadmestiku loetelu, mida tuli jälgida, ja veel palju muid asju.
See oli tõeliselt loominguline töö kolme töögrupi vahel – tellimisteenistuse, mis dikteeris oma nõudmisi ja tingimusi; tehniliste spetsialistide mõlemalt poolt, kelle ülesanne oli need tingimused tehniliseks dokumentatsiooniks vormida; ning hankija programmeerijate meeskonna, kes töötas tellija nõudmiste põhjal välja koostatud tehnilise dokumentatsiooni… Lõpuks kohandati mõned meie mitte-hädaolukordade nõudmised olemasoleva platvormi funktsionaalsuse järgi, samas kui hankija nõustus meie jaoks veel mõned lisama.
Kahe süsteemi paralleelne töö
Kätte on jõudnud rakendamise aeg. Praktikas tähendas see, et anname hankijale võimaluse käivitada BMS prototüüp meie virtuaalses pilves ja pakume võrguühendust kõigile seadmetele, mis vajavad jälgimist.
Sellegipoolest pole uus süsteem veel tööks valmis. Sellel ajal oli meie jaoks oluline säilitada vanas süsteemis jälgimine ja samal ajal anda seadmetele juurde pääs uues süsteemis. Süsteemi ei saa korralikult ehitada, nägemata seal seadmeid, mida omakorda ei saa vanast süsteemist jälgimisest välja lülitada.
Kas seadmed suudavad kahe süsteemi samaaegset küsitlust taluda, ei olnud ilma reaalsete katseteta ilmne. Oli võimalik, et kahekordne samaaegne küsitlus tooks kaasa sagedased seadmete vastuste puudumised ja me saaksime hulgaliselt vigu seadmete kättesaamatuse tõttu, mis omakorda blokeeriks vanas jälgimissüsteemis tööd.
Võrguosakond edastas virtuaalsed marsruudid uue pilvepõhise BMS prototüübi ja seadmete vahel ning saime tulemused:
- seadmed, mis on ühendatud SNMP protokolli kaudu, praktiliselt ei langenud ühisest ühenduse katkestamisest,
- seadmed, mis on ühendatud modbus-TCP protokollide kaudu, olid probleeme, mis lahendati mõistliku küsitluse sageduse vähendamisega.
Ja jätkasime vaatamist, kuidas meie silme ees ehitati uus süsteem, kuhu ilmuvad juba tuttavad seadmed, kuid teises liideses – mugavas, kiiretes ja isegi telefonist kergesti kätte saadavas.
Kuidas lõppkokkuvõttes läks, räägime oma artikli kolmandas osas.
Allikas: habr.com
