U prvom dijelu smo objasnili zašto smo odlučili zamijeniti staru BMS-sustav u našim DC-ima s novim. I ne samo zamijeniti, već razviti od nule prema našim zahtjevima. U drugom dijelu govorimo kako smo to radili.
Analiza tržišta
Uzimajući u obzir opisano u željama i odluci da odustanemo od ažuriranja postojećeg sustava, napisali smo TZ za pronalaženje rješenja na tržištu i poslali zahtjeve nekoliko velikim kompanijama koje se isključivo bave izradom industrijskih SCADA sustava.
Prvi odgovori od njih pokazali su da lideri tržišta sustava nadzora većinom i dalje rade na fizičkim serverima, iako je proces migracije u oblake u ovom segmentu već započeo. Što se tiče rezerviranja virtualnih mašina – ovu opciju nitko nije podržavao. Štaviše, činilo se kao da nijedan od poznatih developera na tržištu nije čak ni prikazao razumijevanje potrebe za rezerviranjem: "oblak se ne ruši" bio je najčešći odgovor. U suštini, nudili su nam da smjestimo nadzor DC-a u oblaku koji se fizički nalazio u istom tom DC-u.
Ovdje se mora napraviti malo odstupanje o procesu odabira izvođača. Cijena, naravno, ima značaj, ali tijekom svakog natječaja za realizaciju složenog projekta, u fazi dijaloga s dobavljačima, počinješ osjećati tko od kandidata je više zainteresiran i sposoban ga realizirati.
To je posebno uočljivo na složenim projektima.
Po karakteru pojašnjavajućih pitanja prema TZ-u, izvođače možemo podijeliti na one koji su zainteresirani samo za prodaju (osjeća se standardni pritisak prodajnog menadžera) i one koji su zainteresirani da razviju proizvod, čujući i razumijevajući klijenta, unoseći konstruktivne promjene u TZ čak i prije konačnog odabira (čak i usprkos stvarnom riziku poboljšanja tuđeg TZ-a i gubitka natječaja), na kraju, jednostavno spremne prihvatiti profesionalni izazov i napraviti dobar proizvod.
Sve to natjeralo nas je da obratimo pažnju na relativno malog lokalnog developera – grupu kompanija "Sanline", koja se odmah odazvala na većinu naših zahtjeva i bila spremna realizirati sve potrebe vezane za novi BMS.
Rizici
Dok su veliki igrači pokušavali shvatiti što mi zapravo želimo i sporazumijevali se s nama polako, lokalni developer je zakazao sastanak u našem uredu s sudjelovanjem svog tehničkog tima. Na tom sastanku, izvođač je još jednom pokazao želju za sudjelovanjem u projektu i – što je najvažnije – objasnio kako će potrebni sustav biti implementiran.
Prije sastanka, primijetili smo dva rizika rada s timom koji nema podršku velike nacionalne ili međunarodne kompanije:
- Stručnjaci su mogli precijeniti svoje mogućnosti i kao rezultat jednostavno ne uspjeti, primjerice, koristit će složen softver ili će dizajnirati neizvedive algoritme rezervacije.
- Nakon implementacije projekta, projektni tim se može raspasti i, shodno tome, podrška proizvoda će biti ugrožena.
Kako bismo minimizirali te rizike, na sastanak smo pozvali naše vlastite stručnjake za razvoj. Zaposlenici potencijalnog izvođača su temeljito ispitani o tome na čemu se temelji sustav, kako planiraju provoditi rezervaciju i o drugim pitanjima u kojima, kao služba za održavanje, nismo dovoljno kompetentni.
Presudna prosudba bila je pozitivna: arhitektura postojećeg BMS sustava je moderna, jednostavna i pouzdana, može se doraditi, a predloženi sustav rezervacije i sinkronizacije je logičan i funkcionalan.
Prvi rizik je riješen. Drugi je isključen, dobivši od izvođača potvrdu o spremnosti za prijenos izvornog koda sustava i dokumentacije, a također su odabrali programski jezik Python, koji je dobro poznat našim stručnjacima. To nam je jamčilo mogućnost održavanja sustava vlastitim snagama bez ikakvih poteškoća i dugog razdoblja obuke zaposlenika u slučaju odlaska kompanije-developera s tržišta.
Dodatna prednost platforme bila je u tome što je implementirana unutar Docker kontejnera: u ovom okruženju funkcionišu jezgro, web sučelje i baza podataka proizvoda. Ovakav pristup donosi brojne prednosti, uključujući unaprijed postavljene postavke za maksimalnu brzinu implementacije rješenja u poređenju s "klasičnim" i jednostavno dodavanje novih uređaja u sistem. Princip "sve zajedno" maksimalno pojednostavljuje uvođenje sistema: dovoljno je samo raspakirati sistem i odmah ga početi koristiti.
S ovim rješenjem jednostavnije je praviti kopije sistema, a unapređenja i implementacije mogu se raditi u odvojenom okruženju, bez zaustavljanja rada rješenja u cjelini.
Nakon što su oba rizika minimalizirana, izvođač je dostavio poslovnu ponudu. U njoj su razrađeni svi najvažniji parametri za nas u vezi s BMS sistemom.
Sigurnosna kopija
Nova BMS paradigma trebala je biti u oblaku, na virtualnoj mašini.
Bez fizičkog hardvera, bez servera i svih neugodnosti i rizika vezanih za ovaj model implementacije – oblačno rješenje omogućilo nam je da se zauvijek riješimo tih problema. Odluka je donesena da će sistem raditi u našem oblaku na dvjema lokacijama data centra u Sankt Peterburgu i Moskvi. To su dva potpuno funkcionalna sistema koja rade u režimu aktivnog spremanja s pristupom za sve ovlaštene stručnjake.
Dva sistema međusobno osiguravaju jedan drugoga, pružajući punu rezervu i za računske snage i za kanale prijenosa podataka. Također su postavljene dodatne mjere sigurnosti, uključujući rezervnu kopiju podataka i kanala, sistema, virtualnih mašina u cjelini, te odvojenu rezervnu kopiju baze podataka svaki mjesec (najdragocjeniji resurs u perspektivi upravljanja i analize).
Napomena: Rješenje rezerviranja kao opcija za BMS razvijeno je posebno prema našem zahtjevu. Sama shema rezerviranja izgledala je ovako:
Podrška
Najvažniji trenutak za učinkovito eksploatiranje BMS rješenja – tehnička podrška.
Ovdje je sve jednostavno: novo rješenje koštalo bi nas prema ovom pokazatelju 35 000 rubalja mjesečno za SLA "reakcija unutar 8 sati", što je 35 000 x 12 / 80 = $5 250 godišnje. Prva godina - besplatno.
Za usporedbu: podrška za staru BMS od dobavljača koštala je 18 000 dolara godišnje uz povećanje iznosa za svaki novo dodani uređaj! Pri tome, kompanija nije isporučila određenog menadžera, a sve interakcije odvijale su se preko prodajnog menadžera koji je bio zainteresiran za nas kao potencijalnog kupca s odgovarajućim naglaskom u obradi zahtjeva.
Za manje novca dobili smo potpunu podršku proizvoda, s menadžerom računa koji bi sudjelovao u razvoju proizvoda, s jednom točkom pristupa itd. Podrška je postala znatno fleksibilnija – zahvaljujući izravnom pristupu programerima za hitne ispravke u svim aspektima rada sustava, integraciji putem API-ja itd.
Ažuriranja
Prema predloženom projektu u novoj BMS sve nadogradnje uključene su u cijenu podrške, tj. ne zahtijevaju dodatno plaćanje. Iznimka su razvoj dodatne funkcionalnosti, iznad onoga što je navedeno u tehničkom zadatku.
Stari sustav podrazumijevao je plaćanje kako za nadogradnju ugrađenog besplatnog softvera (poput Jave), tako i za ispravke grešaka. Nije se moglo odustati od toga, a bez nadogradnji sustav je u cjelini 'usporavao' zbog starih verzija unutarnjih komponenti.
I, naravno, nije bilo moguće nadograditi softver bez kupnje paketa podrške.
Fleksibilan pristup
Još jedan ključni zahtjev odnosio se na sučelje. Željeli smo osigurati pristup njemu putem web preglednika s bilo kojeg mjesta, bez obvezne prisutnosti inženjera u podatkovnom centru. Osim toga, nastojali smo ostvariti animirano sučelje kako bi dinamika funkcioniranja infrastrukture bila jasnija za dežurne inženjere.
Također, u novom sustavu trebalo je osigurati podršku za formule za izračun rada virtualnih senzora u inženjerskim sustavima – primjerice, za optimalnu raspodjelu električnih snaga po policama s opremom. Za to je potrebno imati na raspolaganju sve uobičajene matematičke operacije primjenjive na podatke senzora.
Nakon toga, bio je potreban pristup SQL bazi podataka s mogućnošću preuzimanja potrebnih podataka o radu opreme – naime, svi podaci o praćenju dvije tisuće uređaja i dvije tisuće virtualnih senzora koji generiraju otprilike 20 tisuća varijabli.
Također je bio potreban modul za praćenje opreme u ormaru koji daje grafički prikaz rasporeda uređaja u svakoj jedinici s ukupnom težinom opreme, vođenje biblioteke uređaja i detaljnih informacija o svakom elementu.
Dogovor o tehničkoj specifikaciji i potpisivanje ugovora
U trenutku kada je bilo potrebno započeti rad na novom sustavu, dopisivanje s ‘velikim’ kompanijama još uvijek je bilo daleko od rasprave o troškovima njihovih ponuda, stoga smo usporedili primljenu ponudu s troškovima ažuriranja starog BMS-a (vidi. ), i rezultat je bio da je ona bila financijski privlačnija i odgovarala našim zahtjevima.
Odlučeno je.
Nakon odabira izvođača, pravnici su počeli sastavljati ugovor, a tehnički timovi s obje strane usavršenju tehničku specifikaciju. Kao što je poznato, detaljna i jasna tehnička specifikacija – to je osnova uspjeha svih radova. Što je više konkretnih informacija u tehničkoj specifikaciji, to je manje razočaranja tipa ‘mi smo htjeli drugačije’.
Navest ću dva primjera razine detaljnosti zahtjeva u tehničkoj specifikaciji:
- Nadzorni centri podataka imaju ovlasti dodavati nova uređaja u BMS, najčešće PDU. U starom BMS-u to je bio nivo ‘administrator’ koji je također omogućavao promjenu postavki varijabli svih uređaja, a odvajanje funkcija nije bilo moguće. To nam nije odgovaralo. U osnovnoj verziji nove platforme shema je bila slična. Odmah smo naveli u tehničkoj specifikaciji da želimo odvojiti te uloge: postavke može mijenjati samo ovlašteni radnik, dok nadzornici i dalje trebaju imati mogućnost dodavanja uređaja. Ova shema je prihvaćena za realizaciju.
- U svakom standardnom BMS-u postoje tri tipične kategorije obavijesti: CRVENA – potrebno je hitno reagirati, ŽUTA – može se pratiti, PLAVA – 'Informativna'. Tradicionalno smo koristili 'plave' obavijesti za praćenje prekoračenja komercijalnih parametara, na primjer, prekoračenje limita snage klijentove police. Ova vrsta obavijesti bila je namijenjena menadžerima i nije bila zanimljiva službi održavanja, ali je u starom BMS-u redovito zagušivala popis aktivnih incidenata i ometala operativni rad. Samu logiku i bojnu diferencijaciju obavijesti smatrali smo uspješnom i zadržali, no u tehničkom zadatku smo posebno naznačili da 'plave' obavijesti trebaju, bez ometanja dežurnih, nečujno 'padati' u zaseban odjeljak, gdje će s njima raditi komercijalni stručnjaci.
Slična razina detaljnosti opisivala je formate izrade grafova i izvođenja izvještaja, obrise sučelja, popis uređaja koji su trebali biti praćeni i još mnoštvo drugih stvari.
To je bio zaista kreativni rad triju radnih grupa – službe naručitelja, koja je diktirala svoje zahtjeve i uvjete; tehničkih stručnjaka s obje strane, čija je zadaća bila pretvoriti te uvjete u tehničku dokumentaciju; tima programera izvođača, koji su realizirali zahtjeve naručitelja prema razvijenoj tehničkoj dokumentaciji... Na kraju smo neka od naših neprincipijelnih zahtjeva prilagodili funkcionalnosti već postojećih platformi, dok je izvođač bio dužan dodatno ih napisati za nas.
Paralelni rad dvaju sustava
Došlo je vrijeme za realizaciju. U praksi to je značilo da dajemo izvođaču mogućnost da postavi prototip BMS-a u našem virtualnom oblaku i omogućavamo mrežni pristup svim uređajima koji zahtijevaju praćenje.
Pri tome nova sustav još nije bio spreman za rad. U ovoj fazi bilo nam je važno zadržati praćenje u starom sustavu i istovremeno omogućiti pristup uređajima novom sustavu. Nemoguće je normalno izgraditi sustav ne videći u njemu uređaje, koje zauzvrat ne možemo isključiti iz praćenja starim sustavom.
Je li moguće da uređaji istovremeno odgovore na upite dviju sustava, nije bilo očito bez stvarnih ispitivanja. Postojala je mogućnost da bi dvostruki istodobni upiti doveli do čestih odbijanja odgovora od strane uređaja i da bismo dobili brojne pogreške zbog nedostupnosti uređaja, što bi zauzvrat blokiralo rad starog sustava nadzora.
Mrežni odjel je postavio virtualne rute od prototipa nove BMS, raspoređene u oblaku, do uređaja, a dobili smo rezultate:
- uređaji povezani putem SNMP protokola praktički nisu ispadali iz veze zbog istodobnih pristupa,
- uređaji povezani putem gateway-a preko modbas-TCP protokola imali su problema koji su riješeni razumnim smanjenjem učestalosti njihovih upita.
A zatim smo počeli promatrati kako se pred našim očima gradi novi sustav, u njemu se pojavljuju već poznati uređaji, ali u drugom sučelju – praktičnom, brzim, dostupnom čak i s telefona.
O tome što je konačno uspjelo, pričat ćemo u trećem dijelu našeg članka.
Izvor: habr.com
