Në pjesën e parë, folëm se pse vendosëm të zëvendësojmë sistemin e vjetër BMS në qendrat tona të të dhënave me një të ri. Dhe jo vetëm të ndryshojë, por të zhvillohet nga e para për t'iu përshtatur kërkesave tuaja. Në pjesën e dytë ju tregojmë se si ia dolëm.
Analiza e Tregut
Duke marrë parasysh ato të përshkruara në dëshirat dhe vendimin për të refuzuar përditësimin e sistemit ekzistues, ne shkruam një specifikim teknik për të gjetur një zgjidhje në treg dhe i bëmë pyetje disa kompanive të mëdha të angazhuara vetëm në krijimin e sistemeve industriale SCADA.
Përgjigjet e para prej tyre treguan se drejtuesit e tregut të sistemeve të monitorimit kryesisht vazhdojnë të punojnë në serverët harduerikë, megjithëse procesi i migrimit në retë në këtë segment tashmë ka filluar. Sa i përket rezervimit të makinave virtuale, askush nuk e mbështeti këtë opsion. Për më tepër, kishte një ndjenjë që asnjë nga zhvilluesit e dukshëm në treg nuk demonstroi as një kuptim të nevojës për tepricë: "reja nuk po bie" ishte përgjigjja më e zakonshme. Në fakt, na u ofrua të vendosnim monitorimin e qendrës së të dhënave në një re të vendosur fizikisht në të njëjtën qendër të të dhënave.
Këtu duhet të bëjmë një digresion të vogël në lidhje me procesin e zgjedhjes së një kontraktori. Çmimi, natyrisht, ka rëndësi, por gjatë çdo tenderi për zbatimin e një projekti kompleks, në fazën e dialogut me furnitorët, fillon të ndjesh se cili nga kandidatët është më i interesuar dhe i aftë për ta zbatuar atë.
Kjo është veçanërisht e dukshme në projekte komplekse.
Bazuar në natyrën e pyetjeve sqaruese për specifikimet teknike, kontraktorët mund të ndahen në ata që janë të interesuar për të shitur thjesht (ndjehet presioni standard i një menaxheri shitjesh) dhe ata që janë të interesuar të zhvillojnë një produkt, pasi kanë dëgjuar dhe kuptuar klientin, duke e bërë konstruktiv. ndryshimet në specifikimet teknike edhe para zgjedhjes përfundimtare (edhe pse rreziku është real për të përmirësuar specifikimet teknike të dikujt tjetër dhe për të humbur tenderin), në fund ata janë thjesht të gatshëm të pranojnë një sfidë profesionale dhe të bëjnë një produkt të mirë.
E gjithë kjo na bëri t'i kushtojmë vëmendje një zhvilluesi vendas relativisht të vogël - grupi i kompanive Sunline, i cili iu përgjigj menjëherë shumicës së kërkesave tona dhe ishte gati të zbatonte të gjitha nevojat në lidhje me BMS-në e re.
Rreziqet
Ndërsa lojtarët e mëdhenj po përpiqeshin të kuptonin atë që dëshironim dhe po bënin korrespondencë të qetë me ne duke përfshirë specialistë të nivelit të para-shitjes, zhvilluesi vendas caktoi një takim në zyrën tonë me pjesëmarrjen e ekipit të tij teknik. Në këtë takim, kontraktori tregoi edhe një herë dëshirën e tij për të marrë pjesë në projekt dhe, më e rëndësishmja, shpjegoi se si do të zbatohej sistemi i kërkuar.
Para takimit, ne pamë dy rreziqe të punës me një ekip që nuk ka burimet e një kompanie të madhe kombëtare ose ndërkombëtare pas saj:
- Specialistët mund të mbivlerësojnë aftësitë e tyre dhe, si rezultat, thjesht të dështojnë t'i përballojnë; për shembull, ata do të përdorin softuer kompleks ose do të hartojnë algoritme rezervimi të parealizueshme.
- Pas përfundimit të projektit, ekipi i projektit mund të shpërbëhet dhe, për rrjedhojë, mbështetja e produktit do të jetë në rrezik.
Për të minimizuar këto rreziqe, ne ftuam specialistët tanë të zhvillimit në takim. Punonjësit e kontraktorit të mundshëm janë intervistuar tërësisht rreth asaj se ku bazohet sistemi, si planifikohet të zbatohet teprica dhe çështje të tjera për të cilat ne, si shërbim operativ, nuk jemi mjaftueshëm kompetent.
Verdikti ishte pozitiv: arkitektura e platformës ekzistuese BMS është moderne, e thjeshtë dhe e besueshme, mund të përmirësohet, skema e propozuar e tepricës dhe sinkronizimit është logjike dhe e zbatueshme.
Rreziku i parë u trajtua. E dyta u përjashtua pas marrjes së konfirmimit nga kontraktori se ata ishin gati të transferonin kodin burimor të sistemit dhe dokumentacionin tek ne, si dhe duke zgjedhur gjuhën e programimit Python, e cila ishte e njohur për specialistët tanë. Kjo na garantoi mundësinë për të mirëmbajtur sistemin vetë pa asnjë vështirësi dhe një periudhë të gjatë trajnimi të punonjësve në rast të largimit të kompanisë së zhvillimit nga tregu.
Një avantazh shtesë i platformës ishte se ajo u zbatua në kontejnerët Docker: kerneli, ndërfaqja e internetit dhe baza e të dhënave të produktit funksionojnë në këtë mjedis. Kjo qasje ofron shumë përparësi, duke përfshirë cilësimet e paracaktuara për shpejtësinë më të lartë të vendosjes së zgjidhjes në krahasim me shtimin "klasik" dhe të lehtë të pajisjeve të reja në sistem. Parimi "të gjithë së bashku" thjeshton zbatimin e sistemit sa më shumë që të jetë e mundur: ju vetëm duhet të shpaketoni sistemin dhe mund ta përdorni menjëherë.
Me këtë zgjidhje, është më e lehtë të bësh kopje të sistemit, dhe mund ta përmirësosh atë dhe të zbatosh përmirësime në një mjedis të veçantë, pa ndërprerë funksionimin e zgjidhjes në tërësi.
Pasi të dy rreziqet u minimizuan, kontraktori dha CP. Ai mbuloi të gjithë parametrat më të rëndësishëm të sistemit BMS për ne.
Rezervimi
Sistemi i ri BMS duhej të vendosej në cloud, në një makinë virtuale.
Asnjë harduer, pa server dhe të gjitha shqetësimet dhe rreziqet që lidhen me këtë model vendosjeje - zgjidhja cloud na lejoi t'i heqim qafe ato përgjithmonë. U vendos që sistemi të funksiononte në renë tonë në dy qendra të të dhënave në Shën Petersburg dhe Moskë. Këto janë dy sisteme plotësisht funksionale që funksionojnë në modalitetin e gatishmërisë aktive me akses tek të gjithë specialistët e autorizuar.
Të dy sistemet sigurojnë njëri-tjetrin, duke siguruar rezervë të plotë si të fuqisë kompjuterike ashtu edhe të kanaleve të transmetimit të të dhënave. Janë konfiguruar gjithashtu masa shtesë sigurie, duke përfshirë kopjen rezervë të të dhënave dhe kanaleve, sistemeve, makinave virtuale në përgjithësi dhe një kopje rezervë të veçantë të bazës së të dhënave një herë në muaj (burimi më i vlefshëm për sa i përket menaxhimit dhe analizës).
Vini re se teprica si opsion në zgjidhjen BMS është zhvilluar posaçërisht për kërkesën tonë. Vetë skema e rezervimit dukej kështu:
Mbështetje
Pika më e rëndësishme për funksionimin efektiv të një zgjidhje BMS është mbështetja teknike.
Gjithçka është e thjeshtë këtu: një sistem i ri do të na kushtonte 35 rubla sipas këtij treguesi. në muaj për SLA "përgjigje brenda 000 orëve", domethënë 8 x 35 / 000 = 12 dollarë në vit. Viti i parë është falas.
Për krahasim, mbajtja e BMS-së së vjetër nga shitësi kushton 18 dollarë në vit me një rritje në shumën për çdo pajisje të re të shtuar! Në të njëjtën kohë, kompania nuk ofroi një menaxher të dedikuar; i gjithë ndërveprimi u zhvillua përmes një menaxheri shitjesh i cili është i interesuar për ne si blerës potencial me theks përkatës në përpunimin e kërkesave.
Për më pak para, morëm mbështetje të plotë të produktit, me një menaxher llogarie që do të merrte pjesë në zhvillimin e produktit, me një pikë të vetme hyrjeje, etj. Mbështetja u bë shumë më fleksibël - falë aksesit të drejtpërdrejtë te zhvilluesit për rregullime të shpejta në çdo aspekt të sistemit, integrimit nëpërmjet API, etj.
Updates
Sipas CP-së së propozuar në BMS-në e re, të gjitha përditësimet përfshihen në koston e mbështetjes, d.m.th. nuk kërkojnë pagesë shtesë. Përjashtim është zhvillimi i funksionalitetit shtesë përtej asaj që specifikohet në specifikimet teknike.
Sistemi i vjetër kërkonte pagesë si për përditësimet e firmuerit (siç është Java) ashtu edhe për rregullimet e gabimeve. Ishte e pamundur të refuzohej kjo; në mungesë të përditësimeve, sistemi në tërësi "u ngadalësua" për shkak të versioneve të vjetra të komponentëve të brendshëm.
Dhe, natyrisht, ishte e pamundur të përditësohej softueri pa blerë një paketë mbështetëse.
Qasje fleksibël
Një kërkesë tjetër themelore kishte të bënte me ndërfaqen. Ne donim të siguronim akses në të përmes një shfletuesi të internetit nga kudo, pa praninë e detyrueshme të një inxhinieri në territorin e qendrës së të dhënave. Përveç kësaj, ne kërkuam të krijonim një ndërfaqe të animuar në mënyrë që dinamika e infrastrukturës të ishte më e qartë për inxhinierët në detyrë.
Gjithashtu në sistemin e ri ishte e nevojshme të sigurohet mbështetje për formulat për llogaritjen e funksionimit të sensorëve virtualë në sistemet inxhinierike - për shembull, për shpërndarjen optimale të energjisë elektrike nëpër raftet e pajisjeve. Për ta bërë këtë, duhet të keni në dispozicion të gjitha operacionet e zakonshme matematikore të zbatueshme për treguesit e sensorëve.
Më pas, kërkohej qasja në një bazë të dhënash SQL me aftësinë për të marrë prej saj të dhënat e nevojshme për funksionimin e pajisjeve - domethënë, të gjitha të dhënat e monitorimit të dy mijë pajisjeve dhe dy mijë sensorëve virtualë që gjenerojnë afërsisht 20 mijë variabla.
Një modul i kontabilitetit të pajisjeve raft ishte gjithashtu i nevojshëm, duke siguruar një paraqitje grafike të rregullimit të pajisjeve në çdo njësi me llogaritjen e peshës totale të harduerit, duke mbajtur një bibliotekë pajisjesh dhe informacion të detajuar për secilin element.
Miratimi i specifikimeve teknike dhe nënshkrimi i një marrëveshjeje
Në kohën kur ishte e nevojshme të fillonte punën për sistemin e ri, korrespondenca me kompanitë "e mëdha" ishte ende shumë larg diskutimit të kostos së propozimeve të tyre, kështu që ne krahasuam CP-në e marrë me kostot e përditësimit të BMS-së së vjetër (shih. ), dhe si rezultat rezultoi të ishte më tërheqës në çmim dhe të përmbushte kërkesat tona.
Zgjedhja është bërë.
Pas përzgjedhjes së një kontraktori, avokatët filluan të hartojnë një marrëveshje dhe ekipet teknike nga të dyja palët filluan të lustrojnë specifikimet teknike. Siç e dini, specifikimet teknike të detajuara dhe kompetente janë baza për suksesin e çdo pune. Sa më shumë specifika të ketë në specifikimet teknike, aq më pak zhgënjime si "por kjo nuk është ajo që donim".
Unë do të jap dy shembuj të nivelit të detajeve të kërkesave në specifikimet teknike:
- Qendrat e të dhënave në detyrë janë të autorizuara për të shtuar pajisje të reja në BMS, më shpesh këto janë PDU. Në BMS-në e vjetër, ky ishte niveli i "administratorit", i cili gjithashtu lejonte ndryshimin e cilësimeve të ndryshueshme të të gjitha pajisjeve dhe ishte e pamundur të ndaheshin funksionet. Kjo nuk na shkonte. Në versionin bazë ekzistues të platformës së re, skema ishte e ngjashme. Ne treguam menjëherë në termat e referencës se donim të veçonim këto role: vetëm një punonjës i autorizuar duhet të ndryshojë cilësimet, por ata që janë në detyrë duhet të vazhdojnë të jenë në gjendje të shtojnë pajisje. Kjo skemë u pranua për zbatim.
- Në çdo BMS standard ekzistojnë tre kategori tipike njoftimesh: E KUQE - duhet t'i përgjigjet menjëherë, E VERDHA - mund të vërehet, BLU - "Informative". Ne kemi përdorur tradicionalisht sinjalizimet blu për të monitoruar kur parametrat e biznesit janë tejkaluar, si p.sh. rafti i një klienti tejkalon kufirin e kapacitetit të tij. Ky lloj njoftimi në rastin tonë ishte menduar për menaxherët dhe nuk ishte me interes për shërbimin operativ, por në BMS-në e vjetër bllokonte rregullisht listën e incidenteve aktive dhe ndërhynte në punën operative. Ne e konsideruam vetë diferencimin logjik dhe ngjyrën e pantallonave të njoftimit si të suksesshëm dhe e ruajtëm atë, megjithatë, specifikimet teknike treguan në mënyrë specifike se njoftimet "blu" duhet, pa shpërqendruar oficerët e shërbimit, të "derdhen" në heshtje në një seksion të veçantë, ku ato do të trajtohen nga specialistë tregtarë.
Me një nivel të ngjashëm detajesh, u përshkruan formatet për ndërtimin e grafikëve dhe gjenerimin e raporteve, skicat e ndërfaqeve, lista e pajisjeve që duheshin monitoruar dhe shumë gjëra të tjera.
Kjo ishte një punë vërtet krijuese e tre grupeve të punës - shërbimi ndaj klientit, i cili diktoi kërkesat dhe kushtet e tij; specialistë teknikë nga të dyja palët, detyra e të cilëve ishte shndërrimi i këtyre kushteve në dokumentacion teknik; ekipet e programuesve kontraktorë që zbatuan kërkesat e klientit sipas dokumentacionit teknik të zhvilluar... Si rezultat, ne përshtatëm disa nga kërkesat tona joparimore me funksionalitetin e një platforme ekzistuese dhe kontraktori mori përsipër të shtonte diçka për ne.
Funksionimi paralel i dy sistemeve
Është koha për zbatimin. Në praktikë, kjo do të thoshte që ne i japim kontraktorit mundësinë për të vendosur një prototip BMS në renë tonë virtuale dhe për të siguruar akses në rrjet në të gjitha pajisjet që kërkojnë monitorim.
Megjithatë, sistemi i ri nuk ishte ende gati për funksionim. Në këtë fazë, ishte e rëndësishme për ne që të ruanim monitorimin në sistemin e vjetër dhe në të njëjtën kohë t'u jepnim akses pajisjeve në sistemin e ri. Është e pamundur të ndërtohet siç duhet një sistem pa parë pajisje në të, të cilat nga ana e tyre nuk mund të çaktivizohen nga monitorimi nga sistemi i vjetër.
Nëse pajisjet mund t'i rezistonin marrjes në pyetje të njëkohshme nga dy sisteme nuk ishte e qartë pa testim të vërtetë. Ekzistonte mundësia që sondazhi i dyfishtë i njëkohshëm të çonte në refuzime të shpeshta për t'u përgjigjur nga pajisjet dhe do të merrnim shumë gabime në lidhje me mosdisponueshmërinë e pajisjeve, gjë që do të bllokonte funksionimin e sistemit të vjetër të monitorimit.
Departamenti i rrjetit drejtoi rrugë virtuale nga një prototip i BMS-së së re të vendosur në renë kompjuterike te pajisjet, dhe ne morëm rezultatet:
- pajisjet e lidhura nëpërmjet protokollit SNMP praktikisht nuk u shkëputën kurrë për shkak të kërkesave të njëkohshme,
- pajisjet e lidhura përmes portave duke përdorur protokollet modbas-TCP kishin probleme që u zgjidhën duke reduktuar në mënyrë inteligjente frekuencën e tyre të votimit.
Dhe më pas filluam të vëzhgonim se si po ndërtohej një sistem i ri para syve tanë, në të u shfaqën pajisje tashmë të njohura për ne, por në një ndërfaqe të ndryshme - të përshtatshme, të shpejtë, të arritshme edhe nga një telefon.
Ne do t'ju tregojmë se çfarë ndodhi në fund në pjesën e tretë të artikullit tonë.
Burimi: www.habr.com