I første del talte vi om, hvorfor vi besluttede at udskifte det gamle BMS-system i vores datacentre med et nyt. Og ikke bare ændre, men udvikle fra bunden, så det passer til dine krav. I anden del fortæller vi dig, hvordan vi gjorde det.
Markedsanalyse
Under hensyntagen til dem, der er beskrevet i ønsker og beslutningen om at nægte at opdatere det eksisterende system, skrev vi en teknisk specifikation for at finde en løsning på markedet og lavede forespørgsler til flere store virksomheder, der udelukkende beskæftiger sig med skabelsen af industrielle SCADA-systemer.
De allerførste svar fra dem viste, at lederne af markedet for overvågningssystemer overvejende fortsætter med at arbejde på hardwareservere, selvom processen med migrering til skyerne i dette segment allerede er begyndt. Hvad angår reservation af virtuelle maskiner, understøttede ingen denne mulighed. Desuden var der en fornemmelse af, at ingen af de synlige udviklere på markedet overhovedet demonstrerede en forståelse af behovet for redundans: "skyen falder ikke" var det mest almindelige svar. Faktisk blev vi tilbudt at placere datacenterovervågning i en sky fysisk placeret i samme datacenter.
Her skal vi lave en lille digression om processen med at vælge en entreprenør. Prisen har selvfølgelig betydning, men under ethvert udbud til gennemførelse af et komplekst projekt, i dialogfasen med leverandører, begynder man at mærke, hvem af kandidaterne der er mest interesseret og i stand til at gennemføre det.
Dette er især mærkbart ved komplekse projekter.
Baseret på karakteren af afklarende spørgsmål til de tekniske specifikationer kan entreprenører opdeles i dem, der er interesserede i blot at sælge (standardpresset fra en salgschef mærkes) og dem, der er interesserede i at udvikle et produkt, have hørt og forstået kunden, gøre konstruktive ændringer af de tekniske specifikationer allerede før det endelige valg (selv på trods af den reelle risiko for at forbedre andres tekniske specifikationer og miste tilbuddet), i sidste ende er de simpelthen klar til at acceptere en professionel udfordring og lave et godt produkt.
Alt dette fik os til at være opmærksomme på en relativt lille lokal udvikler - Sunline-gruppen af virksomheder, som reagerede på de fleste af vores krav med det samme og var klar til at implementere alle behovene vedrørende det nye BMS.
Risici
Mens de store spillere forsøgte at forstå, hvad vi ville have, og førte afslappet korrespondance med os, der involverede specialister på før-salgsniveau, planlagde den lokale udvikler et møde på vores kontor med deltagelse af sit tekniske team. På dette møde demonstrerede entreprenøren endnu en gang sit ønske om at deltage i projektet og, vigtigst af alt, forklarede, hvordan det påkrævede system ville blive implementeret.
Før mødet så vi to risici ved at arbejde med et team, der ikke har ressourcerne fra en stor national eller international virksomhed bag sig:
- Specialister kan overvurdere deres evner og som følge heraf simpelthen ikke klare sig; for eksempel vil de bruge kompleks software eller designe uigennemførlige reservationsalgoritmer.
- Efter at projektet er afsluttet, kan projektteamet gå i opløsning, og derfor vil produktsupport være i fare.
For at minimere disse risici inviterede vi vores egne udviklingsspecialister til mødet. Den potentielle entreprenørs medarbejdere blev grundigt interviewet om, hvad systemet bygger på, hvordan afskedigelse planlægges implementeret og andre forhold, hvor vi som driftsservice ikke er kompetente nok.
Dommen var positiv: Arkitekturen af den eksisterende BMS-platform er moderne, enkel og pålidelig, kan forbedres, den foreslåede redundans- og synkroniseringsordning er logisk og brugbar.
Den første risiko blev håndteret. Den anden blev udelukket efter at have modtaget bekræftelse fra entreprenøren om, at de var klar til at overføre systemets kildekode og dokumentation til os, og også ved at vælge Python-programmeringssproget, som var velkendt af vores specialister. Dette garanterede os muligheden for at vedligeholde systemet på egen hånd uden besvær og en lang periode med medarbejderuddannelse i tilfælde af, at udviklingsselskabet forlader markedet.
En yderligere fordel ved platformen var, at den blev implementeret i Docker-containere: kernen, webgrænsefladen og produktdatabasefunktionen i dette miljø. Denne tilgang giver mange fordele, herunder forudindstillede indstillinger for den højeste hastighed for implementering af løsningen sammenlignet med den "klassiske" og lette tilføjelse af nye enheder til systemet. "Alle sammen"-princippet forenkler implementeringen af systemet så meget som muligt: Bare pak systemet ud, og du kan straks bruge det.
Med denne løsning er det nemmere at lave kopier af systemet, og du kan forbedre det og implementere opgraderinger i et separat miljø uden at stoppe driften af løsningen som helhed.
Når begge risici var minimeret, leverede entreprenøren CP. Det dækkede alle de vigtigste parametre i BMS-systemet for os.
Reservation
Det nye BMS-system skulle placeres i skyen, på en virtuel maskine.
Ingen hardware, ingen servere og alle de ulemper og risici, der er forbundet med denne implementeringsmodel – cloud-løsningen gjorde det muligt for os at slippe af med dem for altid. Det blev besluttet, at systemet skulle fungere i vores sky på to datacentersteder i Skt. Petersborg og Moskva. Disse er to fuldt funktionelle systemer, der fungerer i aktiv standby-tilstand med adgang til alle autoriserede specialister.
De to systemer forsikrer hinanden og giver fuld reserve af både computerkraft og datatransmissionskanaler. Yderligere sikkerhedsforanstaltninger er også blevet konfigureret, herunder backup af data og kanaler, systemer, virtuelle maskiner generelt og en separat database backup én gang om måneden (den mest værdifulde ressource i form af styring og analyse).
Bemærk, at redundans som en mulighed i BMS-løsningen er udviklet specifikt til vores anmodning. Selve reservationsordningen så således ud:
Support
Det vigtigste punkt for effektiv drift af en BMS-løsning er teknisk support.
Alt er enkelt her: et nyt system ville koste os 35 rubler ifølge denne indikator. om måneden for SLA'en "svar inden for 000 timer", det vil sige 8 x 35/000 = $12 om året. Det første år er gratis.
Til sammenligning kostede vedligeholdelse af det gamle BMS fra leverandøren $18 om året med en stigning i beløbet for hver ny tilføjet enhed! Samtidig stillede virksomheden ikke en dedikeret leder til rådighed, al interaktion foregik gennem en salgschef, der er interesseret i os som en potentiel køber med en tilsvarende vægt i behandlingen af forespørgsler.
For færre penge fik vi fuld produktsupport, med en account manager, der ville deltage i produktudviklingen, med et enkelt indgangspunkt osv. Support blev meget mere fleksibel - takket være direkte adgang til udviklere for hurtige justeringer af ethvert aspekt af systemet, integration via API osv.
Opdateringer
Ifølge den foreslåede CP i det nye BMS er alle opdateringer inkluderet i omkostningerne til support, dvs. kræver ikke yderligere betaling. Undtagelsen er udvikling af yderligere funktionalitet ud over det, der er specificeret i de tekniske specifikationer.
Det gamle system krævede betaling for både firmwareopdateringer (såsom Java) og fejlrettelser. Det var umuligt at nægte dette; i mangel af opdateringer blev systemet som helhed "sænket" på grund af gamle versioner af interne komponenter.
Og det var selvfølgelig umuligt at opdatere softwaren uden at købe en supportpakke.
Fleksibel tilgang
Et andet grundlæggende krav vedrørte grænsefladen. Vi ønskede at give adgang til det via en webbrowser hvor som helst, uden den obligatoriske tilstedeværelse af en ingeniør på datacentrets område. Derudover søgte vi at skabe en animeret grænseflade, så dynamikken i infrastrukturen ville være mere tydelig for de vagthavende ingeniører.
Også i det nye system var det nødvendigt at understøtte formler til beregning af driften af virtuelle sensorer i tekniske systemer - for eksempel til optimal fordeling af elektrisk strøm på tværs af udstyrsstativer. For at gøre dette skal du have alle de sædvanlige matematiske operationer til rådighed for sensorindikatorer.
Dernæst krævedes adgang til en SQL-database med evnen til at tage de nødvendige data om udstyrets drift - nemlig alle overvågningsregistreringer af to tusinde enheder og to tusinde virtuelle sensorer, der genererer cirka 20 tusinde variabler.
Der var også behov for et rackudstyrsregnskabsmodul, der giver en grafisk repræsentation af arrangementet af enheder i hver enhed med beregning af hardwarens samlede vægt, opretholdelse af et bibliotek af enheder og detaljerede oplysninger om hvert element.
Godkendelse af tekniske specifikationer og underskrivelse af aftale
På det tidspunkt, hvor det var nødvendigt at starte arbejdet med det nye system, var korrespondancen med "store" virksomheder stadig meget langt fra at diskutere omkostningerne ved deres forslag, så vi sammenlignede den modtagne CP med omkostningerne ved at opdatere det gamle BMS (se. ), og som et resultat viste det sig at være mere attraktivt i pris og opfylde vores krav.
Valget er taget.
Efter at have valgt en entreprenør begyndte advokater at udarbejde en aftale, og tekniske teams fra begge sider begyndte at polere de tekniske specifikationer. Som du ved, er detaljerede og kompetente tekniske specifikationer grundlaget for ethvert arbejdes succes. Jo flere detaljer der er i de tekniske specifikationer, jo færre skuffelser som "men det er ikke det, vi ønskede."
Jeg vil give to eksempler på detaljeringsgraden af krav i de tekniske specifikationer:
- Datacentre på vagt har beføjelse til at tilføje nye enheder til BMS, oftest er disse PDU'er. I det gamle BMS var dette "administrator"-niveauet, som også gjorde det muligt at ændre de variable indstillinger for alle enheder, og det var umuligt at adskille funktionerne. Det her passede os ikke. I den eksisterende basisversion af den nye platform var ordningen ens. Vi tilkendegav straks i kommissoriet, at vi ønskede at adskille disse roller: Kun en autoriseret medarbejder skulle ændre indstillingerne, men de på vagt skulle fortsat kunne tilføje enheder. Denne ordning blev accepteret til implementering.
- I enhver standard BMS er der tre typiske kategorier af meddelelser: RØD - skal reageres med det samme, GUL - kan observeres, BLÅ - "Informativ". Vi har traditionelt brugt blå advarsler til at overvåge, når forretningsparametre er blevet overskredet, såsom en kundes rack, der overskrider sin kapacitetsgrænse. Denne type underretning i vores tilfælde var tiltænkt ledere og var ikke af interesse for driftstjenesten, men i det gamle BMS tilstoppede den jævnligt listen over aktive hændelser og forstyrrede det operationelle arbejde. Vi anså selve logikken og farvedifferentieringen af notifikationsbukserne for at være vellykket og beholdt den, men de tekniske specifikationer indikerede specifikt, at "blå" notifikationer, uden at distrahere vagtcheferne, stille "hældes" i en separat sektion, hvor de vil blive behandlet af kommercielle specialister.
Med en lignende detaljeringsgrad blev formaterne til at konstruere grafer og generere rapporter, konturerne af grænseflader, listen over enheder, der skulle overvåges, og mange andre ting foreskrevet.
Dette var et virkelig kreativt arbejde af tre arbejdsgrupper - kundeservicen, som dikterede dets krav og betingelser; tekniske specialister på begge sider, hvis opgave var at omdanne disse forhold til teknisk dokumentation; teams af entreprenørprogrammører, som implementerede kundens krav i henhold til den udviklede tekniske dokumentation... Som et resultat tilpassede vi nogle af vores principløse krav til funktionaliteten af en eksisterende platform, og entreprenøren påtog sig at tilføje noget for os.
Parallel drift af to systemer
Det er tid til implementering. I praksis betød det, at vi giver entreprenøren mulighed for at implementere en BMS-prototype i vores virtuelle sky og give netværksadgang til alle enheder, der kræver overvågning.
Det nye system var dog endnu ikke klar til drift. På dette tidspunkt var det vigtigt for os at opretholde overvågningen i det gamle system og samtidig give adgang til enhederne til det nye system. Det er umuligt at bygge et system korrekt uden at se enheder i det, som igen ikke kan deaktiveres fra overvågning af det gamle system.
Om enhederne kunne modstå samtidige afhøringer af to systemer var ikke indlysende uden reel test. Der var en mulighed for, at dobbeltsamtidig polling ville føre til hyppige afvisninger af at svare fra enheder, og vi ville modtage mange fejl vedrørende enheders utilgængelighed, hvilket igen ville blokere for driften af det gamle overvågningssystem.
Netværksafdelingen kørte virtuelle ruter fra en prototype af den nye BMS installeret i skyen til enhederne, og vi fik resultaterne:
- enheder forbundet via SNMP-protokollen blev praktisk talt aldrig afbrudt på grund af samtidige anmodninger,
- enheder forbundet gennem gateways ved hjælp af modbas-TCP-protokoller havde problemer, der blev løst ved intelligent at reducere deres polling-frekvens.
Og så begyndte vi at observere, hvordan et nyt system blev bygget foran vores øjne, enheder, der allerede var kendt for os, dukkede op i det, men i en anden grænseflade - praktisk, hurtig, tilgængelig selv fra en telefon.
Vi vil fortælle dig, hvad der skete til sidst i tredje del af vores artikel.
Kilde: www.habr.com