В първата част ви разказахме защо решихме да сменим старата 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 (вж. ), и в резултат тя се оказа по-привлекателна по цена и отговаряща на нашите изисквания.
Изборът беше направен.
След избора на изпълнител, юристите започнаха да съставят договора, а техническите екипи от двете страни да дообработват ТЗ. Както е известно, подробно и грамотно ТЗ е основата на успеха на всяка работа. Колкото повече конкретика има в ТЗ, толкова по-малко разочарования от типа „а ние не искахме така“.
Ще дам два примера за нивото на детайлност на изискванията в ТЗ:
- Дежурните ЦОД имат правомощия да добавят нови устройства в BMS, най-често това са PDU. В старата BMS това беше нивото "администратор", позволяващо освен всичко друго да сменя зададените променливи на всички устройства, и функциите не можеха да бъдат разделени. Това не ни удовлетворяваше. В наличната базова версия на новата платформа схемата беше аналогична. Ние веднага указахме в ТЗ, че искаме да разделим тези роли: зададените променливи да сменя само упълномощен служител, но дежурните да имат възможност да добавят устройства. Тази схема и беше приета за реализация.
- По всяка стандартна BMS има три основни категории уведомления: ЧЕРВЕНО – незабавно реагиране, ЖЪЛТО – наблюдение, СИНЬО – „Информационно“. Традиционно използвахме „сини“ уведомления за мониторинг на превишения на търговските параметри, например, превишаване на лимита на мощността на стелажа на клиента. Този тип уведомления в нашия случай беше предназначен за мениджърите и не беше интересен за експлоатационната служба, но в старата BMS редовно запълваше списъка с активни инциденти и пречеше на оперативната работа. Самата логика и цветова диференциация на уведомленията запазихме, но в ТЗ специално указахме, че „сини“ уведомления трябва безшумно да се „пръскат“ в отделен раздел, където да се ангажират търговските специалисти.
С аналогична степен на детайлност бяха записани форматите за генериране на графики и извеждане на отчети, контурите на интерфейсите, списъкът с устройства, които трябва да се наблюдават, и още много други неща.
Това беше наистина творческа работа на три работни групи – обслужващата страна, която задаваше своите изисквания и условия; техническите специалисти от двете страни, чиято задача беше да преобразуват тези условия в техническа документация; екипът от програмисти на изпълнителя, които реализираха изискванията на клиента според разработената техническа документация… В крайна сметка адаптирахме част от нашите неприоритетни изисквания към функционалността на вече съществуващата платформа, а нещо изпълнителят се ангажира да допише за нас.
Паралелна работа на две системи.
Настъпи време за реализация. На практика това означава, че даваме на изпълнителя възможност да разгърне прототип на BMS в нашето виртуално облако и предоставяме мрежов достъп до всички устройства, които се нуждаят от мониторинг.
При това новата система все още не беше готова за работа. На този етап за нас беше важно да запазим мониторинга в старата система и едновременно да предоставим достъп на устройствата на новата система. Невъзможно е да се изгради нормално функционираща система, без да се виждат устройствата в нея, които от своя страна не могат да бъдат изключени от мониторинга на старата система.
Беше неопределено дали устройствата ще издържат на едновременен опит от две системи без реални тестове. Имаше вероятност двойният едновременен опит да доведе до чести откази в отговорите от устройствата и да получим множество грешки по недостъпност на устройствата, което от своя страна ще блокира работата на старата система за мониторинг.
Мрежовият отдел прокара виртуални маршрути от прототипа на новата BMS, внедрена в облака, до устройствата и получихме резултатите:
- устройства, свързани чрез протокола SNMP, практически не изпадаха в дисконект поради едновременни заявки,
- устройства, свързани чрез шлюзове по протоколите modbas-TCP, имаха проблеми, които бяха разрешени чрез разумно намаляване на честотата на техния опит.
А след това започнахме да наблюдаваме как пред очите ни се изгражда нова система, в която се появяват вече познатите ни устройства, но с друг интерфейс – удобен, бърз, достъпен дори от телефона.
За това, което получихме в крайна сметка, ще разкажем в третата част на нашата статия.
Източник: habr.com
