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