Tasks, eventos y auditoría

Los Tasks, los eventos y la auditoría responden a preguntas de gestión distintas. Un Task dice al operador si un trabajo de larga duración ha terminado. Un evento ayuda a la interfaz y a la automatización a reaccionar ante un cambio de estado. Un registro de auditoría dice a un revisor de seguridad quién o qué intentó una acción relevante. Ninguno de ellos demuestra por sí solo el resultado para el cliente.

El responsable del recurso decide si reintentar o revertir, el operador concilia el estado del Task con el entorno de ejecución propietario y el responsable de seguridad define la retención y la exportación de la auditoría. Mantén estos registros conectados con ID estables de recursos, peticiones, Tasks y operaciones.

Los Tasks representan trabajo duradero de larga duración, como builds, despliegues, migraciones, importaciones, aprovisionamiento y actualizaciones. Sigue el estado, el progreso, los logs, el código de error y la disponibilidad de reintentar o cancelar. No inicies duplicados solo porque se haya desconectado un navegador.

Los eventos actualizan el estado en vivo de la interfaz y desencadenan flujos operativos compatibles. Los consumidores deben volver a validar la autorización y tolerar los límites de reconexión o de repetición.

Los registros de auditoría atribuyen las acciones relevantes para la seguridad y la configuración a usuarios o actores del sistema. Bloquear o eliminar a un usuario no elimina la atribución histórica. Exporta a un SIEM cuando se necesite una retención o una correlación independientes.

Los detalles de auditoría deben identificar la acción y el recurso sin guardar secretos, credenciales en bruto, claves privadas, prompts ni salidas de modelos.

Ciclo de vida de un Task

Los estados habituales de un Task distinguen entre trabajo en cola, en ejecución, en espera, correcto, fallido, cancelado e interrumpido. Los estados y las acciones disponibles dependen de la operación. El progreso es una prueba procedente del worker o del daemon propietario, no una animación del navegador.

Registra el ID del Task antes de dejar una operación de larga duración. Recargar la página debe volver a conectarse al estado duradero en lugar de crear una segunda operación. Si se pierde la respuesta a un comando, inspecciona tanto el Task como el propietario antes de reintentar.

Reintentar, cancelar y forzar la cancelación

Reintenta solo cuando el contrato del Task marque la operación como reintentable o la conciliación demuestre que el intento anterior llegó a un estado final. Las peticiones de cancelación son cooperativas cuando el propietario admite la cancelación. Force Cancel puede hacer que Opfield deje de esperar una operación abandonada, pero no justifica suponer que la acción subyacente en el entorno de ejecución no se haya producido.

Tras una cancelación o una interrupción, actualiza el recurso desde su propietario y resuelve cualquier marcador de operación antes de iniciar otro cambio.

Eventos y estado en tiempo real

Los eventos en tiempo real reducen la latencia de la interfaz, pero no son la única fuente de verdad. Los clientes deben tolerar desconexiones, repeticiones, entregas duplicadas y que un evento llegue antes que una instantánea actualizada. Tras reconectarse, carga la instantánea autoritativa y combina los eventos más recientes por la identidad estable del recurso.

Los eventos que desencadenan automatización deben volver a comprobar la autorización, la propiedad, los derechos del plan y el estado del ciclo de vida actuales. Un permiso histórico en el momento de crear el evento no autoriza un cambio posterior.

Interpretación de la auditoría

Los registros de auditoría identifican el actor, la acción, el recurso, la marca de tiempo, el resultado y el contexto relevante de la petición. Los actores del sistema y de la automatización deben poder distinguirse de las sesiones humanas y de la suplantación. Bloquear o eliminar a un usuario conserva la atribución histórica.

La auditoría no es un log de depuración. Usa los logs operativos y los Tasks para los detalles de implementación, y la auditoría para la rendición de cuentas sobre seguridad y configuración. Exporta a un almacenamiento SIEM controlado de forma independiente cuando la retención o la correlación deban sobrevivir a un incidente de Opfield.

«Atribución inmutable» significa que los cambios en el ciclo de vida de las cuentas no reescriben el actor histórico asociado a un registro de auditoría. No significa que la base de datos de auditoría local sea un almacenamiento WORM ni que esté protegida criptográficamente contra manipulaciones de una persona que controle el host de Opfield, PostgreSQL, las copias de seguridad o las claves de cifrado. Esos administradores siguen dentro del límite de confianza.

Si la política exige pruebas que sobrevivan a un compromiso del plano de control, exporta los registros de auditoría de forma continua a un SIEM administrado de forma independiente o a un destino compatible con WORM, restringe allí la eliminación, sincroniza la hora y supervisa los huecos en la exportación. Mantén la política de retención externa y la revisión de accesos separadas de la administración de Opfield.

