Yn it earste diel hawwe wy it oer wêrom't wy besletten it âlde BMS-systeem yn ús datasintra te ferfangen troch in nij. En net allinich feroarje, mar ûntwikkelje fanôf it begjin om oan jo easken te passen. Yn it twadde diel fertelle wy hoe't wy it dien hawwe.
Market Analysis
Rekken hâldend mei dy beskreaun yn winsken en it beslút om te wegerjen om it besteande systeem te aktualisearjen, hawwe wy in technyske spesifikaasje skreaun om in oplossing op 'e merk te finen en fragen makke oan ferskate grutte bedriuwen dy't allinich dwaande binne mei it meitsjen fan yndustriële SCADA-systemen.
De alderearste antwurden fan har lieten sjen dat de lieders fan 'e merk foar tafersjochsystemen yn it foarste plak trochgean te wurkjen oan hardware-tsjinners, hoewol it proses fan migraasje nei de wolken yn dit segmint al begon is. Wat it reservearjen fan firtuele masines oanbelanget, stipe gjinien dizze opsje. Boppedat wie d'r in gefoel dat net ien fan 'e ûntwikkelders sichtber op' e merk sels in begryp fan 'e needsaak foar redundânsje toande: "de wolk falt net" wie it meast foarkommende antwurd. Yn feite waarden wy oanbean om tafersjoch op it datasintrum te pleatsen yn in wolk fysyk yn itselde datasintrum.
Hjir moatte wy in lytse digresje meitsje oer it proses fan it selektearjen fan in oannimmer. Priis is fansels fan belang, mar by elke oanbesteging foar de útfiering fan in kompleks projekt, op it poadium fan dialooch mei leveransiers, begjinne jo te fielen hokker fan 'e kandidaten mear ynteressearre is en yn steat is om it út te fieren.
Dat is benammen opfallend by komplekse projekten.
Op grûn fan 'e aard fan ferdúdlikjende fragen nei de technyske spesifikaasjes, kinne oannimmers wurde ferdield yn dyjingen dy't ynteressearre binne yn gewoan ferkeapjen (de standertdruk fan in ferkeapmanager wurdt field) en dyjingen dy't ynteressearre binne yn it ûntwikkeljen fan in produkt, hawwe heard en begrepen de klant, meitsje konstruktyf amendeminten oan de technyske spesifikaasjes noch foar de definitive kar (sels nettsjinsteande de echte it risiko fan ferbetterjen fan in oar syn technyske spesifikaasjes en ferlieze de oanbesteging), op it lêst binne se gewoan ree om te akseptearjen in profesjonele útdaging en meitsje in goed produkt.
Dit alles makke ús omtinken te jaan oan in relatyf lytse lokale ûntwikkelder - de Sunline-groep fan bedriuwen, dy't fuortendaliks reagearre op de measte fan ús easken en wie ree om alle behoeften oangeande it nije BMS út te fieren.
Risiken
Wylst de grutte spilers besochten te begripen wat wy woenen en in rêstige korrespondinsje mei ús fierden mei spesjalisten foar foarferkeapnivo, plande de pleatslike ûntwikkelder in gearkomste yn ús kantoar mei de dielname fan syn technyske team. Op dizze gearkomste demonstrearre de oannimmer nochris syn winsk om diel te nimmen oan it projekt en, it wichtichste, ferklearre hoe't it fereaske systeem ymplementearre wurde soe.
Foar de gearkomste seagen wy twa risiko's fan it wurkjen mei in team dat net de middels fan in grut nasjonaal of ynternasjonaal bedriuw efter har hat:
- Spesjalisten kinne har kapasiteiten oerskatte en, as gefolch, gewoan net omgean; se sille bygelyks komplekse software brûke of ûnmooglike reservearringsalgoritmen ûntwerpe.
- Nei it projekt is foltôge, kin it projektteam ûntbine en dêrom sil produktstipe yn gefaar wêze.
Om dizze risiko's te minimalisearjen hawwe wy ús eigen ûntwikkelingsspesjalisten útnoege foar de gearkomste. De meiwurkers fan 'e potinsjele oannimmer waarden yngeand ynterviewd oer wêr't it systeem op basearre is, hoe't ûntslach is pland om te ymplementearjen en oare saken wêryn't wy as operaasjetsjinst net kompetint genôch binne.
It oardiel wie posityf: de arsjitektuer fan it besteande BMS-platfoarm is modern, ienfâldich en betrouber, kin ferbettere wurde, it foarstelde ûntslach en syngronisaasjeskema is logysk en wurkber.
It earste risiko waard behannele. De twadde waard útsletten nei it ûntfangen fan befêstiging fan 'e oannimmer dat se ree wiene om de boarnekoade fan it systeem en dokumintaasje oan ús oer te bringen, en ek troch te kiezen foar de programmeartaal Python, dy't ús spesjalisten goed bekend wie. Dit garandearre ús de kâns om it systeem op ús eigen te behâlden sûnder swierrichheden en in lange perioade fan training fan meiwurkers yn it gefal fan it ûntwikkelbedriuw dat de merk ferlit.
In ekstra foardiel fan it platfoarm wie dat it waard ymplementearre yn Docker-konteners: de kernel, webynterface en produktdatabasefunksje yn dizze omjouwing. Dizze oanpak jout in protte foardielen, ynklusyf foarôf ynstelde ynstellings foar de heechste snelheid fan ynset fan 'e oplossing yn ferliking mei de "klassike" en maklike tafoeging fan nije apparaten oan it systeem. It prinsipe fan "allegear tegearre" makket de ymplemintaasje fan it systeem safolle mooglik ferienfâldigje: gewoan it systeem útpakke en jo kinne it daliks brûke.
Mei dizze oplossing is it makliker om kopyen fan it systeem te meitsjen, en jo kinne it ferbetterje en upgrades yn in aparte omjouwing útfiere, sûnder de wurking fan 'e oplossing as gehiel te stopjen.
Ienris waarden beide risiko's minimalisearre, levere de oannimmer de CP. It behannele alle wichtichste parameters fan it BMS-systeem foar ús.
Reservaat
It nije BMS-systeem moast yn 'e wolk sitte, op in firtuele masine.
Gjin hardware, gjin servers en alle ûngemak en risiko's ferbûn mei dit ynsetmodel - de wolkoplossing liet ús foar altyd kwytreitsje. It waard besletten dat it systeem soe operearje yn ús wolk op twa data center sites yn Sint Petersburg en Moskou. Dit binne twa folslein funksjonele systemen dy't wurkje yn aktive standby-modus mei tagong ta alle autorisearre spesjalisten.
De twa systemen fersekerje inoar, en jouwe folsleine reserve fan sawol berekkeningskrêft as datatransmissionkanalen. Oanfoljende feiligensmaatregels binne ek konfigureare, ynklusyf reservekopy fan gegevens en kanalen, systemen, firtuele masines yn 't algemien, en in aparte database-backup ien kear yn'e moanne (de meast weardefolle boarne yn termen fan behear en analyse).
Tink derom dat redundânsje as opsje yn 'e BMS-oplossing spesifyk is ûntwikkele foar ús fersyk. It reservaatskema sels seach der sa út:
stipe
It wichtichste punt foar de effektive wurking fan in BMS-oplossing is technyske stipe.
Alles is ienfâldich hjir: in nij systeem soe kostje ús 35 roebel neffens dizze yndikator. per moanne foar de SLA "antwurd binnen 000 oeren", dat is, 8 x 35 / 000 = $ 12 per jier. It earste jier is fergees.
Foar ferliking, it behâld fan 'e âlde BMS fan' e ferkeaper koste $ 18 yn 't jier mei in ferheging fan it bedrach foar elk nij tafoege apparaat! Tagelyk levere it bedriuw gjin tawijd manager; alle ynteraksje fûn plak troch in ferkeapmanager dy't ynteressearre is yn ús as in potinsjele keaper mei in oerienkommende klam by it ferwurkjen fan oanfragen.
Foar minder jild krigen wy folsleine produktstipe, mei in accountmanager dy't meidwaan soe oan produktûntwikkeling, mei ien yngongspunt, ensfh. Stipe waard folle fleksibeler - tank oan direkte tagong ta ûntwikkelders foar rappe oanpassingen oan elk aspekt fan it systeem, yntegraasje fia API, ensfh.
Updates
Neffens de foarstelde CP yn 'e nije BMS binne alle updates opnommen yn' e kosten fan stipe, d.w.s. net nedich ekstra betelling. De útsûndering is de ûntwikkeling fan ekstra funksjonaliteit boppe wat spesifisearre is yn 'e technyske spesifikaasjes.
It âlde systeem easke betelling foar sawol firmware-updates (lykas Java) as bugfixes. It wie ûnmooglik om dit te wegerjen; by it ûntbrekken fan updates, it systeem as gehiel "fertrage" fanwegen âlde ferzjes fan ynterne komponinten.
En fansels wie it ûnmooglik om de software te aktualisearjen sûnder in stipepakket te keapjen.
Fleksibele oanpak
In oare fûnemintele eask oangeande de ynterface. Wy woenen tagong ta it fia in webblêder fan oeral, sûnder de ferplichte oanwêzigens fan in yngenieur op it grûngebiet fan it datasintrum. Derneist sochten wy in animearre ynterface te meitsjen sadat de dynamyk fan 'e ynfrastruktuer dúdliker wêze soe foar de yngenieurs op plicht.
Ek yn it nije systeem wie it nedich om stipe te jaan foar formules foar it berekkenjen fan de wurking fan firtuele sensoren yn engineeringsystemen - bygelyks foar de optimale ferdieling fan elektryske krêft oer apparatuerrekken. Om dit te dwaan, moatte jo alle gewoane wiskundige operaasjes hawwe dy't fan tapassing binne op sensor-yndikatoaren.
Dêrnei wie tagong ta in SQL-database nedich mei de mooglikheid om derút de nedige gegevens oer de wurking fan 'e apparatuer te nimmen - nammentlik alle monitoaringsrekords fan twatûzen apparaten en twatûzen firtuele sensors dy't sawat 20 tûzen fariabelen generearje.
In rack apparatuer boekhâlding module wie ek nedich, it jaan fan in grafyske foarstelling fan de regeling fan apparaten yn elke ienheid mei berekkening fan it totale gewicht fan de hardware, it behâld fan in bibleteek fan apparaten en detaillearre ynformaasje oer elk elemint.
Goedkarring fan technyske spesifikaasjes en ûndertekening fan in oerienkomst
Op it stuit dat it nedich wie om te begjinnen mei it nije systeem, korrespondinsje mei "grutte" bedriuwen wie noch hiel fier fan it besprekken fan de kosten fan harren foarstellen, dus wy fergelike de ûntfongen CP mei de kosten fan it bywurkjen fan de âlde BMS (sjoch. ), en dêrtroch die bliken dat it oantrekliker wie yn priis en foldie oan ús easken.
De kar is makke.
Nei it selektearjen fan in oannimmer begûnen advokaten in oerienkomst op te stellen, en technyske teams fan beide kanten begûnen de technyske spesifikaasjes te polearjen. Lykas jo witte, detaillearre en kompetinte technyske spesifikaasjes binne de basis foar it sukses fan elk wurk. Hoe mear spesifikaasjes d'r binne yn 'e technyske spesifikaasjes, hoe minder teloarstellingen lykas "mar dit is net wat wy woenen."
Ik sil twa foarbylden jaan fan it detailnivo fan easken yn 'e technyske spesifikaasjes:
- Datasintra yn tsjinst binne machtich om nije apparaten ta te foegjen oan 'e BMS, meastentiids binne dit PDU's. Yn 'e âlde BMS wie dit it nivo fan "administrator", wêrtroch ek de fariabele ynstellings fan alle apparaten kinne feroarje, en it wie ûnmooglik om de funksjes te skieden. Dit paste ús net. Yn 'e besteande basisferzje fan it nije platfoarm wie it skema ferlykber. Wy hawwe yn de oanfraach daliks oanjûn dat wy dizze rollen skieden woene: allinnich in autorisearre meiwurker moat de ynstellings feroarje, mar de tsjinstplichtigen moatte der noch apparaten taheakje kinne. Dit skema waard akseptearre foar ymplemintaasje.
- Yn elke standert BMS binne d'r trije typyske kategoryen fan notifikaasjes: RED - moat fuortendaliks reageare wurde, GEEL - kin wurde waarnommen, BLAUW - "Ynformatyf". Wy hawwe tradisjoneel blauwe warskôgings brûkt om te kontrolearjen wannear't bedriuwsparameters binne oerskreaun, lykas it rek fan in klant dy't syn kapasiteitslimyt oerstjit. Dit soarte fan notifikaasje yn ús gefal wie bedoeld foar managers en wie net fan belang foar de operaasje tsjinst, mar yn 'e âlde BMS it geregeld ferstoppe de list fan aktive ynsidinten en bemuoie mei operasjoneel wurk. Wy beskôgen de tige logika en kleurdifferinsjaasje fan 'e notifikaasjebroek suksesfol en behâlden it, lykwols, de technyske spesifikaasjes spesifyk oanjûn dat "blauwe" notifikaasjes moatte, sûnder de tsjinstoffisieren te ôfliede, stilwei "útgiet" yn in aparte seksje, wêr't se sil wurde behannele troch kommersjele spesjalisten.
Mei in ferlykbere graad fan detail waarden de formaten foar it bouwen fan grafiken en it generearjen fan rapporten, de sketsen fan ynterfaces, de list mei apparaten dy't moatte wurde kontrolearre, en in protte oare dingen foarskreaun.
Dit wie in wier kreatyf wurk fan trije wurkgroepen - de klanttsjinst, dy't har easken en betingsten diktearre; technyske spesjalisten oan beide kanten, waans taak wie om dizze betingsten te transformearjen yn technyske dokumintaasje; teams fan oannimmer programmeurs dy't útfierd de klant syn easken neffens de ûntwikkele technyske dokumintaasje ... As gefolch, wy oanpast guon fan ús unprincipled easken oan 'e funksjonaliteit fan in besteande platfoarm, en de oannimmer ûndernimme te foegjen wat foar ús.
Parallel operaasje fan twa systemen
It is tiid foar ymplemintaasje. Yn 'e praktyk betsjutte dit dat wy de oannimmer de kâns jaan om in BMS-prototype yn ús firtuele wolk yn te setten en netwurk tagong te jaan oan alle apparaten dy't tafersjoch nedich binne.
It nije systeem wie lykwols noch net klear foar operaasje. Op dit stadium wie it wichtich foar ús om tafersjoch te hâlden yn it âlde systeem en tagelyk tagong te jaan oan de apparaten nei it nije systeem. It is ûnmooglik om in systeem goed te bouwen sûnder apparaten dêryn te sjen, dy't op syn beurt net kinne wurde útskeakele fan tafersjoch troch it âlde systeem.
Oft de apparaten tagelyk ûnderfreegjen troch twa systemen koenen wjerstean, wie net dúdlik sûnder echte testen. D'r wie in mooglikheid dat dûbele simultane polling soe liede ta faak wegering om te reagearjen fan apparaten en wy soene in protte flaters krije oangeande de net-beskikberens fan apparaten, dy't op syn beurt de wurking fan it âlde tafersjochsysteem blokkearje.
De netwurkôfdieling rûn firtuele rûtes fan in prototype fan it nije BMS ynset yn 'e wolk nei de apparaten, en wy krigen de resultaten:
- apparaten ferbûn fia it SNMP-protokol waarden praktysk nea loskeppele fanwege simultane oanfragen,
- apparaten ferbûn fia poarten mei help fan modbas-TCP protokollen hie problemen dy't waarden oplost troch yntelligint ferminderjen harren polling frekwinsje.
En doe begûnen wy te observearjen hoe't in nij systeem foar ús eagen waard boud, apparaten dy't ús al bekend wiene, ferskynden deryn, mar yn in oare ynterface - handich, fluch, tagonklik sels fan in tillefoan.
Wy sille fertelle wat der barde yn 'e ein yn it tredde diel fan ús artikel.
Boarne: www.habr.com