U prvom dijelu govorili smo o tome zašto smo stari BMS sustav u našim podatkovnim centrima odlučili zamijeniti novim. I ne samo mijenjati, već razvijati od nule kako bi odgovarao vašim zahtjevima. U drugom dijelu ćemo vam reći kako smo to učinili.
Analiza tržišta
Uzimajući u obzir one opisane u želja i odluke o odbijanju ažuriranja postojećeg sustava, napisali smo tehničku specifikaciju kako bismo pronašli rješenje na tržištu te uputili upite nekoliko velikih tvrtki koje se bave samo izradom industrijskih SCADA sustava.
Već prvi njihovi odgovori pokazali su da lideri na tržištu sustava za nadzor primarno nastavljaju raditi na hardverskim poslužiteljima, iako je proces migracije na oblake u tom segmentu već započeo. Što se tiče rezerviranja virtualnih strojeva, tu opciju nitko nije podržao. Štoviše, postojao je osjećaj da nitko od istaknutih developera na tržištu nije niti pokazao razumijevanje potrebe za redundancijom: “oblak ne pada” bio je najčešći odgovor. Zapravo, ponuđeno nam je da nadzor podatkovnog centra smjestimo u oblak koji se fizički nalazi u istom podatkovnom centru.
Ovdje treba napraviti malu digresiju o procesu odabira izvođača radova. Cijena je, naravno, bitna, ali tijekom bilo kojeg natječaja za realizaciju složenog projekta, u fazi dijaloga s dobavljačima, počinjete osjećati tko je od kandidata zainteresiraniji i sposobniji to provesti.
To je osobito vidljivo na složenim projektima.
Na temelju prirode razjašnjavajućih pitanja tehničkih specifikacija, izvođači se mogu podijeliti na one koji su zainteresirani za jednostavnu prodaju (osjeća se standardni pritisak voditelja prodaje) i one koji su zainteresirani za razvoj proizvoda, nakon što su čuli i razumjeli kupca, čineći konstruktivne izmjene tehničkih specifikacija i prije konačnog izbora (i pored realnog rizika poboljšanja tuđe tehničke specifikacije i gubitka natječaja), na kraju su jednostavno spremni prihvatiti profesionalni izazov i napraviti dobar proizvod.
Sve to nas je potaknulo da obratimo pažnju na relativno malog lokalnog developera - grupu tvrtki Sunline, koja je na većinu naših zahtjeva odmah odgovorila i bila spremna realizirati sve potrebe vezane uz novi BMS.
Rizici
Dok su veliki igrači pokušavali razumjeti što želimo i vodili ležernu korespondenciju s nama uključujući stručnjake za pretprodajnu razinu, lokalni programer zakazao je sastanak u našem uredu uz sudjelovanje njegovog tehničkog tima. Izvođač je na ovom sastanku još jednom pokazao želju za sudjelovanjem u projektu i, što je najvažnije, pojasnio kako će se zahtijevani sustav implementirati.
Prije sastanka vidjeli smo dva rizika rada s timom koji iza sebe nema resurse velike nacionalne ili međunarodne tvrtke:
- Stručnjaci bi mogli precijeniti svoje sposobnosti i, kao rezultat toga, jednostavno se ne bi snašli; na primjer, koristit će složeni softver ili dizajnirati neizvedive algoritme za rezervaciju.
- Nakon završetka projekta, projektni tim se može raspustiti i stoga će podrška za proizvod biti ugrožena.
Kako bismo ove rizike sveli na najmanju moguću mjeru, na sastanak smo pozvali vlastite stručnjake za razvoj. Sa zaposlenicima potencijalnog izvođača detaljno je obavljen razgovor o tome na čemu se temelji sustav, kako se planira implementacija redundantnosti i drugim pitanjima za koja mi kao operativna služba nismo dovoljno kompetentni.
Presuda je bila pozitivna: arhitektura postojeće BMS platforme je moderna, jednostavna i pouzdana, može se poboljšati, predložena shema redundancije i sinkronizacije je logična i izvediva.
Prvi rizik je riješen. Drugi je isključen nakon što smo od izvođača dobili potvrdu da su nam spremni prenijeti izvorni kod sustava i dokumentaciju te odabirom programskog jezika Python koji je našim stručnjacima bio dobro poznat. To nam je zajamčilo mogućnost samostalnog održavanja sustava bez ikakvih poteškoća i dugotrajnu obuku zaposlenika u slučaju odlaska razvojne tvrtke s tržišta.
Dodatna prednost platforme je što je implementirana u Docker spremnike: kernel, web sučelje i baza podataka proizvoda funkcioniraju u ovom okruženju. Ovaj pristup pruža mnoge prednosti, uključujući unaprijed postavljene postavke za najveću brzinu implementacije rješenja u odnosu na “klasični” i jednostavno dodavanje novih uređaja u sustav. Princip "sve zajedno" pojednostavljuje implementaciju sustava što je više moguće: samo trebate raspakirati sustav i odmah ga možete koristiti.
S ovim rješenjem lakše je izrađivati kopije sustava, a možete ga poboljšati i implementirati nadogradnje u zasebnom okruženju, bez zaustavljanja rada rješenja u cjelini.
Nakon što su oba rizika minimizirana, izvođač je osigurao CP. Obuhvaća sve nama najvažnije parametre BMS sustava.
Rezervacija
Novi BMS sustav je morao biti smješten u oblaku, na virtualnom računalu.
Bez hardvera, bez poslužitelja i svih neugodnosti i rizika povezanih s ovim modelom implementacije - rješenje u oblaku omogućilo nam je da ih se zauvijek riješimo. Odlučeno je da će sustav raditi u našem oblaku u dva podatkovna centra u St. Petersburgu i Moskvi. Radi se o dva potpuno funkcionalna sustava koji rade u aktivnom stanju pripravnosti uz pristup svim ovlaštenim stručnjacima.
Dva sustava osiguravaju jedan drugog, osiguravajući punu rezervu i računalne snage i kanala za prijenos podataka. Konfigurirane su i dodatne sigurnosne mjere, uključujući sigurnosno kopiranje podataka i kanala, sustava, općenito virtualnih strojeva te zasebno sigurnosno kopiranje baze podataka jednom mjesečno (najvrjedniji resurs u smislu upravljanja i analize).
Imajte na umu da je redundancija kao opcija u BMS rješenju razvijena posebno za naš zahtjev. Sama shema rezervacije izgledala je ovako:
Podrška
Najvažnija točka za učinkovit rad BMS rješenja je tehnička podrška.
Ovdje je sve jednostavno: novi sustav bi nas koštao 35 rubalja prema ovom pokazatelju. mjesečno za SLA "odgovor u roku od 000 sati", odnosno 8 35 x 000 / 12 = 80 5 USD godišnje. Prva godina je besplatna.
Za usporedbu, održavanje starog BMS-a od dobavljača koštalo je 18 dolara godišnje s povećanjem iznosa za svaki novi dodani uređaj! Istovremeno, tvrtka nije osigurala namjenskog menadžera, sva interakcija odvijala se preko voditelja prodaje koji je zainteresiran za nas kao potencijalnog kupca s odgovarajućim naglaskom na obradu zahtjeva.
Za manje novca dobili smo potpunu podršku za proizvod, s account managerom koji bi sudjelovao u razvoju proizvoda, s jedinstvenom točkom ulaza itd. Podrška je postala mnogo fleksibilnija - zahvaljujući izravnom pristupu programerima za brze prilagodbe bilo kojem aspektu sustava, integraciji putem API-ja itd.
Ažuriranja
Prema predloženom CP-u u novom BMS-u, sva su ažuriranja uključena u trošak podrške, tj. ne zahtijevaju dodatno plaćanje. Izuzetak je razvoj dodatne funkcionalnosti izvan onoga što je navedeno u tehničkim specifikacijama.
Stari sustav zahtijevao je plaćanje i za ažuriranje firmvera (kao što je Java) i za popravke grešaka. Bilo je nemoguće odbiti to; u nedostatku ažuriranja, sustav je u cjelini "usporio" zbog starih verzija internih komponenti.
I, naravno, bilo je nemoguće ažurirati softver bez kupnje paketa podrške.
Fleksibilan pristup
Drugi temeljni zahtjev odnosio se na sučelje. Željeli smo mu omogućiti pristup putem web preglednika s bilo kojeg mjesta, bez obvezne prisutnosti inženjera na području podatkovnog centra. Osim toga, nastojali smo izraditi animirano sučelje kako bi dežurnim inženjerima bila jasnija dinamika infrastrukture.
Također je u novom sustavu bilo potrebno osigurati podršku za formule za izračun rada virtualnih senzora u inženjerskim sustavima - na primjer, za optimalnu distribuciju električne energije preko regala opreme. Da biste to učinili, morate imati na raspolaganju sve uobičajene matematičke operacije primjenjive na indikatore senzora.
Zatim je bio potreban pristup SQL bazi podataka s mogućnošću preuzimanja iz nje potrebnih podataka o radu opreme – naime, svi zapisi nadzora dvije tisuće uređaja i dvije tisuće virtualnih senzora koji generiraju približno 20 tisuća varijabli.
Također je bio potreban modul za računovodstvo opreme regala, koji bi davao grafički prikaz rasporeda uređaja u svakoj jedinici s izračunom ukupne težine hardvera, vođenjem biblioteke uređaja i detaljnim informacijama o svakom elementu.
Odobravanje tehničke specifikacije i potpisivanje ugovora
U vrijeme kada je bilo potrebno započeti s radom na novom sustavu, korespondencija s „velikim“ tvrtkama još je bila daleko od rasprave o cijeni njihovih prijedloga, pa smo primljeni CP usporedili s troškovima ažuriranja starog BMS-a (vidi. ), te se kao rezultat pokazalo da je cjenovno atraktivniji i da ispunjava naše zahtjeve.
Izbor je napravljen.
Nakon odabira izvođača, odvjetnici su počeli sastavljati ugovor, a tehnički timovi s obje strane počeli su brusiti tehničke specifikacije. Kao što znate, detaljne i kompetentne tehničke specifikacije temelj su uspjeha svakog posla. Što je više specifičnosti u tehničkim specifikacijama, to je manje razočarenja poput "ali ovo nije ono što smo htjeli."
Navest ću dva primjera razine detalja zahtjeva u tehničkim specifikacijama:
- Dežurni podatkovni centri ovlašteni su dodavati nove uređaje u BMS, najčešće su to PDU-ovi. U starom BMS-u to je bila “administratorska” razina koja je također omogućavala promjenu varijabilnih postavki svih uređaja, a funkcije je bilo nemoguće odvojiti. Ovo nam nije odgovaralo. U postojećoj osnovnoj verziji nove platforme shema je bila slična. Odmah smo u projektnom zadatku naznačili da želimo razdvojiti ove uloge: samo ovlašteni djelatnik treba mijenjati postavke, ali dežurni bi i dalje trebali moći dodavati uređaje. Ova shema je prihvaćena za provedbu.
- U svakom standardnom BMS-u postoje tri tipične kategorije obavijesti: CRVENA - na njih se mora odmah odgovoriti, ŽUTA - može se vidjeti, PLAVA - "Informativne". Tradicionalno koristimo plava upozorenja za praćenje prekoračenja poslovnih parametara, kao što je korisnikov stalak koji premašuje ograničenje kapaciteta. Ovakav tip obavijesti u našem slučaju bio je namijenjen menadžerima i nije bio od interesa za operativnu službu, ali je u starom BMS-u redovito zakrčivao listu aktivnih incidenata i ometao operativni rad. Samu logiku i razlikovanje boja dojavnih hlača ocijenili smo uspješnom i zadržali je, no u tehničkim specifikacijama je izričito naznačeno da se „plave“ obavijesti trebaju, ne ometajući dežurne, tiho „slijevati“ u zaseban odjeljak, gdje se bavit će se komercijalni stručnjaci.
Sa sličnim stupnjem detalja propisani su formati za izradu grafikona i generiranje izvješća, obrisi sučelja, popis uređaja koje je potrebno nadzirati i još mnogo toga.
Bio je to uistinu kreativan rad triju radnih skupina – korisničke službe koja je diktirala svoje zahtjeve i uvjete; tehnički stručnjaci s obje strane, čiji je zadatak bio pretočiti te uvjete u tehničku dokumentaciju; timove izvođača programera koji su implementirali zahtjeve naručitelja prema izrađenoj tehničkoj dokumentaciji... Kao rezultat toga, neke naše neprincipijelne zahtjeve prilagodili smo funkcionalnosti postojeće platforme, a izvođač se obvezao nešto dodati za nas.
Paralelni rad dvaju sustava
Vrijeme je za implementaciju. U praksi je to značilo da izvođaču dajemo mogućnost implementacije BMS prototipa u našem virtualnom oblaku i omogućavanje mrežnog pristupa svim uređajima koji zahtijevaju nadzor.
Međutim, novi sustav još nije bio spreman za rad. U ovoj fazi bilo nam je važno zadržati nadzor u starom sustavu i istovremeno omogućiti pristup uređajima novom sustavu. Nemoguće je pravilno izgraditi sustav, a da se u njemu ne vide uređaji, kojima stari sustav zauzvrat ne može onemogućiti nadzor.
Mogu li uređaji izdržati istovremeno ispitivanje dvaju sustava nije bilo očito bez pravog testiranja. Postojala je mogućnost da bi duplo istovremeno prozivanje dovelo do čestih odbijanja odgovora uređaja te bismo dobivali brojne greške u vezi nedostupnosti uređaja, što bi opet blokiralo rad starog sustava nadzora.
Mrežni odjel proveo je virtualne rute od prototipa novog BMS-a postavljenog u oblaku do uređaja i dobili smo rezultate:
- uređaji spojeni preko SNMP protokola praktički nikada nisu bili isključeni zbog istovremenih zahtjeva,
- uređaji povezani preko gatewaya koristeći modbas-TCP protokole imali su problema koji su riješeni inteligentnim smanjenjem njihove frekvencije prozivanja.
A onda smo počeli promatrati kako se pred našim očima gradi novi sustav, u njemu su se pojavili nama već poznati uređaji, ali u drugom sučelju - praktičnom, brzom, dostupnom čak i s telefona.
Što se na kraju dogodilo, ispričat ćemo vam u trećem dijelu našeg članka.
Izvor: www.habr.com
