Në pjesën e parë, ne folëm për arsyen pse vendosëm të zëvendësonim sistemin e vjetër të BMS në të dhënat tona me një të re. Dhe jo vetëm ta zëvendësojmë, por ta zhvillojmë nga e para sipas kërkesave tona. Në pjesën e dytë tregojmë se si e bëmë këtë.
Analiza e tregut
Duke marrĂ« parasysh ato qĂ« pĂ«rmenden nĂ« dĂ«shirat e shprehura dhe vendimin pĂ«r tĂ« hequr dorĂ« nga pĂ«rditĂ«simi i sistemit ekzistues, ne shkruam njĂ« TĂ«Z pĂ«r tĂ« kĂ«rkuar zgjidhje nĂ« treg dhe bĂ«mĂ« kĂ«rkesa nĂ« disa kompani tĂ« mĂ«dha qĂ« merreshin vetĂ«m me krijimin e sistemeve industriale SCADA.Â
Përgjigjet e para prej tyre treguan se liderët e tregut të sistemeve të monitorimit kryesisht vazhdojnë të punojnë në serverë fizikë, megjithëse procesi i migrimit në re në këtë segment ka nisur tashmë. Sa i përket rezervimit të makinave virtuale - këtë opsion asnjë nuk e përkrahte. Më shumë se kaq, shkaktohej mendimi se asnjë nga zhvilluesit e njohur në treg nuk tregonte madje edhe kuptimin e nevojës për rezervim: "re nuk bie" ishte përgjigja më e zakonshme. Në fakt, na u ofrua të vendosnim monitorimin e Qendrës së Dhënave në një re, fizikisht të vendosur në këtë Qendër të Dhënave.
KĂ«tu duhet bĂ«rĂ« njĂ« shkĂ«putje e vogĂ«l pĂ«r procesin e pĂ«rzgjedhjes sĂ« kontraktorit. Ămimi, sigurisht, ka rĂ«ndĂ«si, por gjatĂ« çdo tenderi pĂ«r realizimin e njĂ« projekti tĂ« ndĂ«rlikuar, nĂ« fazĂ«n e dialogut me ofruesit, fillon tĂ« ndihesh se kush nga kandidatĂ«t Ă«shtĂ« mĂ« i interesuar dhe i aftĂ« ta realizojĂ« atĂ«.Â
Kjo Ă«shtĂ« veçanĂ«risht e dukshme nĂ« projekte tĂ« ndĂ«rlikuara.Â
Duke u bazuar në natyrën e pyetjeve sqaruese për TëZ-në, mund të ndahet kontraktori në ata që janë të interesuar thjesht të shesin (ndjehet presioni standard i menaxherit të shitjeve) dhe ata që janë të interesuar në zhvillimin e produktit, duke dëgjuar dhe kuptuar porositësin, duke bërë ndryshime konstruktive në TëZ para përzgjedhjes përfundimtare (edhe pse përballë rrezikut real për të përmirësuar një TëZ të huaj dhe për të humbur tenderin), e në fund ishin thjesht të gatshëm të pranonin sfidën profesionale dhe të bënin një produkt cilësor.
TĂ« gjitha kĂ«to na bĂ«nĂ« tĂ« drejtojmĂ« vĂ«mendjen tonĂ« nga njĂ« zhvillues lokal relativisht i vogĂ«l â grupi i kompanive «Sanline», i cili iu pĂ«rgjigj shumicĂ«s sĂ« kĂ«rkesave tona menjĂ«herĂ« dhe ishte i gatshĂ«m tĂ« realizonte tĂ« gjitha nevojat pĂ«r sistemin e ri BMS.Â
Rreziqet
NdĂ«rsa lojtarĂ«t e mĂ«dhenj po pĂ«rpiqeshin tĂ« kuptonin se çfarĂ« donim dhe po zhvillonin njĂ« bisedĂ« tĂ« ngadaltĂ« me ne duke pĂ«rfshirĂ« specialistĂ« nĂ« nivelin presales, zhvilluesi lokal kishte caktuar njĂ« takim nĂ« zyrĂ«n tonĂ« me pjesĂ«marrjen e ekipit tĂ« tij teknik. NĂ« kĂ«tĂ« takim, kontraktori pĂ«rsĂ«ri demonstroi dĂ«shirĂ«n pĂ«r tĂ« marrĂ« pjesĂ« nĂ« projekt dhe - mĂ« e rĂ«ndĂ«sishmja - shpjegoi se si do tĂ« realizohej sistemi i kĂ«rkuar.   Â
Para takimit, ne kemi identifikuar dy rreziqe në punën me një ekip që nuk ka pasur mbështetje nga një kompani të madhe kombëtare ose ndërkombëtare:
- Specialistët mund të kenë tepruar me vlerësimin e mundësive të tyre dhe si rezultat mund të mos përballen dot, për shembull, do të përdorin softuer kompleks ose do të projektojnë algoritme rezervimi që nuk mund të realizohen.
- Pas përfundimit të projektit, ekipi i projektit mund të shpërbëhet dhe, për pasojë, mbështetja e produktit do të jetë nën kërcënim.
Për të minimalizuar këto rreziqe, ne ftuam në takim specialistët tanë të zhvillimit. Punonjësit e kontraktorit potencial u intervistuan me kujdes në lidhje me atë se si është ndërtuar sistemi, si planifikohet realizimi i rezervimit dhe për çështje të tjera në të cilat ne, si shërbimi i operimit, nuk ishim mjaft kompetent.
Verdikti ishte pozitiv: arkitektura e platformĂ«s BMS qĂ« ekziston tashmĂ« Ă«shtĂ« moderne, e thjeshtĂ« dhe e besueshme, mund tĂ« pĂ«rmirĂ«sohet, skema e propozuar e rezervimit dhe sinkronizimit Ă«shtĂ« logjike dhe funksionale.Â
Ne përballuam me rrezikun e parë. Të dytin e eliminuam, pasi morëm konfirmimin nga kontraktori për gatishmërinë e tij për të na dorëzuar kodin burimor të sistemit dhe dokumentacionin, si dhe duke zgjedhur gjuhën e programimit Python, të njohur mirë për specialistët tanë. Kjo na garantoi mundësinë për të mbajtur sistemin me forcat tona pa asnjë vështirësi dhe pa një periudhë të gjatë trajnimi të punonjësve në rast se kompania zhvilluese largohej nga tregu.
NjĂ« plus shtesĂ« i platformĂ«s ishte se ajo u zbatua nĂ« kontejnerĂ« Docker: nĂ« kĂ«tĂ« mjedis funksionojnĂ« bĂ«rthama, ndĂ«rfaqja e uebit dhe databaza e produktit. Ky qasje ofron shumĂ« pĂ«rfitime, duke pĂ«rfshirĂ« parainstallimin e konfigurimeve pĂ«r shpejtĂ«sinĂ« mĂ« tĂ« lartĂ« tĂ« implementimit tĂ« zgjidhjes nĂ« krahasim me "klasiken" dhe shtimin e thjeshtĂ« tĂ« pajisjeve tĂ« reja nĂ« sistem. Prinicpi i "tĂ« gjitha sĂ« bashku" e thjeshton maksimalisht implementimin e sistemit: mjafton tĂ« shkarkoni sistemin dhe mund ta pĂ«rdorni menjĂ«herĂ«.Â
Me njĂ« zgjidhje tĂ« tillĂ«, Ă«shtĂ« mĂ« e lehtĂ« tĂ« bĂ«ni kopje tĂ« sistemit, ndĂ«rsa pĂ«rmirĂ«simi dhe realizimi i pĂ«rditĂ«simeve mund tĂ« bĂ«het nĂ« njĂ« mjedis tĂ« veçantĂ«, pa ndalur punĂ«n e zgjidhjes nĂ« tĂ«rĂ«si. Â
Pas minimizimit të të dy rreziqeve, kontraktori paraqiti ofertën. Ajo përmbante të gjitha parametrat më të rëndësishëm për ne të sistemit BMS.
Rezervimi
Sistemi i ri BMS duhet tĂ« ishte nĂ« cloud, nĂ« njĂ« makinĂ« virtuale.Â
AsnjĂ« harduer, asnjĂ« server dhe tĂ« gjitha shqetĂ«simet e lidhura me kĂ«tĂ« model implementimi â zgjidhja cloud na lejoj tĂ« heqim dorĂ« nga to pĂ«rherĂ«. U vendos qĂ« sistemi do tĂ« funksiononte nĂ« cloud tonĂ« nĂ« dy lokacione tĂ« QendrĂ«s sĂ« tĂ« DhĂ«nave nĂ« ShĂ«n Petersburg dhe MoskĂ«. KĂ«to janĂ« dy sisteme plotesisht funksionale, qĂ« punojnĂ« nĂ« modin aktiv standby me qasje pĂ«r tĂ« gjithĂ« specialistĂ«t e autorizuar.Â
Dy sistemet mbulojnĂ« njĂ«ra-tjetrĂ«n, duke siguruar rezervĂ« tĂ« plotĂ« si nĂ« kapacitetet llogaritĂ«se ashtu edhe nĂ« kanalet e transmetimit tĂ« tĂ« dhĂ«nave. Po ashtu janĂ« konfiguruar masa tĂ« tjera sigurie, duke pĂ«rfshirĂ« kopje rezervĂ« tĂ« tĂ« dhĂ«nave dhe kanaleve, sistemeve, makinave virtuale nĂ« tĂ«rĂ«si, dhe njĂ« kopje rezervĂ« tĂ« veçantĂ« tĂ« DB njĂ« herĂ« nĂ« muaj (burimi mĂ« i çmuar nĂ« perspektivĂ«n e menaxhimit dhe analizĂ«s).Â
Dëshirojmë të theksojmë se rezervimi si një opsion i zgjidhjes BMS u zhvillua posaçërisht sipas kërkesës sonë. Vetë skema e rezervimit dukej kështu:
Mbështetje
NjĂ« moment i rĂ«ndĂ«sishĂ«m pĂ«r njĂ« funksionim efektiv tĂ« zgjidhjes BMS Ă«shtĂ« mbĂ«shtetje teknike.Â
KĂ«tu tĂ« gjitha janĂ« tĂ« thjeshta: sistemi i ri do tĂ« na kushtonte 35 000 rubla nĂ« muaj pĂ«r kĂ«tĂ« tregues sipas SLA "reaksion brenda 8 orĂ«ve", domethĂ«nĂ« 35 000 x 12 / 80 = $5 250 nĂ« vit. Viti i parĂ« Ă«shtĂ« falas.Â
PĂ«r krahasim: mbĂ«shtetje e sistemit tĂ« vjetĂ«r BMS nga tregtari kushtonte $18,000 nĂ« vit me rritjen e shumĂ«s pĂ«r çdo pajisje tĂ« re tĂ« shtuar! NjĂ« menaxher i dedikuar nuk ishte nĂ« dispozicion nga kompania, tĂ« gjithĂ« komunikimi ndodhte pĂ«rmes menaxherit tĂ« shitjeve, i cili ishte i interesuar pĂ«r ne si njĂ« blerĂ«s potencial me theks tĂ« caktuar nĂ« pĂ«rpunimin e kĂ«rkesave.Â
PĂ«r njĂ« çmim mĂ« tĂ« ulĂ«t morĂ«m mbĂ«shtetje tĂ« plotĂ« pĂ«r produktin, me njĂ« menaxher tĂ« llogarive, i cili do merrte pjesĂ« nĂ« zhvillimin e produktit, me njĂ« pikĂ« tĂ« vetme hyrjeje etj. MbĂ«shtetja bĂ«hej shumĂ« mĂ« fleksibile â falĂ« aksesit tĂ« drejtpĂ«rdrejtĂ« te zhvilluesit pĂ«r ndreqje tĂ« shpejta nĂ« çdo aspekt tĂ« funksionimit tĂ« sistemit, integrimit pĂ«rmes API etj.
Azhurnimet
NĂ« ofertĂ«n pĂ«r BMS-nĂ« e re, tĂ« gjitha azhornimet ishin tĂ« pĂ«rfshira nĂ« kostot e mbĂ«shtetjes, dmth. nuk kĂ«rkonin pagesĂ« shtesĂ«. PĂ«rjashtim bĂ«jnĂ« zhvillimi i funksionaliteteve shtesĂ«, pĂ«rtej atyre qĂ« janĂ« pĂ«rcaktuar nĂ« dokumentacionin teknik.Â
Sistemi i vjetĂ«r parashikonte pagesĂ« si pĂ«r azhornimin e software-it tĂ« integruar falas (tipi Java), ashtu edhe pĂ«r korrigjimin e gabimeve. Nuk mund ta refuzonim kĂ«tĂ«, nĂ« mungesĂ« tĂ« azhornimeve, sistemi nĂ« pĂ«rgjithĂ«si ângucitejâ pĂ«r shkak tĂ« versioneve tĂ« vjetra tĂ« komponenteve tĂ« brendshme.
Dhe, natyrisht, nuk mund të azhurnohej softueri pa blerjen e paketës së mbështetjes.
Qasje fleksibile
NjĂ« kĂ«rkesĂ« tjetĂ«r thelbĂ«sore u lidhi me ndĂ«rfaqen. Ne donim tĂ« ofronim qasje pĂ«rmes shfletuesit tĂ« internetit nga çdo pikĂ«, pa nevojĂ«n e pranishĂ«m tĂ« inxhinierĂ«ve nĂ« vendin e QendrĂ«s sĂ« tĂ« DhĂ«nave. PĂ«r mĂ« tepĂ«r, ne synonim krijimin e njĂ« ndĂ«rfaqe tĂ« animuar, nĂ« mĂ«nyrĂ« qĂ« dinamika e funksionimit tĂ« infrastrukturĂ«s tĂ« ishte mĂ« e dukshme pĂ«r inxhinierĂ«t nĂ« detyrĂ«.Â
Po ashtu nĂ« sistemin e ri duhej tĂ« sigurohej mbĂ«shtetje pĂ«r formula pĂ«r llogaritjen e funksionimit tĂ« sensorĂ«ve virtual nĂ« sistemet inxhinierike - pĂ«r shembull, pĂ«r shpĂ«rndarjen optimale tĂ« fuqive elektrike nĂ« raftet me pajisje. PĂ«r kĂ«tĂ« duhet tĂ« kemi nĂ« dispozicion tĂ« gjitha operacionet matematikore tĂ« zakonshme, tĂ« aplikueshme pĂ«r treguesit e sensorĂ«ve.Â
MĂ« pas, ishte e nevojshme tĂ« kishte qasje nĂ« databazĂ«n SQL me mundĂ«sinĂ« pĂ«r tĂ« marrĂ« tĂ« dhĂ«nat e nevojshme rreth funksionimit tĂ« pajisjeve - konkretisht, tĂ« gjitha regjistrimet e monitorimit tĂ« dy mijĂ« pajisjeve dhe dy mijĂ« sensorĂ«ve virtualĂ«, tĂ« cilĂ«t gjeneronin rreth 20 mijĂ« variabla.Â
Ishte gjithashtu e nevojshme njĂ« moduli pĂ«r llogaritjen e pajisjeve nĂ« raft, qĂ« ofronte njĂ« pamje grafike tĂ« vendndodhjes sĂ« pajisjeve nĂ« çdo njĂ«sisĂ« me llogaritjen e peshĂ«s totale tĂ« 'harduerit', duke mbajtur njĂ« bibliotekĂ« pajisjesh dhe informacion tĂ« detajuar pĂ«r secilin element.Â
Miratimi i Të Dhënave dhe nënshkrimi i kontratës
Në atë moment, kur ishte e nevojshme të fillohej puna mbi sistemin e ri, shkëmbimi i mesazheve me kompanitë 'të mëdha' ende ishte shumë larg diskutimit të kostove të ofertave të tyre, prandaj ne e krahasuam ofertën e marrë me shpenzimet për rinovimin e BMS së vjetër (shih. ), dhe si rezultat, ajo doli të ishte më tërheqëse në çmim dhe përputhej me kërkesat tona.
Zgjedhja u bë.
Pas zgjedhjes së kontraktorit, juristët filluan të përgatisin kontratën, ndërsa ekipet teknike nga të dyja anët po përmirësonin Të Dhënat. Siç dihet, një Të Dhëna e detajuar dhe e saktë është baza e suksesit të çdo pune. Sa më shumë konkretësi të ketë në Të Dhëna, aq më pak shpërthime zhgënjyese si 'ne donim ndryshe'.
Do të jap dy shembuj të nivelit të detajimit të kërkesave në Të Dhëna:
- Qendrat e të dhënave janë të autorizuara të shtojnë pajisje të reja në BMS, më së shumti kjo është PDU. Në BMS-në e vjetër, ky ishte niveli 'administrator', i cili gjithashtu lejonte ndryshimin e parametrave të të gjithë pajisjeve, dhe ndarja e funksioneve ishte e pamundur. Ne nuk ishim të kënaqur me këtë. Në versionin bazik të disponueshëm të platformës së re, skema ishte e ngjashme. Ne menjëherë shënuam në Të Dhëna se dëshironim të ndaheshin këto role: parametrat duhet të ndryshoheshin vetëm nga një punonjës i autorizuar, ndërsa rojet duhej të kishin ende mundësinë të shtonin pajisje. Kjo skemë u pranuar për realizim.
-  NĂ« çdo BMS standard, ka tre kategori tipike njoftimesh: E KUQ â duhet tĂ« reagoni menjĂ«herĂ«, E VERDHĂ â mund tĂ« monitorohet, E BARDHĂ â "Informative". Tradicionalisht, ne e kemi pĂ«rdorur njoftimin "e bardhĂ«" pĂ«r monitorimin e kalimeve tĂ« parametrave komercialĂ«, si kalimi i limitit tĂ« fuqisĂ« sĂ« raftit tĂ« klientit. Ky lloj njoftimi nĂ« rastin tonĂ« ishte i destinuar pĂ«r menaxherĂ«t dhe nuk ishte i interesit tĂ« shĂ«rbimit tĂ« operacioneve, por nĂ« BMS-nĂ« e vjetĂ«r rregullisht bllokonte listĂ«n e incidentĂ«ve aktivĂ« dhe pengonte punĂ«n operative. LogjikĂ«n dhe diferencimin vizual tĂ« ngjyrave tĂ« njoftimeve e konsideruam tĂ« suksesshme dhe e ruajtĂ«m, megjithatĂ« nĂ« TZ saktĂ«sisht e theksuam se njoftimet "e bardhĂ«" duhet, pa tĂ«rhequr vĂ«mendjen e rojeve, tĂ« "shpĂ«rndahen" nĂ« heshtje nĂ« njĂ« seksion tĂ« veçantĂ«, ku do tĂ« merret me to specialistĂ«t komercialĂ«.
Me njĂ« nivel tĂ« ngjashĂ«m detajesh ishin shkruar format e ndĂ«rtimit tĂ« grafikĂ«ve dhe nxjerrjes sĂ« raporteve, konturet e ndĂ«rfaqeve, lista e pajisjeve qĂ« duhej tĂ« monitoroheshin dhe shumĂ« gjĂ«ra tĂ« tjera.Â
Ishte njĂ« punĂ« me tĂ« vĂ«rtetĂ« kreative e tri grupeve tĂ« punĂ«s â shĂ«rbimit tĂ« klientit, i cili diktonte kĂ«rkesat dhe kushtet e tij; specialistĂ«ve teknikĂ« nga tĂ« dyja anĂ«t, tĂ« cilĂ«t kishin pĂ«r detyrĂ« tĂ« shndĂ«rronin kĂ«to kushte nĂ« dokumentacion teknik; ekipit tĂ« programuesve tĂ« kontraktorit, tĂ« cilĂ«t realizonin kĂ«rkesat e klientit sipas dokumentacionit teknik tĂ« hartuar... Si rezultat, disa nga kĂ«rkesat tona tĂ« paqĂ«ndrueshme i pĂ«rshtatĂ«m me funksionalitetin e platformĂ«s ekzistuese, disa kontraktori u angazhua t'i shkruante pĂ«r ne.Â
Punë paralele e dy sistemeve
Ka ardhur koha e realizimit. Në praktikë, kjo do të thoshte se i japim kontraktorit mundësinë të zhvillojë një prototip të BMS në retn tonë virtuale dhe të japim akses në rrjet për të gjitha pajisjet që kërkojnë monitorim.
NĂ« kĂ«tĂ« moment, megjithatĂ«, sistemi i ri nuk ishte ende gati pĂ«r punĂ«. NĂ« kĂ«tĂ« fazĂ«, ishte e rĂ«ndĂ«sishme pĂ«r ne qĂ« tĂ« ruanim monitorimin nĂ« sistemin e vjetĂ«r dhe nĂ« tĂ« njĂ«jtĂ«n kohĂ« t'u jepnim akses pajisjeve nĂ« sistemin e ri. Nuk Ă«shtĂ« e mundur tĂ« ndĂ«rtohet njĂ« sistem normalisht, pa parĂ« brenda tij pajisjet, tĂ« cilat nga ana tjetĂ«r nuk mund tĂ« çaktivizohen nga monitorimi i sistemit tĂ« vjetĂ«r.Â
A do devices withstand simultaneous polling by two systems, it was not obvious without real trials. There was a chance that dual simultaneous polling would lead to frequent response failures from the devices, resulting in numerous errors due to device unavailability, which would in turn block the operation of the old monitoring system.
The network department routed virtual paths from the prototype of the new BMS deployed in the cloud to the devices, and we received the results:Â
- devices connected via the SNMP protocol hardly dropped connections due to simultaneous requests,Â
- devices connected through gateways using the modbus-TCP protocols faced issues, which were resolved by reasonably reducing their polling frequency. Â
And then we started to observe how a new system was being built before our eyes, with familiar devices appearing, but in a different interface â convenient, fast, and accessible even from a mobile phone.
We will discuss what we ultimately achieved in the third part of our article.
Burimi: habr.com
