Məlumat mərkəzində monitorinq: köhnə BMS-ni yenisinə necə dəyişdik. 2-ci hissə

Məlumat mərkəzində monitorinq: köhnə BMS-ni yenisinə necə dəyişdik. 2-ci hissə

Birinci hissədə məlumat mərkəzlərimizdəki köhnə BMS sistemini niyə yenisi ilə əvəz etmək qərarına gəldiyimizdən danışdıq. Və yalnız dəyişməyin, həm də tələblərinizə uyğun olaraq sıfırdan inkişaf edin. İkinci hissədə bunu necə etdiyimizi sizə xəbər veririk.

Bazarının analizi

-də təsvir olunanları nəzərə alaraq birinci hissəsində arzular və mövcud sistemi yeniləməkdən imtina etmək qərarına gəldikdə, biz bazarda bir həll tapmaq üçün texniki spesifikasiya yazdıq və yalnız sənaye SCADA sistemlərinin yaradılması ilə məşğul olan bir neçə böyük şirkətə sorğular etdik. 

Onlardan ilk cavablar göstərdi ki, monitorinq sistemləri bazarının liderləri əsasən hardware serverlərində işləməyə davam edirlər, baxmayaraq ki, bu seqmentdə buludlara keçid prosesi artıq başlayıb. Virtual maşınların rezervasiyasına gəlincə, heç kim bu seçimi dəstəkləmədi. Üstəlik, belə bir hiss var idi ki, bazardakı görkəmli tərtibatçılardan heç biri hətta ixtisarın zəruriliyini başa düşmədi: "bulud düşmür" ən çox yayılmış cavab idi. Əslində, bizə məlumat mərkəzinin monitorinqini fiziki olaraq eyni məlumat mərkəzində yerləşən buludda yerləşdirmək təklif edildi.

Burada podratçının seçilməsi prosesi haqqında kiçik bir ekskursiya etməliyik. Qiymət, əlbəttə ki, vacibdir, lakin mürəkkəb layihənin həyata keçirilməsi üçün hər hansı bir tender zamanı, təchizatçılarla dialoq mərhələsində siz namizədlərdən hansının daha çox maraqlı olduğunu və onu həyata keçirməyə qadir olduğunu hiss etməyə başlayırsınız. 

Bu xüsusilə mürəkkəb layihələrdə nəzərə çarpır. 

Texniki spesifikasiyalara dair sualların aydınlaşdırılmasının xarakterindən asılı olaraq, podratçılar sadəcə satışda maraqlı olanlara (satış menecerinin standart təzyiqi hiss olunur) və məhsul hazırlamaqda maraqlı olanlara, müştərini eşidən və başa düşən, konstruktiv olanlara bölünə bilər. hətta son seçimdən əvvəl texniki spesifikasiyalara düzəlişlər (hətta başqasının texniki xüsusiyyətlərini təkmilləşdirmək və tenderdə məğlub olmaq riskinə baxmayaraq), sonda onlar sadəcə olaraq peşəkar çağırışı qəbul etməyə və yaxşı məhsul hazırlamağa hazırdırlar.

Bütün bunlar bizi nisbətən kiçik yerli tərtibatçıya - tələblərimizin əksəriyyətinə dərhal cavab verən və yeni BMS ilə bağlı bütün ehtiyacları həyata keçirməyə hazır olan Sunline şirkətlər qrupuna diqqət yetirməyə vadar etdi. 

Risklər

Böyük oyunçular bizim nə istədiyimizi anlamağa çalışarkən və satış öncəsi səviyyəli mütəxəssisləri cəlb etməklə bizimlə rahat yazışmalar apararkən, yerli developer öz texniki qrupunun iştirakı ilə ofisimizdə görüş təyin etdi. Bu görüşdə podratçı layihədə iştirak etmək arzusunu bir daha nümayiş etdirdi və ən əsası tələb olunan sistemin necə həyata keçiriləcəyini izah etdi.    

Görüşdən əvvəl biz arxasında böyük bir milli və ya beynəlxalq şirkətin resursları olmayan bir komanda ilə işləməyin iki riskini gördük:

  1. Mütəxəssislər öz imkanlarını yüksək qiymətləndirə bilər və nəticədə sadəcə öhdəsindən gələ bilmirlər, məsələn, onlar mürəkkəb proqram təminatından istifadə edəcəklər və ya qeyri-mümkün rezervasiya alqoritmləri tərtib edəcəklər.
  2. Layihə başa çatdıqdan sonra layihə komandası parçalana bilər və buna görə də məhsul dəstəyi təhlükə altında olacaq.