Lista de comprobación para investigar

1. Identifica el recurso y el efecto visible para el cliente.
2. Encuentra el registro de auditoría inicial y el ID de petición.
3. Encuentra el Task o la operación duraderos.
4. Compara el estado deseado con el estado actual del propietario.
5. Revisa unos logs operativos acotados.
6. Registra el reintento, la cancelación, la reversión y la verificación final.

Interpretación del éxito y del fallo

Un Task correcto significa que el flujo propietario llegó a su estado final documentado. No demuestra necesariamente la propagación del DNS, el acceso de clientes externos, la corrección a nivel de aplicación, la entrega de un correo, el procesamiento de los datos de un webhook ni la restauración de datos de negocio. Añade una verificación independiente adecuada al recurso.

Un Task fallido o interrumpido no demuestra que no se haya producido ningún efecto secundario. El propietario puede haber creado un contenedor, escrito un archivo, cambiado algo en un proveedor o completado una acción en el entorno de ejecución antes de que se perdiera la confirmación. Lee el estado actual del propietario y el historial de operaciones antes de limpiar o reintentar.

Los estados de espera deben identificar la dependencia o la entrada necesaria. Si un Task sigue en espera sin un responsable claro, conserva sus ID y escala en lugar de usar Force Cancel como limpieza rutinaria.

Mantenimiento y retención

Las tareas de mantenimiento (Housekeeping) eliminan los datos que Opfield ya no necesita, a diario a las 02:00 por defecto. Se configuran en Settings > Features > Housekeeping: housekeeping:view muestra la configuración, las estadísticas y el historial de ejecuciones, housekeeping:run inicia una ejecución y housekeeping:configure cambia las categorías y la programación. Cada categoría se puede desactivar. La categoría Audit Log conserva 90 días por defecto; exporta los registros de auditoría a un SIEM cuando la política exija una retención más larga.

Dos categorías añadidas en la 2.11 están activadas por defecto:

Categoría	Qué elimina
Operation History	Los Tasks terminados de contenedores Docker tras un día. Tras el periodo de retención, 90 días por defecto: los builds terminados con sus logs, los lotes de builds vacíos, las operaciones terminadas de Compose, Workload Availability y hosting, y las entregas de webhooks de orígenes Git. Cada recurso conserva sus 10 ejecuciones más recientes, y se conservan los registros que algo sigue usando: un artefacto de build, una ubicación de Availability, una instantánea o el origen de un nodo alojado
Expired OAuth Grants	Los códigos de autorización OAuth caducados y los tokens de acceso y de actualización caducados, y los clientes OAuth que llevan 90 días sin ninguna concesión. Un token de actualización se conserva hasta que caduca, para que se siga detectando su reutilización

Otras categorías cubren los logs de nginx, las alertas descartadas, las entregas de notificaciones, los logs estructurados, las tablas del sistema de ClickHouse, los artefactos de IA huérfanos, el registro interno, los volúmenes huérfanos, las claves retiradas de la PKI del sistema, los archivos de desafío ACME y las imágenes antiguas de Opfield.

Retención y pruebas externas

Las filas de auditoría no se pierden cuando Opfield se detiene. Al apagarse, Opfield escribe las filas todavía en tránsito antes de cerrar la conexión con la base de datos. Cuando la base de datos ya no está disponible, como en un apagado del host en el que todos los contenedores se detienen a la vez, una fila que no se puede escribir se añade a un archivo de spool en el volumen de datos de la aplicación (/var/lib/opfield/audit-spool) y se guarda en el siguiente arranque con su ID original, de modo que una repetición que se detiene a medias nunca añade una fila dos veces; la exportación a SIEM recoge las filas que guarda. Las instalaciones nuevas también detienen PostgreSQL con un smart shutdown, que espera hasta 75 segundos a que Opfield cierre sus conexiones; las instalaciones existentes obtienen esto la próxima vez que se recree su contenedor de PostgreSQL.

Conserva los registros de auditoría según la política de seguridad y de cumplimiento, y expórtalos a un almacenamiento SIEM controlado de forma independiente cuando las pruebas deban sobrevivir a una caída de Opfield o a un compromiso de un administrador. Los logs operativos de los Tasks pueden tener una retención y una sensibilidad distintas. No amplíes los payloads de auditoría con secretos o cuerpos de petición en bruto solo para facilitar la depuración.

Cuando proporciones pruebas al soporte o a otro equipo, incluye las marcas de tiempo, los ID estables, el estado final, los detalles del error depurados y el resultado de la verificación independiente. Elimina las credenciales, la topología interna, los datos de clientes, los prompts, las salidas de modelos y los logs sin restricciones.