Añadir trazabilidad, observabilidad y auditoría

Un workflow no está preparado para producción si solo sabes que “ha fallado”. Necesitas poder responder qué caso se estaba procesando, en qué estado, qué evento ocurrió, qué integración respondió, qué decisión se tomó y qué efecto produjo.

La observabilidad técnica y la trazabilidad de negocio se relacionan, pero no son lo mismo. OpenTelemetry utiliza señales como trazas, métricas y logs para observar sistemas distribuidos y permite correlacionarlas mediante contexto. El workflow, además, necesita un historial de negocio capaz de reconstruir la evolución del caso aunque cambie la implementación técnica.

Usa una identidad de extremo a extremo

Conserva un identificador de caso desde el evento inicial hasta el cierre. Añade identificadores técnicos —request ID, event ID, trace ID, job ID— cuando correspondan, pero mantén una relación con la unidad de negocio.

No es necesario que todos los sistemas utilicen el mismo ID internamente. Sí debe existir una forma fiable de correlacionarlos.

Ejemplo:

• case_id: solicitud comercial;
• event_id: evento concreto;
• trace_id: ejecución distribuida;
• operation_id: acción idempotente;
• document_version_id: versión del presupuesto.

Cada identificador responde una pregunta diferente.

Diseña un historial de negocio

El historial debe registrar cambios significativos del caso, no cada detalle interno del código.

Para un evento de negocio conserva, cuando sea relevante:

• caso;
• estado anterior;
• evento;
• estado nuevo;
• actor o sistema;
• timestamp;
• decisión aplicada;
• versión del objeto afectado;
• resultado;
• referencia a evidencia.

Este historial permite explicar por qué un caso terminó en determinada situación incluso si los logs técnicos ya no están disponibles.

Distingue señales operativas

Eventos de negocio

Describen lo que ocurrió en el proceso: solicitud recibida, aprobación concedida, documento generado, caso cancelado.

Métricas

Agregan medidas en el tiempo: duración de cada estado, porcentaje de errores, volumen de excepciones, reintentos por integración o casos que superan un plazo.

Logs

Registran detalles discretos útiles para diagnosticar ejecución. Deben evitar incluir secretos o contenido sensible innecesario.

Trazas

Permiten seguir una petición o transacción distribuida a través de componentes. Son especialmente útiles cuando una operación cruza API, cola, worker y servicio externo.

No intentes convertir cada señal en otra. Un log no sustituye una métrica y una traza técnica no reemplaza el historial de negocio.

Define indicadores que conduzcan a una acción

Medir por medir crea ruido. Cada indicador operativo debería responder qué decisión tomarás si cambia.

Ejemplos:

• tiempo p95 en pendiente_aprobacion;
• porcentaje de casos que necesitan aclaración;
• tasa de reintentos por integración;
• número de operaciones con estado incierto;
• porcentaje de propuestas de IA enviadas a revisión;
• casos cerrados sin resultado válido.

Evita usar solo medias cuando los extremos importan. Una duración media aceptable puede ocultar un grupo pequeño de casos bloqueados durante días.

Diseña alertas con contexto

Una alerta útil debería indicar qué condición se incumplió y permitir localizar los casos afectados. “Error 500” es insuficiente si el equipo no sabe qué proceso empresarial está impactado.

Define:

• señal;
• umbral o condición;
• ventana temporal;
• severidad;
• responsable;
• enlace o consulta de diagnóstico;
• acción inicial esperada.

No configures alertas para cada evento individual si solo generarán fatiga.

Protege el registro

La observabilidad puede convertirse en una fuga de información si los logs contienen prompts completos, documentos, tokens, datos personales o secretos.

Diseña desde el principio:

• qué campos pueden registrarse;
• qué debe enmascararse;
• cuánto tiempo conservar cada señal;
• quién puede acceder;
• qué eventos necesitan evidencia más duradera por motivos operativos o de auditoría.

No asumas que “más logging” equivale a mejor observabilidad.

Ejemplo: seguimiento de presupuesto

Una solicitud entra como REQ-42. El workflow genera eventos de negocio para recepción, validación, creación de borrador y aprobación. La llamada al ERP genera una traza técnica correlacionada. Si el ERP supera el timeout, la métrica de latencia registra la degradación y el caso pasa a estado_incierto_erp.

El operador puede reconstruir la secuencia sin leer el contenido completo del correo: identifica el caso, la integración afectada, el intento, la respuesta y el estado de recuperación.

Ejercicio: plan de señales

Para tu workflow diseña:

1. esquema mínimo del historial de negocio;
2. cinco eventos que siempre deben quedar registrados;
3. cinco métricas operativas;
4. tres trazas o interacciones donde necesites correlación distribuida;
5. tres alertas con responsable y acción;
6. campos que nunca deben aparecer en logs;
7. política inicial de retención por tipo de señal.

Decisión resultante

El workflow ya puede explicarse y operarse. Puedes reconstruir la evolución de un caso, correlacionar fallos técnicos y observar tendencias que exigen intervención. La siguiente fase es probar el diseño de forma deliberada antes de convertirlo en implementación.