I den første delen snakket vi om hvorfor vi bestemte oss for å erstatte det gamle BMS-systemet i datasentrene våre med et nytt. Og ikke bare endre, men utvikle fra bunnen av for å passe dine behov. I den andre delen forteller vi deg hvordan vi gjorde det.
Markedsanalyse
Ta hensyn til de som er beskrevet i ønsker og beslutningen om å nekte å oppdatere det eksisterende systemet, skrev vi en teknisk spesifikasjon for å finne en løsning på markedet og gjorde forespørsler til flere store selskaper kun engasjert i å lage industrielle SCADA-systemer.
De aller første svarene fra dem viste at lederne av overvåkingssystemmarkedet hovedsakelig fortsetter å jobbe på maskinvareservere, selv om prosessen med migrering til skyene i dette segmentet allerede har begynt. Når det gjelder å reservere virtuelle maskiner, var det ingen som støttet dette alternativet. Dessuten var det en følelse av at ingen av de fremtredende utviklerne på markedet i det hele tatt viste en forståelse av behovet for redundans: "skyen faller ikke" var det vanligste svaret. Faktisk ble vi tilbudt å plassere datasenterovervåking i en sky fysisk plassert i samme datasenter.
Her må vi gjøre en liten digresjon om prosessen med å velge en entreprenør. Pris er selvfølgelig viktig, men under ethvert anbud for gjennomføring av et komplekst prosjekt, på stadiet av dialog med leverandører, begynner du å føle hvem av kandidatene som er mer interessert og i stand til å gjennomføre det.
Dette er spesielt merkbart på komplekse prosjekter.
Basert på arten av avklarende spørsmål til de tekniske spesifikasjonene, kan entreprenører deles inn i de som er interessert i å bare selge (standardpresset til en salgssjef merkes) og de som er interessert i å utvikle et produkt, ha hørt og forstått kunden, gjøre konstruktive endringer i de tekniske spesifikasjonene selv før det endelige valget (selv til tross for den reelle risikoen for å forbedre andres tekniske spesifikasjoner og tape anbudet), til slutt er de rett og slett klare til å akseptere en profesjonell utfordring og lage et godt produkt.
Alt dette fikk oss til å ta hensyn til en relativt liten lokal utvikler - Sunline-gruppen av selskaper, som reagerte på de fleste av våre krav umiddelbart og var klar til å implementere alle behovene angående det nye BMS.
Risiko
Mens de store aktørene prøvde å forstå hva vi ønsket og drev rolig korrespondanse med oss med spesialister på forhåndssalgsnivå, avtalte den lokale utvikleren et møte på kontoret vårt med deltakelse av hans tekniske team. På dette møtet viste entreprenøren nok en gang sitt ønske om å delta i prosjektet og, viktigst av alt, forklarte hvordan det nødvendige systemet ville bli implementert.
Før møtet så vi to risikoer ved å jobbe med et team som ikke har ressursene til et stort nasjonalt eller internasjonalt selskap bak seg:
- Spesialister kan overvurdere sine evner og som et resultat rett og slett ikke klare å takle det; for eksempel vil de bruke kompleks programvare eller designe ugjennomførbare reservasjonsalgoritmer.
- Etter at prosjektet er fullført, kan prosjektteamet gå i oppløsning, og derfor vil produktstøtte være i fare.
For å minimere disse risikoene inviterte vi våre egne utviklingsspesialister til møtet. Den potensielle entreprenørens ansatte ble grundig intervjuet om hva systemet bygger på, hvordan redundans planlegges implementert og andre forhold vi som driftstjeneste ikke er kompetente nok på.
Dommen var positiv: Arkitekturen til den eksisterende BMS-plattformen er moderne, enkel og pålitelig, kan forbedres, den foreslåtte redundans- og synkroniseringsordningen er logisk og gjennomførbar.
Den første risikoen ble håndtert. Den andre ble ekskludert etter å ha mottatt bekreftelse fra entreprenøren om at de var klare til å overføre kildekoden til systemet og dokumentasjonen til oss, og også ved å velge Python-programmeringsspråket, som var godt kjent for våre spesialister. Dette garanterte oss muligheten til å vedlikeholde systemet på egen hånd uten problemer og lang periode med opplæring av ansatte i tilfelle utviklingsselskapet skulle forlate markedet.
En ekstra fordel med plattformen var at den ble implementert i Docker-containere: kjernen, webgrensesnittet og produktdatabasefunksjonen i dette miljøet. Denne tilnærmingen gir mange fordeler, inkludert forhåndsinnstilte innstillinger for den høyeste utrullingshastigheten av løsningen sammenlignet med det "klassiske" og enkle tillegget av nye enheter til systemet. "Allsammen"-prinsippet forenkler implementeringen av systemet så mye som mulig: bare pakk ut systemet, så kan du umiddelbart bruke det.
Med denne løsningen er det enklere å lage kopier av systemet, og du kan forbedre det og implementere oppgraderinger i et eget miljø, uten å stoppe driften av løsningen som helhet.
Når begge risikoene var minimert, ga entreprenøren CP. Den dekket alle de viktigste parameterne i BMS-systemet for oss.
Reservasjon
Det nye BMS-systemet måtte være plassert i skyen, på en virtuell maskin.
Ingen maskinvare, ingen servere og alle ulempene og risikoene forbundet med denne distribusjonsmodellen – skyløsningen tillot oss å bli kvitt dem for alltid. Det ble bestemt at systemet skulle operere i skyen vår på to datasentersteder i St. Petersburg og Moskva. Dette er to fullt funksjonelle systemer som opererer i aktiv standby-modus med tilgang til alle autoriserte spesialister.
De to systemene forsikrer hverandre, og gir full reserve av både datakraft og dataoverføringskanaler. Ytterligere sikkerhetstiltak er også konfigurert, inkludert sikkerhetskopiering av data og kanaler, systemer, virtuelle maskiner generelt, og en egen databasesikkerhetskopiering én gang i måneden (den mest verdifulle ressursen når det gjelder styring og analyse).
Merk at redundans som et alternativ i BMS-løsningen ble utviklet spesielt for vår forespørsel. Selve reservasjonsordningen så slik ut:
Støtte
Det viktigste punktet for effektiv drift av en BMS-løsning er teknisk støtte.
Alt er enkelt her: et nytt system vil koste oss 35 000 rubler i henhold til denne indikatoren. per måned for SLA "svar innen 8 timer", det vil si 35 000 x 12 / 80 = $5 250 per år. Det første året er gratis.
Til sammenligning koster vedlikehold av det gamle BMS fra leverandøren $18 000 per år med en økning i beløpet for hver ny enhet som legges til! Samtidig stilte ikke selskapet med en dedikert leder, all interaksjon skjedde gjennom en salgssjef som er interessert i oss som potensiell kjøper med tilsvarende vekt på å behandle forespørsler.
For mindre penger fikk vi full produktstøtte, med en kontoansvarlig som skulle ta del i produktutviklingen, med ett enkelt inngangspunkt osv. Støtten ble mye mer fleksibel - takket være direkte tilgang til utviklere for raske justeringer av alle aspekter av systemet, integrasjon via API, etc.
Oppdateringer
I følge den foreslåtte CP i det nye BMS er alle oppdateringer inkludert i kostnadene for support, d.v.s. krever ikke tilleggsbetaling. Unntaket er utvikling av tilleggsfunksjonalitet utover det som er spesifisert i de tekniske spesifikasjonene.
Det gamle systemet krevde betaling for både fastvareoppdateringer (som Java) og feilrettinger. Det var umulig å nekte dette; i fravær av oppdateringer "bremset systemet" som helhet på grunn av gamle versjoner av interne komponenter.
Og selvfølgelig var det umulig å oppdatere programvaren uten å kjøpe en støttepakke.
Fleksibel tilnærming
Et annet grunnleggende krav gjaldt grensesnittet. Vi ønsket å gi tilgang til den via en nettleser fra hvor som helst, uten obligatorisk tilstedeværelse av en ingeniør på datasenterets territorium. I tillegg søkte vi å lage et animert grensesnitt slik at dynamikken i infrastrukturen skulle være tydeligere for ingeniørene på vakt.
Også i det nye systemet var det nødvendig å gi støtte for formler for beregning av driften av virtuelle sensorer i tekniske systemer - for eksempel for optimal fordeling av elektrisk kraft på tvers av utstyrsstativ. For å gjøre dette, må du ha til din disposisjon alle de vanlige matematiske operasjonene som gjelder for sensorindikatorer.
Deretter var det nødvendig med tilgang til en SQL-database med muligheten til å ta fra den nødvendige data om driften av utstyret - nemlig alle overvåkingspostene til to tusen enheter og to tusen virtuelle sensorer som genererer omtrent 20 tusen variabler.
En regnskapsmodul for stativutstyr var også nødvendig, som ga en grafisk representasjon av arrangementet av enheter i hver enhet med beregning av den totale vekten av maskinvaren, opprettholde et bibliotek med enheter og detaljert informasjon om hvert element.
Godkjenning av tekniske spesifikasjoner og signering av avtale
På det tidspunktet da det var nødvendig å starte arbeidet med det nye systemet, var korrespondanse med "store" selskaper fortsatt veldig langt fra å diskutere kostnadene for forslagene deres, så vi sammenlignet den mottatte CP med kostnadene ved å oppdatere den gamle BMS (se. ), og som et resultat viste det seg å være mer attraktivt i pris og oppfylle kravene våre.
Valget er tatt.
Etter å ha valgt en entreprenør begynte advokater å utarbeide en avtale, og tekniske team fra begge sider begynte å polere de tekniske spesifikasjonene. Som du vet, er detaljerte og kompetente tekniske spesifikasjoner grunnlaget for suksessen til ethvert arbeid. Jo flere detaljer det er i de tekniske spesifikasjonene, jo mindre skuffelser som "men dette er ikke det vi ønsket."
Jeg vil gi to eksempler på detaljeringsgraden av krav i de tekniske spesifikasjonene:
- Datasentre på vakt har fullmakt til å legge til nye enheter til BMS, oftest er disse PDUer. I det gamle BMS var dette nivået "administrator", som også tillot å endre de variable innstillingene for alle enheter, og det var umulig å skille funksjonene. Dette passet ikke oss. I den eksisterende grunnversjonen av den nye plattformen var ordningen lik. Vi indikerte umiddelbart i mandatet at vi ønsket å skille disse rollene: Bare en autorisert ansatt skal endre innstillingene, men de på vakt skal fortsatt kunne legge til enheter. Denne ordningen ble akseptert for implementering.
- I enhver standard BMS er det tre typiske varslingskategorier: RØD - må svares umiddelbart, GUL - kan observeres, BLÅ - "Informativ". Vi har tradisjonelt brukt blå varsler for å overvåke når forretningsparametere har blitt overskredet, for eksempel at en kundes rack overskrider kapasitetsgrensen. Denne typen varsling i vårt tilfelle var ment for ledere og var ikke av interesse for driftstjenesten, men i det gamle BMS tettet det jevnlig listen over aktive hendelser og forstyrret operativt arbeid. Vi anså selve logikken og fargedifferensieringen til varslingsbuksene for å være vellykket og beholdt den, men de tekniske spesifikasjonene indikerte spesifikt at "blå" varsler skulle, uten å distrahere vaktbetjentene, stille "helle" inn i en egen seksjon, der de vil bli behandlet av kommersielle spesialister.
Med en lignende grad av detaljer ble formatene for å konstruere grafer og generere rapporter, konturene av grensesnittene, listen over enheter som måtte overvåkes og mange andre ting foreskrevet.
Dette var et virkelig kreativt arbeid av tre arbeidsgrupper - kundeservicen, som dikterte kravene og betingelsene; tekniske spesialister på begge sider, hvis oppgave var å forvandle disse forholdene til teknisk dokumentasjon; team av entreprenørprogrammerere som implementerte kundens krav i henhold til utviklet teknisk dokumentasjon... Som et resultat tilpasset vi noen av våre uprinsipielle krav til funksjonaliteten til en eksisterende plattform, og entreprenøren forpliktet seg til å tilføre noe for oss.
Parallell drift av to systemer
Det er tid for implementering. I praksis innebar dette at vi gir entreprenøren muligheten til å distribuere en BMS-prototype i vår virtuelle sky og gi nettverkstilgang til alle enheter som krever overvåking.
Det nye systemet var imidlertid ennå ikke klart for drift. På dette stadiet var det viktig for oss å opprettholde overvåking i det gamle systemet og samtidig gi tilgang til enhetene til det nye systemet. Det er umulig å bygge et system riktig uten å se enheter i det, som igjen ikke kan deaktiveres fra overvåking av det gamle systemet.
Hvorvidt enhetene kunne tåle samtidig avhør av to systemer var ikke åpenbart uten reell testing. Det var en mulighet for at dobbel samtidig polling ville føre til hyppige avslag på å svare fra enheter og vi ville motta mange feil angående utilgjengelighet av enheter, som igjen ville blokkere driften av det gamle overvåkingssystemet.
Nettverksavdelingen kjørte virtuelle ruter fra en prototype av den nye BMS-en distribuert i skyen til enhetene, og vi fikk resultatene:
- enheter koblet til via SNMP-protokollen ble praktisk talt aldri koblet fra på grunn av samtidige forespørsler,
- enheter koblet gjennom gatewayer ved hjelp av modbas-TCP-protokoller hadde problemer som ble løst ved å intelligent redusere polling-frekvensen.
Og så begynte vi å observere hvordan et nytt system ble bygget foran øynene våre, enheter som allerede var kjent for oss dukket opp i det, men i et annet grensesnitt - praktisk, raskt, tilgjengelig selv fra en telefon.
Vi vil fortelle deg hva som skjedde til slutt i den tredje delen av artikkelen vår.
Kilde: www.habr.com