Observabilidad de negocio: medir el recorrido del cliente bancario

En banca, el cliente no ve servidores ni APIs. Ve si pudo entrar a la aplicación, si la transferencia llegó, si la tarjeta pasó en el comercio, si terminó de abrir su cuenta. Sin embargo, gran parte del monitoreo sigue midiendo lo que el cliente no ve: disponibilidad de servidores, tiempos de respuesta promedio, uso de recursos.

La observabilidad de negocio cierra esa brecha. Consiste en instrumentar los recorridos del cliente como transacciones de negocio, con métricas que el área de negocio entiende, y ponerlas al lado de las métricas técnicas. El objetivo es concreto: detectar una degradación cuando todavía afecta a pocos clientes, y saber qué componente la causa.

Por qué el semáforo técnico no basta

Una caída total se nota de inmediato. Lo difícil de detectar son las degradaciones parciales:

• Las transferencias a otros bancos fallan, pero las propias funcionan.
• Los pagos con tarjeta se rechazan solo en un tipo de comercio o con una marca de tarjeta.
• El inicio de sesión funciona en la web, pero falla en una versión concreta de la aplicación móvil.
• El alta de clientes se detiene en el paso de validación de identidad porque un proveedor responde lento.

En todos esos casos, los indicadores técnicos agregados pueden seguir en verde. La tasa de error global sube poco porque el segmento afectado es pequeño, y la latencia promedio apenas cambia. El primer aviso llega por el centro de atención telefónica o por redes sociales. Para entonces, el impacto ya es visible para el cliente y, a veces, para el regulador.

Recorridos como transacciones de negocio

Instrumentar un recorrido significa que cada paso relevante emite un evento con su resultado de negocio, no solo con su código HTTP. Una transferencia que responde 200 pero queda rechazada por fondos insuficientes es técnicamente correcta y de negocio fallida, y conviene distinguirla de una rechazada por un error del sistema.

Para cada recorrido conviene definir:

1. Los pasos: por ejemplo, para una transferencia: inicio, validación, autenticación reforzada, ejecución, confirmación.
2. El resultado de cada paso: éxito, rechazo de negocio (con motivo codificado) o error técnico.
3. Las dimensiones de segmentación: canal, versión de la aplicación, tipo de operación, banco destino, marca de tarjeta, región. Son las que permiten ver una degradación parcial.
4. La relación con la traza técnica: el evento de negocio debe compartir el identificador de traza, para pasar del "qué" al "por qué" en un clic.

Las plataformas APM, como Dynatrace o Datadog, permiten capturar parte de estos datos desde la configuración, por ejemplo extrayendo atributos de las solicitudes. Pero los resultados de negocio con significado (motivo de rechazo, paso del recorrido) suelen requerir que la aplicación los emita. Es el mismo principio de toda la observabilidad: plataforma observable no es lo mismo que aplicación observable.

Ejemplo de instrumentación con OpenTelemetry

Este fragmento en Python muestra la idea: un tramo de traza y un contador por resultado, con atributos de negocio y sin datos personales.

from opentelemetry import trace, metrics

tracer = trace.get_tracer("banca.transferencias")
meter = metrics.get_meter("banca.transferencias")

# Contador de transferencias por resultado de negocio
transferencias = meter.create_counter(
    "transferencias.resultado",
    description="Transferencias por canal, tipo y resultado",
)

def ejecutar_transferencia(solicitud):
    with tracer.start_as_current_span("transferencia.ejecutar") as span:
        # Solo atributos de baja cardinalidad y sin datos personales:
        # nunca número de cuenta, nombre, documento ni monto exacto
        atributos = {
            "canal": solicitud.canal,             # "app", "web"
            "tipo": solicitud.tipo,               # "propia", "interbancaria"
        }
        resultado = procesar(solicitud)           # lógica de negocio existente
        atributos["resultado"] = resultado.codigo # "ok", "rechazo_saldo", "error_tecnico"
        span.set_attributes(atributos)
        transferencias.add(1, atributos)
        return resultado

Métricas de negocio al lado de las técnicas

La tabla propone un punto de partida para cuatro recorridos frecuentes en banca. Las métricas son indicativas; cada entidad debe ajustarlas a sus productos y canales.

