В първата част ви разказахме защо решихме да сменим старата BMS система в нашите ЦОД с нова. И не просто да сменим, а да я разработим от нулата, съобразно нашите изисквания. Във втората част ще ви разкажем как го направихме.
Анализ на пазара
С оглед на описаните в желания и решението да се откажем от обновяването на съществуващата система, написахме ТЗ за търсене на решение на пазара и направихме запитвания до няколко големи компании, които се занимават единствено с изграждане на промишлени SCADA системи.
Първите отговори от тях показаха, че лидерите на пазара на системи за мониторинг основно продължават да работят на физически сървъри, въпреки че процесът на миграция към облака в този сегмент вече е започнал. Що се отнася до резервирането на виртуални машини – никой не подкрепяше тази опция. Освен това, се създаваше впечатление, че никой от забележимите разработчици на пазара не демонстрираше дори разбиране за необходимостта от резервиране: „облакът не пада” беше най-честият отговор. Всъщност ни предлагаха да разположим мониторинга на ЦОДа в облака, физически находящ се в същия ЦОД.
Тук трябва да направим малко отклонение относно процеса на избор на изпълнител. Разбира се, цената има значение, но по време на всяка търгова процедура за реализиране на сложен проект, на етапа на диалог с доставчиците, започваш да чувстваш, кой от кандидатите е по-заинтересован и способен да го реализира.
Това е особено забележимо при сложни проекти.
По характера на уточняващите въпроси към ТЗ можем да разделим изпълнителите на заинтересовани просто да продадат (усеща се стандартния натиск на търговския представител) и на заинтересовани в това да разработят продукта, чуят и разберат клиента, да внесат конструктивни корекции в ТЗ още преди финалния избор (дори въпреки реалния риск да подобрят чуждо ТЗ и да загубят търга), в крайна сметка просто готови да приемат професионалната предизвикателство и да направят добър продукт.
Всичко това ни накара да обърнем внимание на сравнително малък местен разработчик – групата компании „Санлайн“, която мигновено реагира на повечето наши изисквания и беше готова да реализира всичките нужди относно новата BMS.
Рискове
Докато големите играчи се опитваха да разберат какво искаме и водеха бавна кореспонденция с привлечени специалисти от ниво пресейл, местният разработчик организира среща в нашия офис с участието на техническия си екип. По време на тази среща изпълнителят отново показа желание да участва в проекта и – най-важното – обясни как ще бъде реализирана изискваната система.
Преди срещата видяхме два риска, свързани с работата на екипа, който няма зад себе си ресурси на голяма национална или международна компания:
- Специалистите могат да надценят възможностите си и в резултат просто да не се справят, например, да използват сложен софтуер или да проектират неизпълними алгоритми за резервиране.
- След реализацията на проекта екипът може да се разпадне и следователно поддръжката на продукта да бъде застрашена.
За да минимизираме тези рискове, поканихме на срещата наши специалисти по разработка. Служителите на потенциалния изпълнител бяха внимателно разпитани относно основата на системата, как се планира извършването на резервиране и по други въпроси, в които ние, като експлоатационна служба, не сме достатъчно компетентни.
Вердиктът беше положителен: архитектурата на вече съществуващата платформа BMS е модерна, проста и надеждна, може да бъде подобрена, предложената схема за резервиране и синхронизация е логична и работеща.
С първия риск се справихме. Вторият беше изключен, получавайки от изпълнителя потвърждение за готовността да ни предаде изходния код на системата и документацията, както и избирайки езика за програмиране Python, добре познат на нашите специалисти. Това ни гарантира възможността да поддържаме системата сами без никакви затруднения и дълги периоди на обучение на служителите в случай на напускане на компанията-разработчик от пазара.
Допълнителен плюс на платформата беше, че тя беше реализирана в Docker контейнери: в тази среда функционират ядрото, уеб интерфейсът и базата данни на продукта. Такъв подход предоставя множество предимства, включително предварителна настройка за висока скорост на внедряване в сравнение с "класическите" решения и лесно добавяне на нови устройства в системата. Принципът "всичко заедно" максимално опростява внедряването на системата: достатъчно е да се разархивира системата и тя може веднага да бъде експлоатирана.
С такова решение е по-лесно да се правят копия на системата, а усъвършенстването и реализирането на обновления може да става в отделна среда, без да се спира работата на решението като цяло.
След като и двата риска бяха минимизирани, изпълнителят предостави оферта. В нея бяха разработени всички най-важни параметри на системата BMS за нас.
Резервиране
Новата BMS система трябваше да бъде в облака, на виртуална машина.
Никакви хардуерни устройства, никакви сървъри и всички свързани с тази модел на внедряване неудобства и рискове – облачното решение ни позволяваше да се отървем от тях завинаги. Решено беше, че системата ще работи в нашия облак на две площадки за данни в Санкт Петербург и Москва. Това са две напълно функционални системи, работещи в режим активна резервираност с достъп за всички упълномощени специалисти.
Двете системи подсигуряват една друга, осигурявайки пълно резервиране както на изчислителните способности, така и на каналите за предаване на данни. Освен това са настроени допълнителни мерки за сигурност, включително резервно копиране на данни и канали, системи, виртуални машини като цяло и отделно резервно копие на базата данни веднъж месечно (най-ценният ресурс в перспектива на управление и анализ).
Важно е да се отбележи, че резервирането като опция за BMS решението беше разработено специално по наш запрос. Схемата за резервиране изглеждаше така:
Поддръжка
Най-важният момент за ефективна експлоатация на BMS решението е техническата поддръжка.
Тук всичко е просто: новата система щеше да ни струва по този показател 35 000 рубли на месец за SLA "реакция в рамките на 8 часа", т.е. 35 000 х 12 / 80 = $5 250 годишно. Първата година – безплатно.
За сравнение: поддръжката на старата BMS от доставчика възлизаше на $18 000 долара годишно, като сумата нарастваше с всяко ново добавено устройство! Въпреки това, компанията не предоставяше посветен мениджър, а цялото взаимодействие ставаше чрез търговския мениджър, който беше заинтересован в нас като потенциален клиент с подходящ акцент в обработката на заявките.
За по-малко пари получихме пълноценна поддръжка на продукта, с акаунт-мениджър, който щеше да участва в разработката на продукта, с единна точка на контакт и т.н. Поддръжката стана значително по-гъвкава – благодарение на пряк достъп до разработчиците за бързи корекции по всички аспекти на работата на системата, интеграция чрез API и т.н.
Актуализации
Според предложената оферта за новата BMS всички актуализации са включени в цената на поддръжката, т.е. не изискват допълнително заплащане. Изключение прави разработването на допълнителна функционалност, над посоченото в ТЗ.
Системата преди предвиждаше плащане както за актуализация на вграденото безплатно ПО (като Java), така и за поправка на грешки. Нямаше как да се откажем от това, при липса на актуализации системата по същество "забавяше" поради стари версии на вътрешните компоненти.
И, разбира се, не беше възможно да се актуализира ПО без закупуване на пакет за поддръжка.
Гъвкав подход
Друго принципно изискване касаеше интерфейса. Искахме да осигурим достъп до него през уеб браузър от всяка точка, без задължително присъствие на инженер на територията на ЦОДа. Освен това, се стремяхме към създаване на анимиран интерфейс, така че динамиката на функционирането на инфраструктурата да бъде по-нагледна за дежурните инженери.
Също така в новата система трябваше да се осигури поддръжка на формули за изчисляване на работата на виртуални датчици в инженерните системи – например, за оптимално разпределение на електрическите мощности по рафтовете с оборудване. За това е необходимо да се разполагат с всички познати математически операции, приложими към показанията на датчиците.
Следваше да бъде предоставен достъп до SQL база данни с възможност за извличане на нужната информация за работата на оборудването – а именно, всички записи за мониторинга на две хиляди устройства и две хиляди виртуални сензора, генериращи около 20 хиляди променливи.
Необходим бе също модул за отчет на оборудването в рафта, предоставящ графично представяне на разположението на устройствата във всеки юнит със сумарно тегло на оборудването, поддържане на библиотека с устройства и подробна информация за всеки елемент.
Съгласуване на техническото задание и подписване на договора
В момента, когато бе необходимо да започнем работа по новата система, кореспонденцията с "големите" компании все още бе далеч от обсъждането на цените на техните предложения, затова сравнението на полученото КП с разходите за обновление на старата БМС показа, че то е по-привлекателно по цена и отговаря на нашите изисквания. ), и в резултат се оказа по-атрактивно по цена и съответстващо на нашите нужди.
Изборът бе направен.
След избора на изпълнителя, юристите започнаха да съставят договора, а техническите екипи от двете страни да доизработват техническото задание. Както е известно, подробно и грамотно техническо задание е основата на успеха на всяка работа. Колкото по-конкретно е техническото задание, толкова по-малко разочарования по отношение на "а ние искахме не така".
Ще дам два примера за нивото на детайлност на изискванията в техническото задание:
- Дежурните ЦОД имат правомощия да добавят нови устройства в BMS, най-често PDU. В старата BMS това беше ниво "администратор", което позволяваше включително да се променят стойностите на променливите на всички устройства, и разделянето на функциите не беше възможно. Това не ни удовлетворяваше. В наличната основна версия на новата платформа схемата беше аналогична. Ние незабавно посочихме в техническото задание, че желаем да разделим тези роли: стойностите трябва да бъдат променяни само от упълномощен служител, но дежурните трябва да имат възможността да добавят устройства. Тази схема беше приета за реализация.
- Във всяка стандартна BMS има три основни категории известия: ЧЕРВЕНА – необходимо е незабавно да се реагира, ЖЪЛТА – може да се наблюдава, СИНЯ – 'Информационна'. Традиционно използвахме 'сини' известия за мониторинг на превишения на търговските параметри, например, превишение на лимита за захранване на шкафа на клиента. Този тип известия в нашия случай беше предназначен за мениджърите и не беше интересен за експлоатационната служба, но в старата BMS редовно затрупваше списъка с активни инциденти и пречеше на оперативната работа. Самата логика и цветова диференциация на известията бяха считани за успешни и бяха запазени, но в ТЗ специално беше указано, че 'сини' известия трябва, без да отвлекат дежурните, тихо 'да се струпват' в отделна секция, където с тях ще се занимават търговски специалисти.
С аналогична степен на подробност бяха прописани формати за изграждане на графици и извеждане на отчети, очертания на интерфейси, списък с устройства, които трябва да бъдат наблюдавани, и още много други неща.
Това беше наистина творческа работа на три работни групи – службата по поръчките, която диктуваше своите изисквания и условия; техническите специалисти от двете страни, чиято задача беше да преобразуват тези условия в техническа документация; екипът от програмисти на изпълнителя, който реализираше изискванията на клиента според разработената техническа документация… В крайна сметка, част от нашите второстепенни изисквания адаптирахме към функционалността на вече съществуващата платформа, а другото изпълнителят се задължи да допише за нас.
Паралелна работа на двете системи
Дойде време за реализация. На практика това означаваше, че даваме на изпълнителя възможност да разположи прототипа на BMS в нашето виртуално облако и предоставяме мрежов достъп до всички устройства, които изискват мониторинг.
В същото време новата система все още не беше готова за работа. На този етап за нас беше важно да запазим мониторинга в старата система и в същото време да дадем достъп на устройствата до новата система. Невъзможно е нормално да се изгражда система, без да се виждат устройствата в нея, които от своя страна не могат да бъдат изключени от мониторинга на старата система.
Беше неочевидно дали устройствата ще издържат на едновременния опит от две системи без реални тестове. Имаше вероятност двойният едновременен опит да доведе до чести откази в отговорите от устройствата, което би поръчало множество грешки поради недостъпност на устройствата, блокирайки работата на старата система за мониторинг.
Мрежовият отдел прокара виртуални маршрути от прототипа на новата BMS, разположен в облака, към устройствата, и получихме резултати:
- устройствата, свързани по SNMP протокол, почти не отпадаха в дисконект при едновременни запитвания,
- устройствата, свързани чрез шлюзове по modbas-TCP протоколи, имаха проблеми, които бяха решени с разумно намаляване на честотата на тяхното запитване.
След това започнахме да наблюдаваме как пред очите ни се изгражда нова система, в която вече познатите ни устройства се появяват с друг интерфейс – удобен, бърз и достъпен дори и от телефона.
За това, какво се получи в крайна сметка, ще разкажем в третата част на нашата статия.
Източник: habr.com
