In a prima parte, avemu parlatu perchè avemu decisu di rimpiazzà u vechju sistema BMS in i nostri centri di dati cù un novu. È micca solu cambià, ma sviluppate da zero per adattà à i vostri bisogni. In a seconda parte vi dicu cumu avemu fattu.
Analisi di Mercatu
Tenendu in contu quelli descritti in i desideri è a decisione di ricusà di aghjurnà u sistema esistente, avemu scrittu una specificazione tecnica per truvà una suluzione nantu à u mercatu è hà fattu dumande à parechje grande cumpagnie impegnate solu in a creazione di sistemi SCADA industriali.
I primi risposti da elli anu dimustratu chì i capi di u mercatu di i sistemi di surviglianza cuntinueghjanu principarmenti à travaglià in i servitori di hardware, ancu s'è u prucessu di migrazione à i nuvuli in questu segmentu hè digià principiatu. In quantu à riservà e macchine virtuali, nimu hà supportatu sta opzione. Inoltre, ci era un sintimu chì nimu di i sviluppatori visibili nantu à u mercatu ùn anu ancu dimustratu una cunniscenza di a necessità di redundanza: "u nuvulu ùn hè micca cascatu" era a risposta più cumuna. In fatti, ci sò stati pruposti di mette u monitoraghju di u centru di dati in un nuvulu situatu fisicamente in u stessu centru di dati.
Quì avemu bisognu di fà una piccula digressione nantu à u prucessu di selezzione di un cuntrattu. U prezzu, sicuru, importa, ma durante ogni licitazione per l'implementazione di un prughjettu cumplessu, in u stadiu di dialogu cù i fornituri, cuminciate à sente quale di i candidati hè più interessatu è capace di implementà.
Questu hè soprattuttu notevuli nantu à prughjetti cumplessi.
Basatu nantu à a natura di e dumande di clarifying à e specificazioni tecniche, i cuntratturi ponu esse divisi in quelli chì anu interessatu à vende solu (a pressione standard di un direttore di vendita si sente) è quelli chì anu interessatu à sviluppà un pruduttu, avè intesu è capitu u cliente, rende constructive. mudificazione di e specificazioni tecniche ancu prima di l'scelta finali (ancu u veru risicu di migliurà e specificazioni tecniche di qualcunu altru è perde l'offerta), à a fine sò solu pronti à accettà una sfida prufessiunale è fà un bonu pruduttu.
Tuttu chistu ci hà fattu attentu à un sviluppatore lucale relativamente chjucu - u gruppu di cumpagnie Sunline, chì hà rispostu à a maiò parte di i nostri bisogni immediatamente è era prontu à implementà tutti i bisogni riguardanti u novu BMS.
Risichi
Mentre chì i grandi attori cercanu di capisce ciò chì vulemu è purtendu una currispundenza tranquilla cun noi chì implicanu specialisti di livellu pre-vendita, u sviluppatore lucale hà pianificatu una riunione in u nostru uffiziu cù a participazione di a so squadra tecnica. In questa riunione, u cuntrattu hà dimustratu una volta a so vuluntà di participà à u prugettu è, più impurtante, spiegò cumu u sistema necessariu serà implementatu.
Prima di a riunione, avemu vistu dui risichi di travaglià cù una squadra chì ùn hà micca e risorse di una grande cumpagnia naziunale o internaziunale daretu à questu:
- I spezialisti puderanu sopravvalutà e so capacità è, in u risultatu, simpricimenti fallenu à affruntà; per esempiu, utilizanu software cumplessu o cuncepisce algoritmi di riservazione impraticabili.
- Dopu chì u prugettu hè finitu, u gruppu di u prughjettu pò disintegrate è, per quessa, u sustegnu di u produttu serà in periculu.
Per minimizzà questi risichi, avemu invitatu i nostri propri specialisti di sviluppu à a riunione. L'impiegati di l'imprenditori potenziali sò stati intervistati accuratamente nantu à ciò chì u sistema hè basatu, cumu a redundanza hè prevista per esse implementata, è altri prublemi in quale noi, cum'è un serviziu di operazione, ùn sò micca abbastanza competenti.
U verdict era pusitivu: l'architettura di a piattaforma BMS esistente hè muderna, simplice è affidabile, pò esse migliurata, u schema di ridondanza pruposta è di sincronizazione hè logica è praticabile.
U primu risicu hè statu trattatu. U sicondu hè statu escludutu dopu avè ricivutu a cunferma da u cuntrattu chì eranu pronti à trasfiriri u codice fonte di u sistema è a documentazione à noi, è ancu scegliendu a lingua di prugrammazione Python, chì era ben cunnisciuta da i nostri specialisti. Questu ci hà garantitu l'uppurtunità di mantene u sistema nantu à u nostru propiu senza difficultà è un longu periodu di furmazione di l'impiegati in casu di a cumpagnia di sviluppu abbandunà u mercatu.
Un vantaghju supplementu di a piattaforma era chì era implementata in cuntenituri Docker: u kernel, l'interfaccia web è a funzione di basa di dati di produttu in questu ambiente. Stu approcciu furnisce assai vantaghji, cumprese i paràmetri predefiniti per a più alta velocità di implementazione di a suluzione paragunata à l'aggiunta "classica" è faciule di novi dispositi à u sistema. U principiu "tutti inseme" simplificà l'implementazione di u sistema quantu pussibule: solu unpack u sistema è pudete immediatamente aduprà.
Cù sta suluzione, hè più faciule per fà copie di u sistema, è pudete migliurà è implementà l'aghjurnamenti in un ambiente separatu, senza piantà l'operazione di a suluzione in tuttu.
Quandu i dui risichi sò stati minimizati, u cuntrattu hà furnitu u CP. Copre tutti i paràmetri più impurtanti di u sistema BMS per noi.
Riservazione
U novu sistema BMS avia da esse situatu in u nuvulu, nantu à una macchina virtuale.
Nisun hardware, senza servitori è tutti l'inconvenienti è i risichi assuciati à stu mudellu di implementazione - a suluzione nuvola ci hà permessu di sbarazzarsi di elli per sempre. Hè statu decisu chì u sistema operarà in a nostra nuvola in dui siti di centru di dati in San Petruburgu è Mosca. Quessi sò dui sistemi cumpletamente funziunali chì operanu in modu di standby attivu cù accessu à tutti i specialisti autorizati.
I dui sistemi si assicuranu l'un l'altru, furnisce una riserva completa di u putere di calculu è di i canali di trasmissione di dati. E misure di sicurezza supplementari sò state cunfigurate ancu, cumprese a copia di salvezza di dati è canali, sistemi, macchine virtuali in generale, è una copia di salvezza di basa di dati separata una volta à u mese (a risorsa più preziosa in termini di gestione è analisi).
Nota chì a redundanza cum'è una opzione in a suluzione BMS hè stata sviluppata apposta per a nostra dumanda. U schema di riservazione stessu pareva cusì:
sustegnu
U puntu più impurtante per l'operazione efficace di una soluzione BMS hè u supportu tecnicu.
Tuttu hè simplice quì: un novu sistema ci costaria 35 000 rubles secondu questu indicatore. per mese per u SLA "risposta in 8 ore", vale à dì, 35 x 000 / 12 = $ 80 per annu. U primu annu hè liberu.
Per paragunà, mantene u vechju BMS da u venditore costa $ 18 annu cù un aumentu di a quantità per ogni novu dispositivu aghjuntu! À u listessu tempu, a cumpagnia ùn hà micca furnitu un manager dedicatu; tutta l'interazzione hè stata fatta per mezu di un direttore di vendita chì hè interessatu à noi cum'è un cumpratore potenziale cù un enfasi currispundente in u trattamentu di e dumande.
Per menu soldi, avemu ricevutu un sustegnu tutale di u produttu, cù un gestore di contu chì participava à u sviluppu di u produttu, cù un puntu d'entrata unicu, etc. U supportu hè diventatu assai più flessibile - grazia à l'accessu direttu à i sviluppatori per aghjustamenti pronti à qualsiasi aspettu di u sistema, integrazione via API, etc.
Updi
Sicondu u CP propositu in u novu BMS, tutti l'aghjurnamenti sò inclusi in u costu di supportu, i.e. ùn hè micca bisognu di pagamentu supplementu. L'eccezzioni hè u sviluppu di funziunalità supplementari oltre ciò chì hè specificatu in e specificazioni tecniche.
U vechju sistema necessitava pagamentu per l'aghjurnamenti di firmware (cum'è Java) è per correzioni di bug. Hè impussibile di ricusà questu; in l'absenza di l'aghjurnamenti, u sistema in tuttu "rallentatu" per via di e versioni antichi di cumpunenti interni.
E, sicuru, era impussibile d'aghjurnà u software senza cumprà un pacchettu di supportu.
Approcciu flexible
Un altru requisitu fundamentale riguardava l'interfaccia. Vulemu furnisce l'accessu à questu via un navigatore web da ogni locu, senza a presenza obligatoria di un ingegnere nantu à u territoriu di u centru di dati. Inoltre, avemu cercatu di creà una interfaccia animata per chì a dinamica di l'infrastruttura sia più chjara à l'ingegneri di turnu.
Ancu in u novu sistema era necessariu di furnisce un supportu per e formule per u calculu di l'operazione di sensori virtuali in sistemi di ingegneria - per esempiu, per a distribuzione ottima di l'energia elettrica in i rack di l'equipaggiu. Per fà questu, avete bisognu à avè à a vostra dispusizione tutte l'operazioni matematiche usuali applicabili à l'indicatori di sensori.
In seguitu, l'accessu à una basa di dati SQL era necessariu cù a capacità di piglià da ellu i dati necessarii nantu à u funziunamentu di l'equipaggiu - vale à dì, tutti i registri di surviglianza di dui mila dispusitivi è dui mila sensori virtuali chì generanu circa 20 mila variàbili.
Un modulu di cuntabilità di l'equipaggiu di rack era ancu necessariu, chì furnisce una rapprisintazioni gràfica di l'arrangiamentu di i dispositi in ogni unità cù u calculu di u pesu tutale di u hardware, mantenendu una biblioteca di dispusitivi è infurmazioni detallate nantu à ogni elementu.
Approvazione di specificazioni tecniche è firma di un accordu
À l'epica quandu era necessariu di principià u travagliu nantu à u novu sistema, a currispundenza cù l'imprese "grandi" era sempre assai luntanu da discutiri u costu di e so pruposte, cusì avemu paragunatu u CP ricevutu cù i costi di l'aghjurnamentu di u vechju BMS (vede. ), è in u risultatu, hè diventatu più attraente in u prezzu è risponde à i nostri bisogni.
A scelta hè stata fatta.
Dopu avè sceltu un cuntrattu, l'avucati cuminciaru à scrive un accordu, è e squadre tecniche da i dui lati cuminciaru à pulisce e specificazioni tecniche. Comu sapete, e specificazioni tecniche detallate è competenti sò a basa per u successu di ogni travagliu. U più specifichi ci sò in e specificazioni tecniche, menu delusioni cum'è "ma questu ùn hè micca ciò chì vulemu".
Daraghju dui esempi di u livellu di dettagliu di i requisiti in e specificazioni tecniche:
- I centri di dati nantu à u duvere sò abilitati per aghjunghje novi dispositi à u BMS, a maiò parte di questi sò PDU. In u vechju BMS, questu era u nivellu di "amministratore", chì hà ancu permessu di cambià i paràmetri variabili di tutti i dispositi, è era impussibile di separà e funzioni. Questu ùn ci cunvene micca. In a versione basica esistente di a nova piattaforma, u schema era simile. Avemu subitu indicatu in i termini di riferimentu chì vulemu separà questi roli: solu un impiigatu autorizatu deve cambià i paràmetri, ma quelli chì sò in turnu duveranu cuntinuà à pudè aghjunghje i dispositi. Stu schema hè statu accettatu per a implementazione.
- In ogni BMS standard ci sò trè categurie tipiche di notificazioni: RED - deve esse rispostu immediatamente, YELLOW - pò esse osservatu, BLUE - "Informativu". Avemu tradizionalmente utilizatu alerti blu per monitorà quandu i paràmetri di l'affari sò stati superati, cum'è u rack di un cliente chì supera u so limitu di capacità. Stu tipu di notizia in u nostru casu era destinatu à i gestori è ùn era micca d'interessu à u serviziu di l'operazioni, ma in l'antica BMS hà regularmente infundatu a lista di incidenti attivi è interferiscenu cù u travagliu operativu. Avemu cunsideratu a stessa logica è a differenziazione di u culore di i pantaloni di notificazione per esse successu è l'hà ritenutu, in ogni modu, e specificazioni tecniche indicanu specificamente chì e notificazioni "blu" duveranu, senza distractà l'ufficiali di serviziu, "pour" in silenziu in una sezione separata, induve si sarà trattatu da specialisti cummirciali.
Cù un gradu simili di dettagliu, i formati per a custruzzione di gràfiche è a generazione di rapporti, i contorni di l'interfaccia, a lista di i dispositi chì deve esse monitoratu, è parechje altre cose sò state prescritte.
Questu era un travagliu veramente criativu di trè gruppi di travagliu - u serviziu di u cliente, chì dettava e so esigenze è e cundizioni; specialisti tecnichi da i dui lati, chì u so compitu era di trasfurmà sti cundizioni in documentazioni tecniche; squadre di prugrammaturi di u cuntrattu chì implementanu i bisogni di u cliente secondu a documentazione tecnica sviluppata ... In u risultatu, avemu adattatu alcuni di i nostri bisogni senza principii à a funziunalità di una piattaforma esistente, è u cuntrattu hà impegnatu à aghjunghje qualcosa per noi.
Funzionamentu parallelu di dui sistemi
Hè u tempu di implementazione. In pratica, questu significava chì demu à u cuntrattu l'uppurtunità di implementà un prototipu BMS in u nostru nuvola virtuale è furnisce l'accessu à a rete à tutti i dispositi chì necessitanu monitoraghju.
Tuttavia, u novu sistema ùn era ancu prontu per u funziunamentu. À questu stadiu, era impurtante per noi di mantene a surviglianza in u vechju sistema è à u stessu tempu dà accessu à i dispositi à u novu sistema. Hè impussibile di custruisce bè un sistema senza vede i dispositi in questu, chì à u turnu ùn pò micca esse disattivatu da u monitoraghju da u vechju sistema.
Sia chì i dispositi puderanu sustene l'interrogazione simultanea da dui sistemi ùn era micca evidenti senza teste reali. Ci era una pussibilità chì u duppiu sondaghju simultanea porta à i rifiuti frequenti di risponde da i dispusitivi è ricevemu assai errori in quantu à l'indisponibilità di i dispusitivi, chì à u turnu bloccà u funziunamentu di u vechju sistema di surviglianza.
U dipartimentu di a rete hà realizatu rotte virtuali da un prototipu di u novu BMS implementatu in u nuvulu à i dispositi, è avemu avutu i risultati:
- i dispusitivi cunnessi via u protokollu SNMP praticamente ùn sò mai stati disconnected per via di richieste simultanee,
- i dispusitivi cunnessi attraversu gateway chì utilizanu protokolli modbas-TCP anu avutu prublemi chì sò stati risolti riduzzione intelligente di a so frequenza di votazione.
E dopu avemu cuminciatu à osservà cumu un novu sistema hè statu custruitu davanti à i nostri ochji, i dispusitivi digià familiari per noi apparsu in questu, ma in una interfaccia sfarente - cunvene, veloce, accessibile ancu da un telefunu.
Vi cuntaremu ciò chì hè accadutu à a fine in a terza parte di u nostru articulu.
Source: www.habr.com