Na primeira parte, falamos sobre por que decidimos substituír o antigo sistema BMS dos nosos centros de datos por un novo. E non só cambia, senón que desenvólvese desde cero para adaptarse ás túas necesidades. Na segunda parte contámosvos como o fixemos.
Análise de mercado
Tendo en conta os descritos en desexos e a decisión de rexeitar actualizar o sistema existente, escribimos unha especificación técnica para atopar unha solución no mercado e fixemos consultas a varias grandes empresas dedicadas só á creación de sistemas SCADA industriais.
As primeiras respostas deles mostraron que os líderes do mercado dos sistemas de monitorización seguen traballando principalmente en servidores de hardware, aínda que o proceso de migración ás nubes neste segmento xa comezou. En canto á reserva de máquinas virtuais, ninguén admitía esta opción. Ademais, había a sensación de que ningún dos desenvolvedores destacados do mercado demostraba sequera comprender a necesidade da redundancia: "a nube non está caendo" era a resposta máis común. De feito, ofrecéronnos colocar a monitorización do centro de datos nunha nube situada fisicamente no mesmo centro de datos.
Aquí temos que facer unha pequena digresión sobre o proceso de selección dun contratista. O prezo, por suposto, importa, pero durante calquera licitación para a execución dun proxecto complexo, na fase de diálogo cos provedores, comeza a sentir cal dos candidatos está máis interesado e capaz de implementalo.
Isto é especialmente notable en proxectos complexos.
En función da natureza de aclarar cuestións ás especificacións técnicas, os contratistas pódense dividir en aqueles interesados en vender simplemente (séntase a presión estándar dun xestor de vendas) e aqueles interesados en desenvolver un produto, ter escoitado e entendido ao cliente, facendo construtivo. modificacións das especificacións técnicas incluso antes da elección final (a pesar do risco real de mellorar as especificacións técnicas doutra persoa e perder a licitación), ao final simplemente están preparados para aceptar un reto profesional e facer un bo produto.
Todo isto fíxonos prestar atención a un desenvolvedor local relativamente pequeno: o grupo de empresas Sunline, que respondeu á maioría dos nosos requisitos de inmediato e estaba preparado para implementar todas as necesidades relativas ao novo BMS.
Riscos
Mentres os grandes xogadores trataban de entender o que queríamos e mantiñan correspondencia pausada connosco na que participaban especialistas en prevenda, o promotor local convocou unha reunión na nosa oficina coa participación do seu equipo técnico. Nesta xuntanza, o contratista volveu demostrar a súa vontade de participar no proxecto e, o máis importante, explicou como se implantaría o sistema requirido.
Antes da reunión, vimos dous riscos de traballar cun equipo que non conta cos recursos dunha gran empresa nacional ou internacional detrás:
- Os especialistas poderían sobreestimar as súas capacidades e, como resultado, simplemente non poden facer fronte; por exemplo, usarán software complexo ou deseñarán algoritmos de reserva inviables.
- Despois de completar o proxecto, o equipo do proxecto pode desintegrarse e, polo tanto, o soporte do produto estará en perigo.
Para minimizar estes riscos, invitamos á reunión aos nosos propios especialistas en desenvolvemento. Os posibles empregados do contratista foron entrevistados a fondo sobre en que se basea o sistema, como se planea implementar a redundancia e outras cuestións nas que nós, como servizo de operación, non somos o suficientemente competentes.
O veredicto foi positivo: a arquitectura da plataforma BMS existente é moderna, sinxela e fiable, pódese mellorar, o esquema de redundancia e sincronización proposto é lóxico e viable.
O primeiro risco foi tratado. O segundo foi excluído despois de recibir a confirmación do contratista de que estaban preparados para transferirnos o código fonte do sistema e a documentación, e tamén mediante a elección da linguaxe de programación Python, que era moi coñecida polos nosos especialistas. Isto garantiunos a oportunidade de manter o sistema pola nosa conta sen dificultades e un longo período de formación dos empregados no caso de que a empresa de desenvolvemento abandonase o mercado.
Unha vantaxe adicional da plataforma foi que se implementou en contedores Docker: o núcleo, a interface web e a función de base de datos de produtos neste ambiente. Este enfoque ofrece moitas vantaxes, incluíndo a configuración preestablecida para a maior velocidade de implantación da solución en comparación co "clásico" e a fácil adición de novos dispositivos ao sistema. O principio "todos xuntos" simplifica o máximo posible a implementación do sistema: só tes que descomprimir o sistema e podes usalo inmediatamente.
Con esta solución, é máis doado facer copias do sistema, e pode melloralo e implementar actualizacións nun ambiente separado, sen deter o funcionamento da solución no seu conxunto.
Unha vez minimizados os dous riscos, o contratista proporcionou o CP. Cubriu todos os parámetros máis importantes do sistema BMS para nós.
Reserva
O novo sistema BMS tiña que estar situado na nube, nunha máquina virtual.
Sen hardware, sen servidores e todos os inconvenientes e riscos asociados a este modelo de implantación: a solución na nube permitiunos desfacernos deles para sempre. Decidiuse que o sistema funcionaría na nosa nube en dous centros de datos en San Petersburgo e Moscova. Trátase de dous sistemas totalmente funcionais que funcionan en modo de espera activo con acceso a todos os especialistas autorizados.
Os dous sistemas asegúranse mutuamente, proporcionando unha reserva total tanto de potencia de cómputo como de canles de transmisión de datos. Tamén se configuraron medidas de seguridade adicionais, entre elas a copia de seguridade de datos e canles, sistemas, máquinas virtuais en xeral e unha copia de seguridade separada da base de datos unha vez ao mes (o recurso máis valioso en canto á xestión e análise).
Teña en conta que a redundancia como opción na solución BMS desenvolveuse especificamente para a nosa solicitude. O esquema de reserva en si quedou así:
Apoiar
O punto máis importante para o funcionamento eficaz dunha solución BMS é o soporte técnico.
Aquí todo é sinxelo: un novo sistema custaríanos 35 rublos segundo este indicador. ao mes para o SLA "resposta en 000 horas", é dicir, 8 x 35 / 000 = $ 12 ao ano. O primeiro ano é gratuíto.
A modo de comparación, o mantemento do antigo BMS do provedor custou 18 dólares ao ano cun aumento da cantidade de cada dispositivo novo engadido. Ao mesmo tempo, a empresa non proporcionou un xestor dedicado; toda a interacción tivo lugar a través dun xestor de vendas que está interesado en nós como potencial comprador coa correspondente énfase na tramitación das solicitudes.
Por menos diñeiro, recibimos soporte completo do produto, cun xestor de contas que participaría no desenvolvemento do produto, cun único punto de entrada, etc. O soporte fíxose moito máis flexible, grazas ao acceso directo aos desenvolvedores para axustes rápidos a calquera aspecto do sistema, integración mediante API, etc.
Actualizacións
Segundo o CP proposto no novo BMS, todas as actualizacións están incluídas no custo do soporte, é dicir. non requiren pago adicional. A excepción é o desenvolvemento de funcionalidades adicionais máis aló do especificado nas especificacións técnicas.
O sistema antigo requiría o pago tanto das actualizacións de firmware (como Java) como das correccións de erros. Era imposible rexeitalo; a falta de actualizacións, o sistema no seu conxunto "ralentouse" debido ás versións antigas dos compoñentes internos.
E, por suposto, era imposible actualizar o software sen mercar un paquete de soporte.
Enfoque flexible
Outro requisito fundamental foi a interface. Queriamos facilitar o acceso a el a través dun navegador web desde calquera lugar, sen a presenza obrigatoria dun enxeñeiro no territorio do centro de datos. Ademais, buscamos crear unha interface animada para que a dinámica da infraestrutura fose máis clara para os enxeñeiros de servizo.
Tamén no novo sistema foi necesario proporcionar soporte para fórmulas para calcular o funcionamento de sensores virtuais en sistemas de enxeñería, por exemplo, para a distribución óptima da enerxía eléctrica entre bastidores de equipos. Para iso, cómpre ter á súa disposición todas as operacións matemáticas habituais aplicables aos indicadores de sensores.
A continuación, requiríase o acceso a unha base de datos SQL coa capacidade de extraer dela os datos necesarios sobre o funcionamento do equipo, é dicir, todos os rexistros de vixilancia de dous mil dispositivos e dous mil sensores virtuais xerando aproximadamente 20 mil variables.
Tamén se necesitou un módulo de contabilidade de equipos de rack, que proporcione unha representación gráfica da disposición dos dispositivos en cada unidade con cálculo do peso total do hardware, mantendo unha biblioteca de dispositivos e información detallada de cada elemento.
Aprobación de pregos técnicos e sinatura de convenio
No momento en que era necesario comezar a traballar no novo sistema, a correspondencia coas "grandes" empresas aínda estaba moi lonxe de discutir o custo das súas propostas, polo que comparamos o CP recibido cos custos de actualización do antigo BMS (ver. ), e como resultado resultou ser máis atractivo no seu prezo e cumpriu os nosos requisitos.
A elección foi feita.
Despois de seleccionar un contratista, os avogados comezaron a elaborar un acordo e os equipos técnicos de ambas as partes comezaron a pulir as especificacións técnicas. Como sabedes, as especificacións técnicas detalladas e competentes son a base para o éxito de calquera traballo. Canto máis detalles haxa nas especificacións técnicas, menos decepcións como "pero isto non é o que queriamos".
Vou poñer dous exemplos do nivel de detalle dos requisitos nas especificacións técnicas:
- Os centros de datos de servizo están facultados para engadir novos dispositivos ao BMS, a maioría das veces son PDU. No antigo BMS, este era o nivel de "administrador", que tamén permitía cambiar a configuración variable de todos os dispositivos e era imposible separar as funcións. Isto non nos conviña. Na versión básica existente da nova plataforma, o esquema era similar. Inmediatamente indicamos nos termos de referencia que queriamos separar estes roles: só un empregado autorizado debería cambiar a configuración, pero os de servizo deberían seguir podendo engadir dispositivos. Este esquema foi aceptado para a súa implantación.
- En calquera BMS estándar hai tres categorías típicas de notificacións: VERMELLO - debe responderse inmediatamente, AMARELO - pódese observar, AZUL - "Informativo". Tradicionalmente utilizamos alertas azuis para supervisar cando se superaron os parámetros da empresa, como que o bastidor dun cliente supera o seu límite de capacidade. Este tipo de notificación no noso caso estaba destinada aos xestores e non era de interese para o servizo de operacións, pero no antigo BMS atascaba regularmente a lista de incidencias activas e interfería no traballo operativo. Consideramos que a propia lóxica e diferenciación de cores dos pantalóns de notificación foi exitosa e mantímola, non obstante, as especificacións técnicas indicaban especificamente que as notificacións "azuis" deberían, sen distraer aos axentes de servizo, "verter" silenciosamente nunha sección separada, onde se serán atendidos por especialistas comerciais.
Cun grao de detalle similar, prescribíronse os formatos para construír gráficos e xerar informes, os esquemas das interfaces, a lista de dispositivos que había que supervisar e moitas outras cousas.
Este foi un traballo verdadeiramente creativo de tres grupos de traballo: o de atención ao cliente, que ditou os seus requisitos e condicións; técnicos especialistas de ambas as partes, que tiñan como tarefa transformar estas condicións en documentación técnica; equipos de programadores contratistas que implementaron os requisitos do cliente segundo a documentación técnica desenvolvida... Como resultado, adaptamos algúns dos nosos requisitos sen principios á funcionalidade dunha plataforma existente e o contratista comprometeuse a engadir algo para nós.
Funcionamento en paralelo de dous sistemas
É o momento da implementación. Na práctica, isto significou que lle damos ao contratista a oportunidade de implantar un prototipo de BMS na nosa nube virtual e proporcionar acceso á rede a todos os dispositivos que requiran monitorización.
Non obstante, o novo sistema aínda non estaba listo para funcionar. Nesta fase, era importante para nós manter a monitorización no sistema antigo e ao mesmo tempo dar acceso aos dispositivos ao novo sistema. É imposible construír correctamente un sistema sen ver os dispositivos nel, que á súa vez non se poden desactivar para a supervisión do sistema antigo.
Se os dispositivos podían soportar a interrogación simultánea de dous sistemas non era obvio sen probas reais. Había a posibilidade de que a dobre votación simultánea levase a negativas frecuentes a responder desde os dispositivos e recibiríamos moitos erros en canto á indisponibilidade dos dispositivos, o que á súa vez bloquearía o funcionamento do antigo sistema de vixilancia.
O departamento de redes realizou rutas virtuais desde un prototipo do novo BMS despregado na nube ata os dispositivos, e obtivemos os resultados:
- os dispositivos conectados mediante o protocolo SNMP practicamente nunca se desconectaron debido a solicitudes simultáneas,
- os dispositivos conectados a través de pasarelas que usaban protocolos modbas-TCP tiñan problemas que se resolvían reducindo de forma intelixente a súa frecuencia de votación.
E entón comezamos a observar como se estaba construíndo un novo sistema ante os nosos ollos, aparecían nel aparecían dispositivos que xa nos coñecemos, pero nunha interface diferente: cómodo, rápido e accesible mesmo desde un teléfono.
Contarémosche o que pasou ao final na terceira parte do noso artigo.
Fonte: www.habr.com