Bu riskləri minimuma endirmək üçün biz öz inkişaf mütəxəssislərimizi görüşə dəvət etdik. Potensial podratçının əməkdaşları ilə sistemin nəyə əsaslandığı, ixtisarın necə həyata keçirilməsinin planlaşdırıldığı və əməliyyat xidməti olaraq bizim kifayət qədər səriştəli olmadığımız digər məsələlərlə bağlı ətraflı müsahibə aparıldı.

Qərar müsbət oldu: mövcud BMS platformasının arxitekturası müasir, sadə və etibarlıdır, təkmilləşdirilə bilər, təklif olunan ehtiyat və sinxronizasiya sxemi məntiqli və işləkdir. 

İlk riskin qarşısı alındı. İkincisi, podratçıdan sistemin mənbə kodunu və sənədləri bizə ötürməyə hazır olduqlarını təsdiqlədikdən sonra, həmçinin mütəxəssislərimizə yaxşı məlum olan Python proqramlaşdırma dilini seçməklə istisna edildi. Bu, inkişaf şirkətinin bazarı tərk etməsi halında bizə heç bir çətinlik çəkmədən sistemi təkbaşına saxlamaq və işçilərə uzun müddət təlim keçmək imkanını təmin etdi.

Platformanın əlavə üstünlüyü onun Docker konteynerlərində həyata keçirilməsi idi: bu mühitdə nüvə, veb interfeys və məhsul verilənlər bazası funksiyası. Bu yanaşma bir çox üstünlükləri, o cümlədən “klassik” ilə müqayisədə həllin yerləşdirilməsinin ən yüksək sürəti üçün əvvəlcədən təyin edilmiş parametrləri və sistemə yeni cihazların asan əlavə edilməsini təmin edir. “Hamı birlikdə” prinsipi sistemin həyata keçirilməsini mümkün qədər asanlaşdırır: sadəcə sistemi paketdən çıxarın və siz ondan dərhal istifadə edə bilərsiniz. 

Bu həll yolu ilə sistemin surətlərini çıxarmaq daha asandır və siz bütövlükdə həllin fəaliyyətini dayandırmadan onu təkmilləşdirə və təkmilləşdirmələri ayrıca mühitdə həyata keçirə bilərsiniz.  

Hər iki risk minimuma endirildikdən sonra podratçı CP-ni təmin etdi. O, bizim üçün BMS sisteminin bütün ən vacib parametrlərini əhatə edirdi.

Rezervasyon

Yeni BMS sistemi buludda, virtual maşında yerləşdirilməli idi. 

Heç bir avadanlıq, heç bir server və bu yerləşdirmə modeli ilə əlaqəli bütün narahatlıqlar və risklər - bulud həlli bizə onlardan əbədi olaraq xilas olmağa imkan verdi. Sistemin Sankt-Peterburq və Moskvadakı iki məlumat mərkəzi saytında buludumuzda işləməsi qərara alındı. Bunlar, bütün səlahiyyətli mütəxəssislərə çıxışı olan aktiv gözləmə rejimində işləyən iki tam funksional sistemdir. 

İki sistem bir-birini sığortalayaraq həm hesablama gücünün, həm də məlumatların ötürülməsi kanallarının tam ehtiyatını təmin edir. Əlavə təhlükəsizlik tədbirləri də konfiqurasiya edilib, o cümlədən məlumatların və kanalların, sistemlərin, ümumilikdə virtual maşınların ehtiyat nüsxəsi və ayda bir dəfə verilənlər bazasının ayrıca ehtiyat nüsxəsi (idarəetmə və təhlil baxımından ən qiymətli resurs). 

Qeyd edək ki, BMS həllində bir seçim kimi artıqlıq bizim sorğumuz üçün xüsusi olaraq hazırlanmışdır. Rezervasiya sxeminin özü belə görünürdü:

Məlumat mərkəzində monitorinq: köhnə BMS-ni yenisinə necə dəyişdik. 2-ci hissə

Dəstək

BMS həllinin effektiv işləməsi üçün ən vacib məqam texniki dəstəkdir. 

Burada hər şey sadədir: yeni sistem bu göstəriciyə görə bizə 35 rubla başa gələcək. SLA üçün ayda “000 saat ərzində cavab”, yəni 8 x 35 / 000 = ildə 12 ABŞ dolları. Birinci il pulsuzdur. 

Müqayisə üçün qeyd edək ki, satıcıdan köhnə BMS-nin saxlanması əlavə edilən hər yeni cihaz üçün məbləğin artması ilə ildə 18 dollara başa gəlir! Eyni zamanda, şirkət xüsusi menecer təmin etməyib; bütün qarşılıqlı əlaqə, sorğuların işlənməsinə müvafiq vurğu ilə potensial alıcı kimi bizimlə maraqlanan satış meneceri vasitəsilə baş verdi. 

