Disparadores y eventos

Los servicios que mueven eventos entre componentes suelen prometer entrega «al menos una vez». Eso significa que el evento llega seguro, pero que en ocasiones llega repetido: el emisor reintenta porque no recibió la confirmación a tiempo, o la cola entrega de nuevo un mensaje que ya se procesó. La promesa contraria, «como máximo una vez», evita los duplicados pero puede perder eventos, y en seguridad perder un evento suele ser peor.

La consecuencia práctica es que el consumidor, el playbook, tiene que estar preparado para ver el mismo evento dos veces. Cada evento trae un identificador propio precisamente para poder reconocerlo.

Abre patron-de-evento.json. Un patrón es un filtro: un evento lo cumple solo si coincide con todos los campos que el patrón nombra, y cada campo acepta una lista de valores posibles. Un campo que el patrón no menciona no se mira. Los comparadores numéricos funcionan como en cualquier filtro: >= 7 deja pasar el 7 y todo lo mayor.

Después abre eventos-recibidos.csv y cuenta cuántas de las entregas del patrón llegaron a la regla. Cuenta entregas, no eventos distintos: una entrega repetida se cuenta cada vez.

Si el playbook de esa regla desactiva una clave o abre un caso, una entrega duplicada puede hacerlo dos veces. La señal de que un evento se repitió es su identificador: dos filas con el mismo id_evento son el mismo hecho contado dos veces, aunque la hora de recepción difiera unos segundos.

Abre reglas-de-automatizacion-de-incidentes.txt. Una regla se activa por un tipo de suceso (crear o actualizar un incidente) y ejecuta acciones. El peligro aparece cuando la acción modifica justo el objeto que la activa. Si la regla se dispara al actualizar un incidente y el playbook que lanza actualiza el incidente, cada ejecución provoca la siguiente: un bucle que solo se detiene cuando alguien lo corta o cuando se agota algún límite.

Apagar la regla resuelve el bucle y deja sin enriquecimiento a todos los incidentes de severidad alta. Es mejor corregir la causa: que la regla distinga entre un cambio hecho por una persona y un cambio hecho por la propia automatización, o que se ejecute una sola vez por incidente. También conviene un tope de ejecuciones por hora, como red de seguridad si el filtro falla.