En la primera parte, hablamos sobre por qué decidimos cambiar nuestro antiguo sistema BMS en nuestros centros de datos por uno nuevo. Y no simplemente cambiarlo, sino desarrollarlo desde cero según nuestras necesidades. En la segunda parte, contamos cómo lo hicimos.
Análisis del mercado
Teniendo en cuenta lo descrito en las peticiones y la decisión de no actualizar el sistema existente, redactamos un pliego de condiciones para buscar soluciones en el mercado y enviamos solicitudes a varias grandes empresas que se dedican exclusivamente a crear sistemas SCADA industriales.
Las primeras respuestas de ellas mostraron que los líderes del mercado de sistemas de monitoreo continúan trabajando predominantemente en servidores físicos, aunque el proceso de migración a la nube en este segmento ya ha comenzado. En cuanto a la disponibilidad de máquinas virtuales, esta opción no era compatible con nadie. Además, daba la impresión de que ninguno de los desarrolladores destacados en el mercado demostraba siquiera comprensión sobre la necesidad de disponer de respaldo: «la nube no se cae» era la respuesta más frecuente. De hecho, nos ofrecieron alojar el monitoreo del centro de datos en una nube, físicamente ubicada en el mismo centro de datos.
Aquí es necesario hacer un pequeño paréntesis sobre el proceso de selección del contratista. El precio, por supuesto, importa, pero durante cualquier licitación para la implementación de un proyecto complicado, en la etapa de diálogo con los proveedores, comienzas a sentir quién de los candidatos está más interesado y es capaz de llevarlo a cabo.
Esto es especialmente evidente en proyectos complejos.
Por la naturaleza de las preguntas de clarificación sobre el pliego de condiciones, se pueden dividir a los contratistas en aquellos que están interesados simplemente en vender (se siente la presión estándar de un gerente de ventas) y en aquellos interesados en desarrollar un producto, escuchando y comprendiendo al cliente, haciendo correcciones constructivas en el pliego de condiciones incluso antes de la elección final (a pesar del riesgo real de mejorar un pliego de otro y perder la licitación), y en última instancia, simplemente dispuestos a aceptar el reto profesional y crear un buen producto.
Todo esto nos llevó a prestar atención a un desarrollador local relativamente pequeño: el grupo de empresas «Sanline», que respondió a la mayoría de nuestras demandas de inmediato y estaba dispuesto a satisfacer todas las necesidades respecto al nuevo BMS.
Riesgos
Mientras los grandes jugadores intentaban entender qué queríamos y mantenían una conversación pausada con la participación de especialistas de nivel preventa, un desarrollador local programó una reunión en nuestra oficina con la presencia de su equipo técnico. En esta reunión, el contratista demostró nuevamente su deseo de participar en el proyecto y, lo más importante, explicó cómo se implementará el sistema requerido.
Antes de la reunión, identificamos dos riesgos al trabajar con un equipo que no cuenta con el respaldo de una gran empresa nacional o internacional:
- Los especialistas podrían sobrestimar sus capacidades y, como resultado, no cumplir, por ejemplo, utilizar software complejo o diseñar algoritmos de reserva inviables.
- Tras la implementación del proyecto, el equipo podría disolverse y, por lo tanto, el soporte del producto estaría en riesgo.
Para mitigar estos riesgos, invitamos a nuestros propios especialistas en desarrollo a la reunión. Los empleados del potencial contratista fueron cuidadosamente interrogados sobre la base del sistema, cómo se planea implementar la reserva y otras cuestiones en las que, como servicio de operaciones, no somos suficientemente competentes.
El veredicto fue positivo: la arquitectura de la plataforma BMS existente es moderna, simple y confiable, puede ser mejorada, el esquema de reserva y sincronización propuesto es lógico y funcional.
Hicimos frente al primer riesgo. Eliminamos el segundo al recibir del contratista la confirmación de que estaban dispuestos a entregarnos el código fuente del sistema y la documentación, además de elegir el lenguaje de programación Python, bien conocido por nuestros especialistas. Esto nos garantizó la posibilidad de mantener el sistema por nuestra cuenta sin ninguna dificultad y sin un largo período de formación para los empleados en caso de que la empresa desarrolladora abandone el mercado.
Una ventaja adicional de la plataforma fue que estaba implementada en contenedores Docker: en este entorno funcionan el núcleo, la interfaz web y la base de datos del producto. Este enfoque ofrece numerosas ventajas, incluida la preconfiguración para una velocidad de despliegue más alta en comparación con la "clásica" y la fácil incorporación de nuevos dispositivos al sistema. El principio de "todo junto" simplifica al máximo la implementación del sistema: basta con descomprimir el sistema y se puede utilizar de inmediato.
Con esta solución, es más fácil hacer copias del sistema, y se pueden realizar mejoras y realizar actualizaciones en un entorno separado, sin interrumpir el funcionamiento de la solución en su conjunto.
Después de minimizar ambos riesgos, el contratista proporcionó la propuesta comercial. En ella se trabajaron todos los parámetros más importantes para nosotros del sistema BMS.
Redundancia
El nuevo sistema BMS debía estar en la nube, en una máquina virtual.
Sin hardware, sin servidores ni las incomodidades y riesgos asociados con este modelo de despliegue: la solución en la nube nos permitió deshacernos de ellos para siempre. Se decidió que el sistema funcionaría en nuestra nube en dos ubicaciones del centro de datos en San Petersburgo y Moscú. Estos son dos sistemas completamente funcionales que operan en modo activo en espera con acceso para todos los especialistas autorizados.
Los dos sistemas se respaldan mutuamente, garantizando completo respaldo tanto en capacidades computacionales como en canales de transmisión de datos. También se han configurado medidas de seguridad adicionales, incluidas las copias de seguridad de datos y canales, sistemas, máquinas virtuales en general, y copias de seguridad separadas de la base de datos una vez al mes (el recurso más valioso en la perspectiva de gestión y análisis).
Cabe destacar que el respaldo como opción de la solución BMS fue diseñado específicamente para nuestra solicitud. El esquema de respaldo se veía así:
Soporte
Un aspecto crucial para la operación efectiva de la solución BMS es el soporte técnico.
Aquí todo es simple: el nuevo sistema nos costaría 35,000 rublos al mes por este indicador bajo un SLA de "respuesta en 8 horas", es decir, 35,000 x 12 / 80 = $5,250 al año. El primer año es gratis.
Para comparación: el soporte del antiguo BMS por parte del proveedor costaba $18,000 al año, aumentando la cantidad por cada nuevo dispositivo agregado. Además, la empresa no proporcionaba un gerente dedicado; toda la interacción se realizaba a través del gerente de ventas, quien estaba más interesado en nosotros como potenciales compradores, lo que influía en la atención a nuestras solicitudes.
Por menos dinero, obtuvimos un soporte integral del producto, con un gerente de cuenta que participaría en el desarrollo del producto, con un único punto de contacto, etc. El soporte se volvió significativamente más flexible, gracias al acceso directo a los desarrolladores para ajustes operativos sobre cualquier aspecto del funcionamiento del sistema, integración a través de API, etc.
Actualizaciones
En la cotización presentada para el nuevo BMS, todas las actualizaciones están incluidas en el costo del soporte, es decir, no requieren pago adicional. La excepción son los desarrollos de funcionalidades adicionales, más allá de lo que se indica en las especificaciones.
El antiguo sistema requería pago tanto por la actualización del software gratuito integrado (como Java), como por la corrección de errores. No se podía renunciar a esto; sin actualizaciones, el sistema en general 'se ralentizaba' debido a las versiones antiguas de los componentes internos.
Y, por supuesto, no se podía actualizar el software sin comprar un paquete de soporte.
Enfoque flexible
Otro requisito fundamental tenía que ver con la interfaz. Queríamos asegurar el acceso a ella a través del navegador web desde cualquier lugar, sin la necesidad de que un ingeniero estuviera presente en las instalaciones del centro de datos. Además, buscábamos crear una interfaz animada para que la dinámica de funcionamiento de la infraestructura fuera más clara para los ingenieros de guardia.
Además, en el nuevo sistema se necesitaba garantizar el soporte de fórmulas para el cálculo del funcionamiento de sensores virtuales en sistemas de ingeniería, por ejemplo, para la distribución óptima de potencias eléctricas en los racks de equipos. Para ello, es necesario tener a disposición todas las operaciones matemáticas habituales aplicables a los indicadores de los sensores.
Luego, se requería acceso a la base de datos SQL con la capacidad de extraer la información necesaria sobre el funcionamiento del equipo; es decir, todos los registros de monitoreo de dos mil dispositivos y dos mil sensores virtuales, generando aproximadamente 20 mil variables.
También se necesitaba un módulo para el seguimiento del equipo en el rack, que proporcionara una representación gráfica de la ubicación de los dispositivos en cada unidad, calculando el peso total del 'hardware', manteniendo una biblioteca de dispositivos e información detallada sobre cada elemento.
Aprobación del pliego de condiciones y firma del contrato
En el momento en que era necesario comenzar a trabajar en el nuevo sistema, la correspondencia con las grandes empresas aún estaba muy lejos de discutir el costo de sus propuestas, por lo que comparamos la oferta recibida con los costos de actualización del viejo BMS (ver ), y como resultado, resultó ser más atractivo en precio y cumplir con nuestros requisitos.
Se tomó la decisión.
Después de elegir al contratista, los abogados comenzaron a redactar el contrato y los equipos técnicos de ambas partes a pulir el pliego de condiciones. Como es sabido, un pliego de condiciones detallado y bien estructurado es la base del éxito de cualquier trabajo. Cuanto más específico sea el pliego de condiciones, menos decepciones habrá como 'nosotros queríamos de otra manera'.
Voy a dar dos ejemplos del nivel de detalle de los requisitos en el pliego de condiciones:
- Los operadores del centro de datos tienen la autoridad para agregar nuevos dispositivos al BMS, siendo más frecuentes los PDU. En el viejo BMS, esto era a nivel de 'administrador', permitiendo también cambiar las configuraciones de todas las variables de los dispositivos, y dividir las funciones era imposible. Esto no nos satisfacía. En la versión básica existente de la nueva plataforma, el esquema era análogo. Inmediatamente indicamos en el pliego de condiciones que queríamos dividir estos roles: solo un empleado autorizado debe cambiar las configuraciones, pero los operadores deben seguir teniendo la opción de agregar dispositivos. Este esquema fue aceptado para su implementación.
- En cualquier BMS estándar hay tres categorías típicas de notificaciones: ROJA - requiere una respuesta inmediata, AMARILLA - se puede observar, AZUL - 'Informativa'. Tradicionalmente, utilizamos las notificaciones 'azules' para monitorear el exceso de parámetros comerciales, por ejemplo, el límite de potencia del rack del cliente. Este tipo de notificaciones en nuestro caso estaba destinado a los gerentes y no interesaba al servicio de operaciones, pero en el antiguo BMS saturaba regularmente la lista de incidentes activos y obstaculizaba el trabajo operativo. Consideramos exitosa la lógica y diferenciación de color de las notificaciones, y la mantuvimos, sin embargo, en los términos de referencia especificamos que las notificaciones 'azules' deben caer silenciosamente en una sección separada, donde serán atendidas por especialistas comerciales sin distraer a los de guardia.
Con un nivel de detalle similar se definieron los formatos para la elaboración de gráficos y la generación de informes, los contornos de las interfaces, la lista de dispositivos que debían ser monitoreados y muchas otras cosas.
Fue realmente un trabajo creativo de tres grupos de trabajo: el servicio del cliente, que dictó sus requisitos y condiciones; los especialistas técnicos de ambas partes, cuya tarea era transformar estas condiciones en documentación técnica; y el equipo de programadores del contratista, que implementó los requisitos del cliente según la documentación técnica desarrollada... Al final, algo de nuestros requisitos no críticos fue adaptado a la funcionalidad de la plataforma existente, y el contratista se comprometió a añadir algunas cosas para nosotros.
Trabajo paralelo de dos sistemas
Llegó el momento de la implementación. En la práctica, esto significaba que dábamos al contratista la oportunidad de desplegar un prototipo de BMS en nuestra nube virtual y proporcionamos acceso de red a todos los dispositivos que requieren monitoreo.
Sin embargo, el nuevo sistema aún no estaba listo para funcionar. En esta etapa, era importante para nosotros mantener el monitoreo en el antiguo sistema y al mismo tiempo proporcionar acceso a los dispositivos desde el nuevo sistema. No es posible construir un sistema adecuadamente sin ver los dispositivos en él, que a su vez no se pueden desconectar del monitoreo del antiguo sistema.
Era incierto si los dispositivos soportarían un sondeo simultáneo de dos sistemas sin pruebas reales. Existía la posibilidad de que un sondeo doble simultáneo condujera a frecuentes fallos en las respuestas de los dispositivos, y obtendríamos numerosos errores de inaccesibilidad, lo que a su vez bloquearía el funcionamiento del antiguo sistema de monitoreo.
El departamento de redes estableció rutas virtuales desde el prototipo de la nueva BMS, desplegada en la nube, hacia los dispositivos, y obtuvimos los resultados:
- los dispositivos conectados mediante el protocolo SNMP casi no se desconectaban debido a las solicitudes simultáneas,
- los dispositivos conectados a través de puertas de enlace por los protocolos modbus-TCP tenían problemas que se resolvieron razonablemente al reducir la frecuencia de sus sondeos.
Luego comenzamos a observar cómo se construía ante nuestros ojos un nuevo sistema, apareciendo los dispositivos que ya conocíamos, pero en otra interfaz: conveniente, rápida y accesible incluso desde el teléfono.
Sobre lo que resultó al final, hablaremos en la tercera parte de nuestro artículo.
Fuente: habr.com
