Nella prima parte abbiamo raccontato perché abbiamo deciso di sostituire il vecchio sistema BMS nei nostri DC con uno nuovo. E non solo sostituirlo, ma svilupparlo da zero secondo le nostre esigenze. Nella seconda parte raccontiamo come lo abbiamo fatto.
Analisi del mercato
Tenendo conto di quanto descritto in richieste e della decisione di rinunciare all'aggiornamento del sistema esistente, abbiamo redatto un piano per la ricerca di soluzioni sul mercato e abbiamo inviato richieste a diverse grandi aziende che si occupano esclusivamente della creazione di sistemi SCADA industriali.
Le prime risposte da parte loro hanno mostrato che i leader del mercato nei sistemi di monitoraggio continuano prevalentemente a lavorare su server fisici, anche se il processo di migrazione verso il cloud in questo segmento è già iniziato. Per quanto riguarda la virtualizzazione delle macchine – nessuno supportava questa opzione. Inoltre, si aveva l'impressione che nessuno tra i noti sviluppatori di mercato avesse nemmeno dimostrato di comprendere l'importanza della virtualizzazione: "il cloud non crolla mai" era la risposta più comune. Di fatto, ci veniva proposto di collocare il monitoraggio del DC nel cloud, fisicamente situato nello stesso DC.
È necessario fare una piccola digressione sul processo di scelta del fornitore. Il prezzo, certo, ha importanza, ma durante qualsiasi gara per l'attuazione di un progetto complesso, nella fase di dialogo con i fornitori, inizi a capire chi tra i candidati è più interessato e capace di realizzarlo.
Questo è particolarmente evidente nei progetti complessi.
In base alla natura delle domande di chiarimento al piano, è possibile suddividere i fornitori in quelli interessati semplicemente a vendere (si percepisce una pressione standard da parte del manager delle vendite) e in quelli interessati invece a sviluppare un prodotto, ascoltando e comprendendo il cliente, apportando modifiche costruttive al piano anche prima della scelta finale (anche nonostante il reale rischio di migliorare il piano di qualcun altro e perdere la gara), e, infine, pronti a raccogliere la sfida professionale e fare un buon prodotto.
Tutto questo ci ha portato a considerare un relativamente piccolo sviluppatore locale – il gruppo di aziende "Sunline", che ha risposto a gran parte delle nostre richieste fin da subito ed era pronto a soddisfare tutte le esigenze relative al nuovo BMS.
Rischi
Mentre i grandi attori cercavano di capire cosa volessimo e avevano scambi di corrispondenza tranquilli coinvolgendo specialisti di livello presale, un sviluppatore locale ha fissato un incontro nel nostro ufficio con la sua squadra tecnica. Durante questo incontro, l'appaltatore ha nuovamente dimostrato il desiderio di partecipare al progetto e, cosa principale, ha spiegato come il sistema richiesto sarà realizzato.
Prima dell'incontro, abbiamo identificato due rischi nel lavorare con un team che non ha alle spalle le risorse di una grande azienda nazionale o internazionale:
- Gli specialisti potrebbero aver sovrastimato le loro capacità e, di conseguenza, non riuscire a gestire il progetto, ad esempio, utilizzando software complessi o progettando algoritmi di prenotazione impraticabili.
- Dopo l'implementazione del progetto, il team potrebbe sciogliersi e, di conseguenza, il supporto del prodotto sarebbe a rischio.
Per minimizzare questi rischi, abbiamo invitato i nostri specialisti per lo sviluppo all'incontro. I dipendenti del potenziale appaltatore sono stati accuratamente interrogati riguardo a come è costruito il sistema, come si prevede di implementare la prenotazione e su altre questioni in cui, come servizio di exploitation, non siamo abbastanza competenti.
Il verdetto è stato positivo: l'architettura della piattaforma BMS esistente è moderna, semplice e affidabile, può essere migliorata, il piano di prenotazione e sincronizzazione proposto è logico e funzionante.
Abbiamo gestito il primo rischio. Il secondo è stato escluso, ottenendo dall'appaltatore la conferma della disponibilità a trasferirci il codice sorgente del sistema e la documentazione, oltre a scegliere il linguaggio di programmazione Python, ben noto ai nostri specialisti. Questo ci ha garantito la possibilità di mantenere il sistema autonomamente senza alcuna difficoltà e senza un lungo periodo di formazione per i dipendenti in caso di uscita della società di sviluppo dal mercato.
Un ulteriore vantaggio della piattaforma era il fatto che fosse realizzata in contenitori Docker: in questo ambiente funzionano il nucleo, l'interfaccia web e il database del prodotto. Questo approccio offre numerosi vantaggi, inclusa la pre-configurazione delle impostazioni per la massima velocità di distribuzione delle soluzioni rispetto alla "classica" e la semplice integrazione di nuovi dispositivi nel sistema. Il principio "tutto insieme" semplifica notevolmente l'implementazione del sistema: basta estrarre il sistema e può essere immediatamente utilizzato.
Con questa soluzione è più semplice effettuare copie del sistema, mentre il miglioramento e l'implementazione di aggiornamenti possono avvenire in un ambiente separato, senza interrompere il funzionamento della soluzione in generale.
Dopo che entrambi i rischi sono stati minimizzati, l'appaltatore ha fornito un preventivo. In esso sono stati elaborati tutti i parametri più importanti per noi del sistema BMS.
Ridondanza
Il nuovo sistema BMS doveva trovarsi nel cloud, su una macchina virtuale.
Niente hardware, nessun server e tutti i disagi e rischi associati a questo modello di distribuzione - la soluzione cloud ci ha permesso di liberarci di essi per sempre. È stato deciso che il sistema funzionerà nel nostro cloud su due sedi del data center a San Pietroburgo e Mosca. Questi sono due sistemi completamente funzionali, operanti in modalità active standby con accesso per tutti i professionisti autorizzati.
I due sistemi si garantiscono reciprocamente, assicurando pieno backup sia delle capacità di calcolo che dei canali di trasmissione dei dati. Sono state anche configurate misure di sicurezza aggiuntive, incluso il backup dei dati e dei canali, dei sistemi e delle macchine virtuali nel loro complesso, e un backup separato del database una volta al mese (la risorsa più preziosa in prospettiva di gestione e analisi).
Va notato che la riserva come opzione della soluzione BMS è stata sviluppata specificamente su nostra richiesta. Lo schema di riserva appariva in questo modo:
Supporto
Un aspetto fondamentale per un'efficace operatività della soluzione BMS è il supporto tecnico.
Qui è tutto semplice: il nuovo sistema ci costerebbe per questo parametro 35.000 rubli al mese per SLA "risposta entro 8 ore", ovvero 35.000 x 12 / 80 = 5.250 $ all'anno. Il primo anno è gratuito.
A titolo di confronto: il supporto per il vecchio BMS da parte del fornitore costava 18.000 dollari all'anno, con un aumento dell'importo per ogni nuovo dispositivo aggiunto! Inoltre, l'azienda non forniva un manager dedicato, tutte le interazioni avvenivano attraverso il manager delle vendite, il quale era interessato a noi come potenziali acquirenti con un corrispondente accento nella gestione delle richieste.
Per una cifra inferiore abbiamo ottenuto un supporto completo del prodotto, con un account manager che partecipava allo sviluppo del prodotto, con un unico punto di accesso, ecc. Il supporto è diventato di gran lunga più flessibile, grazie all'accesso diretto agli sviluppatori per correzioni tempestive su qualsiasi aspetto del funzionamento del sistema, integrazione tramite API, ecc.
Aggiornamenti
Secondo la proposta di offerta, nel nuovo BMS tutti gli aggiornamenti sono inclusi nel costo del supporto, quindi non richiedono pagamenti aggiuntivi. Fanno eccezione lo sviluppo di funzionalità aggiuntive, oltre a quelle indicate nel documento di specifica.
Il vecchio sistema prevedeva pagamenti sia per l'aggiornamento di software integrato gratuito (come Java), sia per la correzione di errori. Non era possibile fare a meno di questo; in assenza di aggiornamenti, il sistema in generale "rallentava" a causa delle vecchie versioni dei componenti interni.
E, ovviamente, non era possibile aggiornare il software senza acquistare un pacchetto di supporto.
Approccio flessibile
Un altro requisito fondamentale riguardava l'interfaccia. Volevamo garantire l'accesso attraverso un browser web da qualsiasi luogo, senza la necessità della presenza di un ingegnere presso il data center. Inoltre, miravamo a creare un'interfaccia animata, affinché la dinamica di funzionamento dell'infrastruttura fosse più visibile per gli ingegneri in servizio.
Inoltre, nel nuovo sistema era necessario garantire il supporto per formule per il calcolo del funzionamento di sensori virtuali nei sistemi ingegneristici, ad esempio, per la distribuzione ottimale delle potenze elettriche tra i rack con l'attrezzatura. A tal fine, era necessario avere a disposizione tutte le operazioni matematiche consuete, applicabili ai dati dei sensori.
Inoltre, era necessario avere accesso a un database SQL per poter estrarre i dati necessari sul funzionamento delle apparecchiature: in particolare, tutte le registrazioni di monitoraggio di duemila dispositivi e duemila sensori virtuali che generano circa 20.000 variabili.
Era inoltre necessario un modulo per la gestione delle apparecchiature nel rack, che fornisse una rappresentazione grafica della disposizione dei dispositivi in ogni unità, contando il peso totale dell'«hardware», mantenendo una libreria dei dispositivi e informazioni dettagliate su ogni elemento.
Conferma del capitolato e firma del contratto
Al momento in cui era necessario iniziare a lavorare sul nuovo sistema, la corrispondenza con le «grandi» aziende era ancora molto lontana dalla discussione sui costi delle loro proposte, quindi abbiamo confrontato l'offerta ricevuta con le spese per l'aggiornamento del vecchio BMS (vedi ), e alla fine si è rivelata più conveniente e conforme ai nostri requisiti.
La scelta è stata fatta.
Dopo la selezione dell'appaltatore, gli avvocati hanno iniziato a redigere il contratto, mentre i team tecnici di entrambe le parti affinavano il capitolato. Come è noto, un capitolato dettagliato e ben redatto è la base del successo di qualsiasi lavoro. Maggiore è la specificità nel capitolato, minori saranno le delusioni come «ma noi non volevamo così».
Fornirò due esempi del livello di dettaglio dei requisiti nel capitolato:
- Gli operatori del data center hanno il potere di aggiungere nuovi dispositivi al BMS, spesso si tratta di PDU. Nel vecchio BMS questo era il livello di «amministratore», che consentiva anche di modificare le impostazioni delle variabili di tutti i dispositivi, e non era possibile separare le funzioni. Questo non ci andava bene. Nella versione base attuale della nuova piattaforma la configurazione era simile. Abbiamo subito indicato nel capitolato che volevamo separare questi ruoli: solo un dipendente autorizzato deve poter modificare le impostazioni, mentre gli operatori devono comunque avere la possibilità di aggiungere dispositivi. Questa configurazione è stata accettata per l'implementazione.
- In ogni standard BMS ci sono tre categorie tipiche di notifiche: ROSSA – è necessario reagire immediatamente, GIALLA – può essere monitorata, BLU – «Informativa». Abbiamo tradizionalmente utilizzato le notifiche «blu» per monitorare il superamento dei parametri commerciali, ad esempio, il superamento del limite di potenza del rack del cliente. Questo tipo di notifiche, nel nostro caso, era destinato ai manager e non interessava il servizio operativo, ma nella vecchia BMS intasava regolarmente l'elenco degli incidenti attivi e ostacolava il lavoro operativo. Abbiamo ritenuto che la logica e la differenziazione cromatica delle notifiche siano state fortunate e le abbiamo mantenute; tuttavia, nel documento di specifiche abbiamo specificamente indicato che le notifiche «blu» dovevano, senza distrarre i turnisti, «cadere» silenziosamente in una sezione separata, dove sarebbero state gestite da specialisti commerciali.
Con un grado di dettaglio simile sono stati definiti i formati di costruzione dei grafici e di generazione dei rapporti, le contornature delle interfacce, l'elenco dei dispositivi da monitorare e molte altre cose.
È stato veramente un lavoro creativo di tre gruppi di lavoro - il servizio clienti, che dettava i propri requisiti e condizioni; esperti tecnici di entrambe le parti, il cui compito era trasformare queste condizioni in documentazione tecnica; il team di programmatori dell'appaltatore, che implementava i requisiti del cliente secondo la documentazione tecnica sviluppata... Alla fine, alcune delle nostre richieste non essenziali le abbiamo adattate alla funzionalità della piattaforma già esistente, mentre l'appaltatore si è impegnato a scriverne alcune per noi.
Funzionamento parallelo di due sistemi
È arrivato il momento dell'implementazione. Nella pratica ciò significava che davamo all'appaltatore la possibilità di sviluppare un prototipo della BMS nel nostro cloud virtuale e fornivamo accesso di rete a tutti i dispositivi che richiedevano monitoraggio.
A questo punto, tuttavia, il nuovo sistema non era ancora pronto per l'uso. In questa fase era importante per noi mantenere il monitoraggio nella vecchia sistema e allo stesso tempo dare accesso ai dispositivi al nuovo sistema. Non è possibile costruire un sistema correttamente senza vedere i dispositivi in esso, che a loro volta non possono essere disconnessi dal monitoraggio della vecchia sistema.
Se i dispositivi possono sopportare un interrogatorio simultaneo da due sistemi, era poco chiaro senza test reali. Esisteva la possibilità che un interrogatorio doppio simultaneo portasse a frequenti errori di risposta dai dispositivi, generando una serie di errori per l'inaccessibilità degli stessi, il che a sua volta avrebbe bloccato il funzionamento del vecchio sistema di monitoraggio.
Il reparto di rete ha configurato percorsi virtuali dal prototipo della nuova BMS, distribuito nel cloud, verso i dispositivi, e abbiamo ottenuto i seguenti risultati:
- i dispositivi collegati tramite il protocollo SNMP non sono praticamente mai disconnessi a causa di interrogazioni simultanee,
- i dispositivi collegati tramite gateway con protocolli modbus-TCP hanno avuto problemi, risolti con una ragionevole diminuzione della loro frequenza di interrogazione.
E poi abbiamo iniziato a osservare come si stesse costruendo un nuovo sistema davanti ai nostri occhi, con dispositivi già conosciuti che apparivano, ma in un'interfaccia diversa – comoda, veloce, accessibile anche da telefono.
Di ciò che è stato ottenuto alla fine, parleremo nella terza parte del nostro articolo.
Fonte: habr.com
