Cómo configurar una notificación de alarma por correo en SCADA

Volver al glosario

Ingresar los ajustes SMTP y de relevo

Antes de que el sistema SCADA pueda enviar correo a alguien, necesita un servidor de correo al que entregar sus mensajes, y configurar esa conexión es la puesta a punto de SMTP. SMTP es el protocolo estándar para enviar correo, y los ajustes son la dirección del servidor de correo, el puerto que escucha, si la conexión está cifrada y, en casi todos los casos hoy, un usuario y contraseña u otras credenciales que el servidor exige antes de aceptar correo. También fija una dirección remitente, el emisor del que las notificaciones aparentan venir, que los destinatarios verán y pueden filtrar. Estos valores vienen de quien administra el servicio de correo, un servidor interno de TI o un proveedor de correo alojado, y tienen que coincidir con exactitud o el servidor simplemente se niega a retransmitir el mensaje.

SMTP es también donde las notificaciones fallan en silencio con más frecuencia, porque los servidores de correo modernos son estrictos sobre para quién enviarán correo, y con razón, ya que un relevo abierto es un imán de spam. Un servidor rechazará mensajes que carezcan de autenticación adecuada, que vengan de una dirección remitente inesperada o que lleguen por el puerto equivocado o sin el cifrado esperado. Por eso acertar estos ajustes al detalle no es una formalidad; un solo valor equivocado, un puerto incorrecto, una contraseña faltante, el cifrado apagado cuando el servidor lo exige, hace que cada notificación se rechace en silencio mientras el sistema SCADA quizá siga creyendo que las envió. Por eso probar después es esencial, porque el eslabón SMTP falla de forma invisible más seguido que cualquier otra parte de la cadena.

También está la cuestión de la entregabilidad que vive más allá de los ajustes del SCADA en sí. Aun una conexión SMTP bien configurada puede ver sus mensajes aterrizar en una carpeta de spam o ser descartados si el dominio emisor no está bien preparado para autorizar al servidor de correo, o si la dirección remitente le parece sospechosa al lado receptor. Esto suele ser un asunto de TI y de administración de correo más que del SCADA, pero vale la pena tener en cuenta que configurar SMTP correctamente logra que el mensaje sea aceptado por su servidor emisor, mientras que llevarlo de forma confiable a las bandejas de entrada de los destinatarios también depende de la configuración de correo más amplia. Coordinar con quien administra el servicio de correo es la manera práctica de asegurar que los correos de alarma no solo se envíen sino que de verdad lleguen.

Armar la regla de notificación y los destinatarios

Con una manera funcional de enviar correo, el siguiente paso es decidir qué alarmas deberían generar un correo, porque enviar correo por cada alarma es una vía rápida a entrenar a todos para ignorar los correos. Esta es la regla de notificación, y el filtro más común y útil es la prioridad de la alarma. Usted configura la regla de modo que solo las alarmas por encima de una prioridad elegida envíen un correo, así un HI-HI crítico en un recipiente notifica a alguien mientras que una alarma informativa de baja prioridad no. Filtrar por prioridad es lo que mantiene con sentido las notificaciones, porque una bandeja de entrada inundada de correos de alarma triviales se vuelve ruido que la gente silencia, y entonces el correo que sí importaba queda sin leer entre los demás.

Las reglas de notificación suelen poder filtrar por algo más que la prioridad, y usar esos filtros con deliberación afina las notificaciones. Puede acotar una regla a un área o conjunto de sitios en particular, de modo que la persona responsable del campo norte solo reciba las alarmas del campo norte, o restringirla a ciertos tipos de alarma, o incluso a ciertos tags. La meta en todo momento es que cada destinatario reciba exactamente las alarmas que son suyas para actuar y ninguna de las que no lo son, porque un destinatario que recibe alarmas sobre las que no puede hacer nada aprende a dejar de leerlas. Ajustar el alcance de la regla a la responsabilidad real de una persona es lo que hace de la notificación un aviso útil y no ruido de fondo.

Los destinatarios son las personas o listas a las que la regla envía, y elegirlos es más trascendente de lo que parece. Una regla puede enviar a una sola persona, a varias o a una lista de distribución, y la elección correcta depende de quién de verdad necesita saber y quién puede actuar. Para una alarma crítica quizá quiera más de un destinatario para que un mensaje no se pierda si una persona está inalcanzable, mientras que para notificaciones de rutina basta un solo responsable o una bandeja compartida. También vale la pena pensar en el escalamiento, arreglar que si el primer destinatario no responde, la alarma alcance a una segunda persona tras un retardo, para que una condición seria no se quede sin atender porque la única persona de la lista estaba dormida o ausente. Mantener las listas de destinatarios al día conforme la gente cambia de rol es una tarea continua, porque una notificación enviada a alguien que dejó la empresa es una falla silenciosa de toda la cadena.

Plantillas de mensaje, pruebas y notificaciones desde la nube

La plantilla de mensaje es lo que el destinatario de verdad lee, y una buena convierte una alarma levantada en un aviso accionable. La plantilla debe incluir lo esencial extraído automáticamente de la alarma: qué sitio y equipo, cuál es la condición, el valor real que la disparó y la hora en que ocurrió, todo en lenguaje sencillo y no en códigos crípticos. Un correo que dice solo PT-301 HI obliga al destinatario a iniciar sesión e investigar antes siquiera de entender el problema, mientras que uno que dice Estación Norte, presión de descarga del pozo 3 alta en 118 psi a las 2:14 a.m. le dice casi todo lo que necesita antes de tocar un teclado. Escribir la plantilla para alguien que la lee medio dormido en un teléfono, que quizá no conoce bien este sitio, es la misma disciplina que hace útil cualquier mensaje de alarma.

Ninguna configuración de notificación está terminada hasta que una alarma real ha recorrido la cadena entera y se ha confirmado que llega, porque muchos eslabones pueden fallar en silencio. Usted dispara una alarma de prueba que coincida con la regla, en o por encima de la prioridad que debe notificar, y confirma que el correo de verdad aterriza en la bandeja de entrada del destinatario, con el contenido correcto, no atorado en spam ni perdido en el servidor de correo. Esta prueba de punta a punta es lo único que demuestra que los ajustes SMTP, la regla, la lista de destinatarios y la plantilla funcionan juntos, y atrapa las fallas invisibles, un relevo rechazado, una prioridad filtrada, un error de tecleo en una dirección, mientras aún son fáciles de arreglar. Saltarse la prueba significa que la primera vez que se entera de que las notificaciones no funcionan es durante la emergencia que se suponía debían advertir.

La notificación por correo es uno de los argumentos más fuertes a favor del SCADA en la nube, porque convierte una flota de sitios no atendidos en algo que un equipo pequeño puede vigilar desde cualquier lugar. En una plataforma SCADA en la nube como Merobix, el motor de notificación corre en el sistema alojado que siempre está en línea y siempre conectado a los sitios, así que una alarma en un pozo remoto llega al teléfono de la persona de guardia aunque nadie esté cerca del sitio y ningún servidor local tenga que seguir corriendo para enviar el correo. Como la plataforma ya ve las alarmas de todos los sitios en un solo lugar, un único conjunto de reglas de notificación puede cubrir una operación entera, enrutando las alarmas serias de cada sitio a las personas correctas por prioridad y por área, que es justo lo que hace viables las operaciones remotas y con poco personal en vez de una apuesta a que alguien note un problema a tiempo.

Preguntas frecuentes