En la unua parto, ni parolis pri kial ni decidis anstataŭigi la malnovan BMS-sistemon en niaj datumcentroj per nova. Kaj ne nur ŝanĝi, sed evolui de nulo por konveni viajn postulojn. En la dua parto ni rakontas al vi kiel ni faris ĝin.
Merkata analizo
Konsiderante tiujn priskribitajn en deziroj kaj la decido rifuzi ĝisdatigi la ekzistantan sistemon, ni skribis teknikan specifon por trovi solvon sur la merkato kaj faris demandojn al pluraj grandaj kompanioj okupiĝantaj nur pri la kreado de industriaj SCADA-sistemoj.
La unuaj respondoj de ili montris, ke la gvidantoj de la merkato de monitoraj sistemoj ĉefe daŭre laboras pri aparataj serviloj, kvankam la procezo de migrado al la nuboj en ĉi tiu segmento jam komenciĝis. Koncerne rezervi virtualajn maŝinojn, neniu subtenis ĉi tiun opcion. Plie, estis sento, ke neniu el la programistoj videblaj sur la merkato eĉ pruvis komprenon pri la bezono de redundo: "la nubo ne falas" estis la plej ofta respondo. Fakte, oni proponis al ni loki datumcentran monitoradon en nubo fizike situanta en la sama datumcentro.
Ĉi tie ni devas fari malgrandan digresion pri la procezo de elekto de entreprenisto. Prezo, kompreneble, gravas, sed dum ajna oferto por la efektivigo de kompleksa projekto, en la stadio de dialogo kun provizantoj, vi komencas senti, kiu el la kandidatoj estas pli interesita kaj kapabla efektivigi ĝin.
Ĉi tio estas precipe videbla ĉe kompleksaj projektoj.
Surbaze de la naturo de klarigado de demandoj al la teknikaj specifoj, entreprenistoj povas esti dividitaj en tiuj, kiuj interesiĝas pri simple vendado (la norma premo de vendisto estas sentata) kaj tiuj, kiuj interesiĝas pri evoluigado de produkto, aŭdinte kaj kompreninte la klienton, farante konstruivan. amendoj al la teknikaj specifoj eĉ antaŭ la fina elekto (eĉ malgraŭ la reala la risko plibonigi la teknikajn specifojn de iu alia kaj perdi la oferton), finfine ili simple pretas akcepti profesian defion kaj fari bonan produkton.
Ĉio ĉi atentigis nin pri relative malgranda loka programisto - la grupo de kompanioj Sunline, kiu tuj respondis al la plej multaj el niaj postuloj kaj estis preta efektivigi ĉiujn bezonojn pri la nova BMS.
Risoj
Dum la grandaj ludantoj provis kompreni tion, kion ni volis kaj trankvile korespondis kun ni kun antaŭvendaj specialistoj, la loka programisto planis renkontiĝon en nia oficejo kun la partopreno de sia teknika teamo. En ĉi tiu renkontiĝo, la entreprenisto denove montris sian deziron partopreni la projekton kaj, plej grave, klarigis kiel la postulata sistemo estos efektivigita.
Antaŭ la renkontiĝo, ni vidis du riskojn labori kun teamo, kiu ne havas la rimedojn de granda nacia aŭ internacia kompanio malantaŭ ĝi:
- Specialistoj povus supertaksi siajn kapablojn kaj, kiel rezulto, simple malsukcesi elteni ekzemple, ili uzos kompleksan programaron aŭ desegnos nerealigeblajn rezervalgoritmojn;
- Post kiam la projekto estas finita, la projektteamo povas disiĝi kaj, tial, produkta subteno estos en danĝero.
Por minimumigi ĉi tiujn riskojn, ni invitis niajn proprajn disvolvajn specialistojn al la kunveno. La dungitoj de la eblaj entreprenistoj estis plene intervjuitaj pri tio, sur kio baziĝas la sistemo, kiel redundo estas planita esti efektivigita, kaj aliaj aferoj en kiuj ni, kiel operacia servo, ne estas sufiĉe kompetentaj.
La verdikto estis pozitiva: la arkitekturo de la ekzistanta BMS-platformo estas moderna, simpla kaj fidinda, plibonigebla, la proponita redundo kaj sinkroniga skemo estas logika kaj realigebla.
La unua risko estis traktita. La dua estis ekskludita post ricevi konfirmon de la kontraktisto, ke ili estas pretaj transdoni al ni la fontkodon de la sistemo kaj dokumentaron, kaj ankaŭ elektante la programlingvon Python, kiu estis bone konata de niaj specialistoj. Ĉi tio garantiis al ni la ŝancon konservi la sistemon memstare sen ajnaj malfacilaĵoj kaj longan periodon de dungita trejnado en la okazo de la evoluiga kompanio forlasas la merkaton.
Plia avantaĝo de la platformo estis, ke ĝi estis efektivigita en Docker-ujoj: la kerno, retinterfaco kaj produkta datumbazo funkcias en ĉi tiu medio. Ĉi tiu aliro provizas multajn avantaĝojn, inkluzive de antaŭfiksitaj agordoj por la plej alta rapideco de disfaldiĝo de la solvo kompare kun la "klasika" kaj facila aldono de novaj aparatoj al la sistemo. La principo "ĉio kune" simpligas la efektivigon de la sistemo kiel eble plej multe: simple malpaku la sistemon kaj vi povas tuj uzi ĝin.
Kun ĉi tiu solvo, estas pli facile fari kopiojn de la sistemo, kaj vi povas plibonigi ĝin kaj efektivigi ĝisdatigojn en aparta medio, sen ĉesigi la funkciadon de la solvo entute.
Post kiam ambaŭ riskoj estis minimumigitaj, la entreprenisto disponigis la CP. Ĝi kovris ĉiujn plej gravajn parametrojn de la BMS-sistemo por ni.
Rezervado
La nova BMS-sistemo devis troviĝi en la nubo, sur virtuala maŝino.
Neniu aparataro, neniu servilo kaj ĉiuj ĝenoj kaj riskoj asociitaj kun ĉi tiu deplojmodelo - la nuba solvo permesis al ni forigi ilin por ĉiam. Estis decidite, ke la sistemo funkcios en nia nubo ĉe du datumcentroj en Sankt-Peterburgo kaj Moskvo. Ĉi tiuj estas du plene funkciaj sistemoj funkciigantaj en aktiva standby-reĝimo kun aliro al ĉiuj rajtigitaj specialistoj.
La du sistemoj asekuras unu la alian, disponigante plenan rezervon de kaj komputa potenco kaj datumtranssendokanaloj. Pliaj sekurecaj mezuroj ankaŭ estis agordis, inkluzive de sekurkopio de datumoj kaj kanaloj, sistemoj, virtualaj maŝinoj ĝenerale, kaj aparta datumbaza sekurkopio unufoje monate (la plej valora rimedo laŭ administrado kaj analizo).
Notu, ke redundo kiel opcio en la BMS-solvo estis evoluigita specife por nia peto. La rezervadskemo mem aspektis jene:
subteno
La plej grava punkto por efika funkciado de BMS-solvo estas teknika subteno.
Ĉio ĉi tie estas simpla: nova sistemo kostus al ni 35 000 rublojn laŭ ĉi tiu indikilo. monate por la SLA "respondo ene de 8 horoj", tio estas, 35 x 000 / 12 = $ 80 jare. La unua jaro estas senpaga.
Por komparo, konservi la malnovan BMS de la vendisto kostis $ 18 jare kun pliigo de la kvanto por ĉiu nova aparato aldonita! Samtempe, la firmao ne disponigis dediĉitan administranton ĉiu interagado okazis per vendisto, kiu interesiĝas pri ni kiel ebla aĉetanto kun responda emfazo en prilaborado de petoj.
Por malpli da mono, ni ricevis plenan produktan subtenon, kun konta administranto, kiu partoprenus en produkt-disvolviĝo, kun ununura enirpunkto, ktp. Subteno fariĝis multe pli fleksebla - danke al rekta aliro al programistoj por rapidaj alĝustigoj al iu ajn aspekto de la sistemo, integriĝo per API, ktp.
Ĝisdatigoj
Laŭ la proponita CP en la nova BMS, ĉiuj ĝisdatigoj estas inkluzivitaj en la kosto de subteno, t.e. ne postulas plian pagon. La escepto estas la evoluo de plia funkcieco preter tio, kio estas specifita en la teknikaj specifoj.
La malnova sistemo postulis pagon por kaj firmware-ĝisdatigoj (kiel Java) kaj cimoj. Estis neeble rifuzi ĉi tion en foresto de ĝisdatigoj, la sistemo entute "malrapidiĝis" pro malnovaj versioj de internaj komponantoj.
Kaj, kompreneble, estis neeble ĝisdatigi la programaron sen aĉeti subtenan pakaĵon.
Fleksebla aliro
Alia fundamenta postulo koncernis la interfacon. Ni volis havigi aliron al ĝi per retumilo de ie ajn, sen deviga ĉeesto de inĝeniero sur la teritorio de la datumcentro. Krome, ni serĉis krei viglan interfacon por ke la dinamiko de la infrastrukturo estus pli klara al la deĵorantaj inĝenieroj.
Ankaŭ en la nova sistemo necesis provizi subtenon por formuloj por kalkuli la funkciadon de virtualaj sensiloj en inĝenieristiksistemoj - ekzemple por la optimuma distribuo de elektra potenco trans ekipaĵrakoj. Por fari tion, vi devas havi je via dispono ĉiujn kutimajn matematikajn operaciojn aplikeblajn al sensilindikiloj.
Poste, aliro al SQL-datumbazo estis postulata kun la kapablo preni el ĝi la necesajn datumojn pri la funkciado de la ekipaĵo - nome, ĉiuj monitoraj registroj de du mil aparatoj kaj du mil virtualaj sensiloj generantaj proksimume 20 mil variabloj.
Ankaŭ bezonis rako-ekipaĵa kontada modulo, provizante grafikan reprezenton de la aranĝo de aparatoj en ĉiu unuo kun kalkulo de la totala pezo de la aparataro, konservante bibliotekon de aparatoj kaj detalajn informojn pri ĉiu elemento.
Aprobo de teknikaj specifoj kaj subskribo de interkonsento
En la tempo, kiam estis necese komenci laboron sur la nova sistemo, korespondado kun "grandaj" kompanioj estis ankoraŭ tre malproksima de diskuti pri la kosto de iliaj proponoj, do ni komparis la ricevitan CP kun la kostoj de ĝisdatigo de la malnova BMS (vidu. ), kaj kiel rezulto ĝi montriĝis pli alloga en prezo kaj plenumi niajn postulojn.
La elekto estas farita.
Post elekto de entreprenisto, advokatoj komencis ellabori interkonsenton, kaj teknikaj teamoj de ambaŭ flankoj komencis poluri la teknikajn specifojn. Kiel vi scias, detalaj kaj kompetentaj teknikaj specifoj estas la bazo por la sukceso de iu ajn laboro. Ju pli da specifaĵoj estas en la teknikaj specifoj, des malpli da seniluziiĝoj kiel "sed ĉi tio ne estas tio, kion ni volis."
Mi donos du ekzemplojn de la nivelo de detalo de postuloj en la teknikaj specifoj:
- Datumcentroj deĵorantaj estas rajtigitaj por aldoni novajn aparatojn al la BMS, plej ofte ĉi tiuj estas PDUoj. En la malnova BMS, ĉi tio estis la "administranto" nivelo, kiu ankaŭ permesis ŝanĝi la variajn agordojn de ĉiuj aparatoj, kaj estis neeble apartigi la funkciojn. Ĉi tio ne konvenis al ni. En la ekzistanta baza versio de la nova platformo, la skemo estis simila. Ni tuj indikis en la referenco, ke ni volas apartigi ĉi tiujn rolojn: nur rajtigita dungito devas ŝanĝi la agordojn, sed la deĵorantoj daŭre povu aldoni aparatojn. Ĉi tiu skemo estis akceptita por efektivigo.
- En iu norma BMS estas tri tipaj kategorioj de sciigoj: RUĜA - devas esti respondata tuj, FLAVA - observabla, BLUA - "Informa". Ni tradicie uzis bluajn atentigojn por kontroli kiam komercaj parametroj estis superitaj, kiel la rako de kliento superanta sian kapacitan limon. Ĉi tiu speco de sciigo en nia kazo estis destinita por administrantoj kaj ne interesis la operacian servon, sed en la malnova BMS ĝi regule ŝtopis la liston de aktivaj okazaĵoj kaj malhelpis funkcian laboron. Ni konsideris la tre logikon kaj kolordiferencigon de la sciigaj pantalonoj sukcesa kaj konservis ĝin, tamen, la teknikaj specifoj specife indikis, ke "bluaj" sciigoj devus, sen distri la deĵorantajn oficirojn, silente "verŝi" en apartan sekcion, kie ili pritraktos komercaj specialistoj.
Kun simila grado de detalo, la formatoj por konstrui grafikaĵojn kaj generi raportojn, la konturoj de interfacoj, la listo de aparatoj kiuj devis esti monitoritaj, kaj multaj aliaj aferoj estis preskribitaj.
Tio estis vere krea laboro de tri laborgrupoj – la klientservo, kiu diktis ĝiajn postulojn kaj kondiĉojn; teknikaj specialistoj ambaŭflanke, kies tasko estis transformi tiujn kondiĉojn en teknikan dokumentadon; teamoj de entreprenistprogramistoj, kiuj efektivigis la postulojn de la kliento laŭ la evoluinta teknika dokumentaro... Kiel rezulto, ni adaptis kelkajn el niaj senprincipaj postuloj al la funkcieco de ekzistanta platformo, kaj la entreprenisto entreprenis aldoni ion por ni.
Paralela funkciado de du sistemoj
Estas tempo por efektivigo. En praktiko, ĉi tio signifis, ke ni donas al la entreprenisto la ŝancon deploji BMS-prototipon en nia virtuala nubo kaj disponigi retaliron al ĉiuj aparatoj kiuj postulas monitoradon.
Tamen, la nova sistemo ankoraŭ ne estis preta por funkciado. En ĉi tiu etapo, estis grave por ni konservi monitoradon en la malnova sistemo kaj samtempe doni aliron al la aparatoj al la nova sistemo. Estas neeble konvene konstrui sistemon sen vidi aparatojn en ĝi, kiuj siavice ne povas esti malŝaltitaj de monitorado de la malnova sistemo.
Ĉu la aparatoj povis elteni samtempan pridemandadon de du sistemoj ne estis evidenta sen reala testado. Ekzistis ebleco, ke duobla samtempa balotado kondukus al oftaj rifuzoj respondi de aparatoj kaj ni ricevus multajn erarojn rilate la nehaveblecon de aparatoj, kiuj siavice blokus la funkciadon de la malnova monitora sistemo.
La retsekcio prizorgis virtualajn itinerojn de prototipo de la nova BMS deplojita en la nubo al la aparatoj, kaj ni ricevis la rezultojn:
- aparatoj konektitaj per la SNMP-protokolo preskaŭ neniam malkonektiĝis pro samtempaj petoj,
- aparatoj ligitaj tra enirejoj uzantaj modbas-TCP-protokolojn havis problemojn kiuj estis solvitaj inteligente reduktante sian balotfrekvencon.
Kaj tiam ni komencis observi, kiel antaŭ niaj okuloj konstruiĝas nova sistemo, aperis en ĝi aparatoj jam konataj al ni, sed en alia interfaco - oportuna, rapida, alirebla eĉ de telefono.
Ni rakontos al vi kio okazis finfine en la tria parto de nia artikolo.
fonto: www.habr.com