En las partes anteriores, hablamos sobre cómo creamos e implementamos un nuevo sistema de monitoreo del centro de datos. Como resultado, contamos con un poderoso mecanismo para rastrear y mantener estadísticas de todos los parámetros del centro de datos que afectan la disponibilidad de sus recursos e indicadores de operación ininterrumpida.
La siguiente tarea en el camino del desarrollo del sistema fue la cuestión de su ajuste: ¿cómo hacer que sea conveniente trabajar con el nuevo sistema, y que él mismo sea lo más informativo posible?
El problema aquí es que la funcionalidad del sistema le permite habilitar muchas notificaciones y señales de emergencia; con tales configuraciones, el personal se verá obligado a responder constantemente, elaborando los escenarios apropiados.
Otra opción es configurar un número insuficiente de notificaciones de este tipo, lo que crea el riesgo de que los asistentes se pierdan un evento realmente importante.
En esta parte, compartiremos nuestra experiencia práctica en la configuración de nuestro sistema de monitoreo de centro de datos.
Un poco de teoría
“Las variables recopiladas por el sistema SCADA se dividen en tele-señalización y telemetría” , me enseñaron una vez en el instituto. Y, de hecho, nada ha cambiado: la teleseñalización es un estadodispositivos, por ejemplo, "sin alarma", "hay una alarma", "abierto", "cerrado", etc.
Y la telemetría, como puede imaginar, es el valor digital de algún parámetro, por ejemplo, "220 Voltios" o "10 amperios".
El estado o valor establecido por el usuario en el que aparece un mensaje (alarma) en la pantalla se denomina “punto de ajuste”. Puede establecer un retraso antes de que aparezca el mensaje, es decir, la alarma aparece en la pantalla solo después de X segundos (siempre que la emergencia no se haya detenido antes) o para "congelar" el mensaje en la pantalla, en este caso, la alarma ya ha desaparecido, pero el mensaje al respecto está almacenado en la pantalla durante otros X segundos.
Los accidentes por prioridad se suelen dividir en tres tipos principales: "Rojo", "Amarillo" y "Azul". Los accidentes "rojos" requieren una acción inmediata por parte de los empleados, los "amarillos" les advierten sobre algo, y los "azules" informan con mayor frecuencia algunos eventos no críticos. Por ejemplo, hemos deducido los accidentes "azules" del resumen que ven los asistentes y los utilizan para monitorear varios parámetros comerciales (excediendo la capacidad solicitada). Estos accidentes se informan solo a los gerentes y no distraen a los asistentes.
Para la conveniencia de configurar el mismo tipo de equipo, las variables en diferentes dispositivos, pero con el mismo nombre (por ejemplo, "OutputCurrent") tienen la misma configuración en todos los dispositivos del sistema. Si cambiamos la configuración en un lugar, cambia en todas partes.
Cuando un dispositivo requiere configuraciones individuales para la variable requerida, aplicamos una marca especial "Solo para este dispositivo". Ahora la variable se ha vuelto individual para un dispositivo específico, tiene su propia configuración y no afecta a otras variables del mismo nombre.
Además, los propios dispositivos tienen su propia configuración de fábrica. Por ejemplo, la PDU está configurada de fábrica para reconocer una alarma de sobrecorriente de 32A. Si se activa, la PDU notificará sobre el tipo de alarma "Alarma de sobrecarga". Y esta es una variable completamente diferente, no relacionada con la variable "OutputCurrent" configurada en el BMS.
Ejemplo de configuración predeterminada de fábrica dentro de una PDU:
Entonces, hemos enumerado la funcionalidad principal para configurar un sistema de monitoreo.
¿Cómo afinar este "piano" correctamente? Repasemos las tareas en orden.
Qué queremos lograr
La tarea más importante: cualquier mensaje de alarma en la parte
La segunda tarea es minimizar los mensajes falsos o poco informativos. No importa cuán atento y responsable pueda ser, si algo parpadea, parpadea y suena constantemente frente a sus ojos, entonces se perderá un accidente real, se ahogará en un mar de alertas o apagará el sonido, y como resultado, también perderán la alerta de incidente.
Etapa 1. Determinación de las variables necesarias e innecesarias para cada dispositivo
Por lo general, cada dispositivo viene con un llamado "mapa de variables", a partir del cual el ingeniero de puesta en servicio crea un "controlador". Su tarea es "indicar" al sistema de monitorización en qué registro de los datos recibidos se encuentra la variable requerida. Por ejemplo, el registro 1 del protocolo de sondeo del dispositivo contiene información sobre el modo de funcionamiento del motor "System_on_fun", y el registro 2, sobre el modo de funcionamiento del compresor "Compressor_1".
El número de variables para un dispositivo suele ser superior a 100. El empleado que configura inicialmente el sistema (generalmente un ingeniero de TI) no puede decidir por sí mismo qué es importante aquí y qué no lo es. Como regla general, todas las variables se agregan al monitoreo según el principio de “qué pasa si son útiles”.
Al principio, esto está permitido: el personal de operaciones puede observar los valores reales de todas las variables disponibles y comprender lo que realmente necesitan. Pero si deja el sistema en este estado durante mucho tiempo, obtendremos los siguientes efectos negativos:
- Las variables superfluas cargan la tarea operativa del sistema de monitoreo y aumentan el tamaño del archivo; el sistema se ve obligado a procesar y guardar datos innecesarios.
- Cuantas más variables sean encuestadas, mayor será la probabilidad de falla en la encuesta. Esto es especialmente cierto para los dispositivos conectados a través de un lazo (por ejemplo, a través de una puerta de enlace que utiliza el protocolo MODBUS). Esto conduce a la recepción de los estados "sin datos (N / A)" o "interrupción de la comunicación", es decir, de hecho, el dispositivo se desconecta periódicamente de la supervisión.
- Algunas variables son superfluas "por defecto". Por ejemplo, su versión del equipo no tiene compresor ni sensor de presión, pero se registran en el controlador universal para toda la gama de modelos de equipos y se sondean, se agregan al archivo, se cargan la red y se procesan.
Las capturas de pantalla muestran parte del código del controlador. Los símbolos // indican variables ocultas de la encuesta. También es visible una lista de variables que se muestra al usuario al configurar los puntos de ajuste en el propio BMS.
Según nuestra experiencia, es mejor no tocar la configuración de fábrica dentro de los dispositivos en la etapa inicial (por supuesto, si aún no le informan sobre el accidente). Sin embargo, en cada sesión de capacitación sobre un equipo específico, se debe recordar a los empleados la presencia de configuraciones tanto en el dispositivo como en el BMS. En el futuro, esto ayudará a los asistentes a comprender exactamente cuál es exactamente la causa del mensaje de alarma.
Las variables superfluas en el controlador deben revelarse y ocultarse gradualmente de la encuesta, y las restantes deben dividirse en aquellas a las que se deben asignar configuraciones y aquellas que se guardan sin configuraciones solo para análisis y estadísticas posteriores.
Esto no debe ser realizado por el ajustador del sistema, sino por un empleado que comprenda el funcionamiento del sistema controlado por el sistema de monitoreo, preferiblemente el ingeniero jefe o el ingeniero jefe de energía.
Etapa 2. Minimización de mensajes falsos y no informativos Los
falsos positivos a menudo ocurren debido a fallas en el sondeo del dispositivo. Si la tarjeta de red del dispositivo no tiene alimentación propia, tanto una falla en el sondeo como un corte de energía real se mostrarán como un tipo de falla: "interrupción de la comunicación".
En este caso, es necesario dividir el equipo en crítico (por ejemplo, PDU) y ordinario (por ejemplo, paneles de ventilación "SHCHUV"). Para equipos convencionales, puede establecer un retraso para la señal de "desconexión" (por ejemplo, 300 segundos); luego, la mayoría de las falsas desconexiones se ignorarán.
Está claro que tal demora no se puede colocar en equipos críticos, por lo tanto, si constantemente da falsas fallas, entonces debe lidiar con la red física, la cantidad de variables encuestadas. Es muy posible que muchos dispositivos estén "colgados" en una puerta de enlace y es necesario segmentar la red agregando nuevas puertas de enlace.
Los accidentes no informativos ocurren con mayor frecuencia durante procesos transitorios. No se pueden llamar falsos; en realidad existen, pero son "normales" para un modo de funcionamiento específico del equipo. El ejemplo más obvio es la transición a un grupo electrógeno diesel.
En este caso, una parte del equipo alimentado sin un UPS "normalmente" está desenergizado y da un error de "desconexión", y el UPS mismo envía un montón de mensajes: "no hay energía en la entrada", "no hay energía en bypass "," alimentación de la batería "Etc. El personal recibe inmediatamente decenas de mensajes.
Para optimizar la cantidad de mensajes al cambiar a DGS, debe:
- configurada para alarmas de aparición “normal” durante la transición, demoras de tiempo más largas que el momento en que aparece la fuente de alimentación del grupo electrógeno. Por ejemplo, configure el retardo para la señal de "desconexión" del panel de ventilación en 300 segundos cuando el tiempo estándar para cambiar al grupo electrógeno diesel es de 200 segundos.
Entonces, la fuente de alimentación de la SCHU aparecerá antes del retardo del punto de ajuste y la situación no se reconocerá como una emergencia. Al mismo tiempo, hay dispositivos críticos que son alimentados por el UPS y deben estar siempre conectados (por ejemplo, PDU) - los mensajes sobre su "desconexión" deben aparecer sin demora.
- analizar los mensajes del SAI al cambiar a un grupo electrógeno diesel y dividirlos en "normales" asignándoles un tipo "amarillo" (por ejemplo, una declaración del hecho "no hay energía en la entrada") y "anormal "(" desconexión del disyuntor de batería ", que no debe ser ningún modo de funcionamiento), con la asignación de los mismos al tipo" rojo ".
Al mismo tiempo, escribimos por separado en las instrucciones a los oficiales de servicio que en el caso de una transición a un grupo electrógeno diesel, los accidentes "amarillos" pueden ser observados y no reconocidos (desaparecerán ellos mismos después de completar una transición regular ), y los accidentes “rojos” pueden eliminarse de inmediato (no deberían serlo).
Basándose únicamente en la teoría, es muy difícil ajustar los puntos de ajuste para este proceso "transitorio" al mismo tiempo. Para una sintonización exitosa, es necesario observar las transiciones al DGS varias veces en tiempo real.
Por ejemplo, necesitábamos observar 4-5 transiciones para una configuración aceptable de un nuevo BMS. Para analizar el proceso de transición no programada, realizamos un registro de la pantalla del sistema de monitoreo, ya que es importante observar las alarmas no en el archivo de eventos, sino analizar la ocurrencia de alarmas en la dinámica del resumen operacional.
Paso 3. Consejos adicionales de nuestra experiencia
1. En las pantallas del turno de trabajo, no debería haber ninguna indicación innecesaria en los colores de los mensajes de alarma.
Ejemplo del mundo real. Un centro de datos pidió un mapa de flujo de temperatura en la sala de servidores. Este es un modelo 3D de flujos de aire con una gran cantidad de datos de temperatura de los sensores. El resultado fue una vista del aire del norte con corrientes de aire; en algún lugar, el aire estaba resaltado en verde, en algún lugar: amarillo y rojo (de más frío a más caliente). Al mismo tiempo, las temperaturas del aire están en todas partes dentro de los límites normales y los colores se utilizan solo para mostrar claramente la diferencia de temperatura en diferentes puntos.
Además, esta vista "abigarrada" se mostró en uno de los monitores en la "sala de servicio". Como resultado, resultó que la herramienta, creada para el análisis de procesos, apareció ante los ojos de los que estaban de servicio, quienes estaban "afilados" para correr hacia el equipo cuando ven rojo y tensarse cuando ven amarillo.
Probablemente, explicaron a los asistentes que en la pantalla de la izquierda "rojo / amarillo" es normal, y en la pantalla de la derecha los mismos colores son una señal de acción. Sin embargo, está claro que esta práctica aumenta el riesgo de error humano de manera muy seria.
Es lógico eliminar dichos sistemas de los monitores en la sala de servicio, el ingeniero jefe debe observarlos con el fin de analizar las tendencias, por ejemplo, después de algunos cambios en los parámetros del entorno del aire en la sala de servidores o la puesta en servicio. de equipo nuevo.
2. Utilice las notificaciones por SMS con precaución.
Hace varios años, todavía teníamos miedo de una mala Internet móvil y usábamos SMS en lugar de mensajería instantánea. Una vez que establecí accidentalmente la configuración incorrecta, se aplicó a todos los dispositivos del mismo nombre en 100 dispositivos, y mis colegas suscritos a la lista de correo recibieron 100 mensajes SMS cada uno. Desde entonces, no hemos utilizado el envío de SMS.
3. Configure la duplicación de mensajes sobre problemas a través del mensajero.
Esto se puede hacer, por ejemplo, a través de Microsoft Teams o Telegram. Tanto usted como la persona de turno recibirán mensajes sobre accidentes, mientras que el teléfono emitirá sonidos y vibrará (lo que no es el caso cuando se trabaja con el sistema a través de un navegador).
Y no tengas miedo de que haya muchos mensajes. En nuestra experiencia, durante el día promedio de operación de un centro de datos, solo se reciben unas pocas docenas de mensajes y no cargan los teléfonos de los empleados. Es decir, los equipos del centro de datos y el sistema BMS se pueden configurar para no recibir cientos de notificaciones y al mismo tiempo no perderse nada importante.
Para reducir la cantidad de mensajes, incluya en la lista de correo solo notificaciones sobre la ocurrencia de alarmas "rojas" y "amarillas", es decir, el mínimo necesario, lo que le permite estar al tanto de los eventos.
4. Agrupar mensajes en mensajeros.
Durante la transición a un grupo electrógeno diesel o debido a un accidente complejo, tendrá decenas de emergencias activas, el teléfono vibrará constantemente por los mensajes entrantes al mensajero, lo que le impedirá realizar una llamada importante o abrir la ventana del sistema de monitoreo.
Puedes configurar la distribución para que el messenger reciba un mensaje general con una lista general de accidentes ocurridos en el último minuto. Esta configuración no afecta la aparición de alarmas en el resumen del sistema BMS (las alarmas aparecen en el resumen sin demora), y por 1 minuto de retraso en la recepción de un mensaje en su teléfono, no se perderá nada, pero habrá muchas veces menos mensajes en su teléfono.
5. Resalte el mensaje sobre la pérdida de conexión con el servidor en la interfaz.
Por ejemplo, Internet se perdió en las instalaciones de los asistentes. La interfaz de usuario no tiene conexión con el servidor y, por lo tanto, la alarma no aparece en el resumen, es posible que el personal no note la inscripción atenuada "el servidor no está disponible", los empleados pueden ver el panel BMS "verde" con parámetros numéricos durante mucho tiempo, sin saber que se encuentra fuera de línea.
La captura de pantalla muestra un ejemplo de una indicación de la pérdida de comunicación con el servidor BMS, mientras se muestran parámetros irrelevantes del equipo.
6. Conecte tantos sistemas como sea posible a la monitorización.
Por ejemplo, tradicionalmente un sistema de alarma contra incendios funciona de forma autónoma y su panel cuelga del puesto de seguridad.
Sí, en la señal de "FUEGO", se activan los algoritmos automáticos de los sistemas, se inicia el sistema de alerta, pero el oficial de seguridad informa sobre la aparición de las señales de "Fallo" o "Atención" en una voz de guardia.
Es muy difícil conectar completamente un sistema de este tipo al monitoreo, pero en un sistema de este tipo es fácil configurar tres señales de relé "falla", "atención" y "fuego", y luego conectarlas con "contactos secos" al BMS. módulo del sistema.
Esto reduce el riesgo del notorio factor humano. Un ejemplo de una señal de prueba "FUEGO" en el sistema BMS del centro de datos, conectado a través de "contactos secos".
Resumen de nuestra historia de la serie 4
Un sistema de monitoreo de centro de datos es más que "ojos y oídos" para monitorear los sistemas de ingeniería del centro de datos. Su correcto funcionamiento permite alcanzar el más alto nivel de confiabilidad a través de la continuidad del sitio y, por lo tanto, brinda a la empresa una ventaja competitiva adicional.
Habiendo pasado un camino bastante difícil y largo, obtuvimos:
- un sistema de monitoreo rápido y estable que actualmente monitorea más de 2,500 dispositivos y calcula alrededor de 10,000 sensores virtuales;
- reserva de sistema basada en la plataforma de soluciones en la nube Lindatacenter en San Petersburgo y Moscú;
- -, , 1 ;
- , , ;
- , , – .