Nella prima parte abbiamo parlato del motivo per cui abbiamo deciso di sostituire il vecchio sistema BMS nei nostri data center con uno nuovo. E non solo cambiare, ma sviluppare da zero per soddisfare le vostre esigenze. Nella seconda parte vi raccontiamo come abbiamo fatto.
Analisi di mercato
Tenendo conto di quelli descritti in desideri e la decisione di rifiutare di aggiornare il sistema esistente, abbiamo scritto una specifica tecnica per trovare una soluzione sul mercato e abbiamo chiesto informazioni a diverse grandi aziende impegnate solo nella creazione di sistemi SCADA industriali.
Le primissime risposte da parte loro hanno mostrato che i leader del mercato dei sistemi di monitoraggio continuano a lavorare principalmente su server hardware, sebbene il processo di migrazione verso i cloud in questo segmento sia già iniziato. Per quanto riguarda la prenotazione delle macchine virtuali, nessuno supportava questa opzione. Inoltre, si aveva la sensazione che nessuno degli sviluppatori visibili sul mercato dimostrasse di comprendere la necessità di ridondanza: “il cloud non cade” era la risposta più comune. In effetti, ci è stato offerto di collocare il monitoraggio del data center in un cloud situato fisicamente nello stesso data center.
Qui dobbiamo fare una piccola digressione sul processo di selezione di un appaltatore. Il prezzo, ovviamente, conta, ma durante qualsiasi gara per la realizzazione di un progetto complesso, nella fase di dialogo con i fornitori, si inizia a sentire quale dei candidati è più interessato e capace di realizzarlo.
Ciò è particolarmente evidente nei progetti complessi.
In base alla natura delle domande chiarificatrici delle specifiche tecniche, gli appaltatori possono essere divisi in quelli interessati semplicemente a vendere (si sente la normale pressione di un responsabile commerciale) e quelli interessati a sviluppare un prodotto, avendo ascoltato e compreso il cliente, rendendosi costruttivo modifiche alle specifiche tecniche ancor prima della scelta finale (anche nonostante il rischio concreto di migliorare le specifiche tecniche di qualcun altro e perdere la gara), alla fine sono semplicemente pronti ad accettare una sfida professionale e realizzare un buon prodotto.
Tutto ciò ci ha portato a prestare attenzione a uno sviluppatore locale relativamente piccolo, il gruppo di società Sunline, che ha risposto immediatamente alla maggior parte delle nostre esigenze ed era pronto a implementare tutte le esigenze relative al nuovo BMS.
Rischi
Mentre i grandi player cercavano di capire cosa volevamo e intrattenevano con noi una piacevole corrispondenza coinvolgendo specialisti a livello di prevendita, lo sviluppatore locale ha programmato un incontro nel nostro ufficio con la partecipazione del suo team tecnico. Durante questo incontro, l'appaltatore ha dimostrato ancora una volta il suo desiderio di partecipare al progetto e, soprattutto, ha spiegato come sarebbe stato implementato il sistema richiesto.
Prima dell’incontro, abbiamo visto due rischi nel lavorare con un team che non ha alle spalle le risorse di una grande azienda nazionale o internazionale:
- Gli specialisti potrebbero sopravvalutare le proprie capacità e, di conseguenza, semplicemente non riuscire a farcela; ad esempio, utilizzeranno software complessi o progetteranno algoritmi di prenotazione irrealizzabili.
- Una volta completato il progetto, il team di progetto potrebbe disintegrarsi e, pertanto, il supporto del prodotto sarà in pericolo.
Per ridurre al minimo questi rischi, abbiamo invitato all'incontro i nostri specialisti di sviluppo. I dipendenti del potenziale appaltatore sono stati intervistati approfonditamente su ciò su cui si basa il sistema, su come è prevista l'implementazione della ridondanza e su altre questioni in cui noi, come servizio operativo, non siamo sufficientemente competenti.
Il verdetto è stato positivo: l'architettura della piattaforma BMS esistente è moderna, semplice e affidabile, può essere migliorata, lo schema di ridondanza e sincronizzazione proposto è logico e praticabile.
Il primo rischio è stato affrontato. Il secondo è stato escluso dopo aver ricevuto conferma da parte del contraente che era pronto a trasmetterci il codice sorgente del sistema e la documentazione, nonché scegliendo il linguaggio di programmazione Python, ben noto ai nostri specialisti. Ciò ci ha garantito la possibilità di mantenere il sistema da soli senza alcuna difficoltà e un lungo periodo di formazione dei dipendenti nel caso in cui la società di sviluppo lasciasse il mercato.
Un ulteriore vantaggio della piattaforma è che è stata implementata in contenitori Docker: il kernel, l'interfaccia web e il database dei prodotti funzionano in questo ambiente. Questo approccio offre numerosi vantaggi, tra cui impostazioni preimpostate per la massima velocità di implementazione della soluzione rispetto a quella “classica” e facile aggiunta di nuovi dispositivi al sistema. Il principio “tutti insieme” semplifica al massimo l'implementazione del sistema: basta disimballare il sistema e potrete utilizzarlo immediatamente.
Con questa soluzione è più semplice creare copie del sistema ed è possibile migliorarlo e implementare aggiornamenti in un ambiente separato, senza interrompere il funzionamento della soluzione nel suo insieme.
Una volta ridotti al minimo entrambi i rischi, l'appaltatore ha fornito il CP. Per noi ha coperto tutti i parametri più importanti del sistema BMS.
Prenotazione
Il nuovo sistema BMS doveva essere collocato nel cloud, su una macchina virtuale.
Nessun hardware, nessun server e tutti gli inconvenienti e i rischi associati a questo modello di implementazione: la soluzione cloud ci ha permesso di eliminarli per sempre. È stato deciso che il sistema avrebbe funzionato nel nostro cloud in due data center a San Pietroburgo e Mosca. Si tratta di due sistemi completamente funzionanti che operano in modalità standby attivo con accesso a tutti gli specialisti autorizzati.
I due sistemi si assicurano a vicenda, garantendo la riserva completa sia della potenza di calcolo che dei canali di trasmissione dei dati. Sono state inoltre configurate ulteriori misure di sicurezza, tra cui il backup di dati e canali, sistemi, macchine virtuali in generale, ed un backup separato del database una volta al mese (la risorsa più preziosa in termini di gestione e analisi).
Tieni presente che la ridondanza come opzione nella soluzione BMS è stata sviluppata appositamente per la nostra richiesta. Lo schema di prenotazione stesso era simile al seguente:
Sostegno
Il punto più importante per il funzionamento efficace di una soluzione BMS è il supporto tecnico.
Qui tutto è semplice: secondo questo indicatore, il nuovo sistema ci costerebbe 35 rubli. al mese per lo SLA “risposta entro 000 ore”, ovvero 8 x 35 / 000 = $ 12 all'anno. Il primo anno è gratuito.
Per fare un confronto, la manutenzione del vecchio BMS presso il fornitore costa $ 18 all'anno con un aumento dell'importo per ogni nuovo dispositivo aggiunto! Allo stesso tempo, l'azienda non ha fornito un manager dedicato; tutta l'interazione è avvenuta tramite un responsabile delle vendite che è interessato a noi come potenziale acquirente con una corrispondente enfasi nell'elaborazione delle richieste.
Per meno soldi, abbiamo ricevuto supporto completo sul prodotto, con un account manager che avrebbe preso parte allo sviluppo del prodotto, con un unico punto di accesso, ecc. Il supporto è diventato molto più flessibile, grazie all'accesso diretto agli sviluppatori per modifiche tempestive a qualsiasi aspetto del sistema, integrazione tramite API, ecc.
Aggiornamenti
Secondo la CP proposta nel nuovo BMS, tutti gli aggiornamenti sono inclusi nel costo del supporto, ovvero non richiedono un pagamento aggiuntivo. L'eccezione è lo sviluppo di funzionalità aggiuntive oltre a quanto specificato nelle specifiche tecniche.
Il vecchio sistema richiedeva il pagamento sia per gli aggiornamenti del firmware (come Java) che per le correzioni dei bug. Era impossibile rifiutarlo, in assenza di aggiornamenti il sistema nel suo insieme “rallentava” a causa delle vecchie versioni dei componenti interni.
E, naturalmente, era impossibile aggiornare il software senza acquistare un pacchetto di supporto.
Approccio flessibile
Un altro requisito fondamentale riguardava l'interfaccia. Volevamo fornirne l'accesso tramite un browser web da qualsiasi luogo, senza la presenza obbligatoria di un tecnico sul territorio del data center. Inoltre, abbiamo cercato di creare un'interfaccia animata in modo che le dinamiche dell'infrastruttura fossero più chiare agli ingegneri in servizio.
Anche nel nuovo sistema era necessario fornire supporto per le formule per il calcolo del funzionamento dei sensori virtuali nei sistemi di ingegneria, ad esempio per la distribuzione ottimale dell'energia elettrica tra i rack delle apparecchiature. Per fare ciò, è necessario avere a disposizione tutte le consuete operazioni matematiche applicabili agli indicatori dei sensori.
Successivamente è stato richiesto l'accesso a un database SQL con la possibilità di estrarre da esso i dati necessari sul funzionamento dell'apparecchiatura, vale a dire tutte le registrazioni di monitoraggio di duemila dispositivi e duemila sensori virtuali che generano circa 20mila variabili.
Era inoltre necessario un modulo di contabilità delle apparecchiature rack, che fornisse una rappresentazione grafica della disposizione dei dispositivi in ciascuna unità con il calcolo del peso totale dell'hardware, mantenendo una libreria di dispositivi e informazioni dettagliate su ciascun elemento.
Approvazione delle specifiche tecniche e firma di un accordo
Nel momento in cui è stato necessario iniziare a lavorare sul nuovo sistema, la corrispondenza con le “grandi” aziende era ancora molto lontana dal discutere il costo delle loro proposte, quindi abbiamo confrontato il CP ricevuto con i costi di aggiornamento del vecchio BMS (vedi. ) e di conseguenza si è rivelato più interessante in termini di prezzo e ha soddisfatto le nostre esigenze.
La scelta è stata fatta
Dopo aver selezionato un appaltatore, gli avvocati hanno iniziato a stilare un accordo e i team tecnici di entrambe le parti hanno iniziato a perfezionare le specifiche tecniche. Come sapete, specifiche tecniche dettagliate e competenti sono la base per il successo di qualsiasi lavoro. Più specifiche ci sono nelle specifiche tecniche, meno delusioni del tipo “ma non è quello che volevamo”.
Fornirò due esempi del livello di dettaglio dei requisiti nelle specifiche tecniche:
- I data center in servizio hanno il potere di aggiungere nuovi dispositivi al BMS, molto spesso si tratta di PDU. Nel vecchio BMS questo era il livello “amministratore”, che permetteva anche di modificare le impostazioni variabili di tutti i dispositivi, ed era impossibile separare le funzioni. Questo non ci andava bene. Nella versione base esistente della nuova piattaforma, lo schema era simile. Abbiamo subito indicato nel capitolato d'oneri che volevamo separare questi ruoli: solo un dipendente autorizzato dovrebbe modificare le impostazioni, ma chi è in servizio dovrebbe continuare a poter aggiungere dispositivi. Questo schema è stato accettato per l'implementazione.
- In qualsiasi BMS standard esistono tre categorie tipiche di notifiche: ROSSO - è necessario rispondere immediatamente, GIALLO - può essere osservato, BLU - “Informativo”. Tradizionalmente utilizziamo gli avvisi blu per monitorare quando i parametri aziendali vengono superati, ad esempio se il rack di un cliente supera il limite di capacità. Questo tipo di notifica nel nostro caso era destinata ai manager e non interessava il servizio operativo, ma nel vecchio BMS intasava regolarmente l'elenco degli incidenti attivi e interferiva con il lavoro operativo. Abbiamo ritenuto che la logica stessa e la differenziazione dei colori dei pantaloni di notifica fossero un successo e l'abbiamo mantenuta, tuttavia, le specifiche tecniche indicavano specificamente che le notifiche "blu" dovrebbero, senza distrarre gli ufficiali di servizio, "versarsi" silenziosamente in una sezione separata, dove saranno trattati da specialisti commerciali.
Con un simile grado di dettaglio furono prescritti i formati per costruire grafici e generare report, i contorni delle interfacce, l'elenco dei dispositivi che dovevano essere monitorati e molte altre cose.
Questo è stato un lavoro veramente creativo di tre gruppi di lavoro: il servizio clienti, che ha dettato le sue esigenze e condizioni; specialisti tecnici di entrambe le parti, il cui compito era trasformare queste condizioni in documentazione tecnica; squadre di programmatori appaltatori che hanno implementato i requisiti del cliente in base alla documentazione tecnica sviluppata... Di conseguenza, abbiamo adattato alcuni dei nostri requisiti senza principi alla funzionalità di una piattaforma esistente e l'appaltatore si è impegnato ad aggiungere qualcosa per noi.
Funzionamento in parallelo di due sistemi
È tempo di implementazione. In pratica, ciò significava dare al contraente l'opportunità di implementare un prototipo BMS nel nostro cloud virtuale e fornire l'accesso alla rete a tutti i dispositivi che richiedono monitoraggio.
Tuttavia, il nuovo sistema non era ancora pronto per l’uso. In questa fase per noi era importante mantenere il monitoraggio nel vecchio sistema e allo stesso tempo consentire l'accesso ai dispositivi nel nuovo sistema. È impossibile costruire correttamente un sistema senza vedere i dispositivi al suo interno, che a loro volta non possono essere disabilitati dal monitoraggio da parte del vecchio sistema.
Se i dispositivi potessero resistere a interrogazioni simultanee da parte di due sistemi non era ovvio senza test reali. Esisteva la possibilità che il doppio polling simultaneo portasse a frequenti rifiuti di risposta da parte dei dispositivi e che ricevessimo molti errori riguardanti l'indisponibilità dei dispositivi, che a loro volta bloccherebbero il funzionamento del vecchio sistema di monitoraggio.
Il dipartimento di rete ha eseguito percorsi virtuali da un prototipo del nuovo BMS distribuito nel cloud ai dispositivi e abbiamo ottenuto i risultati:
- i dispositivi collegati tramite il protocollo SNMP non si sono praticamente mai disconnessi a causa di richieste simultanee,
- i dispositivi collegati tramite gateway utilizzando i protocolli modbas-TCP presentavano problemi che sono stati risolti riducendo in modo intelligente la frequenza di polling.
E poi abbiamo iniziato a osservare come si stava costruendo un nuovo sistema davanti ai nostri occhi, in esso apparivano dispositivi a noi già familiari, ma in un'interfaccia diversa: comoda, veloce, accessibile anche da un telefono.
Vi racconteremo cosa è successo alla fine nella terza parte del nostro articolo.
Fonte: habr.com