In het eerste deel bespraken we waarom we besloten om het oude BMS-systeem in onze datacenters te vervangen door een nieuw exemplaar. En niet alleen veranderen, maar vanaf nul ontwikkelen om aan uw wensen te voldoen. In het tweede deel vertellen we hoe we dat deden.
marktanalyse
Rekening houdend met hetgeen beschreven in wensen en de beslissing om te weigeren het bestaande systeem te updaten, hebben we een technische specificatie geschreven om een oplossing op de markt te vinden en hebben we navraag gedaan bij verschillende grote bedrijven die zich uitsluitend bezighouden met het creëren van industriële SCADA-systemen.
Uit de allereerste reacties van hen bleek dat de leiders van de markt voor monitoringsystemen vooral blijven werken aan hardwareservers, hoewel het proces van migratie naar de clouds in dit segment al is begonnen. Wat betreft het reserveren van virtuele machines: niemand ondersteunde deze optie. Bovendien was er het gevoel dat geen van de op de markt zichtbare ontwikkelaars zelfs maar blijk gaf van begrip voor de noodzaak van redundantie: “de cloud valt niet” was het meest voorkomende antwoord. Er werd ons zelfs aangeboden om de monitoring van het datacenter in een cloud te plaatsen die zich fysiek in hetzelfde datacenter bevond.
Hier moeten we een kleine uitweiding maken over het proces van het selecteren van een aannemer. Prijs doet er natuurlijk toe, maar tijdens elke aanbesteding voor de implementatie van een complex project, in de fase van de dialoog met leveranciers, begin je te voelen welke van de kandidaten meer geïnteresseerd is en in staat is om het uit te voeren.
Dit is vooral merkbaar bij complexe projecten.
Op basis van de aard van het verduidelijken van vragen over de technische specificaties kunnen aannemers worden onderverdeeld in degenen die geïnteresseerd zijn in simpelweg verkopen (de standaarddruk van een verkoopmanager wordt gevoeld) en degenen die geïnteresseerd zijn in het ontwikkelen van een product, nadat ze de klant hebben gehoord en begrepen, constructieve wijzigingen in de technische specificaties aanbrengen zelfs vóór de definitieve keuze (ook al is het risico reëel dat de technische specificaties van iemand anders worden verbeterd en de aanbesteding verloren gaat), uiteindelijk zijn ze gewoon klaar om een professionele uitdaging aan te gaan en een goed product te maken.
Dit alles zorgde ervoor dat we onze aandacht richtten op een relatief kleine lokale ontwikkelaar: de Sunline-bedrijvengroep, die onmiddellijk op de meeste van onze eisen reageerde en klaar was om alle behoeften met betrekking tot het nieuwe BMS te implementeren.
Risico's
Terwijl de grote spelers probeerden te begrijpen wat we wilden en op hun gemak met ons correspondeerden, waarbij specialisten op pre-saleniveau betrokken waren, plande de lokale ontwikkelaar een bijeenkomst in ons kantoor met deelname van zijn technische team. Tijdens deze bijeenkomst toonde de aannemer opnieuw zijn wens om aan het project deel te nemen en, belangrijker nog, hij legde uit hoe het vereiste systeem zou worden geïmplementeerd.
Voorafgaand aan de bijeenkomst zagen we twee risico’s van het werken met een team dat niet over de middelen beschikt van een groot nationaal of internationaal bedrijf:
- Specialisten kunnen hun capaciteiten overschatten en als gevolg daarvan eenvoudigweg niet in staat zijn om hiermee om te gaan; ze zullen bijvoorbeeld complexe software gebruiken of onhaalbare reserveringsalgoritmen ontwerpen.
- Nadat het project is voltooid, kan het projectteam uiteenvallen en komt de productondersteuning in gevaar.
Om deze risico's te minimaliseren, hebben we onze eigen ontwikkelingsspecialisten uitgenodigd voor de bijeenkomst. De medewerkers van de potentiële opdrachtnemer zijn uitgebreid geïnterviewd over waar het systeem op is gebaseerd, hoe de redundantie zal worden geïmplementeerd en andere zaken waarin wij als exploitatiedienst niet competent genoeg zijn.
Het oordeel was positief: de architectuur van het bestaande BMS-platform is modern, eenvoudig en betrouwbaar, kan verbeterd worden, het voorgestelde redundantie- en synchronisatieschema is logisch en werkbaar.
Het eerste risico werd aangepakt. De tweede werd uitgesloten na bevestiging van de aannemer dat hij bereid was de broncode van het systeem en de documentatie aan ons over te dragen, en ook door te kiezen voor de programmeertaal Python, die bij onze specialisten goed bekend was. Dit garandeerde ons de mogelijkheid om het systeem zonder problemen zelfstandig te onderhouden en een lange periode van opleiding van de medewerkers in het geval dat het ontwikkelingsbedrijf de markt zou verlaten.
Bijkomend voordeel van het platform was dat het geïmplementeerd was in Docker-containers: de kernel, webinterface en productdatabase functioneren in deze omgeving. Deze aanpak biedt veel voordelen, waaronder vooraf ingestelde instellingen voor de hoogste implementatiesnelheid van de oplossing in vergelijking met de “klassieke” en eenvoudige toevoeging van nieuwe apparaten aan het systeem. Het ‘alles samen’-principe vereenvoudigt de implementatie van het systeem zoveel mogelijk: u hoeft het systeem alleen maar uit te pakken en u kunt er direct mee aan de slag.
Met deze oplossing is het eenvoudiger om kopieën van het systeem te maken en kunt u het in een aparte omgeving verbeteren en upgrades implementeren, zonder dat de werking van de oplossing als geheel wordt stopgezet.
Nadat beide risico's waren geminimaliseerd, leverde de aannemer de CP. Het omvatte voor ons alle belangrijkste parameters van het BMS-systeem.
езервирование
Het nieuwe BMS-systeem moest in de cloud staan, op een virtuele machine.
Geen hardware, geen servers en alle ongemakken en risico's die aan dit implementatiemodel verbonden zijn - dankzij de cloudoplossing konden we er voor altijd vanaf komen. Er werd besloten dat het systeem in onze cloud zou werken op twee datacenterlocaties in St. Petersburg en Moskou. Dit zijn twee volledig functionele systemen die in actieve standby-modus werken en toegang hebben tot alle geautoriseerde specialisten.
De twee systemen verzekeren elkaar en bieden volledige reserve van zowel rekenkracht als datatransmissiekanalen. Er zijn ook aanvullende beveiligingsmaatregelen geconfigureerd, waaronder een back-up van gegevens en kanalen, systemen, virtuele machines in het algemeen, en een afzonderlijke databaseback-up eenmaal per maand (de meest waardevolle bron in termen van beheer en analyse).
Houd er rekening mee dat redundantie als optie in de BMS-oplossing speciaal voor ons verzoek is ontwikkeld. Het reserveringsschema zelf zag er als volgt uit:
Ondersteunen
Het belangrijkste punt voor de effectieve werking van een BMS-oplossing is technische ondersteuning.
Alles is hier eenvoudig: een nieuw systeem zou ons volgens deze indicator 35 roebel kosten. per maand voor de SLA “respons binnen 000 uur”, dat wil zeggen 8 x 35 / 000 = $12 per jaar. Het eerste jaar is gratis.
Ter vergelijking: het onderhouden van het oude BMS van de leverancier kostte $18 per jaar, met een verhoging van het bedrag voor elk nieuw toegevoegd apparaat! Tegelijkertijd leverde het bedrijf geen toegewijde manager; alle interactie verliep via een verkoopmanager die geïnteresseerd is in ons als potentiële koper met een overeenkomstige nadruk op het verwerken van verzoeken.
Voor minder geld kregen we volledige productondersteuning, met een accountmanager die meewerkte aan de productontwikkeling, met één aanspreekpunt, etc. De ondersteuning werd veel flexibeler - dankzij directe toegang tot ontwikkelaars voor snelle aanpassingen aan elk aspect van het systeem, integratie via API, enz.
Updates
Volgens de voorgestelde CP in het nieuwe BMS zijn alle updates inbegrepen in de ondersteuningskosten, d.w.z. vereisen geen extra betaling. De uitzondering is de ontwikkeling van extra functionaliteit die verder gaat dan wat is gespecificeerd in de technische specificaties.
Het oude systeem vereiste betaling voor zowel firmware-updates (zoals Java) als bugfixes. Het was onmogelijk om dit te weigeren: bij gebrek aan updates werd het systeem als geheel "vertraagd" vanwege oude versies van interne componenten.
En het was natuurlijk onmogelijk om de software te updaten zonder een ondersteuningspakket aan te schaffen.
Flexibele aanpak
Een andere fundamentele vereiste betrof de interface. We wilden er vanaf elke plek toegang toe bieden via een webbrowser, zonder de verplichte aanwezigheid van een ingenieur op het grondgebied van het datacenter. Daarnaast probeerden we een geanimeerde interface te creëren, zodat de dynamiek van de infrastructuur duidelijker zou zijn voor de dienstdoende ingenieurs.
Ook in het nieuwe systeem was het nodig om ondersteuning te bieden voor formules voor het berekenen van de werking van virtuele sensoren in technische systemen - bijvoorbeeld voor de optimale verdeling van elektrisch vermogen over apparatuurrekken. Om dit te doen, moet u over alle gebruikelijke wiskundige bewerkingen beschikken die van toepassing zijn op sensorindicatoren.
Vervolgens was toegang tot een SQL-database vereist met de mogelijkheid om daaruit de nodige gegevens over de werking van de apparatuur te halen - namelijk alle monitoringrecords van tweeduizend apparaten en tweeduizend virtuele sensoren die ongeveer 20 variabelen genereerden.
Er was ook een boekhoudmodule voor rackapparatuur nodig, die een grafische weergave bood van de opstelling van apparaten in elke eenheid, met berekening van het totale gewicht van de hardware, een bibliotheek met apparaten en gedetailleerde informatie over elk element.
Goedkeuring van technische specificaties en ondertekening van een overeenkomst
Op het moment dat het nodig was om aan het nieuwe systeem te gaan werken, was de correspondentie met "grote" bedrijven nog ver verwijderd van het bespreken van de kosten van hun voorstellen, dus vergeleken we de ontvangen CP met de kosten voor het updaten van het oude BMS (zie. ), en daardoor bleek het qua prijs aantrekkelijker en voldeed het aan onze eisen.
De keuze is gemaakt.
Nadat ze een aannemer hadden geselecteerd, begonnen advocaten een overeenkomst op te stellen en begonnen technische teams van beide kanten de technische specificaties bij te werken. Zoals u weet vormen gedetailleerde en competente technische specificaties de basis voor het succes van elk werk. Hoe meer details er in de technische specificaties zitten, hoe minder teleurstellingen als “maar dit is niet wat we wilden.”
Ik zal twee voorbeelden geven van het detailniveau van eisen in de technische specificaties:
- Datacenters van dienst zijn bevoegd om nieuwe apparaten aan het BMS toe te voegen, meestal zijn dit PDU's. In het oude BMS was dit het “beheerdersniveau”, waardoor ook de variabele instellingen van alle apparaten konden worden gewijzigd, en het was onmogelijk om de functies te scheiden. Dit beviel ons niet. In de bestaande basisversie van het nieuwe platform was het schema vergelijkbaar. We hebben in het bestek meteen aangegeven dat we deze rollen wilden scheiden: alleen een geautoriseerde medewerker mag de instellingen wijzigen, maar de dienstdoende medewerker moet apparaten kunnen blijven toevoegen. Dit schema werd geaccepteerd voor implementatie.
- In elk standaard BMS zijn er drie typische categorieën meldingen: ROOD - er moet onmiddellijk op worden gereageerd, GEEL - kan worden waargenomen, BLAUW - "Informatief". Van oudsher gebruiken we blauwe waarschuwingen om te monitoren wanneer bedrijfsparameters worden overschreden, bijvoorbeeld als het rack van een klant de capaciteitslimiet overschrijdt. Dit soort meldingen was in ons geval bedoeld voor leidinggevenden en niet interessant voor de operationele dienst, maar in het oude BMS verstopte het regelmatig de lijst met actieve incidenten en verstoorde het de operationele werkzaamheden. We beschouwden de logica en de kleurdifferentiatie van de meldingsbroek als succesvol en behielden deze, maar de technische specificaties gaven specifiek aan dat ‘blauwe’ meldingen, zonder de dienstdoende officieren af te leiden, stilletjes in een aparte sectie moesten ‘stromen’, waar ze zal worden behandeld door commerciële specialisten.
Met een vergelijkbare mate van detail werden de formaten voor het construeren van grafieken en het genereren van rapporten, de contouren van interfaces, de lijst met apparaten die moesten worden gemonitord en nog veel meer voorgeschreven.
Dit was een waarlijk creatief werk van drie werkgroepen: de klantenservice, die de eisen en voorwaarden dicteerde; technische specialisten aan beide kanten, wier taak het was om deze omstandigheden om te zetten in technische documentatie; teams van opdrachtnemer-programmeurs die de eisen van de klant implementeerden volgens de ontwikkelde technische documentatie... Als gevolg hiervan hebben we een aantal van onze principeloze eisen aangepast aan de functionaliteit van een bestaand platform, en de opdrachtnemer beloofde iets voor ons toe te voegen.
Parallelle werking van twee systemen
Het is tijd voor implementatie. In de praktijk betekende dit dat we de opdrachtnemer de mogelijkheid gaven om een BMS-prototype in onze virtuele cloud in te zetten en netwerktoegang te bieden aan alle apparaten die monitoring nodig hebben.
Het nieuwe systeem was echter nog niet klaar voor gebruik. In deze fase was het belangrijk voor ons om de monitoring in het oude systeem te behouden en tegelijkertijd toegang te geven tot de apparaten aan het nieuwe systeem. Het is onmogelijk om een systeem goed te bouwen zonder er apparaten in te zien, die op hun beurt niet kunnen worden uitgeschakeld voor monitoring door het oude systeem.
Of de apparaten bestand waren tegen gelijktijdige ondervraging door twee systemen was niet duidelijk zonder echte tests. Er bestond een mogelijkheid dat dubbele gelijktijdige polling zou leiden tot frequente weigeringen om te reageren vanaf apparaten en dat we veel fouten zouden ontvangen over de onbeschikbaarheid van apparaten, wat op zijn beurt de werking van het oude monitoringsysteem zou blokkeren.
De netwerkafdeling voerde virtuele routes uit van een prototype van het nieuwe BMS dat in de cloud was geïmplementeerd naar de apparaten, en we kregen de resultaten:
- apparaten die via het SNMP-protocol zijn verbonden, raakten vrijwel nooit de verbinding kwijt vanwege gelijktijdige verzoeken,
- Apparaten die via gateways waren verbonden met behulp van modbas-TCP-protocollen hadden problemen die werden opgelost door hun pollingfrequentie op intelligente wijze te verminderen.
En toen begonnen we te observeren hoe een nieuw systeem voor onze ogen werd gebouwd, apparaten die we al kenden verschenen erin, maar in een andere interface - handig, snel, zelfs toegankelijk vanaf een telefoon.
Wat er uiteindelijk is gebeurd, zullen we u vertellen in het derde deel van ons artikel.
Bron: www.habr.com