Alertas de tus sistemas: cuáles merecen un ticket

Una alerta de tus sistemas merece un ticket cuando alguien tiene que hacer algo y hay un cliente afectado. Las demás son información que basta con leer, o ruido que conviene corregir en la herramienta que lo envía. Para separar las alertas útiles del ruido, junta todos los avisos en una sola lista, ordénalos por severidad y decide cuáles pasan a ticket.

Piensa en una empresa que mantiene los sitios web de treinta clientes. El panel de monitoreo, el revisor de disponibilidad, los respaldos nocturnos y el proceso de publicación mandan sus avisos a un buzón compartido. El lunes hay doscientos mensajes. Los «resolved» se mezclan con los «down», y el respaldo que falló el sábado pasa sin que nadie lo vea porque se parecía a los otros cuarenta respaldos que salieron bien.

Tres preguntas para cada aviso

Antes de configurar nada, decide con tu equipo qué hacer con cada tipo de aviso. Tres preguntas alcanzan:

1. ¿Alguien tiene que actuar? Si la respuesta es no, el aviso es informativo.
2. ¿Afecta a un cliente concreto? Si afecta, el trabajo tiene que quedar a nombre de ese cliente, con alguien a cargo.
3. ¿Se repite sin que nadie haga nada? Entonces es ruido, y se corrige en el origen.

Con esas respuestas cada aviso cae en uno de tres destinos: pasa a ticket, se lee y se marca como leído, o se ajusta en la herramienta que lo envía para que deje de llegar.

Qué avisos suelen merecer un ticket y cuáles no

Suelen merecer ticket los que significan trabajo pendiente para un cliente: un respaldo que falló, un sitio que dejó de responder y no volvió, una publicación que se detuvo a medio camino, un servidor en estado crítico.

Suelen ser informativos los avisos de que algo se resolvió o volvió a funcionar, los respaldos que terminaron bien y las actualizaciones de contenedores que salieron sin problema. Conviene recibirlos, porque confirman que el sistema sigue enviando, pero no piden trabajo.

El ruido son las advertencias que se disparan a cada rato sin que nadie actúe, como un límite demasiado bajo en una métrica. Borrarlas cada mañana no resuelve nada. Hay que subir el límite o cambiar la regla en la herramienta de monitoreo, porque es ella la que detecta el problema y decide cuándo avisar.

Cómo llegan y se ordenan en AgentticCRM

Alertas reúne en una lista los avisos de tus herramientas de monitoreo, tus respaldos y tus sistemas propios. No vigila nada por su cuenta: recibe lo que tus herramientas envían. Para cada sistema creas un canal con su propia dirección privada, que se muestra una sola vez, y le asignas una severidad por defecto.

Cada aviso se lee igual aunque cada herramienta nombre sus datos a su manera. Alertas reconoce el título, el mensaje, la severidad, el identificador del incidente y el enlace. La severidad sale de las palabras del aviso: critical, down o firing la vuelven crítica; warning, error, fail o degraded, advertencia; info, ok, up o resolved, informativa. Si no hay ninguna, se usa la del canal.

Hay tres detalles que bajan el ruido sin que hagas nada. Si el mismo incidente llega dos veces por el mismo canal con el mismo identificador, se guarda una sola alerta. Cada canal acepta como máximo 120 avisos por minuto, para que un sistema que falla en bucle no inunde la lista. Y las alertas no llenan de notificaciones a tu equipo: se revisan en su propia lista, con un contador de las que siguen sin leer.

El silencio también es una señal. Cada canal muestra cuántas alertas recibió y cuándo llegó la última, así que un sistema que dejó de enviar se nota en esa fecha.

De la alerta al ticket y a las tareas

Cuando una alerta requiere trabajo, pulsas «Crear ticket» y eliges el cliente afectado. El ticket lleva el título de la alerta como asunto, y el mensaje y el enlace al incidente en la descripción. La alerta pasa a leída, muestra «Tiene ticket» y te lleva a él con un clic. Cada alerta genera un solo ticket.

Desde ahí el trabajo sigue en los tickets de soporte: tu equipo conversa con el cliente y reparte el seguimiento en tareas con responsable, prioridad y fecha. La alerta conserva el aviso técnico original, y las críticas y advertencias sin leer aparecen en el resumen del día del panel principal.

Si la misma alerta se repite cada mes, escribe una vez el procedimiento para resolverla y súbelo a tu base de conocimiento interna: el análisis de un ticket consulta tus procedimientos documentados.

Quién decide qué es ruido

Administrar canales y revisar alertas son permisos distintos. Quien atiende el soporte trabaja la lista sin cambiar por dónde entran los avisos, y quien administra los canales puede pausar uno o reemplazar su clave si la dirección se filtra.

Las alertas que no sirven se borran una por una o varias a la vez. Salen de la lista, pero el aviso original se conserva para auditoría y recuperación. Crear un canal, reemplazar su clave, borrar alertas o convertirlas en ticket queda registrado. También puedes pedirle al Asistente que te muestre las alertas pendientes o que convierta una en ticket; antes de guardar el cambio, te lo presenta para que lo apruebes.

Este flujo es el día a día de las empresas MSP y de soporte TI, y le sirve a cualquier equipo que mantiene sistemas para sus clientes.

Preguntas frecuentes

¿Alertas vigila mis sistemas por su cuenta?

No. Tus herramientas de monitoreo detectan el problema y envían el aviso; Alertas lo recibe, lo ordena y lo pone frente a tu equipo.

¿Qué herramientas puedo conectar?

Cualquiera capaz de enviar un aviso a una dirección web: paneles como Grafana, revisores de disponibilidad, herramientas como Beszel o Watchtower, respaldos, procesos de publicación y programas propios.

¿Qué hago si la dirección de un canal se filtra?

Reemplaza la clave del canal desde «Editar canal». La dirección anterior deja de funcionar de inmediato y recibes una nueva para pegar en tu herramienta.