Daha az pul üçün məhsulun hazırlanmasında iştirak edəcək bir hesab meneceri ilə, tək giriş nöqtəsi və s. ilə tam məhsul dəstəyi aldıq. Dəstək daha çevik oldu - sistemin istənilən aspektinə operativ düzəlişlər etmək üçün tərtibatçılara birbaşa çıxış, API vasitəsilə inteqrasiya və s.

Updates

Yeni BMS-də təklif olunan CP-yə əsasən, bütün yeniləmələr dəstəyin qiymətinə daxildir, yəni. əlavə ödəniş tələb etmir. İstisna texniki spesifikasiyalarda göstərilənlərdən kənar əlavə funksionallığın inkişafıdır. 

Köhnə sistem həm proqram təminatı yeniləmələri (məsələn, Java), həm də səhvlərin düzəldilməsi üçün ödəniş tələb edirdi. Bundan imtina etmək mümkün deyildi, yeniləmələr olmadıqda, daxili komponentlərin köhnə versiyaları səbəbindən sistem bütövlükdə "yavaşladı".

Və əlbəttə ki, dəstək paketi almadan proqramı yeniləmək mümkün deyildi.

Çevik yanaşma

Digər əsas tələb interfeyslə bağlı idi. Məlumat mərkəzinin ərazisində mühəndisin məcburi iştirakı olmadan istənilən yerdən veb-brauzer vasitəsilə ona girişi təmin etmək istədik. Bundan əlavə, infrastrukturun dinamikasının növbətçi mühəndislərə daha aydın olması üçün animasiya interfeysi yaratmağa çalışdıq. 

Həm də yeni sistemdə mühəndislik sistemlərində virtual sensorların işini hesablamaq üçün düsturlara dəstək vermək lazım idi - məsələn, elektrik enerjisinin avadanlıq rafları arasında optimal paylanması üçün. Bunu etmək üçün, sizin ixtiyarınızda sensor göstəricilərinə tətbiq olunan bütün adi riyazi əməliyyatlara sahib olmalısınız. 

Bundan sonra, SQL verilənlər bazasına giriş ondan avadanlığın işləməsi haqqında lazımi məlumatları - yəni iki min cihazın bütün monitorinq qeydlərini və təxminən 20 min dəyişən yaradan iki min virtual sensoru götürmək imkanı tələb olunurdu. 

Hər bir bölmədə cihazların yerləşdirilməsinin qrafik təsvirini aparatın ümumi çəkisinin hesablanması, cihazların kitabxanasını və hər bir element haqqında ətraflı məlumatı təmin edən bir rack avadanlığının uçotu modulu da lazım idi. 

Texniki şərtlərin təsdiqi və müqavilənin imzalanması

Yeni sistem üzərində işə başlamaq lazım olduğu bir vaxtda, "böyük" şirkətlərlə yazışmalar onların təkliflərinin dəyərini müzakirə etməkdən hələ çox uzaq idi, buna görə də alınan CP-ni köhnə BMS-nin yenilənməsi xərcləri ilə müqayisə etdik (bax. birinci hissə) və nəticədə qiymət baxımından daha cəlbedici oldu və tələblərimizə cavab verdi.

Seçim edildi.

Podratçı seçildikdən sonra hüquqşünaslar müqavilə tərtib etməyə başladılar və hər iki tərəfdən texniki qruplar texniki şərtləri cilalamağa başladılar. Bildiyiniz kimi, təfərrüatlı və bacarıqlı texniki spesifikasiyalar istənilən işin uğurunun əsasını təşkil edir. Texniki spesifikasiyalar nə qədər çox olsa, “amma bizim istədiyimiz bu deyil” kimi məyusluqlar bir o qədər az olar.

