Ensimmäisessä osassa puhuimme siitä, miksi päätimme vaihtaa vanhan BMS-järjestelmän konesaleissamme uuteen. Eikä vain muuta, vaan kehity alusta alkaen tarpeidesi mukaan. Toisessa osassa kerromme kuinka teimme sen.
Markkina-analyysi
Ottaen huomioon kohdassa kuvatut toiveista ja päätöksestä kieltäytyä nykyisen järjestelmän päivittämisestä, kirjoitimme teknisen spesifikaation löytääksemme ratkaisun markkinoille ja teimme tiedustelut useille suurille yrityksille, jotka harjoittavat vain teollisten SCADA-järjestelmien luomista.
Heiltä saadut ensimmäiset vastaukset osoittivat, että valvontajärjestelmämarkkinoiden johtajat jatkavat ensisijaisesti laitteistopalvelimien parissa työskentelemistä, vaikka siirtyminen pilviin tällä segmentillä on jo alkanut. Mitä tulee virtuaalikoneiden varaamiseen, kukaan ei tukenut tätä vaihtoehtoa. Lisäksi jäi tunne, ettei kukaan markkinoilla näkyvistä kehittäjistä edes osoittanut ymmärrystä redundanssin tarpeesta: "pilvi ei putoa" oli yleisin vastaus. Itse asiassa meille tarjottiin palvelinkeskuksen valvonnan sijoittamista pilveen, joka sijaitsee fyysisesti samassa palvelinkeskuksessa.
Tässä meidän on tehtävä pieni poikkeama urakoitsijan valintaprosessista. Hinnalla on tietysti väliä, mutta missä tahansa tarjouskilpailussa monimutkaisen projektin toteuttamiseksi, toimittajien kanssa käytävän vuoropuhelun vaiheessa alat tuntea, kumpi ehdokkaista on kiinnostunut ja kykenevämpi toteuttamaan sen.
Tämä on erityisen havaittavissa monimutkaisissa projekteissa.
Teknisten eritelmien selventävien kysymysten luonteen perusteella urakoitsijat voidaan jakaa yksinkertaisesti myynnistä kiinnostuneisiin (myyntipäällikön standardipaine tuntuu) ja tuotteen kehittämisestä kiinnostuneisiin, jotka ovat kuulleet ja ymmärtäneet asiakkaan, rakentavan Muutokset teknisiin eritelmiin jo ennen lopullista valintaa (vaikka todellisesta vaarasta parantaa jonkun muun teknisiä eritelmiä ja hävitä tarjous), he ovat lopulta valmiita ottamaan vastaan ammattihaasteen ja tekemään hyvän tuotteen.
Kaikki tämä sai meidät kiinnittämään huomiota suhteellisen pieneen paikalliseen kehittäjään - Sunline-yritysryhmään, joka vastasi välittömästi useimpiin vaatimuksiimme ja oli valmis toteuttamaan kaikki uuden BMS:n tarpeet.
Riskit
Sillä aikaa, kun suuret pelaajat yrittivät ymmärtää, mitä halusimme, ja jatkoivat rauhallista kirjeenvaihtoa kanssamme ennakkomyyntitason asiantuntijoiden kanssa, paikallinen kehittäjä järjesti toimistollemme tapaamisen, johon hänen teknisen tiiminsä osallistui. Tässä kokouksessa urakoitsija osoitti jälleen halunsa osallistua hankkeeseen ja mikä tärkeintä, selitti, kuinka vaadittu järjestelmä toteutetaan.
Ennen kokousta näimme kaksi riskiä työskennellä tiimin kanssa, jolla ei ole takanaan suuren kansallisen tai kansainvälisen yrityksen resursseja:
- Asiantuntijat voivat yliarvioida kykynsä ja sen seurauksena yksinkertaisesti epäonnistua; he esimerkiksi käyttävät monimutkaisia ohjelmistoja tai suunnittelevat mahdottomia varausalgoritmeja.
- Projektin päätyttyä projektitiimi voi hajota, jolloin tuotetuki on vaarassa.
Näiden riskien minimoimiseksi kutsuimme kokoukseen omat kehitysasiantuntijamme. Potentiaalisen urakoitsijan työntekijöitä haastateltiin perusteellisesti siitä, mihin järjestelmä perustuu, miten irtisanomisia suunnitellaan toteuttamaan ja muista asioista, joissa emme käyttöpalveluna ole riittävän päteviä.
Tuomio oli myönteinen: nykyisen BMS-alustan arkkitehtuuri on moderni, yksinkertainen ja luotettava, sitä voidaan parantaa, ehdotettu redundanssi- ja synkronointimalli on looginen ja toimiva.
Ensimmäinen riski käsiteltiin. Toinen poistettiin saatuaan urakoitsijalta vahvistuksen, että he olivat valmiita siirtämään järjestelmän lähdekoodia ja dokumentaatiota meille, sekä valitsemalla asiantuntijoidemme hyvin tunteman Python-ohjelmointikielen. Tämä takasi meille mahdollisuuden ylläpitää järjestelmää omatoimisesti ilman vaikeuksia ja pitkän henkilöstökoulutuksen, mikäli kehitysyhtiö lähtisi markkinoilta.
Alustan lisäetu oli, että se toteutettiin Docker-säiliöissä: ydin, web-käyttöliittymä ja tuotetietokantatoiminto tässä ympäristössä. Tämä lähestymistapa tarjoaa monia etuja, mukaan lukien esiasetetut asetukset, jotka mahdollistavat ratkaisun nopeimman käyttöönoton "klassiseen" verrattuna ja uusien laitteiden helpon lisäämisen järjestelmään. "Kaikki yhdessä" -periaate yksinkertaistaa järjestelmän käyttöönottoa mahdollisimman paljon: vain pura järjestelmä ja voit käyttää sitä heti.
Tämän ratkaisun avulla järjestelmästä on helpompi tehdä kopioita, ja sitä voi parantaa ja toteuttaa päivitykset erillisessä ympäristössä ilman, että koko ratkaisun toiminta pysähtyy.
Kun molemmat riskit oli minimoitu, urakoitsija toimitti CP:n. Se kattoi kaikki meille tärkeimmät BMS-järjestelmän parametrit.
Varaus
Uusi BMS-järjestelmä oli sijoitettava pilveen, virtuaalikoneeseen.
Ei laitteistoa, ei palvelimia ja kaikkia tähän käyttöönottomalliin liittyviä haittoja ja riskejä – pilviratkaisu antoi meille mahdollisuuden päästä eroon niistä ikuisesti. Päätettiin, että järjestelmä toimisi pilvessämme kahdessa palvelinkeskuksessa Pietarissa ja Moskovassa. Nämä ovat kaksi täysin toimivaa järjestelmää, jotka toimivat aktiivisessa valmiustilassa ja joihin pääsevät kaikki valtuutetut asiantuntijat.
Molemmat järjestelmät vakuuttavat toisensa ja tarjoavat täyden reservin sekä laskentateholle että tiedonsiirtokanaville. Myös lisäturvatoimenpiteitä on konfiguroitu, mukaan lukien tietojen ja kanavien, järjestelmien, virtuaalikoneiden varmuuskopiointi yleensä ja erillinen tietokannan varmuuskopiointi kerran kuukaudessa (hallinnan ja analyysin kannalta arvokkain resurssi).
Huomaa, että redundanssi vaihtoehtona BMS-ratkaisussa on kehitetty erityisesti meidän pyynnöstämme. Itse varausjärjestelmä näytti tältä:
Tukea
BMS-ratkaisun tehokkaan toiminnan tärkein asia on tekninen tuki.
Täällä kaikki on yksinkertaista: uusi järjestelmä maksaisi meille tämän indikaattorin mukaan 35 000 ruplaa. kuukaudessa SLA:n "vastaukselle 8 tunnin sisällä", eli 35 000 x 12 / 80 = 5 250 dollaria vuodessa. Ensimmäinen vuosi on ilmainen.
Vertailun vuoksi: toimittajan vanhan BMS:n ylläpito maksoi 18 000 dollaria vuodessa, ja jokaista lisättyä uutta laitetta kohden lisätty määrä! Samaan aikaan yhtiö ei tarjonnut omaa johtajaa, vaan kaikki vuorovaikutus tapahtui myyntipäällikön kautta, joka on kiinnostunut meistä potentiaalisena ostajana painottaen vastaavasti pyyntöjen käsittelyä.
Pienemmällä rahalla saimme täyden tuotetuen, asiakaspäällikön, joka osallistui tuotekehitykseen, yhdellä sisääntulopisteellä jne. Tuki muuttui paljon joustavammaksi – kiitos suoran pääsyn kehittäjiin järjestelmän minkä tahansa osa-alueen nopeaan säätöön, API:n kautta tapahtuvaan integrointiin jne.
Päivitykset
Uuden BMS:n ehdotetun CP:n mukaan kaikki päivitykset sisältyvät tukikustannuksiin, ts. eivät vaadi lisämaksua. Poikkeuksena on lisätoimintojen kehittäminen teknisissä eritelmissä määritellyn lisäksi.
Vanha järjestelmä vaati maksun sekä laiteohjelmistopäivityksistä (kuten Java) että virheenkorjauksista. Tästä oli mahdotonta kieltäytyä; päivitysten puuttuessa järjestelmä kokonaisuudessaan "hidastui" sisäisten komponenttien vanhojen versioiden vuoksi.
Ja tietysti oli mahdotonta päivittää ohjelmistoa ostamatta tukipakettia.
Joustava lähestymistapa
Toinen perustavanlaatuinen vaatimus koski käyttöliittymää. Halusimme tarjota pääsyn siihen verkkoselaimen kautta mistä tahansa, ilman insinöörin pakollista läsnäoloa palvelinkeskuksen alueella. Lisäksi pyrimme luomaan animoidun käyttöliittymän, jotta infrastruktuurin dynamiikka olisi päivystävälle insinöörille selkeämpi.
Myös uudessa järjestelmässä oli tarpeen tarjota tukea kaavoille virtuaalisten antureiden toiminnan laskemiseksi suunnittelujärjestelmissä - esimerkiksi sähkötehon optimaalista jakautumista varten laitetelineiden välillä. Tätä varten sinulla on oltava käytettävissäsi kaikki tavanomaiset anturiindikaattoreihin sovellettavat matemaattiset toiminnot.
Seuraavaksi vaadittiin pääsy SQL-tietokantaan, jotta siitä voidaan ottaa tarvittavat tiedot laitteiden toiminnasta - nimittäin kaikki kahden tuhannen laitteen ja kahden tuhannen virtuaalisen anturin valvontatietueet, jotka tuottavat noin 20 tuhatta muuttujaa.
Tarvittiin myös telinelaitteiden laskentamoduuli, joka tarjoaa graafisen esityksen laitteiden sijoittelusta kussakin yksikössä laitteiston kokonaispainon laskennalla, laitekirjaston ylläpidolla ja yksityiskohtaiset tiedot jokaisesta elementistä.
Teknisten eritelmien hyväksyminen ja sopimuksen allekirjoittaminen
Kun uuden järjestelmän parissa piti aloittaa työskentely, kirjeenvaihto "suurten" yritysten kanssa oli vielä hyvin kaukana keskustelusta heidän ehdotustensa kustannuksista, joten vertailimme saatua CP:tä vanhan BMS:n päivittämisen kustannuksiin (ks. ), ja sen seurauksena se osoittautui houkuttelevammaksi hinnaltaan ja vastaa vaatimuksiamme.
Valinta on tehty.
Urakoitsijan valinnan jälkeen lakimiehet alkoivat laatia sopimusta, ja molempien osapuolten tekniset tiimit alkoivat hioa teknisiä eritelmiä. Kuten tiedät, yksityiskohtaiset ja pätevät tekniset tiedot ovat perusta minkä tahansa työn onnistumiselle. Mitä tarkempia teknisissä tiedoissa on, sitä vähemmän pettymyksiä kuten "mutta tämä ei ole sitä, mitä halusimme".
Annan kaksi esimerkkiä teknisten eritelmien vaatimusten yksityiskohtaisuudesta:
- Päivystävällä datakeskuksella on valtuudet lisätä uusia laitteita BMS:ään, useimmiten nämä ovat PDU:ita. Vanhassa BMS:ssä tämä oli "järjestelmänvalvojan" taso, joka mahdollisti myös kaikkien laitteiden muuttuvien asetusten muuttamisen, eikä toimintoja ollut mahdollista erottaa toisistaan. Tämä ei sopinut meille. Uuden alustan nykyisessä perusversiossa järjestelmä oli samanlainen. Ilmoitimme heti toimeksiannoissa, että halusimme erottaa nämä roolit: vain valtuutettu työntekijä saa muuttaa asetuksia, mutta päivystävät saavat jatkossakin lisätä laitteita. Tämä suunnitelma hyväksyttiin toteutettavaksi.
- Kaikissa standardeissa BMS:ssä on kolme tyypillistä ilmoitusluokkaa: PUNAINEN - on vastattava välittömästi, KELTAINEN - havaittavissa, SININEN - "Tietoa". Olemme perinteisesti käyttäneet sinisiä hälytyksiä valvomaan liiketoimintaparametrien ylittymistä, kuten asiakkaan telineen kapasiteettirajan ylittymistä. Tämäntyyppinen ilmoitus meidän tapauksessamme oli suunnattu esimiehille, eikä se kiinnostanut operatiivista palvelua, mutta vanhassa BMS:ssä se tukkisi säännöllisesti aktiivisten poikkeamien luetteloa ja häiritsi operatiivista työtä. Pidämme ilmoitushousujen logiikkaa ja värierottelua onnistuneena ja säilytimme sen, mutta tekniset eritelmät osoittivat nimenomaisesti, että "sinisten" ilmoitusten tulisi päivystäviä häiritsemättä "vuodata" äänettömästi erilliseen osioon, jossa ne käsitellään kaupallisten asiantuntijoiden toimesta.
Samalla tarkkuudella määrättiin kaavioiden ja raporttien muodostamisen muodot, rajapintojen ääriviivat, luettelo valvottavista laitteista ja paljon muuta.
Tämä oli kolmen työryhmän – asiakaspalvelun, joka saneli vaatimukset ja ehdot; molempien osapuolten tekniset asiantuntijat, joiden tehtävänä oli muuttaa nämä ehdot tekniseksi dokumentaatioksi; urakoitsijaohjelmoijatiimit, jotka toteuttivat asiakkaan vaatimukset kehitetyn teknisen dokumentaation mukaan... Tämän seurauksena sovitimme osan periaatteettomista vaatimuksistamme olemassa olevan alustan toimivuuteen, ja urakoitsija sitoutui lisäämään jotain meille.
Kahden järjestelmän rinnakkainen toiminta
On toteutuksen aika. Käytännössä tämä tarkoitti sitä, että annoimme urakoitsijalle mahdollisuuden ottaa käyttöön BMS-prototyyppi virtuaalipilvessämme ja tarjota verkkoyhteys kaikille valvontaa vaativille laitteille.
Uusi järjestelmä ei kuitenkaan ollut vielä valmis käyttöön. Tässä vaiheessa meille oli tärkeää säilyttää valvonta vanhassa järjestelmässä ja samalla päästää laitteisiin uuteen järjestelmään. Järjestelmää on mahdotonta rakentaa kunnolla näkemättä siinä laitteita, joita ei puolestaan voida estää vanhan järjestelmän valvontaa.
Se, kestivätkö laitteet kahden järjestelmän samanaikaisen kyselyn, ei ollut selvää ilman todellista testausta. Oli mahdollista, että kaksinkertainen samanaikainen kysely johtaisi toistuviin laitteilta kieltäytymiseen ja saisimme paljon virheitä laitteiden epäkäytettävyydestä, mikä puolestaan estäisi vanhan valvontajärjestelmän toiminnan.
Verkkoosasto ajoi virtuaalisia reittejä pilvessä käyttöönotetun uuden BMS:n prototyypistä laitteisiin, ja saimme tulokset:
- SNMP-protokollalla yhdistetyt laitteet eivät käytännössä koskaan katkenneet samanaikaisten pyyntöjen vuoksi,
- yhdyskäytävien kautta modbas-TCP-protokollia käyttävillä laitteilla oli ongelmia, jotka ratkaistiin vähentämällä älykkäästi niiden kyselytaajuutta.
Ja sitten aloimme tarkkailla, kuinka uusi järjestelmä rakennettiin silmiemme edessä, siihen ilmestyi meille jo tuttuja laitteita, mutta eri käyttöliittymässä - kätevä, nopea, saatavilla jopa puhelimesta.
Kerromme sinulle, mitä lopulta tapahtui artikkelimme kolmannessa osassa.
Lähde: will.com