Remediación automática: del evento al playbook con Event-Driven Ansible

Qué resuelve la remediación automática, y qué no

Buena parte de los incidentes de un centro de operaciones se repite: un servicio que deja de responder, un disco que se llena con logs, un proceso que consume memoria hasta degradar el servidor. La respuesta también se repite: alguien recibe la alerta, abre una sesión, ejecuta los mismos pasos y documenta en el ticket. Si ese procedimiento ya está automatizado en un playbook, el siguiente paso lógico es que la propia alerta lo dispare.

Eso es la remediación automática: detectar un evento conocido y ejecutar una respuesta conocida, sin esperar a que una persona la lance. Bien aplicada, reduce el tiempo de restauración de incidentes repetitivos y libera al equipo para los problemas que sí requieren análisis.

Conviene ser preciso sobre sus límites. La remediación automática trata síntomas conocidos; no sustituye a la gestión de problemas, que busca la causa raíz. Si un servicio necesita reiniciarse todas las semanas, automatizar el reinicio alivia la operación, pero el problema sigue ahí. Un buen diseño registra cada remediación para que esas recurrencias sean visibles y alguien las investigue.

Cómo funciona Event-Driven Ansible

Event-Driven Ansible (EDA) añade a Ansible la capacidad de reaccionar a eventos. Su pieza central es el rulebook, un archivo YAML que ejecuta ansible-rulebook y que combina tres elementos:

• Fuentes de eventos (sources): plugins que reciben o consultan eventos. Hay fuentes para webhooks genéricos, Prometheus Alertmanager, Kafka y otras, distribuidas en colecciones como ansible.eda. Muchas herramientas de monitoreo pueden enviar sus alertas por webhook.
• Reglas (rules): cada regla tiene una condición que se evalúa sobre los datos del evento.
• Acciones (actions): lo que ocurre cuando la condición se cumple. Por ejemplo, ejecutar un playbook, lanzar una plantilla de trabajo o un flujo de trabajo en Ansible Automation Platform, o simplemente imprimir el evento para depuración.

En Ansible Automation Platform, el controlador de EDA gestiona los rulebooks como "activaciones", con su propio control de acceso e historial. Para entornos regulados, la acción recomendable es lanzar plantillas de trabajo del controlador de automatización en lugar de ejecutar playbooks locales: así cada remediación queda registrada como un trabajo más, con su salida, su inventario y sus credenciales gestionadas.

Un rulebook de ejemplo

El siguiente rulebook recibe alertas por webhook y define dos respuestas: un reinicio controlado para servicios incluidos en una lista explícita, y un flujo de trabajo con aprobación humana para un caso de mayor riesgo. Los nombres de alertas, servicios y plantillas son ejemplos; el formato del evento depende de lo que envíe tu herramienta de monitoreo.

---
- name: Remediación de servicios de aplicación
  hosts: all
  sources:
    - ansible.eda.webhook:             # recibe las alertas del monitoreo por HTTP
        host: 0.0.0.0
        port: 5000
  rules:
    - name: Reinicio controlado de un servicio permitido
      condition: >-
        event.payload.alert == "service_down" and
        event.payload.service in ["app-pagos", "app-portal"]
      throttle:
        once_within: 30 minutes        # como máximo una acción por host cada 30 minutos
        group_by_attributes:
          - event.payload.host
      action:
        run_job_template:
          name: Reinicio controlado de servicio
          organization: Operaciones
          job_args:
            limit: "{{ event.payload.host }}"   # solo el host afectado
            extra_vars:
              servicio: "{{ event.payload.service }}"
              incidente: "{{ event.payload.incident_id }}"

    - name: Disco lleno en base de datos con aprobación previa
      condition: event.payload.alert == "disk_full" and event.payload.role == "database"
      action:
        run_workflow_template:         # el flujo incluye un nodo de aprobación
          name: Liberar espacio en base de datos
          organization: Operaciones
          job_args:
            extra_vars:
              host_afectado: "{{ event.payload.host }}"

Para que la plantilla acepte limit y extra_vars desde el rulebook, debe estar configurada para solicitarlos al lanzarse. Y la plantilla de reinicio puede ser exactamente un playbook con verificaciones previas y posteriores, derivado del runbook que el equipo ya usaba: la remediación automática reutiliza procedimientos ya probados, no inventa otros.

Dos recomendaciones de diseño. La primera: normaliza los eventos antes de que lleguen al rulebook. Si cada herramienta de monitoreo envía un formato distinto, las condiciones se vuelven largas y frágiles. Es preferible acordar un formato mínimo (tipo de alerta, host, servicio, severidad, identificador de incidente) y adaptarlo en el origen o en una capa intermedia. La segunda: mantén la lógica de decisión en el rulebook y la lógica de ejecución en el playbook. El rulebook decide si se actúa y con qué datos; el playbook decide cómo, y vuelve a validar sus propias condiciones antes de tocar nada. Esa doble validación evita que un evento malformado o inesperado llegue a producir un cambio.