Texniki spesifikasiyalardakı tələblərin təfərrüat səviyyəsinə iki nümunə verəcəyəm:

  1. Növbətçi məlumat mərkəzləri BMS-ə yeni cihazlar əlavə etmək səlahiyyətinə malikdir, əksər hallarda bunlar PDU-lardır. Köhnə BMS-də bu, bütün cihazların dəyişən parametrlərini dəyişdirməyə imkan verən "inzibatçı" səviyyəsi idi və funksiyaları ayırmaq mümkün deyildi. Bu bizə yaraşmadı. Yeni platformanın mövcud əsas versiyasında sxem oxşar idi. Biz dərhal texniki tapşırıqda bu rolları ayırmaq istədiyimizi bildirdik: yalnız səlahiyyətli işçi parametrləri dəyişdirməlidir, ancaq növbətçi olanlar cihazları əlavə edə bilməyə davam etməlidirlər. Bu sxem həyata keçirmək üçün qəbul edildi.
  2.  İstənilən standart BMS-də bildirişlərin üç tipik kateqoriyası var: QIRMIZI - dərhal cavab verilməlidir, SARI - müşahidə edilə bilər, MAVİ - "Məlumat xarakterli". Müştərinin rəfinin tutum həddini aşması kimi biznes parametrlərinin nə vaxt keçdiyini izləmək üçün ənənəvi olaraq mavi siqnallardan istifadə etmişik. Bizim vəziyyətimizdə bu cür bildiriş menecerlər üçün nəzərdə tutulmuşdu və əməliyyat xidməti üçün maraqlı deyildi, lakin köhnə BMS-də müntəzəm olaraq aktiv hadisələrin siyahısını tıxayırdı və əməliyyat işlərinə müdaxilə edirdi. Bildiriş şalvarının məntiqini və rəng fərqini uğurlu hesab etdik və onu saxladıq, lakin texniki spesifikasiyalar xüsusi olaraq qeyd etdi ki, “mavi” bildirişlər növbətçilərin diqqətini yayındırmadan, səssizcə ayrı bir bölməyə “tökülməlidir”. kommersiya mütəxəssisləri məşğul olacaqlar.

Bənzər bir detalla, qrafiklərin qurulması və hesabatların yaradılması formatları, interfeyslərin konturları, nəzarət edilməli olan cihazların siyahısı və bir çox başqa şeylər təyin edildi. 

Bu, həqiqətən üç işçi qrupunun - onun tələblərini və şərtlərini diktə edən müştəri xidmətlərinin yaradıcı işi idi; hər iki tərəfin vəzifəsi bu şərtləri texniki sənədlərə çevirmək olan texniki mütəxəssislər; sifarişçinin tələblərini hazırlanmış texniki sənədlərə uyğun həyata keçirən podratçı proqramçılardan ibarət komandalar... Nəticədə biz prinsipsiz tələblərimizin bir qismini mövcud platformanın funksionallığına uyğunlaşdırdıq və podratçı bizim üçün nəsə əlavə etməyi öhdəsinə götürdü. 

İki sistemin paralel işləməsi

Məlumat mərkəzində monitorinq: köhnə BMS-ni yenisinə necə dəyişdik. 2-ci hissə
İcra vaxtıdır. Praktikada bu o demək idi ki, biz podratçıya virtual buludumuzda BMS prototipini yerləşdirmək və monitorinq tələb edən bütün cihazlara şəbəkəyə çıxış təmin etmək imkanı veririk.

Lakin yeni sistem hələ işə hazır deyildi. Bu mərhələdə köhnə sistemdə monitorinqi saxlamaq və eyni zamanda cihazlara yeni sistemə giriş imkanı vermək bizim üçün vacib idi. İçindəki cihazları görmədən sistemi düzgün qurmaq mümkün deyil, bu da öz növbəsində köhnə sistem tərəfindən monitorinqi dayandıra bilməz. 

Cihazların iki sistem tərəfindən eyni vaxtda sorğu-sualına tab gətirə bilməyəcəyi real sınaq olmadan aydın deyildi. İkiqat eyni vaxtda sorğunun cihazlardan tez-tez cavab verməkdən imtina etməsinə səbəb olacağı və cihazların əlçatmazlığı ilə bağlı çoxlu səhvlər alacağımız ehtimalı var idi ki, bu da öz növbəsində köhnə monitorinq sisteminin işini əngəlləyəcək.

Şəbəkə şöbəsi buludda yerləşdirilmiş yeni BMS-in prototipindən cihazlara virtual marşrutlar keçirdi və biz nəticələr əldə etdik: 

  • SNMP protokolu ilə qoşulan qurğular eyni vaxtda edilən sorğular səbəbindən praktiki olaraq heç vaxt əlaqəsi kəsilmədi, 
  • modbas-TCP protokollarından istifadə edərək şlüzlər vasitəsilə qoşulan cihazlarda səsvermə tezliyini ağıllı şəkildə azaltmaqla həll edilən problemlər var idi.  

Və sonra gözlərimiz önündə yeni bir sistemin necə qurulduğunu müşahidə etməyə başladıq, orada bizə artıq tanış olan cihazlar göründü, lakin fərqli bir interfeysdə - rahat, sürətli, hətta telefondan da əlçatandır.

Sonda nə baş verdiyini yazımızın üçüncü hissəsində sizə xəbər verəcəyik.

Mənbə: www.habr.com

Добавить комментарий