Playbooks de enriquecimiento

Un playbook de enriquecimiento tiene un contrato sencillo: lee de varias fuentes y escribe solo en el caso (el ticket, el incidente, el comentario). Cuanto menos toca, menos puede romper: si falla a medias, el peor resultado es un caso con datos incompletos, no un servidor modificado. Por eso es el lugar ideal para empezar a automatizar y por eso conviene que la definición diga con claridad dónde escribe cada paso.

Cuando un paso de lectura empieza a escribir en el recurso afectado, el playbook cambia de naturaleza: ya no solo informa, actúa, y debería pasar por la política de las acciones y no por la del enriquecimiento.

Abre ejecucion-EJE-8841.txt: la ejecución se disparó para el activo AST-0418. El primer paso de casi todo enriquecimiento es averiguar a quién avisar. Esa respuesta vive en el inventario, no en el evento: el evento trae el identificador del activo y el inventario lo cruza con una persona.

Cada paso del registro termina con un estado. Un ok es un paso que cumplió, un error es un paso que no pudo, y el playbook decide qué hacer con ese error: abortar, reintentar o continuar. En la definición, el campo si_falla es el que lo dice; un tiempo de espera máximo evita que una fuente lenta detenga todo el flujo.

Mira el comentario que el paso 4 añadió al caso. La consulta de reputación expiró y su resultado fue «sin dato». Aun así, el playbook escribió una conclusión. Quien lea el caso por la tarde no ve el error del registro: ve la frase y cree que alguien comprobó la dirección.

Un enriquecimiento honesto distingue tres estados: dato encontrado, dato no disponible y dato no consultado. Escribir «limpia» cuando no hay dato convierte una ausencia en un veredicto.

La definición declara en su política que el enriquecimiento escribe en el caso y nunca en el recurso. Cada paso trae un campo tipo que dice qué clase de operación hace: lectura, escritura-en-el-caso o escritura-en-el-recurso. Revisa los cinco pasos con esa regla en la mano.