Prueba las condiciones antes de habilitar acciones reales. Una regla cuya acción solo imprime el evento (la acción debug) permite comprobar, con alertas reales, qué eventos cumplen cada condición y cuáles no.

Barreras: lo que separa una remediación de un incidente nuevo

Un playbook que se ejecuta solo, en respuesta a eventos que no controlas, puede causar daño muy rápido. Una alerta mal configurada o una tormenta de eventos puede disparar el mismo reinicio decenas de veces. Por eso las barreras no son opcionales:

• Lista explícita de acciones. Solo se automatizan respuestas aprobadas, sobre servicios y hosts nombrados. En el ejemplo, la condición enumera los servicios permitidos; cualquier otro queda fuera.
• Límite de frecuencia. La opción throttle evita que la misma regla actúe repetidamente sobre el mismo host en una ventana de tiempo. Si el problema vuelve dentro de esa ventana, no conviene insistir: es señal de que hace falta una persona.
• Radio de impacto acotado. La acción afecta solo al host del evento (limit), y el playbook trabaja un nodo por vez. Ninguna regla debería poder actuar sobre "todos los servidores".
• Aprobación humana para lo riesgoso. Las acciones que pueden causar pérdida de datos o indisponibilidad (borrar archivos en una base de datos, conmutar un clúster) pasan por un nodo de aprobación del flujo de trabajo.
• Interruptor de apagado. Debe ser posible desactivar la activación del rulebook de inmediato, y el equipo de guardia debe saber cómo hacerlo.
• Ventanas y excepciones. Durante un cambio planificado, las alertas esperadas no deberían disparar remediaciones. Coordina con las ventanas de mantenimiento de tu herramienta de monitoreo.

Una forma práctica de decidir el nivel de autonomía es clasificar cada acción por riesgo:

Nivel	Ejemplo de acción	Tratamiento
Diagnóstico	Recoger logs, métricas y estado del servicio	Automático, sin aprobación
Bajo riesgo	Reiniciar un nodo de un servicio redundante	Automático, con límite de frecuencia y lista explícita
Riesgo medio	Limpiar archivos temporales en un servidor de aplicación	Automático tras un periodo en modo observación
Alto riesgo	Liberar espacio en una base de datos, conmutar un clúster	Aprobación humana antes de ejecutar

Incluso en el nivel de diagnóstico hay valor: cuando la persona de guardia abre el ticket, los datos que necesita ya están adjuntos.

Cerrar el ciclo con el ticket ITSM

Una remediación que no deja rastro en la herramienta de gestión de servicios es invisible para la gestión de incidentes y de problemas. El ciclo completo tiene cuatro momentos:

1. Registro. El incidente se abre (por la herramienta de monitoreo o por el propio playbook) antes de actuar, y su identificador viaja como variable hasta la ejecución.
2. Acción. El playbook ejecuta la remediación y sus verificaciones.
3. Documentación. El playbook añade al incidente qué hizo, en qué host, con qué resultado y el enlace al trabajo de Ansible.
4. Cierre o escalamiento. Si la verificación posterior es correcta, el incidente se resuelve con un código de cierre que identifique la remediación automática. Si falla, se reasigna al grupo de guardia con el diagnóstico adjunto.

La integración puede hacerse con colecciones específicas (por ejemplo, servicenow.itsm para ServiceNow) o con llamadas a la API REST de la herramienta mediante ansible.builtin.uri. Lo importante es que la actualización del ticket sea parte del playbook y no un paso manual posterior.

Con los cierres identificados, la gestión de problemas tiene datos objetivos: qué remediaciones se repiten, en qué servicios y con qué frecuencia. Esa información debería alimentar el análisis de causa raíz, no quedarse como estadística.

Cómo empezar sin asumir riesgos innecesarios

La remediación automática se construye de forma gradual. Un camino razonable:

1. Elige los casos con criterio. Aplica el marco Valor × Complejidad a los incidentes repetitivos. Los que tienen alto valor y baja complejidad, con un procedimiento ya automatizado y probado, son las Victorias rápidas naturales.
2. Empieza en modo observación. Durante un periodo, las reglas solo registran o notifican lo que habrían hecho. Así compruebas que las condiciones son correctas sin tocar producción.
3. Automatiza primero el diagnóstico. Recoger datos es útil y casi no tiene riesgo.
4. Habilita acciones de bajo riesgo con todas las barreras activas, y revisa cada ejecución durante las primeras semanas.
5. Mide. Remediaciones ejecutadas, tasa de éxito de la verificación posterior, escalamientos y recurrencias por servicio.

Trata además los rulebooks como el resto del código de automatización: en un repositorio, con revisión, pruebas y promoción entre entornos, como describimos en Ansible a escala. Una regla nueva en producción es un cambio, y como tal debe pasar por tu práctica de habilitación de cambios.