Pirmoje dalyje kalbėjome, kodėl nusprendėme savo duomenų centruose seną BMS sistemą pakeisti nauja. Ir ne tik keisti, bet ir tobulėti nuo nulio, kad atitiktų jūsų poreikius. Antroje dalyje papasakosime, kaip tai padarėme.
Rinkos analizė
Atsižvelgiant į aprašytus pageidavimus ir sprendimą atsisakyti atnaujinti esamą sistemą, surašėme techninę specifikaciją, siekdami rasti sprendimą rinkoje ir užklausėme keletą didelių įmonių, užsiimančių tik pramoninių SCADA sistemų kūrimu.
Jau pirmieji jų atsakymai parodė, kad stebėjimo sistemų rinkos lyderiai pirmiausia ir toliau dirba prie aparatinės įrangos serverių, nors migracijos į debesis procesas šiame segmente jau prasidėjo. Kalbant apie virtualių mašinų rezervavimą, niekas nepalaikė šios parinkties. Be to, buvo jausmas, kad nė vienas iš rinkoje matomų kūrėjų net neparodė supratimo apie atleidimo poreikį: „debesis nekrenta“ buvo dažniausias atsakymas. Tiesą sakant, mums buvo pasiūlyta duomenų centro stebėjimą patalpinti debesyje, fiziškai esančiame tame pačiame duomenų centre.
Čia turime padaryti nedidelį nukrypimą nuo rangovo pasirinkimo proceso. Kaina, žinoma, turi reikšmės, tačiau bet kurio kompleksinio projekto įgyvendinimo konkurso metu dialogo su tiekėjais stadijoje pradedi jausti, kuris iš kandidatų yra labiau suinteresuotas ir galintis tai įgyvendinti.
Tai ypač pastebima sudėtinguose projektuose.
Pagal techninių specifikacijų klausimų patikslinimo pobūdį rangovai gali būti skirstomi į tuos, kurie domisi tiesiog pardavimu (jaučiamas standartinis pardavimų vadybininko spaudimas) ir tuos, kurie domisi gaminio kūrimu, išgirdę ir supratę klientą, konstruktyvūs. techninių specifikacijų pakeitimus dar prieš galutinį pasirinkimą (net nepaisant realios rizikos patobulinti kažkieno technines specifikacijas ir pralaimėti konkursą), galų gale jie tiesiog yra pasirengę priimti profesinį iššūkį ir pagaminti gerą produktą.
Visa tai privertė atkreipti dėmesį į santykinai nedidelį vietinį kūrėją – Sunline įmonių grupę, kuri iš karto reagavo į daugumą mūsų reikalavimų ir buvo pasiruošusi įgyvendinti visus su naujuoju BMS susijusius poreikius.
Rizika
Kol didieji žaidėjai bandė suprasti, ko mes norime, ir neskubėdami su mumis susirašinėjo, įtraukdami išankstinio pardavimo lygio specialistus, vietinis kūrėjas suplanavo susitikimą mūsų biure, kuriame dalyvautų jo techninė komanda. Šiame susitikime rangovas dar kartą pademonstravo norą dalyvauti projekte ir, svarbiausia, paaiškino, kaip bus įdiegta reikiama sistema.
Prieš susitikimą matėme dvi rizikas dirbant su komanda, kuri neturi didelės nacionalinės ar tarptautinės įmonės išteklių:
- Specialistai gali pervertinti savo galimybes ir dėl to tiesiog nesusitvarkyti, pavyzdžiui, naudos sudėtingą programinę įrangą arba kurs neįgyvendinamus rezervavimo algoritmus.
- Pasibaigus projektui, projekto komanda gali iširti ir dėl to kils pavojus produkto palaikymui.
Siekdami sumažinti šias rizikas, į susitikimą pakvietėme savo plėtros specialistus. Potencialūs rangovo darbuotojai buvo nuodugniai apklausti, kuo paremta sistema, kaip planuojama įgyvendinti atleidimą ir kitus klausimus, kuriuose mes, kaip eksploatavimo tarnyba, nesame pakankamai kompetentingi.
Verdiktas buvo teigiamas: esamos BMS platformos architektūra moderni, paprasta ir patikima, tobulinama, siūloma atleidimo ir sinchronizavimo schema logiška ir veikianti.
Pirmoji rizika buvo išspręsta. Antrasis buvo pašalintas gavus rangovo patvirtinimą, kad jie pasiruošę mums perduoti sistemos ir dokumentacijos pirminį kodą, taip pat pasirinkus mūsų specialistams gerai žinomą Python programavimo kalbą. Tai mums garantavo galimybę savarankiškai be jokių sunkumų prižiūrėti sistemą ir ilgą darbuotojų mokymą tuo atveju, jei vystymo įmonė pasitrauktų iš rinkos.
Papildomas platformos pranašumas buvo tai, kad ji buvo įdiegta Docker konteineriuose: branduolio, žiniatinklio sąsajos ir produktų duomenų bazės funkcija šioje aplinkoje. Šis metodas suteikia daug privalumų, įskaitant iš anksto nustatytus parametrus, kad sprendimas būtų įdiegtas didžiausias greitis, palyginti su „klasikiniu“ ir paprastas naujų įrenginių įtraukimas į sistemą. Principas „viskas kartu“ maksimaliai supaprastina sistemos diegimą: tereikia išpakuoti sistemą ir galite iš karto ja naudotis.
Taikant šį sprendimą lengviau daryti sistemos kopijas, o ją tobulinti ir įdiegti atnaujinimus galima atskiroje aplinkoje, nesustabdant viso sprendimo veikimo.
Kai abi rizika buvo sumažinta, rangovas pateikė CP. Ji apėmė visus mums svarbiausius BMS sistemos parametrus.
Rezervacija
Naujoji BMS sistema turėjo būti debesyje, virtualioje mašinoje.
Jokios aparatinės įrangos, jokių serverių ir visų nepatogumų bei rizikų, susijusių su šiuo diegimo modeliu – debesies sprendimas leido mums jų atsikratyti amžiams. Buvo nuspręsta, kad sistema veiks mūsų debesyje dviejuose duomenų centruose Sankt Peterburge ir Maskvoje. Tai dvi pilnai veikiančios sistemos, veikiančios aktyviuoju budėjimo režimu ir prieiga prie visų įgaliotų specialistų.
Abi sistemos apdraudžia viena kitą, suteikdamos visą tiek skaičiavimo galios, tiek duomenų perdavimo kanalų rezervą. Taip pat sukonfigūruotos papildomos saugos priemonės, įskaitant duomenų ir kanalų, sistemų, virtualių mašinų atsarginę kopiją apskritai ir atskirą duomenų bazės atsarginę kopiją kartą per mėnesį (vertingiausias išteklius valdymo ir analizės požiūriu).
Atkreipkite dėmesį, kad atleidimas kaip galimybė BMS sprendime buvo sukurtas specialiai mūsų užklausai. Pati rezervavimo schema atrodė taip:
Remti
Svarbiausias dalykas, kad BMS sprendimas veiktų efektyviai, yra techninė pagalba.
Čia viskas paprasta: nauja sistema pagal šį rodiklį mums kainuotų 35 000 rublių. per mėnesį už SLA „atsakymą per 8 valandas“, tai yra, 35 000 x 12 / 80 = 5 250 USD per metus. Pirmi metai nemokami.
Palyginimui, pardavėjo senojo BMS išlaikymas kainuoja 18 000 USD per metus, padidinus kiekvieno naujo pridėto įrenginio sumą! Tuo pačiu metu įmonė nepaskyrė dedikuoto vadovo, visa sąveika vyko per pardavimų vadybininką, kuris domisi mumis kaip potencialiu pirkėju, atitinkamu akcentu nagrinėjant užklausas.
Už mažesnius pinigus gavome visą produkto palaikymą, su paskyros vadybininku, kuris dalyvautų gaminant produktą, su vienu įėjimo tašku ir t.t. Palaikymas tapo daug lankstesnis – dėl tiesioginės prieigos prie kūrėjų, kad būtų galima greitai koreguoti bet kurį sistemos aspektą, integruoti per API ir kt.
Atnaujinimai
Pagal siūlomą CP naujajame BMS visi atnaujinimai įskaičiuojami į palaikymo kainą, t.y. nereikalauja papildomo mokėjimo. Išimtis yra papildomų funkcijų kūrimas, nei nurodyta techninėse specifikacijose.
Senoji sistema reikalavo mokėti už programinės aparatinės įrangos atnaujinimus (pvz., „Java“), ir už klaidų taisymus. To buvo neįmanoma atsisakyti, nesant atnaujinimų, visa sistema „sulėtėjo“ dėl senų vidinių komponentų versijų.
Ir, žinoma, nebuvo įmanoma atnaujinti programinės įrangos neįsigijus palaikymo paketo.
Lankstus požiūris
Kitas esminis reikalavimas buvo susijęs su sąsaja. Norėjome suteikti prieigą prie jo per interneto naršyklę iš bet kurios vietos, be privalomo inžinieriaus buvimo duomenų centro teritorijoje. Be to, siekėme sukurti animuotą sąsają, kad infrastruktūros dinamika būtų aiškesnė budintiems inžinieriams.
Taip pat naujojoje sistemoje reikėjo numatyti virtualių jutiklių veikimo inžinerinėse sistemose skaičiavimo formules – pavyzdžiui, optimaliam elektros energijos paskirstymui įrangos stovuose. Norėdami tai padaryti, turite turėti visas įprastas matematines operacijas, taikomas jutiklių indikatoriams.
Toliau buvo reikalinga prieiga prie SQL duomenų bazės su galimybe iš jos paimti reikiamus duomenis apie įrangos veikimą – būtent visus dviejų tūkstančių įrenginių ir dviejų tūkstančių virtualių jutiklių, generuojančių apie 20 tūkstančių kintamųjų, stebėjimo įrašus.
Taip pat buvo reikalingas stovo įrangos apskaitos modulis, grafiškai pavaizduojantis įrenginių išdėstymą kiekviename bloke, apskaičiuojant bendrą techninės įrangos svorį, tvarkant įrenginių biblioteką ir išsamią informaciją apie kiekvieną elementą.
Techninių specifikacijų tvirtinimas ir sutarties pasirašymas
Tuo metu, kai reikėjo pradėti kurti naują sistemą, susirašinėjimas su „stambiomis“ įmonėmis dar buvo labai toli nuo jų pasiūlymų kainos aptarimo, todėl gautą CP palyginome su senosios BMS atnaujinimo išlaidomis (žr. ), ir dėl to jis pasirodė patrauklesnis savo kaina ir atitinka mūsų reikalavimus.
Pasirinkimas padarytas.
Pasirinkę rangovą, teisininkai pradėjo rengti sutartį, abiejų pusių techninės komandos pradėjo šlifuoti technines specifikacijas. Kaip žinote, išsamios ir kompetentingos techninės specifikacijos yra bet kokio darbo sėkmės pagrindas. Kuo daugiau specifikos yra techninėse specifikacijose, tuo mažiau nusivylimų, pavyzdžiui, „bet ne tai, ko norėjome“.
Pateiksiu du techninių specifikacijų reikalavimų detalumo pavyzdžius:
- Budintys duomenų centrai turi teisę papildyti BMS naujais įrenginiais, dažniausiai tai yra PDU. Senojoje BMS tai buvo „administratoriaus“ lygis, kuris taip pat leido keisti visų įrenginių kintamus nustatymus, o funkcijų atskirti nebuvo įmanoma. Tai mums netiko. Esamoje pagrindinėje naujos platformos versijoje schema buvo panaši. Darbo užduotyje iš karto nurodėme, kad norime atskirti šiuos vaidmenis: nustatymus turėtų keisti tik įgaliotas darbuotojas, o budintys ir toliau galės pridėti įrenginių. Ši schema buvo priimta įgyvendinti.
- Bet kuriame standartiniame BMS yra trys tipinės pranešimų kategorijos: RAUDONAS – į juos reikia reaguoti nedelsiant, GELTONAS – galima pastebėti, MĖLYNA – „Informacinis“. Tradiciškai naudojame mėlynus įspėjimus, kad stebėtume, kada viršijami verslo parametrai, pavyzdžiui, kai kliento stovas viršija talpos ribą. Tokio tipo pranešimai mūsų atveju buvo skirti vadovams ir nesudomino operacijų tarnybos, tačiau senojoje BMS reguliariai užkimšo aktyvių incidentų sąrašą ir trukdė operatyviniam darbui. Pačią pranešimų kelnių logiką ir spalvų diferenciaciją laikėme sėkminga ir ją išlaikėme, tačiau techninėse specifikacijose buvo konkrečiai nurodyta, kad „mėlyni“ pranešimai, neatitraukiant budinčių pareigūnų dėmesio, turi tyliai „pilti“ į atskirą skyrių, kur jie su juo spręsis komercijos specialistai.
Panašiai detaliai buvo nustatyti grafikų sudarymo ir ataskaitų generavimo formatai, sąsajų kontūrai, įrenginių, kuriuos reikia stebėti, sąrašas ir daug kitų dalykų.
Tai buvo tikrai kūrybingas trijų darbo grupių darbas – klientų aptarnavimo tarnyba, kuri padiktavo savo reikalavimus ir sąlygas; abiejų pusių techniniai specialistai, kurių užduotis buvo šias sąlygas paversti technine dokumentacija; rangovų programuotojų komandos, kurios įgyvendino užsakovo reikalavimus pagal parengtą techninę dokumentaciją... Dėl to kai kuriuos savo neprincipingus reikalavimus pritaikėme prie esamos platformos funkcionalumo, o rangovas įsipareigojo ką nors pridėti už mus.
Lygiagretus dviejų sistemų veikimas
Atėjo laikas įgyvendinti. Praktiškai tai reiškė, kad rangovui suteikiame galimybę įdiegti BMS prototipą mūsų virtualiame debesyje ir suteikti prieigą prie tinklo visiems įrenginiams, kuriems reikalingas stebėjimas.
Tačiau naujoji sistema dar nebuvo paruošta darbui. Šiame etape mums buvo svarbu išlaikyti stebėjimą senoje sistemoje ir tuo pačiu suteikti prieigą prie įrenginių naujai sistemai. Neįmanoma tinkamai sukurti sistemos nematant joje įrenginių, kurie savo ruožtu negali būti išjungti iš senosios sistemos stebėjimo.
Ar įrenginiai gali atlaikyti vienu metu atliekamus dviejų sistemų tardymus, nebuvo akivaizdu be realių bandymų. Buvo tikimybė, kad dviguba apklausa vienu metu lems dažnus atsisakymus reaguoti iš įrenginių ir sulauksime daug klaidų dėl įrenginių neprieinamumo, o tai savo ruožtu blokuotų senos stebėjimo sistemos veikimą.
Tinklo skyrius vykdė virtualius maršrutus nuo naujojo BMS prototipo, įdiegto debesyje iki įrenginių, ir mes gavome rezultatus:
- įrenginiai, prijungti per SNMP protokolą, praktiškai niekada nebuvo atjungti dėl vienalaikių užklausų,
- įrenginiai, prijungti per šliuzus naudojant modbas-TCP protokolus, turėjo problemų, kurios buvo išspręstos sumaniai sumažinus jų apklausos dažnį.
Ir tada pradėjome stebėti, kaip prieš akis statoma nauja sistema, joje atsirado mums jau pažįstami įrenginiai, bet kitoje sąsajoje – patogioje, greitoje, pasiekiamoje net iš telefono.
Mes jums pasakysime, kas atsitiko pabaigoje, trečioje mūsų straipsnio dalyje.
Šaltinis: www.habr.com