Esimeses osas rääkisime sellest, miks otsustasime oma andmekeskustes vana BMS-süsteemi uue vastu välja vahetada. Ja mitte ainult muuta, vaid arendada nullist oma vajadustele vastavaks. Teises osas räägime teile, kuidas me seda tegime.
Turuanalüüs
Võttes arvesse punktis kirjeldatud soovidest ja otsusest keelduda olemasoleva süsteemi uuendamisest, kirjutasime turule lahenduse leidmiseks tehnilise spetsifikatsiooni ning tegime päringud mitmele suurettevõttele, kes tegelevad ainult tööstuslike SCADA süsteemide loomisega.
Juba esimesed vastused neilt näitasid, et seiresüsteemide turu liidrid jätkavad valdavalt tööd riistvaraserverite kallal, kuigi pilvedesse migreerumisprotsess selles segmendis on juba alanud. Mis puudutab virtuaalmasinate reserveerimist, siis keegi seda võimalust ei toetanud. Pealegi oli tunne, et ükski turul olevatest silmapaistvatest arendajatest ei näidanud üles isegi arusaamist koondamise vajadusest: "pilv ei lange" oli kõige levinum vastus. Tegelikult pakuti meile andmekeskuse jälgimise paigutamist pilve, mis asub füüsiliselt samas andmekeskuses.
Siinkohal peame tegema väikese kõrvalepõike töövõtja valimise protsessi kohta. Hind muidugi loeb, kuid mis tahes keeruka projekti elluviimise pakkumise ajal hakkate tarnijatega dialoogi etapis tundma, kumb kandidaatidest on rohkem huvitatud ja suuteline seda ellu viima.
See on eriti märgatav keerukate projektide puhul.
Lähtuvalt tehniliste kirjelduste täpsustavate küsimuste olemusest võib töövõtjad jagada pelgalt müügihuvilisteks (tunneb müügijuhi tavalist survet) ja toote arendamise huvilisteks, klienti kuulnud ja mõistvateks, konstruktiivseks muutmiseks. tehniliste kirjelduste muudatused juba enne lõplikku valikut (isegi vaatamata reaalsele riskile kellegi teise tehnilisi näitajaid parandada ja pakkumist kaotada), ollakse lõpuks lihtsalt valmis professionaalse väljakutse vastu võtma ja hea toote tegema.
Kõik see pani meid tähelepanu pöörama suhteliselt väikesele kohalikule arendajale - Sunline ettevõtete grupile, kes reageeris enamikule meie nõudmistele koheselt ja oli valmis ellu viima kõiki uue BMS-i vajadusi.
Riskid
Samal ajal kui suured tegijad püüdsid aru saada, mida me tahame, pidasid meiega rahulikku kirjavahetust, kaasates müügieelse taseme spetsialiste, planeeris kohalik arendaja meie kontoris kohtumise oma tehnilise meeskonna osavõtul. Sellel koosolekul demonstreeris töövõtja veel kord oma soovi projektis osaleda ja mis kõige tähtsam, selgitas, kuidas vajalik süsteem rakendub.
Enne kohtumist nägime kahte riski, kui töötate meeskonnaga, mille taga ei ole suure riikliku või rahvusvahelise ettevõtte ressursse:
- Spetsialistid võivad oma võimeid üle hinnata ja selle tulemusena lihtsalt hakkama ei saa, näiteks kasutavad nad keerulist tarkvara või kavandavad teostamatuid broneerimisalgoritme.
- Pärast projekti lõppemist võib projektimeeskond laiali minna ja seetõttu on tootetugi ohus.
Nende riskide minimeerimiseks kutsusime kohtumisele oma arendusspetsialistid. Potentsiaalsete töövõtjate töötajatega küsitleti põhjalikult, millel süsteem põhineb, kuidas koondamist plaanitakse rakendada ja muudel teemadel, milles me operatiivteenistusena ei ole piisavalt pädevad.
Otsus oli positiivne: olemasoleva BMS-platvormi arhitektuur on kaasaegne, lihtne ja töökindel, täiustatav, pakutud koondamis- ja sünkroniseerimisskeem on loogiline ja toimiv.
Esimese riskiga sai tegeletud. Teine välistati pärast töövõtjalt kinnituse saamist, et nad on valmis süsteemi lähtekoodi ja dokumentatsiooni meile üle kandma, ning valides ka meie spetsialistidele hästi tuntud Pythoni programmeerimiskeele. See tagas meile võimaluse süsteemi iseseisvalt raskusteta ülal pidada ja pika töötajate koolitusperioodi arendusettevõtte turult lahkumise korral.
Platvormi lisaeelis oli see, et seda rakendati Dockeri konteinerites: selles keskkonnas toimib kernel, veebiliides ja tootebaasi funktsioon. See lähenemisviis pakub palju eeliseid, sealhulgas eelseadistatud sätted lahenduse kiireimaks juurutamiseks võrreldes "klassikalise" ja uute seadmete lihtsa lisamisega süsteemi. “Kõik koos” põhimõte lihtsustab süsteemi rakendamist nii palju kui võimalik: lihtsalt pakkige süsteem lahti ja saate seda kohe kasutada.
Selle lahendusega on lihtsam teha süsteemist koopiaid ning seda saab täiustada ja uuendusi juurutada eraldi keskkonnas, ilma et see peataks lahenduse kui terviku tööd.
Kui mõlemad riskid olid viidud miinimumini, esitas töövõtja CP. See hõlmas kõiki meie jaoks BMS-süsteemi kõige olulisemaid parameetreid.
Reserveerimine
Uus BMS-süsteem pidi asuma pilves, virtuaalmasinas.
Ei mingit riistvara, servereid ja kõiki selle juurutusmudeliga kaasnevaid ebamugavusi ja riske – pilvelahendus võimaldas meil neist igaveseks vabaneda. Otsustati, et süsteem hakkab meie pilves töötama kahes andmekeskuses Peterburis ja Moskvas. Need on kaks täisfunktsionaalset süsteemi, mis töötavad aktiivses ooterežiimis ja millel on juurdepääs kõigile volitatud spetsialistidele.
Need kaks süsteemi kindlustavad teineteist, pakkudes nii arvutusvõimsuse kui ka andmeedastuskanalite täielikku reservi. Samuti on konfigureeritud täiendavad turvameetmed, sealhulgas andmete ja kanalite, süsteemide, virtuaalmasinate varundamine üldiselt ning eraldi andmebaasi varukoopia kord kuus (halduse ja analüüsi seisukohalt kõige väärtuslikum ressurss).
Pange tähele, et koondamine kui võimalus BMS-i lahenduses töötati välja spetsiaalselt meie soovi järgi. Broneerimisskeem ise nägi välja selline:
Toetama
BMS-i lahenduse tõhusa toimimise kõige olulisem punkt on tehniline tugi.
Siin on kõik lihtne: uus süsteem maksaks meile selle näitaja järgi 35 000 rubla. kuus SLA "vastus 8 tunni jooksul", st 35 000 x 12 / 80 = 5 $ aastas. Esimene aasta on tasuta.
Võrdluseks, vana BMS-i ülalpidamine müüjalt maksis 18 000 dollarit aastas, kusjuures summa suureneb iga uue lisatava seadme kohta! Samas ei olnud ettevõttel spetsiaalset juhti, kogu suhtlemine toimus müügijuhi kaudu, kes on meist kui potentsiaalsest ostjast huvitatud, vastava rõhuga päringute töötlemisel.
Väiksema raha eest saime täieliku tootetoe, kliendihalduriga, kes osaleks tootearenduses, ühe sisestuspunktiga jne. Tugi muutus palju paindlikumaks – tänu otsesele juurdepääsule arendajatele süsteemi mis tahes aspekti kiireks kohandamiseks, API kaudu integreerimiseks jne.
Uuendused
Vastavalt kavandatavale CP-le uues BMS-is sisalduvad kõik uuendused toe maksumuses, s.o. lisatasu ei nõua. Erandiks on lisafunktsionaalsuse arendamine, mis ületab tehnilistes kirjeldustes ettenähtu.
Vana süsteem nõudis nii püsivara värskenduste (nt Java) kui ka veaparanduste eest tasumist. Sellest oli võimatu keelduda, värskenduste puudumisel süsteem tervikuna "aeglustus" sisemiste komponentide vanade versioonide tõttu.
Ja loomulikult ei saanud tarkvara uuendada ilma tugipaketti ostmata.
Paindlik lähenemine
Teine põhinõue puudutas liidest. Tahtsime võimaldada sellele juurdepääsu veebibrauseri kaudu kõikjalt, ilma inseneri kohustusliku kohalolekuta andmekeskuse territooriumil. Lisaks püüdsime luua animeeritud liidese, et taristu dünaamika oleks valves olevatele inseneridele selgem.
Ka uues süsteemis oli vaja pakkuda tuge insenerisüsteemide virtuaalsete andurite töö arvutamise valemitele - näiteks elektrienergia optimaalseks jaotamiseks seadmete riiulite vahel. Selleks peavad teie käsutuses olema kõik tavapärased andurite indikaatorite jaoks kasutatavad matemaatilised toimingud.
Järgmiseks oli vaja juurdepääsu SQL-andmebaasile koos võimalusega võtta sealt vajalikud andmed seadmete töö kohta - nimelt kõik kahe tuhande seadme ja kahe tuhande virtuaalse anduri seirekirjed, mis genereerivad ligikaudu 20 tuhat muutujat.
Vaja oli ka rack-seadmete arvestusmoodulit, mis esitaks graafiliselt seadmete paigutuse igas üksuses koos riistvara kogumassi arvutamisega, säilitaks seadmete raamatukogu ja üksikasjaliku teabe iga elemendi kohta.
Tehniliste kirjelduste kinnitamine ja lepingu allkirjastamine
Ajal, mil oli vaja alustada tööd uue süsteemi kallal, oli kirjavahetus “suurte” ettevõtetega veel väga kaugel nende ettepanekute maksumusest, mistõttu võrdlesime saadud KP-d vana BMS-i uuendamise kuludega (vt. ) ning selle tulemusena osutus see hinna poolest atraktiivsemaks ja meie nõuetele vastavaks.
Valik on tehtud.
Pärast töövõtja valimist asusid juristid lepingut koostama ja mõlema poole tehnilised meeskonnad hakkasid tehnilisi kirjeldusi lihvima. Nagu teate, on üksikasjalikud ja pädevad tehnilised kirjeldused iga töö õnnestumise aluseks. Mida täpsemad on tehnilistes kirjeldustes, seda vähem on selliseid pettumusi nagu "aga see pole see, mida me tahtsime".
Toon kaks näidet tehniliste kirjelduste nõuete üksikasjalikkuse taseme kohta:
- Valve andmekeskustel on õigus lisada BMS-i uusi seadmeid, enamasti on need PDU-d. Vanas BMS-is oli selleks “administraatori” tase, mis võimaldas ka kõikide seadmete muutuvaid seadistusi muuta ning funktsioone polnud võimalik eraldada. See meile ei sobinud. Uue platvormi olemasolevas põhiversioonis oli skeem sarnane. Lähteülesandes andsime kohe märku, et soovime need rollid eraldada: seadeid tohib muuta vaid volitatud töötaja, kuid tööülesannetel peaks olema jätkuvalt võimalik seadmeid lisada. See skeem võeti rakendamiseks vastu.
- Igas standardses BMS-is on kolm tüüpilist teatiste kategooriat: PUNANE - tuleb kohe reageerida, KOLLANE - on võimalik jälgida, SININE - "Teabeline". Oleme traditsiooniliselt kasutanud siniseid hoiatusi, et jälgida, kui äriparameetrid on ületatud, näiteks kui kliendi riiul ületab oma mahupiirangu. Seda tüüpi teatis oli meie puhul mõeldud juhtidele ega pakkunud operatiivteenistusele huvi, kuid vanas BMS-is ummistas see regulaarselt aktiivsete intsidentide nimekirja ja segas operatiivtööd. Pidasime edukaks just teavituspükste loogikat ja värvide eristamist ja säilitasime selle, kuid tehnilistes kirjeldustes oli konkreetselt ette nähtud, et "sinised" teated peaksid ilma korrapidajate tähelepanu segamata vaikselt "valama" eraldi sektsiooni, kus need tegelevad kaubandusspetsialistid.
Sarnase detailsusastmega olid ette kirjutatud graafikute koostamise ja aruannete genereerimise vormingud, liideste piirjooned, jälgimist vajavate seadmete loetelu ja palju muud.
Tegemist oli kolme töörühma tõeliselt loomingulise tööga – klienditeenindaja, kes dikteeris oma nõuded ja tingimused; mõlema poole tehnilised spetsialistid, kelle ülesanne oli muuta need tingimused tehniliseks dokumentatsiooniks; töövõtjate programmeerijate meeskonnad, kes realiseerisid tellija nõuded vastavalt väljatöötatud tehnilisele dokumentatsioonile... Selle tulemusena kohandasime osa oma põhimõteteta nõudeid olemasoleva platvormi funktsionaalsusega ning töövõtja kohustus meie jaoks midagi lisama.
Kahe süsteemi paralleelne töö
Käes on rakendamise aeg. Praktikas tähendas see seda, et anname töövõtjale võimaluse juurutada meie virtuaalses pilves BMS-i prototüüp ja võimaldame võrgujuurdepääsu kõigile jälgimist vajavatele seadmetele.
Uus süsteem polnud aga veel töövalmis. Selles etapis oli meie jaoks oluline säilitada vanas süsteemis monitooring ja samal ajal anda juurdepääs seadmetele uuele süsteemile. Süsteemi on võimatu korralikult üles ehitada ilma selles seadmeid nägemata, millel omakorda ei saa vana süsteemi jälgimist keelata.
See, kas seadmed suudavad vastu pidada kahe süsteemi samaaegsele ülekuulamisele, polnud ilma tõelise testimiseta ilmne. Oli võimalus, et kahekordne samaaegne küsitlus toob kaasa sagedased seadmete vastamisest keeldumised ning saame palju seadmete kättesaamatuse tõrkeid, mis omakorda blokeerivad vana seiresüsteemi töö.
Võrguosakond juhtis virtuaalseid marsruute pilves juurutatud uue BMS-i prototüübist seadmetesse ja saime tulemused:
- SNMP-protokolli kaudu ühendatud seadmed ei katkenud samaaegsete päringute tõttu praktiliselt kunagi,
- Modbas-TCP protokolle kasutavate lüüside kaudu ühendatud seadmetel oli probleeme, mis lahendati nende küsitlussageduse nutika vähendamisega.
Ja siis hakkasime jälgima, kuidas meie silme all ehitati uut süsteemi, millesse ilmusid meile juba tuttavad seadmed, kuid erinevas liideses - mugav, kiire, ligipääsetav isegi telefonist.
Mis lõpuks juhtus, räägime teile meie artikli kolmandas osas.
Allikas: www.habr.com