Recorrido	Métricas de negocio	Señales técnicas asociadas	Dimensiones útiles
Inicio de sesión	Inicios exitosos por minuto, proporción de éxito, abandonos en el segundo factor	Latencia del servicio de identidad, errores del proveedor de segundo factor	Canal, versión de la aplicación, método de autenticación
Transferencias	Transferencias completadas por minuto, rechazos por motivo, tiempo hasta la confirmación	Latencia del núcleo bancario, colas hacia la red de pagos, errores de integración	Tipo (propia o interbancaria), banco destino, canal
Pagos con tarjeta	Autorizaciones por minuto, proporción aprobada, rechazos técnicos frente a rechazos de negocio	Latencia del autorizador, tiempos de espera con la red de la marca, errores del módulo de fraude	Marca, tipo de comercio, presente o no presente, región
Alta de clientes	Altas iniciadas y completadas, abandono por paso, tiempo total	Latencia de los proveedores de validación de identidad, errores de carga de documentos	Canal, paso del recorrido, proveedor

Poner ambas métricas en el mismo tablero cambia la conversación en un incidente. El área de negocio ve cuántas operaciones se están perdiendo, y el equipo técnico ve en qué componente. Ambos hablan del mismo hecho.

Detectar la degradación parcial antes de la llamada

Las métricas de negocio tienen un patrón fuerte por hora, día de la semana y fechas especiales (pago de nóminas, fin de mes, campañas). Por eso, un umbral fijo como "menos de 100 transferencias por minuto" no sirve: es normal a las 3 de la mañana y alarmante a mediodía.

Funcionan mejor estas técnicas:

• Proporciones en lugar de volúmenes: la proporción de transferencias completadas sobre iniciadas es más estable que el volumen absoluto. Si baja, algo se rompió, aunque el volumen sea normal.
• Comparación con la línea base: contrastar con la misma hora de semanas anteriores, o usar la detección de anomalías de la plataforma, que aprende la estacionalidad.
• Segmentación: evaluar la proporción por dimensión (banco destino, marca, versión). Una caída en un segmento pequeño desaparece en el total y se ve con claridad en el desglose.
• Separar rechazos de negocio y técnicos: un aumento de rechazos por saldo insuficiente es un dato de negocio; un aumento de rechazos por tiempo de espera es un incidente.
• Objetivos de nivel de servicio por recorrido: definir un SLO sobre la proporción de éxito técnico de cada recorrido y alertar por la velocidad de consumo del presupuesto de error.

Las pruebas sintéticas complementan este enfoque. Un robot que inicia sesión y consulta saldo cada pocos minutos, desde varias ubicaciones, detecta problemas en horas de poco tráfico, cuando las métricas reales tienen pocos datos.

Privacidad: sin datos personales en la telemetría

La observabilidad de negocio acerca la telemetría a los datos del cliente, y ahí está el riesgo. Logs, trazas y métricas suelen tener más accesos, más copias y menos controles que la base de datos principal. Además, muchas veces se envían a plataformas externas.

Recomendamos reglas explícitas:

• Nada identificable en atributos, métricas ni logs: nombres, documentos de identidad, números de cuenta, números de tarjeta, correos, teléfonos, direcciones.
• Montos en rangos, no exactos, cuando el monto sea necesario para el análisis.
• Seudónimos solo si hacen falta para soporte, generados de forma que no se puedan revertir desde la plataforma de observabilidad, y con acceso restringido a la correspondencia.
• Filtrado en el origen y en el recolector: el Collector de OpenTelemetry permite eliminar o transformar atributos antes de enviarlos. Es una segunda barrera, no la primera.
• Retención y accesos definidos para la telemetría, igual que para cualquier otro repositorio de datos.
• Revisión de la instrumentación en el proceso de revisión de código, con una lista de campos prohibidos.

En España, el Reglamento General de Protección de Datos (RGPD) establece el principio de minimización de datos. En Latinoamérica, cada país tiene su propia ley de protección de datos personales. Para tarjetas, el estándar PCI DSS exige proteger los datos de titulares de tarjeta donde se almacenen, lo que incluye logs y otros repositorios de telemetría. El alcance exacto en cada caso debe validarse con las áreas de cumplimiento y protección de datos.

Cómo empezar

1. Elige un recorrido con alto volumen y dueño de negocio claro. Las transferencias o el inicio de sesión suelen ser buenos candidatos.
2. Dibuja sus pasos y resultados con negocio y desarrollo juntos, incluida la lista de motivos de rechazo.
3. Acuerda las dimensiones y los campos prohibidos antes de escribir código.
4. Instrumenta con OpenTelemetry o con las capacidades de la plataforma APM, conectando cada evento de negocio con su traza.
5. Construye un tablero compartido con las métricas de negocio arriba y las técnicas debajo.
6. Define el SLO del recorrido y sus alertas, y llévalas al centro de comando.

Con un recorrido funcionando, el siguiente es más sencillo: el modelo de eventos, las reglas de privacidad y el tablero ya existen.