У першай частцы мы распавялі аб тым, чаму вырашылі памяняць старую BMS-сістэму ў нашых ЦАДах на новую. І не проста памяняць, а распрацаваць з нуля пад свае патрабаванні. У другой частцы расказваем, як мы гэта рабілі.
Аналіз рынку
З улікам апісаных у пажаданняў і рашэнні адмовіцца ад абнаўлення існуючай сістэмы мы напісалі ТЗ для пошуку рашэння на рынку і зрабілі запыты ў некалькі буйных кампаній, якія займаюцца толькі стварэннем прамысловых сістэм SCADA.
Першыя ж адказы ад іх паказалі, што лідэры рынку сістэм маніторынгу пераважна працягваюць працаваць на жалезных серверах, хаця працэс міграцыі ў аблокі ў гэтым сегменце ўжо пачаўся. Што тычыцца рэзервавання віртуальных машын - гэтую опцыю не падтрымліваў ніхто. Больш за тое, складалася адчуванне, што ніхто з прыкметных на рынку распрацоўшчыкаў не прадэманстраваў нават разумення неабходнасці рэзервавання: "воблака ж не падае" быў найбольш часты адказ. Фактычна нам прапаноўвалі размясціць маніторынг ЦАД у воблаку, які фізічна знаходзіцца ў гэтым жа ЦАД.
Тут трэба зрабіць невялікі адступ аб працэсе выбару падрадчыка. Кошт, вядома, мае значэнне, але падчас любога тэндэру на рэалізацыю складанага праекту, на стадыі дыялогу з пастаўшчыкамі ты пачынаеш адчуваць, хто з кандыдатаў больш зацікаўлены і здольны рэалізаваць яго.
Гэта асабліва заўважна на складаных праектах.
Па характары ўдакладняючых пытанняў да ТЗ можна падзяліць падрадчыкаў на зацікаўленых проста прадаць (адчуваецца стандартны напор мэнэджара па продажах) і на зацікаўленых у тым, каб распрацаваць прадукт, пачуўшы і зразумеўшы замоўца, унесці канструктыўныя праўкі ў ТЗ яшчэ да фінальнага выбару (нават нягледзячы на рэальны рызыка палепшыць чужое ТЗ і прайграць тэндэр), у рэшце рэшт проста гатовых прыняць прафесійны выклік і зрабіць добры прадукт.
Усё гэта прымусіла нас звярнуць увагу на адносна невялікага лакальнага распрацоўніка - групу кампаній "Санлайн", які адгукнуўся на большасць нашых патрабаванняў адразу і быў гатовы рэалізаваць усе патрэбы датычна новай BMS.
Рызыкі
Пакуль вялікія гульцы спрабавалі зразумець, што ж мы жадаем, і загадай з намі павольную перапіску з прыцягненнем адмыслоўцаў узроўня пресейл, лакальны дэвелапер прызначыў сустрэчу ў нашым офісе з удзелам сваёй тэхнічнай каманды. На гэтай сустрэчы падрадчык яшчэ раз прадэманстраваў жаданне ўдзельнічаць у праекце і - галоўнае - растлумачыў, як патрабаваная сістэма будзе рэалізавана.
Перад сустрэчай мы бачылі дзве рызыкі працы з камандай, якая не мае за спіной рэсурсу вялікай нацыянальнай ці міжнароднай кампаніі:
- Спецыялісты маглі пераацаніць свае магчымасці і ў выніку проста не справіцца, напрыклад, будуць выкарыстоўваць складаны софт або спраектуюць невыканальныя алгарытмы рэзервавання.
- Пасля рэалізацыі праекта каманда праекта можа распасціся і, такім чынам, падтрымка прадукта апынецца пад пагрозай.
Каб мінімізаваць гэтыя рызыкі, мы запрасілі на сустрэчу ўласных спецыялістаў па распрацоўцы. Супрацоўнікі патэнцыйнага падрадчыка былі старанна апытаны на прадмет таго, на чым будуецца сістэма, як плануецца рэалізоўваць рэзерваванне і па іншых пытаннях, у якіх мы, як служба эксплуатацыі, недастаткова кампетэнтныя.
Вердыкт быў станоўчым: архітэктура наяўнай ужо платформы BMS сучасная, простая і надзейная, можа быць дапрацавана, прапанаваная схема рэзервавання і сінхранізацыі лагічная і працаздольная.
З першай рызыкай справіліся. Другі выключылі, атрымаўшы ад падрадчыка пацверджанне аб гатоўнасці перадаць нам зыходнікі кода сістэмы і дакументацыі, а таксама выбраўшы мову праграмавання Python, добра знаёмую нашым спецыялістам. Гэта гарантавала нам магчымасць падтрымліваць сістэму саматугам без якіх-небудзь цяжкасцяў і працяглага перыяду навучання супрацоўнікаў у выпадку сыходу кампаніі-распрацоўніка з рынка.
Дадатковым плюсам платформы з'яўлялася тое, што яна была рэалізаваная ў Docker кантэйнерах: у гэтым асяроддзі функцыянуюць ядро, вэб-інтэрфейс і БД прадукта. Такі падыход дае мноства пераваг, у тым ліку перадусталёўку налад для высокай хуткасці разгортвання рашэння ў параўнанні з «класікай» і простае даданне ў сістэму новых прылад. Прынцып «усе разам» максімальна спрашчае ўкараненне сістэмы: дастаткова распакаваць сістэму і можна адразу яе эксплуатаваць.
З такім рашэннем прасцей рабіць копіі сістэмы, а ўдасканаліць яе і рэалізоўваць апгрэйды можна ў асобным асяроддзі, без спынення працы рашэння ў цэлым.
Пасля таго як абедзве рызыкі былі мінімізаваны, падрадчык падаў КП. У ім былі прапрацаваны ўсе найважнейшыя для нас параметры сістэмы BMS.
Рэзерваванне
Новая BMS-сістэма павінна была знаходзіцца ў воблаку, на віртуальнай машыне.
Ніякага жалеза, ніякіх сервераў і ўсіх звязаных з гэтай мадэллю разгортвання нязручнасцяў і рызык - хмарнае рашэнне дазваляла нам пазбавіцца ад іх назаўжды. Было вырашана, што сістэма будзе працаваць у нашым воблаку на двух пляцоўках ЦАД у Санкт-Пецярбургу і Маскве. Гэта дзве цалкам функцыянальныя сістэмы, якія працуюць у рэжыме active standby з доступам для ўсіх аўтарызаваных адмыслоўцаў.
Дзве сістэмы страхуюць адна адну, забяспечваючы поўны рэзерв і па вылічальных магутнасцях, і па каналах перадачы даных. Таксама настроены дадатковыя меры бяспекі, у тым ліку рэзервовае капіраванне дадзеных і каналаў, сістэм, віртуальных машын у цэлым, і асобнае рэзервовае капіраванне БД раз у месяц (самы каштоўны рэсурс у перспектыве кіравання і аналізу).
Адзначым, што рэзерваванне як опцыя BMS-рашэнні было распрацавана спецыяльна пад наш запыт. Сама схема рэзервавання выглядала вось так:
Падтрымка
Найважнейшы момант для эфектыўнай эксплуатацыі BMS-рашэнні - тэхпадтрымка.
Тут усё проста: новая сістэма каштавала б нам па гэтым паказчыку 35 руб. у месяц за SLA «рэакцыя на працягу 000 гадзін», гэта значыць 8 х 35 / 000 = $ 12 у год. Першы год - бясплатна.
Для параўнання: падтрымка старой BMS ад вендара абыходзілася ў $18 000 даляраў у год з павелічэннем сумы за кожную новую дабаўленую прыладу! Пры гэтым выдзеленага мэнэджэра кампанія не давала, усё ўзаемадзеянне адбывалася праз мэнэджара па продажах, які зацікаўлены ў нас як у патэнцыйным пакупніку з адпаведным акцэнтам у апрацоўцы запытаў.
За меншыя грошы мы атрымалі паўнавартасную падтрымку прадукта, з акаўнт-мэнэджарам, які браў удзел у распрацоўцы прадукта, з адзінай кропкай уваходу і г.д. Падтрымка станавілася на парадак больш гнуткай - дзякуючы прамога доступу да распрацоўшчыкаў для аператыўных карэкціровак па любых аспектах працы сістэмы, інтэграцыі праз API і г.д.
Абнаўленні
Па прапанаваным КП у новай BMS усе абнаўленні ўключаны ў кошт падтрымкі, г.зн. не патрабуюць дадатковай аплаты. Выключэнне складае распрацоўка дадатковай функцыянальнасці, звыш той, што пазначана ў ТЗ.
Старая сістэма меркавала аплату як за абнаўленне ўбудаванага бясплатнага ПЗ (тыпу Java), так і за выпраўленне памылак. Адмовіцца ад гэтага было нельга, пры адсутнасці абнаўленняў сістэма ў цэлым "тармазіла" з-за старых версій унутраных кампанентаў.
І, само сабой, нельга было абнавіць ПА без пакупкі пакета падтрымкі.
Гнуткі падыход
Яшчэ адно прынцыповае патрабаванне датычылася інтэрфейсу. Мы хацелі забяспечыць доступ да яго праз вэб-браўзэр з любой кропкі, без абавязковай прысутнасці інжынера на тэрыторыі ЦАД. Акрамя таго, мы імкнуліся да стварэння аніміраванага інтэрфейсу, каб дынаміка функцыянавання інфраструктуры была больш навочнай для дзяжурных інжынераў.
Таксама ў новай сістэме трэба было забяспечыць падтрымку формул для абліку працы віртуальных датчыкаў у інжынерных сістэмах - напрыклад, для аптымальнага размеркавання электрычных магутнасцяў па стойках з абсталяваннем. Для гэтага трэба мець у сваім распараджэнні ўсе звыклыя матэматычныя аперацыі, дастасавальныя да паказчыкаў датчыкаў.
Далей, патрабаваўся доступ да базы дадзеных SQL з магчымасцю браць з яе патрэбныя дадзеныя аб працы абсталявання – а менавіта, усе запісы аб маніторынгу дзвюх тысяч прылад і дзвюх тысяч віртуальных датчыкаў, якія генеруюць прыкладна 20 тысяч зменных.
Патрэбен быў таксама модуль уліку абсталявання ў стойцы, які дае графічнае ўяўленне размяшчэння прылад у кожным юните з падлікам агульнай вагі "жалеза", вядзеннем бібліятэкі прылад і падрабязнай інфармацыяй аб кожным элеменце.
Узгадненне ТЗ і падпісанне дамовы
На той момант, калі было неабходна пачынаць працу над новай сістэмай, перапіска з "вялікімі" кампаніямі ўсё яшчэ была вельмі далёкая ад абмеркавання кошту іх прапаноў, таму мы параўналі атрыманае КП з выдаткамі на абнаўленне старой БМС (гл. ), і ў выніку яно аказалася больш прывабным па кошце і адпаведным нашым патрабаванням.
Выбар быў зроблены.
Пасля выбару падрадчыка юрысты сталі складаць дамову, а тэхнічныя каманды абапал шліфаваць ТЗ. Як вядома, падрабязнае і пісьменнае ТЗ - гэта аснова поспеху любых работ. Чым больш канкрэтыкі ў ТЗ, тым менш расчараванняў кшталту "а мы хацелі не так".
Прывяду два прыклады ўзроўню дэталізацыі патрабаванняў у ТЗ:
- Дзяжурныя ЦАД нададзены паўнамоцтвамі дадаваць у BMS новыя прылады, часцей за ўсё гэта PDU. У старой BMS гэта быў узровень "адміністратара", які дазваляе ў тым ліку змяняць уставки зменных усіх прылад, і падзяліць функцыі было немагчыма. Нас гэта не задавальняла. У наяўнай базавай версіі новай платформы схема была аналагічнай. Мы адразу ўказалі ў ТЗ, што хочам падзяліць гэтыя ролі: устаўкі павінен мяняць толькі ўпаўнаважаны супрацоўнік, але дзяжурныя павінны і далей мець магчымасць дадаваць прылады. Гэтая схема і была прынята да рэалізацыі.
- У любой стандартнай BMS ёсць тры тыпавыя катэгорыі апавяшчэнняў: ЧЫРВОНАЯ - трэба неадкладна рэагаваць, Жоўтая - можна назіраць, сіняя - "Інфармацыйная". Мы традыцыйна выкарыстоўвалі "сінія" апавяшчэння для маніторынгу перавышэння камерцыйных параметраў, напрыклад, перавышэнне ліміту магутнасці стойкі кліента. Гэты тып апавяшчэнняў у нашым выпадку быў прызначаны для мэнэджэраў і не быў цікавы службе эксплуатацыі, але ў старой BMS рэгулярна засмечваў спіс актыўных інцыдэнтаў і перашкаджаў аператыўнай працы. Саму логіку і каляровую дыферэнцыяцыю штаноў апавяшчэнняў мы палічылі ўдалай і захавалі, аднак у ТЗ спецыяльна паказалі, што «сінія» апавяшчэнні павінны, не адцягваючы дзяжурных, бязгучна «сыпацца» ў асобны раздзел, дзе імі будуць займацца камерцыйныя спецыялісты.
З аналагічнай ступенню дэталізацыі былі прапісаны фарматы пабудовы графікаў і вывядзення справаздач, абрысы інтэрфейсаў, пералік прылад, якія трэба было маніторыць і яшчэ мноства іншых рэчаў.
Гэта была па-сапраўднаму творчая праца трох працоўных груп - службы заказчыка, якая дыктавала свае патрабаванні і ўмовы; тэхнічных спецыялістаў абапал, у задачу якіх уваходзіла пераўтварэнне гэтых умоў у тэхнічную дакументацыю; каманды праграмістаў падрадчыка, якія рэалізоўвалі патрабаванні заказчыка па распрацаванай тэхнічнай дакументацыі… У выніку нешта з нашых непрынцыповых патрабаванняў мы адаптавалі пад функцыянал ужо наяўнай платформы, нешта падрадчык абавязаўся дапісаць пад нас.
Раўналежная праца двух сістэм
Надышоў час рэалізацыі. На практыцы гэта азначала, што мы даем падрадчыку магчымасць разгарнуць прататып BMS у нашым віртуальным воблаку і даем сеткавы доступ да ўсіх прылад, якія патрабуюць маніторынгу.
Пры гэтым новая сістэма яшчэ не была гатова да працы. На дадзеным этапе для нас было важна захаваць маніторынг у старой сістэме і адначасова даць доступ да прылад новай сістэмы. Немагчыма нармальна пабудаваць сістэму, не бачачы ў ёй прылад, якія ў сваю чаргу нельга адключыць ад маніторынгу старой сістэмай.
Ці вытрымаюць прылады адначасовае апытанне дзвюма сістэмамі, было невідавочна без рэальных выпрабаванняў. Існавала верагоднасць, што падвойнае адначасовае апытанне прывядзе да частых адмоваў у адказах ад прылад і мы атрымаем мноства памылак па недаступнасці прылад, што ў сваю чаргу заблакуе працу старой сістэмы маніторынгу.
Сеткавы аддзел пракінуў віртуальныя маршруты ад прататыпа новай BMS, разгорнутага ў воблаку, да прылад, і мы атрымалі вынікі:
- прылады, падлучаныя па пратаколе SNMP, практычна не выпадалі ў дысканнект з-за адначасовых зваротаў,
- прылады, падлучаныя праз шлюзы па пратаколах modbas-TCP, мелі праблемы, якія былі вырашаны разумным зніжэннем частаты іх апытання.
А далей мы сталі назіраць, як на нашых вачах будуецца новая сістэма, у ёй з'яўляюцца ўжо знаёмыя нам прылады, але ў іншым інтэрфейсе - зручным, хуткім, даступным нават з тэлефона.
Пра тое, што атрымалася ў выніку, мы раскажам у трэцяй частцы нашага артыкула.
Крыніца: habr.com