I den första delen pratade vi om varför vi bestämde oss för att byta ut det gamla BMS-systemet i våra datacenter mot ett nytt. Och inte bara förändra, utan utveckla från grunden för att passa dina krav. I den andra delen berättar vi hur vi gjorde.
Marknadsanalys
Med hänsyn till de som beskrivs i önskemål och beslutet att vägra att uppdatera det befintliga systemet skrev vi en teknisk specifikation för att hitta en lösning på marknaden och gjorde förfrågningar till flera stora företag som enbart sysslade med att skapa industriella SCADA-system.
De allra första svaren från dem visade att ledarna för övervakningssystemmarknaden i första hand fortsätter att arbeta på hårdvaruservrar, även om migreringsprocessen till molnen i detta segment redan har börjat. När det gäller att reservera virtuella maskiner, stödde ingen detta alternativ. Dessutom fanns det en känsla av att ingen av de synliga utvecklarna på marknaden ens visade en förståelse för behovet av redundans: "molnet faller inte" var det vanligaste svaret. Faktum är att vi erbjöds att placera datacenterövervakning i ett moln fysiskt placerat i samma datacenter.
Här måste vi göra en liten avvikelse om processen för att välja en entreprenör. Priset spelar så klart roll, men under varje anbudsförfarande för genomförandet av ett komplext projekt, i dialogstadiet med leverantörer, börjar du känna vem av kandidaterna som är mest intresserad och kapabel att genomföra det.
Detta märks särskilt vid komplexa projekt.
Baserat på arten av förtydligande frågor till de tekniska specifikationerna kan entreprenörer delas in i de som är intresserade av att helt enkelt sälja (standardtrycket från en försäljningschef känns) och de som är intresserade av att utveckla en produkt, ha hört och förstått kunden, göra konstruktiva ändringar av de tekniska specifikationerna redan innan det slutliga valet (även trots den verkliga risken att förbättra någon annans tekniska specifikationer och förlora anbudet), i slutändan är de helt enkelt redo att anta en professionell utmaning och göra en bra produkt.
Allt detta fick oss att uppmärksamma en relativt liten lokal utvecklare - Sunline-gruppen av företag, som svarade på de flesta av våra krav omedelbart och var redo att implementera alla behov gällande det nya BMS.
Risker
Medan de stora spelarna försökte förstå vad vi ville ha och förde en lugn korrespondens med oss som involverade specialister på före försäljningsnivå, bokade den lokala utvecklaren ett möte på vårt kontor med deltagande av sitt tekniska team. Vid detta möte visade entreprenören återigen sin önskan att delta i projektet och, viktigast av allt, förklarade hur det erforderliga systemet skulle implementeras.
Innan mötet såg vi två risker med att arbeta med ett team som inte har resurserna från ett stort nationellt eller internationellt företag bakom sig:
- Specialister kan överskatta sina förmågor och som ett resultat helt enkelt misslyckas med att klara sig; till exempel kommer de att använda komplex programvara eller designa omöjliga reservationsalgoritmer.
- Efter att projektet är slutfört kan projektgruppen sönderfalla och därför kommer produktsupporten att vara i fara.
För att minimera dessa risker bjöd vi in våra egna utvecklingsspecialister till mötet. Den potentiella entreprenörens medarbetare intervjuades noggrant om vad systemet bygger på, hur övertalighet planeras att genomföras och andra frågor där vi som drifttjänst inte är tillräckligt kompetenta.
Domen var positiv: arkitekturen för den befintliga BMS-plattformen är modern, enkel och pålitlig, kan förbättras, det föreslagna redundans- och synkroniseringsschemat är logiskt och fungerande.
Den första risken hanterades. Den andra uteslöts efter att ha fått bekräftelse från entreprenören att de var redo att överföra källkoden för systemet och dokumentationen till oss, och även genom att välja Python-programmeringsspråket, som var välkänt för våra specialister. Detta garanterade oss möjligheten att underhålla systemet på egen hand utan några svårigheter och en lång period av personalutbildning i händelse av att utvecklingsföretaget lämnar marknaden.
En ytterligare fördel med plattformen var att den implementerades i Docker-containrar: kärnan, webbgränssnittet och produktdatabasfunktionen i denna miljö. Detta tillvägagångssätt ger många fördelar, inklusive förinställda inställningar för den högsta hastigheten för implementering av lösningen jämfört med det "klassiska" och enkla tillägget av nya enheter till systemet. "Alla tillsammans"-principen förenklar implementeringen av systemet så mycket som möjligt: packa bara upp systemet så kan du omedelbart använda det.
Med denna lösning är det enklare att göra kopior av systemet, och du kan förbättra det och implementera uppgraderingar i en separat miljö, utan att stoppa driften av lösningen som helhet.
När båda riskerna var minimerade tillhandahöll entreprenören CP. Den täckte alla de viktigaste parametrarna i BMS-systemet för oss.
Bokning
Det nya BMS-systemet måste placeras i molnet, på en virtuell maskin.
Ingen hårdvara, inga servrar och alla olägenheter och risker som är förknippade med den här implementeringsmodellen – molnlösningen gjorde att vi kunde bli av med dem för alltid. Det beslutades att systemet skulle fungera i vårt moln på två datacenterplatser i St. Petersburg och Moskva. Dessa är två fullt fungerande system som arbetar i aktivt standbyläge med tillgång till alla auktoriserade specialister.
De två systemen försäkrar varandra och ger full reserv av både datorkraft och dataöverföringskanaler. Ytterligare säkerhetsåtgärder har också konfigurerats, inklusive säkerhetskopiering av data och kanaler, system, virtuella maskiner i allmänhet och en separat databasbackup en gång i månaden (den mest värdefulla resursen när det gäller hantering och analys).
Observera att redundans som tillval i BMS-lösningen utvecklades specifikt för vår begäran. Själva bokningsschemat såg ut så här:
Support
Den viktigaste punkten för effektiv drift av en BMS-lösning är teknisk support.
Allt är enkelt här: ett nytt system skulle kosta oss 35 000 rubel enligt denna indikator. per månad för SLA:et "svar inom 8 timmar", det vill säga 35 000 x 12 / 80 = $5 250 per år. Det första året är gratis.
Som jämförelse kostade att underhålla det gamla BMS från leverantören $18 000 per år med en ökning av beloppet för varje ny enhet som läggs till! Samtidigt tillhandahöll inte företaget en dedikerad chef, all interaktion skedde genom en försäljningschef som är intresserad av oss som potentiell köpare med motsvarande betoning på att behandla förfrågningar.
För mindre pengar fick vi full produktsupport, med en kontoansvarig som skulle ta del av produktutvecklingen, med en enda ingång osv. Supporten blev mycket mer flexibel – tack vare direkt tillgång till utvecklare för snabba justeringar av alla aspekter av systemet, integration via API, etc.
Uppdateringar
Enligt den föreslagna CP i nya BMS ingår alla uppdateringar i kostnaden för support, d.v.s. kräver ingen ytterligare betalning. Undantaget är utvecklingen av ytterligare funktionalitet utöver vad som anges i de tekniska specifikationerna.
Det gamla systemet krävde betalning för både firmwareuppdateringar (som Java) och buggfixar. Det var omöjligt att vägra detta; i avsaknad av uppdateringar "saknade systemet som helhet ner" på grund av gamla versioner av interna komponenter.
Och det var naturligtvis omöjligt att uppdatera programvaran utan att köpa ett supportpaket.
Flexibelt förhållningssätt
Ett annat grundläggande krav gällde gränssnittet. Vi ville ge åtkomst till det via en webbläsare var som helst, utan obligatorisk närvaro av en ingenjör på datacentrets territorium. Dessutom försökte vi skapa ett animerat gränssnitt så att dynamiken i infrastrukturen skulle bli tydligare för de tjänstgörande ingenjörerna.
Också i det nya systemet var det nödvändigt att tillhandahålla stöd för formler för att beräkna driften av virtuella sensorer i tekniska system - till exempel för optimal fördelning av elektrisk kraft över utrustningsställ. För att göra detta måste du ha till ditt förfogande alla vanliga matematiska operationer som gäller för sensorindikatorer.
Därefter krävdes tillgång till en SQL-databas med förmågan att ta från den nödvändiga data om driften av utrustningen - nämligen alla övervakningsposter för två tusen enheter och två tusen virtuella sensorer som genererar cirka 20 tusen variabler.
En redovisningsmodul för rackutrustning behövdes också, som gav en grafisk representation av arrangemanget av enheter i varje enhet med beräkning av hårdvarans totala vikt, upprätthållande av ett bibliotek med enheter och detaljerad information om varje element.
Godkännande av tekniska specifikationer och undertecknande av avtal
Vid den tidpunkt då det var nödvändigt att börja arbeta med det nya systemet var korrespondensen med "stora" företag fortfarande väldigt långt ifrån att diskutera kostnaden för deras förslag, så vi jämförde den mottagna CP med kostnaderna för att uppdatera det gamla BMS (se. ), och som ett resultat visade det sig vara mer attraktivt i pris och uppfylla våra krav.
Valet är gjort.
Efter att ha valt en entreprenör började advokater upprätta ett avtal och tekniska team från båda sidor började polera de tekniska specifikationerna. Som ni vet är detaljerade och kompetenta tekniska specifikationer grunden för framgången för allt arbete. Ju fler detaljer det finns i de tekniska specifikationerna, desto mindre besvikelser som "men det här är inte vad vi ville ha."
Jag kommer att ge två exempel på detaljeringsgraden för kraven i de tekniska specifikationerna:
- Datacenter i tjänst har befogenhet att lägga till nya enheter till BMS, oftast är dessa PDU:er. I det gamla BMS var detta "administratörsnivån", vilket också gjorde det möjligt att ändra de variabla inställningarna för alla enheter, och det var omöjligt att separera funktionerna. Det här passade inte oss. I den befintliga grundversionen av den nya plattformen var schemat liknande. Vi angav omedelbart i uppdragsbeskrivningen att vi ville separera dessa roller: endast en auktoriserad anställd ska ändra inställningarna, men de i tjänst ska fortsätta att kunna lägga till enheter. Detta system godkändes för genomförande.
- I varje standard BMS finns det tre typiska kategorier av meddelanden: RÖD - måste besvaras omedelbart, GUL - kan observeras, BLÅ - "Informativ". Vi har traditionellt använt blå varningar för att övervaka när affärsparametrar har överskridits, till exempel att en kunds rack överskrider sin kapacitetsgräns. Den här typen av avisering var i vårt fall avsedd för chefer och var inte av intresse för drifttjänsten, men i gamla BMS täppte den regelbundet till listan över aktiva incidenter och störde det operativa arbetet. Vi ansåg att själva logiken och färgdifferentieringen av anmälningsbyxorna var framgångsrik och behöll den, men de tekniska specifikationerna indikerade specifikt att "blå" meddelanden skulle, utan att distrahera vakthavande befäl, tyst "hälla" i en separat sektion, där de kommer att hanteras av kommersiella specialister.
Med en liknande detaljgrad föreskrevs formaten för att konstruera grafer och generera rapporter, konturerna av gränssnitt, listan över enheter som behövde övervakas och många andra saker.
Detta var ett verkligt kreativt arbete av tre arbetsgrupper - kundtjänsten, som dikterade dess krav och villkor; tekniska specialister på båda sidor, vars uppgift var att omvandla dessa förhållanden till teknisk dokumentation; team av entreprenörsprogrammerare som implementerade kundens krav enligt den utvecklade tekniska dokumentationen... Som ett resultat anpassade vi några av våra principlösa krav till funktionaliteten hos en befintlig plattform, och entreprenören åtog sig att tillföra något åt oss.
Parallell drift av två system
Det är dags för implementering. I praktiken innebar det att vi ger entreprenören möjlighet att distribuera en BMS-prototyp i vårt virtuella moln och ge nätverksåtkomst till alla enheter som kräver övervakning.
Det nya systemet var dock ännu inte klart för drift. I det här skedet var det viktigt för oss att behålla övervakningen i det gamla systemet och samtidigt ge tillgång till enheterna till det nya systemet. Det är omöjligt att bygga ett system ordentligt utan att se enheter i det, som i sin tur inte kan inaktiveras från övervakning av det gamla systemet.
Huruvida enheterna kunde motstå samtidiga förhör av två system var inte självklart utan verklig testning. Det fanns en möjlighet att dubbla samtidiga polling skulle leda till frekventa vägran att svara från enheter och vi skulle få många fel angående otillgänglighet av enheter, vilket i sin tur skulle blockera driften av det gamla övervakningssystemet.
Nätverksavdelningen körde virtuella rutter från en prototyp av den nya BMS som är utplacerad i molnet till enheterna, och vi fick resultaten:
- enheter anslutna via SNMP-protokollet blev praktiskt taget aldrig frånkopplade på grund av samtidiga förfrågningar,
- enheter som var anslutna via gateways med modbas-TCP-protokoll hade problem som löstes genom att intelligent minska deras pollingfrekvens.
Och sedan började vi observera hur ett nytt system byggdes framför våra ögon, enheter som redan var bekanta för oss dök upp i det, men i ett annat gränssnitt - bekvämt, snabbt, tillgängligt även från en telefon.
Vi kommer att berätta vad som hände till slut i den tredje delen av vår artikel.
Källa: will.com