Në pjesën e parë, folëm për arsyet pse vendosëm të zëvendësojmë sistemin tonë të vjetër BMS në Qendrat tona të të Dhënave me një të re. E jo thjesht të zëvendësojmë, por ta zhvillojmë nga e para sipas kërkesave tona. Në pjesën e dytë, tregojmë se si e realizuam këtë.
Analiza e tregut
Duke marrĂ« parasysh dĂ«shirat e pĂ«rmendura nĂ« vendosĂ«m tĂ« heqim dorĂ« nga pĂ«rmirĂ«simi i sistemit ekzistues, pĂ«r tĂ« shkruar njĂ« TĂ« DhĂ«na pĂ«r tĂ« gjetur zgjidhje nĂ« treg dhe bĂ«mĂ« kĂ«rkesa te disa kompani tĂ« mĂ«dha qĂ« merreshin ekskluzivisht me krijimin e sistemeve industriale SCADA.Â
Përgjigjet e para nga ata treguan se liderët e tregut të sistemeve të monitorimit kryesisht vazhdojnë të punojnë me servera fizikë, edhe pse procesi i migrimit në cloud ka filluar tashmë në këtë segmen. Sa i përket rezervimit të makinave virtuale - kjo opsion nuk ishte mbështetur nga askush. Për më tepër, dukej se askush nga zhvilluesit e njohur në treg nuk e kishte treguar as njëfarë kuptimi për nevojën për rezervim: "cloud-i nuk bie" ishte përgjigja më e shpeshtë. Në thelb, na u ofrua që të vendosnim monitorimin e Qendrës së të Dhënave në cloud, i cili ndodhej fizikisht në të njëjtën Qendër.
KĂ«tu duhet tĂ« bĂ«jmĂ« njĂ« kalim tĂ« vogĂ«l pĂ«r procesin e zgjedhjes sĂ« kontraktorit. Ămimi, sigurisht, ka rĂ«ndĂ«si, por gjatĂ« çdo tenderi pĂ«r realizimin e njĂ« projekti tĂ« komplikuar, nĂ« fazĂ«n e dialogut me furnizuesit, fillon tĂ« ndihesh se kush nga kandidatĂ«t Ă«shtĂ« mĂ« i interesuar dhe nĂ« gjendje ta realizojĂ« atĂ«.Â
Kjo Ă«shtĂ« veçanĂ«risht e dukshme nĂ« projektet e komplikuara.Â
Në bazë të natyrës së pyetjeve sqaruese për Të Dhënat, mund të ndahen kontraktorët në ata që janë të interesuar thjesht të shesin (ndjehet një presion standard nga menaxheri i shitjeve) dhe në ata që janë të interesuar në zhvillimin e produktit, duke dëgjuar dhe kuptuar klientin, duke bërë ndryshime konstruktive në Të Dhënat edhe para përzgjedhjes finale (madje pavarësisht rrezikut të vërtetë për të përmirësuar Të Dhënat e dikujt tjetër dhe humbur tenderin), përfundimisht të gatshëm të pranojnë sfidat profesionale dhe të krijojnë një produkt të mirë.
E gjithĂ« kjo na bĂ«ri tĂ« kushtojmĂ« vĂ«mendje njĂ« zhvilluesi lokal relativisht tĂ« vogĂ«l â grupit tĂ« kompanive "Sanline", i cili iu pĂ«rgjigj shumicĂ«s sĂ« kĂ«rkesave tona menjĂ«herĂ« dhe ishte i gatshĂ«m tĂ« realizonte tĂ« gjitha nevojat lidhur me BMS tĂ« re.Â
Rreziqet
NdĂ«rsa lojtarĂ«t e mĂ«dhenj pĂ«rpiqeshin tĂ« kuptonin se çfarĂ« dĂ«shironim dhe zhvillonin njĂ« komunikim tĂ« ngadaltĂ« me specialistĂ« tĂ« nivelit presales, zhvilluesi lokal caktuar njĂ« takim nĂ« zyrĂ«n tonĂ« me pjesĂ«marrjen e ekipit tĂ« tij teknik. GjatĂ« kĂ«tij takimi, kontraktori demonstroi pĂ«rsĂ«ri dĂ«shirĂ«n pĂ«r tĂ« marrĂ« pjesĂ« nĂ« projekt dhe â mĂ« e rĂ«ndĂ«sishmja â shpjegoi se si do tĂ« realizohej sistemi i kĂ«rkuar.   Â
Para takimit, ne pamë dy rreziqe në punën me një ekip, që nuk kishte prapa burimet e një kompanie të madhe kombëtare apo ndërkombëtare:
- Specialistët mund të nënvlerësojnë kapacitetet e tyre dhe në rezultat të mos arrijnë, për shembull, mund të përdorin softuer të ndërlikuar ose të projektuan algoritme rezervimi të pamundura.
- Pas realizimit të projektit, ekipi i projektit mund të shqiptohet dhe, si rezultat, mbështetja e produktit do të ishte nën kërcënim.
Për të minimizuar këto rreziqe, ftuam në takim specialistët tanë të zhvillimit. Punonjësit e kontraktorit të mundshëm u pyetën hollësisht në lidhje me ndërtimin e sistemit, mënyrën si do të realizohet rezervimi dhe pyetje të tjera, në të cilat ne, si shërbim operativ, nuk ishim mjaft 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 pĂ«r rezervimin dhe sinkronizimin Ă«shtĂ« logjike dhe funksionale.Â
Me rrezikun e parë u përballëm. Të dytin e përjashtuam, duke marrë nga kontraktori konfirmimin e gatishmërisë për të na transferuar burimet e kodit të sistemit dhe dokumentacionit, dhe gjithashtu duke zgjedhur gjuhën e programimit Python, e cila i është njohur mirë specialistëve tanë. Kjo na garantoi mundësinë për të mbështetur sistemin me forcat tona pa ndonjë vështirësi dhe pa një periudhë të gjatë trajnimi për punonjësit në rast se kompania zhvilluese largohet nga tregu.
NjĂ« pĂ«rfitim shtesĂ« i platformĂ«s ishte se ajo ishte realizuar nĂ« konteinerĂ« Docker: nĂ« kĂ«tĂ« ambient funksionojnĂ« bĂ«rthama, ndĂ«rfaqja web dhe DB e produktit. Ky qasje ofron shumĂ« avantazhe, duke pĂ«rfshirĂ« paracaktimin e konfigurimeve pĂ«r shpejtĂ«sinĂ« mĂ« tĂ« lartĂ« tĂ« shpĂ«rndarjes sĂ« zgjidhjes nĂ« krahasim me "klasikĂ«n" dhe shtimin e thjeshtĂ« tĂ« pajisjeve tĂ« reja nĂ« sistem. Principi "tĂ« gjithĂ« sĂ« bashku" thjeshton maksimalisht implementimin e sistemit: mjafton tĂ« nxjerrĂ«sh sistemin nga paketa dhe mund ta pĂ«rdorĂ«sh menjĂ«herĂ«.Â
Me njĂ« zgjidhje tĂ« tillĂ«, Ă«shtĂ« mĂ« e lehtĂ« tĂ« bĂ«sh kopje tĂ« sistemit, ndĂ«rsa pĂ«rmirĂ«simet dhe realizimi i pĂ«rditĂ«simeve mund tĂ« bĂ«het nĂ« njĂ« mjedis tĂ« veçantĂ«, pa ndĂ«rprerĂ« funksionimin e zgjidhjes nĂ« tĂ«rĂ«si. Â
Pas minimizimit të të dy riskëve, kontraktori ofroi një propozim. Ai përfshinte të gjitha parametrat më të rëndësishëm për ne për sistemin BMS.
Kopjim rezervë
Sistemi i ri BMS duhet tĂ« ishte nĂ« re, nĂ« njĂ« makinĂ« virtuale.Â
AsnjĂ« harduer, asnjĂ« server dhe tĂ« gjitha inconveniencat dhe rreziqet e lidhura me kĂ«tĂ« model tĂ« implementimit - zgjidhja nĂ« re na lejoi tĂ« shpĂ«tonim prej tyre pĂ«rfundimisht. U vendos qĂ« sistemi do tĂ« funksiononte nĂ« re tonĂ«n nĂ« dy lokacione tĂ« QendrĂ«s tĂ« tĂ« DhĂ«nave nĂ« ShĂ«nd Petersburg dhe MoskĂ«. KĂ«to janĂ« dy sisteme plotĂ«sisht funksionale, qĂ« punojnĂ« nĂ« modalitetin aktiv qĂ«ndrim me akses pĂ«r tĂ« gjithĂ« specialistĂ«t e autorizuar.Â
Dy sistemet mbulojnĂ« njĂ«ra-tjetrĂ«n, duke siguruar njĂ« rezervĂ« tĂ« plotĂ« si pĂ«r kapacitetet llogaritĂ«se, ashtu edhe pĂ«r kanalet e transmetimit tĂ« tĂ« dhĂ«nave. Gjithashtu janĂ« vendosur masa tĂ« tjera sigurie, duke pĂ«rfshirĂ« kopjimin e tĂ« dhĂ«nave dhe kanaleve, sistemeve, makinave virtuale nĂ« tĂ«rĂ«si, dhe njĂ« kopjim tĂ« veçantĂ« tĂ« DB çdo muaj (burimi mĂ« i çmuar nĂ« perspektivĂ«n e menaxhimit dhe analizĂ«s).Â
Vlen të theksohet se rezervimi si një opsion për zgjidhjen BMS u zhvillua posaçërisht sipas kërkesës tonë. Schemi i rezervimit dukej kështu:
Mbështetje
NjĂ« moment thelbĂ«sor pĂ«r pĂ«rdorimin efektiv tĂ« zgjidhjes BMS â mbĂ«shtetje teknike.Â
KĂ«tu gjithçka Ă«shtĂ« e thjeshtĂ«: sistemi i ri do tĂ« na kushtonte pĂ«r kĂ«tĂ« tregues 35,000 rubla nĂ« muaj pĂ«r SLA "reaksion brenda 8 orĂ«sh", pra 35,000 x 12 / 80 = $5,250 nĂ« vit. Viti i parĂ« â falas.Â
PĂ«r krahasim: mbĂ«shtetje e sistemit tĂ« vjetĂ«r BMS nga ofruesi na kushtonte $18,000 nĂ« vit me rritjen e shumĂ«s pĂ«r çdo pajisje tĂ« re qĂ« shtohej! MegjithatĂ«, kompania nuk ofronte menaxher tĂ« dedikuar, tĂ« gjitha ndĂ«rveprimet ndodhnin pĂ«rmes menaxherit tĂ« shitjeve, i cili kishte interes pĂ«r ne si njĂ« blerĂ«s potencial me perspektivĂ«n pĂ«rkatĂ«se nĂ« pĂ«rpunimin e kĂ«rkesave.Â
PĂ«r mĂ« pak para morĂ«m mbĂ«shtetje tĂ« plotĂ« pĂ«r produktin, 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Ă« qasjes direkte te zhvilluesit pĂ«r korigjime tĂ« menjĂ«hershme nĂ« çdo aspekt tĂ« funksionimit tĂ« sistemit, integrimit pĂ«rmes API etj.
Përditësime
NĂ« propozimin e ofruar pĂ«r BMS-nĂ« e re, tĂ« gjitha pĂ«rditĂ«simet pĂ«rfshiheshin nĂ« koston e mbĂ«shtetjes, domethĂ«nĂ« nuk kĂ«rkonin pagesa shtesĂ«. PĂ«rjashtimi Ă«shtĂ« zhvillimi i funksionaliteteve shtesĂ«, pĂ«rtej asaj qĂ« tregohet nĂ« TKT.Â
Sistemi i vjetër supozonte pagesë për përditësimin e programeve të integruara falas (si Java), si dhe për korrigjimin e gabimeve. Nuk mund të hiqeshim nga kjo, përndryshe në mungesë të përditësimeve sistemi në tërësi "ngadalësonte" për shkak të versioneve të vjetra të komponenteve të brendshme.
Dhe, natyrisht, nuk mund të përditësohej programi pa blerjen e paketës së mbështetjes.
Qasja fleksibile
NjĂ« kĂ«rkesĂ« tjetĂ«r e rĂ«ndĂ«sishme kishte tĂ« bĂ«nte me ndĂ«rfaqen. Ne dĂ«shironim tĂ« siguronim qasje nĂ« tĂ« pĂ«rmes njĂ« shfletuesi nga çdo pikĂ«, pa pasur nevojĂ« pĂ«r praninĂ« e njĂ« inxhinieri nĂ« territorin e QendrĂ«s sĂ« tĂ« DhĂ«nave. PĂ«r mĂ« tepĂ«r, ne pĂ«rpiqeshim pĂ«r krijimin e njĂ« ndĂ«rfaqe animacioni, pĂ«r tĂ« bĂ«rĂ« dinamizmin e funksionimit tĂ« infrastrukturĂ«s mĂ« vizual pĂ«r inxhinierĂ«t e turneve.Â
Gjithashtu, nĂ« sistemin e ri duhej tĂ« sigurohej mbĂ«shtetje pĂ«r formulat pĂ«r llogaritjen e punĂ«s sĂ« senzorĂ«ve virtualĂ« nĂ« sistemet inxhinierike â pĂ«r shembull, pĂ«r shpĂ«rndarjen optimale tĂ« kapacitetit elektrik nĂ« raftet me pajisje. PĂ«r kĂ«tĂ«, duhej tĂ« kishim nĂ« dispozicion tĂ« gjitha operacionet matematikore tĂ« njohura, tĂ« aplikueshme pĂ«r treguesit e sensorĂ«ve.Â
MĂ« tej, ishte e nevojshme qasje nĂ« bazĂ«n e tĂ« dhĂ«nave SQL me mundĂ«sinĂ« pĂ«r tĂ« marrĂ« tĂ« dhĂ«nat e nevojshme mbi funksionimin e pajisjeve â konkretisht, tĂ« gjitha regjistrimet mbi monitorimin e dy mijĂ« pajisjeve dhe dy mijĂ« sensorĂ«ve virtualĂ«, qĂ« gjeneronin rreth 20 mijĂ« variabla.Â
Gjithashtu, na nevojitej njĂ« modul pĂ«r llogaritjen e pajisjeve nĂ« raft, qĂ« do tĂ« jepte njĂ« paraqitje grafike tĂ« vendosjes sĂ« pajisjeve nĂ« çdo unit, duke llogaritur gjithashtu peshĂ«n totale tĂ« "harduerit", duke mbajtur njĂ« bibliotekĂ« pajisjesh dhe informacion tĂ« detajuar mbi çdo element.Â
Miratimi i TKT-së dhe nënshkrimi i kontratës
Në atë kohë, kur ishte e nevojshme të fillonim punën mbi sistemin e ri, korespondenca me "kompanitë e mëdha" ende ishte shumë larg diskutimit të kostove të propozuar prej tyre, prandaj krahasuam propozimin e pranuar me shpenzimet për përditësimin e BMS-së së vjetër (shih. ), dhe në rezultat ai rezultoi më tërheqës në çmim dhe përputhës me kërkesat tona.
U bë zgjedhja.
Pas pasjesh marrjen e kontraktuesit, avokatët filluan të përgatisin marrëveshjen, ndërsa ekipet teknike nga të dyja anët përfunduan detajet e specifikimeve teknike. Siç dihet, një specifikim teknik i detajuar dhe i saktë është baza e suksesit të çdo projekti. Sa më shumë detaje të jepen në specifikime, aq më pak zhgënjime do të ketë si «ne nuk e kishim parashikuar kështu».
Do të jap dy shembuj të nivelit të detajimit të kërkesave në specifikimet teknike:
- Qendrat e të dhënave kanë kompetencën për të shtuar pajisje të reja në BMS, zakonisht PDU. Në BMS-në e vjetër, kjo ishte një nivel «administratori», i cili, përfshirë, lejonte të ndiheshin parametrat e të gjitha pajisjeve, dhe ndarja e funksioneve ishte e pamundur. Kjo na shqetësoi. Në versionin bazë të platformës së re, skema ishte e ngjashme. Ne e kemi shënuar menjëherë në specifikimet që dëshironim të ndanim këto role: vetëm një punonjës i autorizuar duhet të ndante parametrat, por rojet e natës duhet të kishin ende mundësinë të shtonin pajisje. Kjo skemë u miratua për zbatim.
-  NĂ« çdo BMS standarde janĂ« tri kategori tipike tĂ« njoftimeve: TĂ KUQE â duhet tĂ« reagohet menjĂ«herĂ«, TĂ VERDHĂ â mund tĂ« vĂ«zhgohet, TĂ BLU â «Informuese». Ne tradicionalisht pĂ«rdorim njoftimet «blu» pĂ«r tĂ« monitoruar tejkalimin e parametrave tregtarĂ«, pĂ«r shembull, tejkalimin e kufijve tĂ« fuqisĂ« sĂ« raftit tĂ« klientit. Ky lloj njoftimi, nĂ« rastin tonĂ«, ishte pĂ«r menaxherĂ«t dhe nuk ishte i interesuar pĂ«r shĂ«rbimin e operimit, por nĂ« BMS-nĂ« e vjetĂ«r rregullisht mbushte listĂ«n e incidentĂ«ve aktiv dhe pengonte punĂ«n operative. Logjika dhe ngjyra dalluese e njoftimeve ne i konsideruam tĂ« suksesshme dhe e ruajtĂ«m, megjithatĂ« nĂ« specifikime e shĂ«nuam qartĂ« qĂ« njoftimet «blu» duhet, pa i shpĂ«rqendruar rojet, tĂ« «shkarkoheshin» pa zĂ« nĂ« njĂ« seksion tĂ« veçantĂ«, ku do tĂ« merreshin nga specialistĂ«t tregtarĂ«.
Me njĂ« nivel tĂ« ngjashĂ«m detajimi, ishin pĂ«rcaktuar format e ndĂ«rtimit tĂ« grafikĂ«ve dhe nxjerrjes sĂ« raporteve, konturet e ndĂ«rfaqeve, lista e pajisjeve qĂ« duhej tĂ« monitoroheshin dhe shumĂ« gjĂ«ra tĂ« tjera.Â
Ishte njĂ« punĂ« vĂ«rtet krijuese e tre grupeve tĂ« punĂ«s â shĂ«rbimi i porositĂ«sit, i cili diktonte kĂ«rkesat dhe kushtet e tij; specialistĂ«t teknikĂ« nga tĂ« dyja anĂ«t, tĂ« cilĂ«t kishin detyrĂ«n pĂ«r tĂ« shndĂ«rruar kĂ«to kushte nĂ« dokumentacion teknik; ekipi i programuesve tĂ« kontraktuesit, qĂ« zbatonte kĂ«rkesat e porositĂ«sit sipas dokumentacionit tĂ« zhvilluar teknik... NĂ« fund, disa nga kĂ«rkesat tona qĂ« nuk ishin thelbĂ«sore i pĂ«rshtatĂ«m pas funksionalitetit tĂ« platformĂ«s sĂ« ekzistueshme, ndĂ«rsa disa kontraktuesi u angazhua t'i shkruajĂ« pĂ«r ne.Â
Puna paralele e dy sistemeve
Arriti koha për realizim. Në praktikë, kjo nënkuptonte se ne i japim kontraktuesit mundësinë për të zhvilluar një prototip BMS në cloud-in tonë virtual dhe ofrojmë qasje në rrjet për të gjitha pajisjet e nevojshme për monitorim.
MegjithatĂ«, sistemi i ri ende nuk ishte gati pĂ«r punĂ«. NĂ« kĂ«tĂ« fazĂ«, ishte e rĂ«ndĂ«sishme pĂ«r ne tĂ« ruanim monitorimin nĂ« sistemin e vjetĂ«r dhe nĂ« tĂ« njĂ«jtĂ«n kohĂ« tĂ« ofronim qasje nĂ« pajisje pĂ«r sistemin e ri. Nuk Ă«shtĂ« e mundur tĂ« ndĂ«rtosh njĂ« sistem tĂ« pĂ«rshtatshĂ«m pa parĂ« pajisjet qĂ«, nĂ« tĂ« njĂ«jtĂ«n kohĂ«, nuk mund tĂ« dislokojmĂ« nga monitorimi nĂ« sistemin e vjetĂ«r.Â
Këto pajisje do të ishin në gjendje të përballonin pyetjet nga dy sisteme, nuk ishte e qartë pa provë reale. Ekzistonte mundësia që pyetja e dyfishtë e përbashkët të sillte shpesh dështime në përgjigje nga pajisjet dhe ne do të merrnim shumë gabime për papërshtatshmërinë e pajisjeve, që do të bllokonte punën e sistemit të vjetër të monitorimit.
Departamenti i rrjetit krijoi rrugĂ« virtuale nga prototipi i BMS-sĂ« sĂ« re, e vendosur nĂ« cloud, nĂ« pajisje, dhe ne morĂ«m rezultatet:Â
- pajisjet e lidhura pĂ«rmes protokollit SNMP, praktikisht nuk shpĂ«rbĂ«heshin pĂ«r shkak tĂ« kĂ«rkesave tĂ« pĂ«rbashkĂ«ta,Â
- pajisjet e lidhura pĂ«rmes portave pĂ«r protokollet modbas-TCP, kishin probleme, tĂ« cilat u zgjidhĂ«n me njĂ« ulje tĂ« arsyeshme tĂ« frekuencĂ«s sĂ« pyetjes sĂ« tyre. Â
Dhe pastaj filluam tĂ« shohim sesi po ndĂ«rtohej sistemi i ri para syve tanĂ«, aty po shfaqeshin pajisjet qĂ« na ishin tashmĂ« tĂ« njohura, por nĂ« njĂ« ndĂ«rfaqe tjetĂ«r â tĂ« rehatshme, tĂ« shpejtĂ«, tĂ« aksesueshme edhe nga telefoni.
Për atë që arritëm në fund, do të flasim në pjesën e tretë të artikullit tonë.
Burimi: habr.com
