Sa unang bahagi, pinag-usapan namin kung bakit nagpasya kaming palitan ng bago ang lumang BMS system sa aming mga data center. At hindi lamang pagbabago, ngunit bumuo mula sa simula upang umangkop sa iyong mga kinakailangan. Sa ikalawang bahagi, sasabihin namin sa iyo kung paano namin ito ginawa.
Pagsusuri ng merkado
Isinasaalang-alang ang mga inilarawan sa mga kagustuhan at ang desisyon na tumanggi na i-update ang umiiral na sistema, sumulat kami ng teknikal na detalye upang makahanap ng solusyon sa merkado at gumawa ng mga katanungan sa ilang malalaking kumpanya na nakikibahagi lamang sa paglikha ng mga pang-industriyang sistema ng SCADA.
Ang pinakaunang mga tugon mula sa kanila ay nagpakita na ang mga pinuno ng merkado ng mga sistema ng pagsubaybay ay pangunahing patuloy na nagtatrabaho sa mga server ng hardware, kahit na ang proseso ng paglipat sa mga ulap sa segment na ito ay nagsimula na. Tulad ng para sa pagpapareserba ng mga virtual machine, walang sumuporta sa opsyong ito. Bukod dito, may pakiramdam na wala sa mga kilalang developer sa merkado ang nagpakita ng pag-unawa sa pangangailangan para sa redundancy: "ang ulap ay hindi bumabagsak" ang pinakakaraniwang sagot. Sa katunayan, inaalok kami na ilagay ang pagsubaybay sa data center sa isang cloud na pisikal na matatagpuan sa parehong data center.
Dito kailangan nating gumawa ng isang maliit na digression tungkol sa proseso ng pagpili ng isang kontratista. Ang presyo, siyempre, ay mahalaga, ngunit sa anumang tender para sa pagpapatupad ng isang kumplikadong proyekto, sa yugto ng pag-uusap sa mga supplier, nagsisimula kang madama kung alin sa mga kandidato ang mas interesado at may kakayahang ipatupad ito.
Ito ay lalo na kapansin-pansin sa mga kumplikadong proyekto.
Batay sa likas na katangian ng paglilinaw ng mga tanong sa mga teknikal na detalye, ang mga kontratista ay maaaring nahahati sa mga interesado sa simpleng pagbebenta (ang karaniwang presyon ng isang sales manager ay nararamdaman) at sa mga interesado sa pagbuo ng isang produkto, na narinig at naunawaan ang customer, na gumagawa ng nakabubuo. mga pag-amyenda sa mga teknikal na detalye bago pa man ang pinal na pagpipilian (kahit na sa kabila ng tunay na panganib ng pagpapabuti ng teknikal na mga detalye ng ibang tao at pagkawala ng tender), sa huli ay handa lang silang tumanggap ng isang propesyonal na hamon at gumawa ng isang mahusay na produkto.
Ang lahat ng ito ay nagbigay-pansin sa amin sa isang medyo maliit na lokal na developer - ang Sunline na grupo ng mga kumpanya, na tumugon kaagad sa karamihan ng aming mga kinakailangan at handang ipatupad ang lahat ng mga pangangailangan tungkol sa bagong BMS.
Mga panganib
Habang sinusubukan ng malalaking manlalaro na maunawaan kung ano ang gusto namin at nagsasagawa ng masayang pakikipag-ugnayan sa amin na kinasasangkutan ng mga espesyalista sa antas ng pre-sale, nag-iskedyul ang lokal na developer ng pulong sa aming opisina kasama ang partisipasyon ng kanyang technical team. Sa pulong na ito, muling ipinakita ng kontratista ang kanyang pagnanais na lumahok sa proyekto at, higit sa lahat, ipinaliwanag kung paano ipapatupad ang kinakailangang sistema.
Bago ang pulong, nakita namin ang dalawang panganib ng pakikipagtulungan sa isang koponan na walang mga mapagkukunan ng isang malaking pambansa o internasyonal na kumpanya sa likod nito:
- Ang mga espesyalista ay maaaring mag-overestimate sa kanilang mga kakayahan at, bilang isang resulta, mabibigo lamang na makayanan, halimbawa, gagamit sila ng kumplikadong software o magdidisenyo ng hindi magagawang mga algorithm sa pagpapareserba.
- Pagkatapos makumpleto ang proyekto, maaaring maghiwa-hiwalay ang pangkat ng proyekto at, samakatuwid, ang suporta sa produkto ay nasa panganib.
Upang mabawasan ang mga panganib na ito, inimbitahan namin ang aming sariling mga espesyalista sa pag-unlad sa pulong. Ang mga empleyado ng potensyal na kontratista ay lubusang nainterbyu tungkol sa kung ano ang batayan ng sistema, kung paano pinaplanong ipatupad ang redundancy, at iba pang mga isyu kung saan kami, bilang isang serbisyo sa pagpapatakbo, ay hindi sapat na may kakayahan.
Ang hatol ay positibo: ang arkitektura ng umiiral na BMS platform ay moderno, simple at maaasahan, maaaring mapabuti, ang iminungkahing redundancy at synchronization scheme ay lohikal at magagawa.
Ang unang panganib ay hinarap. Ang pangalawa ay hindi kasama pagkatapos makatanggap ng kumpirmasyon mula sa kontratista na handa silang ilipat ang source code ng system at dokumentasyon sa amin, at gayundin sa pamamagitan ng pagpili ng Python programming language, na kilala ng aming mga espesyalista. Ginagarantiyahan nito sa amin ang pagkakataong mapanatili ang system nang mag-isa nang walang anumang kahirapan at mahabang panahon ng pagsasanay ng empleyado kung sakaling umalis ang kumpanya ng pag-unlad sa merkado.
Ang isang karagdagang bentahe ng platform ay ipinatupad ito sa mga lalagyan ng Docker: ang kernel, web interface at function ng database ng produkto sa kapaligirang ito. Nagbibigay ang diskarteng ito ng maraming pakinabang, kabilang ang mga preset na setting para sa pinakamataas na bilis ng pag-deploy ng solusyon kumpara sa "classic" at madaling pagdaragdag ng mga bagong device sa system. Pinapasimple ng prinsipyong "all together" ang pagpapatupad ng system hangga't maaari: kailangan mo lang i-unpack ang system at magagamit mo agad ito.
Sa solusyon na ito, mas madaling gumawa ng mga kopya ng system, at maaari mong pagbutihin ito at ipatupad ang mga pag-upgrade sa isang hiwalay na kapaligiran, nang hindi tumitigil sa pagpapatakbo ng solusyon sa kabuuan.
Kapag nabawasan na ang dalawang panganib, ibinigay ng kontratista ang CP. Sinakop nito ang lahat ng pinakamahalagang parameter ng BMS system para sa amin.
Pagpapareserba
Ang bagong BMS system ay kailangang matatagpuan sa cloud, sa isang virtual machine.
Walang hardware, walang server at lahat ng abala at panganib na nauugnay sa modelong ito ng deployment - pinahintulutan kami ng cloud solution na alisin ang mga ito magpakailanman. Napagpasyahan na ang system ay gagana sa aming cloud sa dalawang data center site sa St. Petersburg at Moscow. Ito ay dalawang fully functional na system na tumatakbo sa active standby mode na may access sa lahat ng awtorisadong espesyalista.
Ang dalawang sistema ay nagsisiguro sa isa't isa, na nagbibigay ng buong reserba ng parehong computing power at data transmission channels. Ang mga karagdagang hakbang sa seguridad ay na-configure din, kabilang ang backup ng data at mga channel, system, virtual machine sa pangkalahatan, at isang hiwalay na backup ng database minsan sa isang buwan (ang pinakamahalagang mapagkukunan sa mga tuntunin ng pamamahala at pagsusuri).
Tandaan na ang redundancy bilang isang opsyon sa BMS solution ay partikular na binuo para sa aming kahilingan. Ang reservation scheme mismo ay ganito ang hitsura:
Suporta
Ang pinakamahalagang punto para sa epektibong pagpapatakbo ng isang solusyon sa BMS ay teknikal na suporta.
Ang lahat ay simple dito: ang isang bagong sistema ay nagkakahalaga sa amin ng 35 rubles ayon sa tagapagpahiwatig na ito. bawat buwan para sa "tugon sa loob ng 000 oras" ng SLA, ibig sabihin, 8 x 35 / 000 = $12 bawat taon. Ang unang taon ay libre.
Para sa paghahambing, ang pagpapanatili ng lumang BMS mula sa vendor ay nagkakahalaga ng $18 bawat taon na may pagtaas sa halaga para sa bawat bagong device na idinagdag! Kasabay nito, ang kumpanya ay hindi nagbigay ng dedikadong tagapamahala na naganap ang lahat ng pakikipag-ugnayan sa pamamagitan ng isang sales manager na interesado sa amin bilang isang potensyal na mamimili na may kaukulang diin sa pagproseso ng mga kahilingan.
Para sa mas kaunting pera, nakatanggap kami ng buong suporta sa produkto, kasama ang isang account manager na makikibahagi sa pagbuo ng produkto, na may isang punto ng pagpasok, atbp. Naging mas flexible ang suporta - salamat sa direktang pag-access sa mga developer para sa agarang pagsasaayos sa anumang aspeto ng system, pagsasama sa pamamagitan ng API, atbp.
Update
Ayon sa iminungkahing CP sa bagong BMS, ang lahat ng mga update ay kasama sa halaga ng suporta, i.e. hindi nangangailangan ng karagdagang bayad. Ang pagbubukod ay ang pagbuo ng karagdagang pag-andar na lampas sa tinukoy sa mga teknikal na pagtutukoy.
Ang lumang system ay nangangailangan ng pagbabayad para sa parehong mga update sa firmware (gaya ng Java) at mga pag-aayos ng bug. Imposibleng tanggihan ito; sa kawalan ng mga pag-update, ang sistema sa kabuuan ay "bumagal" dahil sa mga lumang bersyon ng mga panloob na bahagi.
At, siyempre, imposibleng i-update ang software nang hindi bumili ng package ng suporta.
Flexible na diskarte
Ang isa pang pangunahing kinakailangan ay may kinalaman sa interface. Nais naming magbigay ng access dito sa pamamagitan ng isang web browser mula sa kahit saan, nang walang obligadong presensya ng isang engineer sa teritoryo ng data center. Bilang karagdagan, hinangad naming lumikha ng isang animated na interface upang ang dynamics ng imprastraktura ay maging mas malinaw sa mga inhinyero na naka-duty.
Gayundin sa bagong sistema kinakailangan na magbigay ng suporta para sa mga formula para sa pagkalkula ng pagpapatakbo ng mga virtual na sensor sa mga sistema ng engineering - halimbawa, para sa pinakamainam na pamamahagi ng elektrikal na kapangyarihan sa mga rack ng kagamitan. Upang gawin ito, kailangan mong nasa iyong pagtatapon ang lahat ng karaniwang mga pagpapatakbo ng matematika na naaangkop sa mga tagapagpahiwatig ng sensor.
Susunod, ang pag-access sa isang database ng SQL ay kinakailangan na may kakayahang kunin mula dito ang kinakailangang data sa pagpapatakbo ng kagamitan - ibig sabihin, ang lahat ng mga talaan ng pagsubaybay ng dalawang libong mga aparato at dalawang libong mga virtual na sensor na bumubuo ng humigit-kumulang 20 libong mga variable.
Kinakailangan din ang isang module ng accounting ng rack equipment, na nagbibigay ng graphical na representasyon ng pag-aayos ng mga device sa bawat unit na may pagkalkula ng kabuuang bigat ng hardware, pagpapanatili ng library ng mga device at detalyadong impormasyon tungkol sa bawat elemento.
Pag-apruba ng mga teknikal na pagtutukoy at pagpirma ng isang kasunduan
Sa oras na kinakailangan upang simulan ang trabaho sa bagong sistema, ang pakikipag-ugnayan sa "malalaki" na kumpanya ay napakalayo pa rin sa pagtalakay sa halaga ng kanilang mga panukala, kaya't inihambing namin ang natanggap na CP sa mga gastos sa pag-update ng lumang BMS (tingnan. ), at bilang resulta naging mas kaakit-akit ito sa presyo at nakakatugon sa aming mga kinakailangan.
Ang pagpili ay ginawa na.
Pagkatapos pumili ng isang kontratista, nagsimulang gumawa ng kasunduan ang mga abogado, at ang mga teknikal na koponan mula sa magkabilang panig ay nagsimulang bulihin ang mga teknikal na detalye. Tulad ng alam mo, ang mga detalyado at karampatang teknikal na pagtutukoy ay ang batayan para sa tagumpay ng anumang gawain. Kung mas maraming mga detalye ang nasa mga teknikal na detalye, mas kaunting mga pagkabigo tulad ng "ngunit hindi ito ang gusto namin."
Magbibigay ako ng dalawang halimbawa ng antas ng detalye ng mga kinakailangan sa mga teknikal na pagtutukoy:
- Ang mga data center na naka-duty ay binibigyang kapangyarihan na magdagdag ng mga bagong device sa BMS, kadalasan ito ay mga PDU. Sa lumang BMS, ito ang antas ng "administrator", na nagpapahintulot din sa pagbabago ng mga variable na setting ng lahat ng mga device, at imposibleng paghiwalayin ang mga function. Hindi ito nababagay sa amin. Sa umiiral na pangunahing bersyon ng bagong platform, ang scheme ay katulad. Kaagad naming ipinahiwatig sa mga tuntunin ng sanggunian na gusto naming paghiwalayin ang mga tungkuling ito: isang awtorisadong empleyado lamang ang dapat magbago ng mga setting, ngunit ang mga naka-duty ay dapat patuloy na makapagdagdag ng mga device. Ang scheme na ito ay tinanggap para sa pagpapatupad.
- Sa anumang karaniwang BMS mayroong tatlong tipikal na kategorya ng mga abiso: RED - dapat matugunan kaagad, DILAW - maaaring obserbahan, BLUE - "Informational". Nakasanayan na naming gumamit ng mga asul na alerto upang subaybayan kapag nalampasan na ang mga parameter ng negosyo, gaya ng rack ng customer na lumampas sa limitasyon ng kapasidad nito. Ang ganitong uri ng abiso sa aming kaso ay inilaan para sa mga tagapamahala at hindi interesado sa serbisyo ng pagpapatakbo, ngunit sa lumang BMS ay regular nitong binara ang listahan ng mga aktibong insidente at nakakasagabal sa gawaing pagpapatakbo. Itinuring namin na ang mismong lohika at pagkakaiba-iba ng kulay ng mga pantalon ng abiso ay matagumpay at pinanatili ito, gayunpaman, ang mga teknikal na detalye ay partikular na nagpahiwatig na ang mga "asul" na mga abiso ay dapat, nang hindi nakakagambala sa mga opisyal ng tungkulin, ay tahimik na "ibuhos" sa isang hiwalay na seksyon, kung saan sila ay haharapin ng mga komersyal na espesyalista.
Sa katulad na antas ng detalye, ang mga format para sa pagbuo ng mga graph at pagbuo ng mga ulat, ang mga balangkas ng mga interface, ang listahan ng mga device na kailangang subaybayan, at marami pang ibang bagay ay inireseta.
Ito ay isang tunay na malikhaing gawain ng tatlong nagtatrabahong grupo - ang serbisyo sa customer, na nagdidikta ng mga kinakailangan at kundisyon nito; mga teknikal na espesyalista sa magkabilang panig, na ang gawain ay gawing teknikal na dokumentasyon ang mga kundisyong ito; mga koponan ng mga contractor programmer na nagpatupad ng mga kinakailangan ng customer ayon sa binuong teknikal na dokumentasyon... Bilang resulta, inangkop namin ang ilan sa aming mga walang prinsipyong kinakailangan sa functionality ng isang umiiral nang platform, at nagsagawa ang contractor na magdagdag ng isang bagay para sa amin.
Parallel na operasyon ng dalawang sistema
Oras na para sa pagpapatupad. Sa pagsasagawa, nangangahulugan ito na binibigyan namin ang contractor ng pagkakataong mag-deploy ng BMS prototype sa aming virtual cloud at magbigay ng access sa network sa lahat ng device na nangangailangan ng pagsubaybay.
Gayunpaman, ang bagong sistema ay hindi pa handa para sa operasyon. Sa yugtong ito, mahalaga para sa amin na mapanatili ang pagsubaybay sa lumang system at sa parehong oras ay bigyan ng access ang mga device sa bagong system. Imposibleng maayos na bumuo ng isang sistema nang hindi nakikita ang mga device sa loob nito, na kung saan ay hindi maaaring hindi paganahin mula sa pagsubaybay ng lumang sistema.
Kung ang mga aparato ay makatiis ng sabay-sabay na interogasyon ng dalawang sistema ay hindi halata nang walang tunay na pagsubok. May posibilidad na ang dobleng sabay-sabay na botohan ay hahantong sa madalas na pagtanggi na tumugon mula sa mga device at makakatanggap kami ng maraming error tungkol sa hindi available na mga device, na hahadlang naman sa pagpapatakbo ng lumang sistema ng pagsubaybay.
Ang network department ay nagpatakbo ng mga virtual na ruta mula sa isang prototype ng bagong BMS na naka-deploy sa cloud hanggang sa mga device, at nakuha namin ang mga resulta:
- Ang mga device na konektado sa pamamagitan ng SNMP protocol ay halos hindi kailanman nadiskonekta dahil sa sabay-sabay na mga kahilingan,
- Ang mga device na konektado sa pamamagitan ng mga gateway gamit ang modbas-TCP protocol ay nagkaroon ng mga problema na nalutas sa pamamagitan ng matalinong pagbabawas ng dalas ng kanilang pagboto.
At pagkatapos ay sinimulan naming obserbahan kung paano itinayo ang isang bagong sistema sa harap ng aming mga mata, lumitaw ang mga device na pamilyar sa amin, ngunit sa ibang interface - maginhawa, mabilis, naa-access kahit mula sa isang telepono.
Sasabihin namin sa iyo kung ano ang nangyari sa dulo sa ikatlong bahagi ng aming artikulo.
Pinagmulan: www.habr.com