Առաջին մասում մենք խոսեցինք այն մասին, թե ինչու որոշեցինք մեր տվյալների կենտրոններում հին BMS համակարգը փոխարինել նորով։ Եվ ոչ թե պարզապես փոխարինել այն, այլ զրոյից զարգացնել՝ մեր պահանջներին համապատասխանեցնելու համար։ Երկրորդ մասում մենք ձեզ կպատմենք, թե ինչպես ենք դա արել։
Շուկայական վերլուծություն
Հաշվի առնելով վերը նշվածը ցանկություններից և գործող համակարգը թարմացնելուց հրաժարվելու որոշումից հետո մենք գրեցինք տեխնիկական բնութագիր՝ շուկայում լուծում գտնելու համար և հարցումներ կատարեցինք մի քանի խոշոր ընկերություններից, որոնք զբաղվում էին միայն արդյունաբերական SCADA համակարգերի ստեղծմամբ։
Նրանց առաջին պատասխանները ցույց տվեցին, որ մոնիթորինգի համակարգերի շուկայի առաջատարները շարունակում են աշխատել հիմնականում երկաթե սերվերների վրա, չնայած այս հատվածում ամպային տեխնոլոգիաներին անցնելու գործընթացն արդեն սկսվել է: Ինչ վերաբերում է վիրտուալ մեքենաների պահուստավորմանը, ապա ոչ ոք չի աջակցել այս տարբերակին: Ավելին, թվում էր, թե շուկայում նկատելի մշակողներից ոչ մեկը նույնիսկ պահուստավորման անհրաժեշտության ըմբռնում չի ցուցաբերել. «ամպը չի ընկնում»՝ սա ամենատարածված պատասխանն էր: Փաստորեն, մեզ առաջարկվեց տվյալների կենտրոնի մոնիթորինգը տեղադրել ամպի մեջ, որը ֆիզիկապես տեղակայված է նույն տվյալների կենտրոնում:
Այստեղ մենք պետք է մի փոքր շեղվենք կապալառուի ընտրության գործընթացից։ Գինը, իհարկե, կարևոր է, բայց բարդ նախագծի իրականացման ցանկացած մրցույթի ժամանակ, մատակարարների հետ երկխոսության փուլում, դուք սկսում եք զգալ, թե թեկնածուներից որն է ավելի հետաքրքրված և ունակ իրականացնել այն։
Սա հատկապես նկատելի է բարդ նախագծերի դեպքում։
Տեխնիկական բնութագրերի պարզաբանման հարցերի բնույթից ելնելով՝ կապալառուները կարելի է բաժանել պարզապես վաճառելով հետաքրքրվածների (զգացվում է վաճառքի մենեջերի ստանդարտ ճնշումը) և ապրանք մշակելով, հաճախորդին լսելով և հասկանալով, վերջնական ընտրությունից առաջ տեխնիկական բնութագրերում կառուցողական փոփոխություններ կատարելով (նույնիսկ չնայած ուրիշի տեխնիկական բնութագրերը բարելավելու և մրցույթում պարտվելու իրական ռիսկին), և, ի վերջո, պարզապես պատրաստ են ընդունել մասնագիտական մարտահրավերը և լավ ապրանք պատրաստել։
Այս ամենը մեզ ստիպեց ուշադրություն դարձնել համեմատաբար փոքր տեղական կառուցապատողի՝ Sunline ընկերությունների խմբի վրա, որը անմիջապես արձագանքեց մեր պահանջների մեծ մասին և պատրաստ էր իրականացնել նոր BMS-ի հետ կապված բոլոր կարիքները։
Ռիսկերի
Մինչ խոշոր խաղացողները փորձում էին հասկանալ, թե ինչ ենք մենք ուզում և դանդաղորեն նամակագրվում էին մեզ հետ՝ նախավաճառքի մասնագետների օգնությամբ, տեղացի կառուցապատողը մեր գրասենյակում հանդիպում նշանակեց իր տեխնիկական թիմի մասնակցությամբ։ Այս հանդիպման ժամանակ կապալառուն ևս մեկ անգամ ցույց տվեց նախագծին մասնակցելու իր ցանկությունը և, ամենակարևորը, բացատրեց, թե ինչպես է ներդրվելու պահանջվող համակարգը։
Հանդիպումից առաջ մենք տեսանք երկու ռիսկ՝ աշխատելով այնպիսի թիմի հետ, որի ետևում չկան խոշոր ազգային կամ միջազգային ընկերության ռեսուրսները.
- Մասնագետները կարող են գերագնահատել իրենց հնարավորությունները և, որպես արդյունք, պարզապես չկարողանալ հաղթահարել խնդիրները, օրինակ՝ նրանք կօգտագործեն բարդ ծրագրային ապահովում կամ կմշակեն անիրագործելի պահուստավորման ալգորիթմներ։
- Նախագծի իրականացումից հետո նախագծի թիմը կարող է քայքայվել, ուստի ապրանքի աջակցությունը կարող է վտանգի տակ լինել։
Այս ռիսկերը նվազագույնի հասցնելու համար մենք հանդիպմանը հրավիրեցինք մեր սեփական զարգացման մասնագետներին։ Հավանական կապալառուի աշխատակիցների հետ մանրամասն հարցազրույց անցկացվեց այն մասին, թե ինչի վրա է հիմնված համակարգը, ինչպես է նախատեսվում իրականացնել ավելորդությունը և այլ հարցեր, որոնցում մենք՝ որպես գործառնական ծառայություն, բավականաչափ կոմպետենտ չենք։
Դատավճիռը դրական էր. գոյություն ունեցող BMS հարթակի ճարտարապետությունը ժամանակակից է, պարզ և հուսալի, կարող է բարելավվել, առաջարկվող պահուստավորման և համաժամեցման սխեման տրամաբանական է և արդյունավետ։
Մենք հաղթահարեցինք առաջին ռիսկը։ Երկրորդը վերացրինք՝ կապալառուից ստանալով հաստատում համակարգի սկզբնական կոդը և փաստաթղթերը մեզ փոխանցելու պատրաստակամության մասին, և ընտրելով Python ծրագրավորման լեզուն, որը լավ հայտնի է մեր մասնագետներին։ Սա մեզ երաշխավորեց համակարգը առանց որևէ դժվարության ինքնուրույն սպասարկելու և աշխատակիցների համար երկարատև ուսուցման հնարավորություն՝ այն դեպքում, եթե մշակող ընկերությունը լքի շուկան։
Հարթակի լրացուցիչ առավելությունն այն էր, որ այն ներդրվել էր Docker կոնտեյներներում. միջուկը, վեբ ինտերֆեյսը և արտադրանքի տվյալների բազան գործում են այս միջավայրում: Այս մոտեցումը բազմաթիվ առավելություններ է տալիս, այդ թվում՝ կարգավորումների նախնական տեղադրում՝ «դասականի» համեմատ լուծման տեղակայման ամենաբարձր արագության համար և համակարգին նոր սարքերի հեշտ ավելացման համար: «Բոլորը միասին» սկզբունքը հնարավորինս պարզեցնում է համակարգի ներդրումը. պարզապես բացեք համակարգը, և դուք կարող եք անմիջապես այն գործարկել:
Նման լուծման դեպքում համակարգի պատճեններ պատրաստելն ավելի հեշտ է, և այն կարող է բարելավվել և արդիականացվել առանձին միջավայրում՝ առանց լուծման ամբողջական աշխատանքը դադարեցնելու։
Երկու ռիսկերն էլ նվազագույնի հասցնելուց հետո, կապալառուն տրամադրեց CP: Այն ներառում էր մեզ համար BMS համակարգի բոլոր ամենակարևոր պարամետրերը:
Ամրագրում
Նոր BMS համակարգը պետք է տեղակայված լիներ ամպում՝ վիրտուալ մեքենայի վրա։
Առանց սարքավորումների, առանց սերվերների և այս տեղակայման մոդելի հետ կապված բոլոր անհարմարությունների ու ռիսկերի՝ ամպային լուծումը թույլ տվեց մեզ ընդմիշտ ազատվել դրանցից։ Որոշվեց, որ համակարգը կաշխատի մեր ամպում՝ Սանկտ Պետերբուրգի և Մոսկվայի երկու տվյալների կենտրոնների կայքերում։ Սրանք երկու լիարժեք ֆունկցիոնալ համակարգեր են, որոնք գործում են ակտիվ սպասման ռեժիմով՝ բոլոր լիազորված մասնագետների համար հասանելիությամբ։
Երկու համակարգերը պահուստավորում են միմյանց՝ ապահովելով ինչպես հաշվողական հզորության, այնպես էլ տվյալների փոխանցման ալիքների լիարժեք պաշար: Կարգավորվում են նաև լրացուցիչ անվտանգության միջոցառումներ, այդ թվում՝ տվյալների և ալիքների, համակարգերի, վիրտուալ մեքենաների ընդհանուր պահուստավորում և ամսական մեկ անգամ տվյալների բազայի առանձին պահուստավորում (ամենաարժեքավոր ռեսուրսը կառավարման և վերլուծության առումով):
Նկատի ունեցեք, որ BMS լուծման տարբերակի համար նախատեսված ամրագրումը մշակվել է հատուկ մեր հարցման համար։ Ամրագրման սխեման ինքնին այսպիսին էր.
Աջակցություն
BMS լուծման արդյունավետ գործունեության ամենակարևոր կետը տեխնիկական աջակցությունն է։
Այստեղ ամեն ինչ պարզ է. նոր համակարգը մեզ կարժենա ամսական 35 ռուբլի SLA-ի «000 ժամվա ընթացքում արձագանքի» համար, այսինքն՝ 8 x 35 / 000 = $12 տարեկան: Առաջին տարին անվճար է:
Համեմատության համար. հին BMS-ի մատակարարի կողմից աջակցությունը տարեկան արժեցել է 18 դոլար՝ յուրաքանչյուր նոր սարքի ավելացման համար գումարի ավելացմամբ։ Միևնույն ժամանակ, ընկերությունը չի տրամադրել մասնագիտացված մենեջեր, բոլոր փոխազդեցությունները տեղի են ունեցել վաճառքի մենեջերի միջոցով, որը հետաքրքրված է մեզանով որպես պոտենցիալ գնորդ՝ համապատասխան շեշտը դնելով հարցումների մշակման վրա։
Ավելի քիչ գումարի դիմաց մենք ստացանք արտադրանքի լիարժեք աջակցություն՝ հաշվի կառավարիչով, որը կմասնակցեր արտադրանքի մշակմանը, մեկ մուտքի կետով և այլն: Աջակցությունը դարձավ անհամեմատ ավելի ճկուն՝ շնորհիվ մշակողների հետ անմիջական մուտքի՝ համակարգի գործունեության ցանկացած ասպեկտի արագ ճշգրտումների, API-ի միջոցով ինտեգրման և այլնի համար:
Updates
Առաջարկվող CP-ի համաձայն, նոր BMS-ի բոլոր թարմացումները ներառված են աջակցության արժեքի մեջ, այսինքն՝ չեն պահանջում լրացուցիչ վճարում: Բացառություն է կազմում լրացուցիչ ֆունկցիոնալության մշակումը, որը գերազանցում է տեխնիկական առաջադրանքում նշվածը:
Հին համակարգը պահանջում էր վճար ինչպես ներկառուցված անվճար ծրագրաշարի (օրինակ՝ Java-ի) թարմացման, այնպես էլ սխալների շտկման համար: Անհնար էր հրաժարվել դրանից, և առանց թարմացումների համակարգը որպես ամբողջություն «կդանդաղեր» ներքին բաղադրիչների հին տարբերակների պատճառով:
Եվ, իհարկե, անհնար էր թարմացնել ծրագիրը առանց աջակցության փաթեթ գնելու։
ճկուն մոտեցում
Մեկ այլ հիմնարար պահանջ վերաբերում էր ինտերֆեյսին։ Մենք ցանկանում էինք դրան հասանելիություն ապահովել վեբ զննարկչի միջոցով՝ ցանկացած վայրից, առանց տվյալների կենտրոնի տարածքում ինժեների պարտադիր ներկայության։ Բացի այդ, մենք ձգտում էինք ստեղծել անիմացիոն ինտերֆեյս, որպեսզի ենթակառուցվածքի գործունեության դինամիկան ավելի տեսանելի լինի հերթապահ ինժեներների համար։
Նոր համակարգը պետք է նաև աջակցեր ինժեներական համակարգերում վիրտուալ սենսորների աշխատանքը հաշվարկելու բանաձևերին, օրինակ՝ սարքավորումների դարակների միջև էլեկտրական հզորության օպտիմալ բաշխման համար: Դրա համար անհրաժեշտ է ձեր տրամադրության տակ ունենալ սենսորների ցուցմունքների համար կիրառելի բոլոր սովորական մաթեմատիկական գործողությունները:
Հաջորդը, անհրաժեշտ էր SQL տվյալների բազա մուտք գործել՝ դրանից սարքավորումների աշխատանքի վերաբերյալ անհրաժեշտ տվյալները վերցնելու հնարավորությամբ, մասնավորապես՝ երկու հազար սարքերի և մոտ 20 հազար փոփոխական գեներացնող երկու հազար վիրտուալ սենսորների մոնիթորինգի բոլոր գրառումները։
Մեզ նաև անհրաժեշտ էր դարակաշարին ամրացված սարքավորումների հաշվառման մոդուլ, որը կապահովեր յուրաքանչյուր միավորում սարքերի տեղադրության գրաֆիկական ներկայացումը, կհաշվարկեր սարքավորումների ընդհանուր քաշը, կպահպաներ սարքերի գրադարան և կտրամադրեր մանրամասն տեղեկատվություն յուրաքանչյուր տարրի մասին։
Տեխնիկական պայմանների համաձայնեցում և պայմանագրի ստորագրում
Այն ժամանակ, երբ անհրաժեշտ էր սկսել աշխատանքները նոր համակարգի վրա, «խոշոր» ընկերությունների հետ նամակագրությունը դեռևս շատ հեռու էր նրանց առաջարկների արժեքի քննարկումից, ուստի մենք ստացված CP-ն համեմատեցինք հին BMS-ի թարմացման արժեքի հետ (տե՛ս ), և արդյունքում այն ավելի գրավիչ դարձավ գնով և համապատասխանում էր մեր պահանջներին։
Ընտրությունը կատարվեց։
Կապալառու ընտրելուց հետո իրավաբանները սկսեցին կազմել պայմանագիր, իսկ երկու կողմերի տեխնիկական թիմերը սկսեցին կատարելագործել տեխնիկական առաջադրանքը: Ինչպես հայտնի է, մանրամասն և գրագետ տեխնիկական առաջադրանքը ցանկացած աշխատանքի հաջողության հիմքն է: Որքան շատ մանրամասներ լինեն տեխնիկական առաջադրանքում, այնքան քիչ կլինեն հիասթափությունները, ինչպիսիք են՝ «բայց մենք այդպես չէինք ուզում»:
Ես կբերեմ տեխնիկական բնութագրերում պահանջների մանրամասնության մակարդակի երկու օրինակ.
- Տվյալների կենտրոնի հերթապահները լիազորված են BMS-ին նոր սարքեր ավելացնել, ամենից հաճախ դրանք PDU-ներ են: Հին BMS-ում սա «ադմինիստրատորի» մակարդակն էր, որը թույլ էր տալիս, ի թիվս այլ բաների, փոխել բոլոր սարքերի փոփոխական կարգավորումները, և անհնար էր առանձնացնել գործառույթները: Սա մեզ չէր համապատասխանում: Նոր հարթակի առկա հիմնական տարբերակում սխեման նման էր: Մենք անմիջապես տեխնիկական բնութագրերում նշեցինք, որ ցանկանում ենք առանձնացնել այս դերերը. միայն լիազորված աշխատակիցը պետք է փոխի կարգավորումները, բայց հերթապահները պետք է շարունակեն ունենալ սարքեր ավելացնելու հնարավորություն: Այս սխեման ընդունվեց ներդրման համար:
- Ցանկացած ստանդարտ BMS-ում կան ծանուցումների երեք տիպիկ կատեգորիաներ՝ ԿԱՐՄԻՐ՝ անհրաժեշտ է անհապաղ արձագանք, ԴԵՂԻՆ՝ կարելի է դիտարկել, ԿԱՊՈՒՅՏ՝ «Տեղեկատվություն»։ Մենք ավանդաբար օգտագործում էինք «կապույտ» ծանուցումները՝ առևտրային պարամետրերի գերազանցումները վերահսկելու համար, օրինակ՝ հաճախորդի դարակի հզորության սահմանաչափի գերազանցումը։ Մեր դեպքում այս տեսակի ծանուցումը նախատեսված էր ղեկավարների համար և չէր հետաքրքրում գործառնական բաժնին, բայց հին BMS-ում այն պարբերաբար լցնում էր ակտիվ միջադեպերի ցանկը և խանգարում գործառնական աշխատանքներին։ Մենք ծանուցումների տաբատների տրամաբանությունն ու գունային տարբերակումը համարեցինք հաջողված և պահպանեցինք դրանք, բայց տեխնիկական բնութագրերում մենք հատուկ նշեցինք, որ «կապույտ» ծանուցումները, առանց հերթապահներին շեղելու, պետք է լուռ «թափվեն» առանձին բաժին, որտեղ առևտրային մասնագետները կզբաղվեն դրանցով։
Գրաֆիկների կառուցման և հաշվետվությունների ստեղծման ձևաչափերը, ինտերֆեյսների ուրվագծերը, մոնիթորինգի ենթակա սարքերի ցանկը և շատ այլ բաներ նկարագրվել են նմանատիպ մանրամասնությամբ։
Սա իսկապես ստեղծագործական աշխատանք էր երեք աշխատանքային խմբերի՝ հաճախորդների սպասարկման, որը թելադրում էր իր պահանջներն ու պայմանները, երկու կողմերի տեխնիկական մասնագետների, որոնց խնդիրն էր այդ պայմանները վերածել տեխնիկական փաստաթղթերի, կապալառու ծրագրավորողների թիմի, որը մշակված տեխնիկական փաստաթղթերի համաձայն իրականացրեց հաճախորդի պահանջները... Արդյունքում, մենք մեր որոշ ոչ հիմնարար պահանջներ հարմարեցրինք առկա հարթակի ֆունկցիոնալությանը, և կապալառուն պարտավորվեց մեզ համար ինչ-որ բան ավելացնել։
Երկու համակարգերի զուգահեռ աշխատանք
Ժամանակն էր իրականացնելու։ Գործնականում սա նշանակում էր, որ մենք կապալառուին հնարավորություն տվեցինք մեր վիրտուալ ամպում տեղակայել BMS նախատիպը և ցանցային հասանելիություն ապահովել մոնիթորինգի կարիք ունեցող բոլոր սարքերին։
Միևնույն ժամանակ, նոր համակարգը դեռևս պատրաստ չէր աշխատանքի: Այս փուլում մեզ համար կարևոր էր պահպանել հին համակարգում մոնիթորինգը և միևնույն ժամանակ նոր համակարգին հասանելիություն տրամադրել սարքերին: Համակարգը նորմալ կառուցել հնարավոր չէ՝ առանց դրա մեջ սարքերը տեսնելու, որոնք, իրենց հերթին, չեն կարող անջատվել հին համակարգի կողմից մոնիթորինգից:
Արդյո՞ք սարքերը կդիմանային երկու համակարգերի կողմից միաժամանակյա հարցումներին, պարզ չէր իրական փորձարկումների առանց։ Հնարավոր էր, որ կրկնակի միաժամանակյա հարցումը կհանգեցներ սարքերի պատասխանների հաճախակի մերժումների, և մենք կստանայինք սարքերի անհասանելիության վերաբերյալ բազմաթիվ սխալներ, ինչն էլ իր հերթին կխոչընդոտեր հին մոնիթորինգի համակարգի աշխատանքը։
Ցանցային բաժինը վիրտուալ երթուղիներ անցկացրեց ամպում տեղակայված նոր BMS նախատիպից դեպի սարքեր, և մենք ստացանք հետևյալ արդյունքները.
- SNMP արձանագրությամբ միացված սարքերը գրեթե երբեք չեն անջատվել միաժամանակյա հարցումների պատճառով,
- Modbas-TCP արձանագրություններ օգտագործող դարպասների միջոցով միացված սարքերն ունեին խնդիրներ, որոնք լուծվեցին՝ դրանց հարցումների հաճախականությունը խելամտորեն նվազեցնելով։
Եվ այդ ժամանակ մենք սկսեցինք դիտարկել, թե ինչպես էր մեր աչքերի առաջ կառուցվում մի նոր համակարգ, որի մեջ հայտնվում էին մեզ արդեն ծանոթ սարքեր, բայց այլ ինտերֆեյսով՝ հարմար, արագ, հասանելի նույնիսկ հեռախոսից։
Վերջնական արդյունքի մասին կպատմենք մեր հոդվածի երրորդ մասում։
Source: www.habr.com
