Dashboard operativo

(Sección: Operaciones y Gestión)

1) Nombramiento y principios

El dashboard operativo es una «ventanilla única» para monitorear la salud de la plataforma y tomar medidas. Agrega métricas, eventos, alertas e indicadores de negocio en el contexto del rol de usuario (SRE, Producto, Finanzas, Compliance, Support, Partners).

• Actuable por diseño: cada widget tiene un botón de acción (rollback, pauze, re-run, re-route).
• Role-aware: los derechos y los niveles de detalle dependen del rol/tenant/región.
• Fuente-de-verdad: los números convergen con facturación/registros/recibos.
• Near-real-time + historicidad: segundos/minutos para incidentes, meses/años para tendencias.
• Explainability: cualquier agregado se despliega antes de un evento crudo con 'trace _ id'.

2) Roles y escenarios (quién y por qué viene)

SRE/Plataforma: disponibilidad, latencia p50/p95/p99, error/retroceso, capacidad, costo por 1k eventos.
Producto/Operaciones: E2E-Success Tasa, conversión, tiempo de onboarding de socios, flagelación.
Finanzas/FinOps: ingresos/COGS/CM por unidad, egress/ingress, presupuestos y caps, desviaciones.
Cumplimiento/Seguridad: recibos/firmas, solicitudes PII, infracciones SoD, estado de las recertificaciones.
Support/CS: cola de tickets, MTTA/MTTR, SLA por socios y regiones.
Socios/Tenantes: métricas propias de SLO, estados de webhooks, usage y cuotas.

3) North Star y SLI/SLO clave

North Star: E2E Tasa de éxito en rutas críticas con p95 objetivo en cada región.

• Disponibilidad por canal/región.
• Latencia p50/p95/p99.
• Error-rate y proporción de retraídas.
• Éxito de las entregas de webhooks (% con recibos).
• El costo de 1k eventos y egress/ingress por unidad.
• Resumen de incidentes: MTTA, MTTR, error-budget burn.

• Disponibilidad ≥ 99. 95 %/región/canal.
• p95 ≤ 120 ms (escaparate), ≤ 250 ms (checkout/quote).
• Éxito de webhooks ≥ 99. 5% por 5 minutos. ventana.
• Δ entre quote y checkout = 0 (± 1 unidad menor según las reglas de distribución).
• Tiempo de reacción a P1 ≤ 10 min, MTTR ≤ 60 min.

4) Arquitectura de datos de dashboard

Bus de eventos: telemetría (traces/metrics/logs), eventos empresariales, facturación, cumplimiento.
Streaming/agregaciones: ventanas T + 5s/T + 1m para near-real-time; CDC/outbox para entrega garantizada.
Repositorios: series de tiempo (en línea), OLAP (larga historia), registros WORM (auditoría).
Capa semántica: diccionario de métricas, unidades de medida, normalización por regiones y tenantes.
Enlace en materia prima: drill-down a 'trace _ id '/' event _ id' y firmas (receipt_hash).

5) Diseño de interfaz y widgets

Gorro global: filtros (tiempo, región, tenant, producto, entorno), indicadores de estado.
Azulejos (KPIs): E2E Éxito, disponibilidad, p95, error-rate, costo/1k, egress.
Gráficos: sparkline tendencias, heat-map por región, gráficos percentil.
Tablas: errores superiores, socios con degradación, exceso de cuotas, incidentes no resueltos.
Secciones de acción: «Pausa promo», «Revertir fichas», «Aumentar cuota», «Reiniciar entrega».
Context-help: sugerencias sobre métricas/técnicas y relación con SLO.

6) Módulos de dashboard (conjunto recomendado)

1. Plataforma de salud: disponibilidad/latencia/errores, burn-down error-presupuesto.
2. Integraciones de socios: estado de webhooks, recibos, tomas idempotentes, lag colas.
3. Checkout & Precios: cumplimiento vitrina↔checkout, 'fx _ version', 'tax _ rule _ version', casos de fallo.
4. Contenido/Directorios: tiempo de publicación, errores de caché/inválido, freshness.
5. RTP & Limits (si corresponde): teor. vs observed RTP, activación de límites, exposición.
6. FinOps: COGS/unit, egress/ingress, compute/storage, presupuestos/cap-alert.
7. Seguridad/Cumplimiento: SoD, JIT, MFA, operaciones firmadas, solicitudes PII y registros.
8. Soporte: colas, MTTA/MTTR, causas, runbooks automáticos.
9. Release/Feature Flags: estados de lanzamiento, regiones canarias, autoliquidación de regresiones de incidentes.
10. Experimentos: Guardrails A/B, influencia del fich en SLI/ROI.

7) Alertas, runas y escaladas

Alertas de nivel P1-P3 con cancelación de ruido y deduplicación por 'trace _ id'.
Auto-runbooks: cuando se activa, se inician las comprobaciones/ficks (limpieza de caché, cambio de routing, pausa promocional).
Escalaciones: matriz 24 × 7, respuesta SLO, canales (chat/voz/SMS), «botón rojo».
Post-incident: plantillas de informes con relaciones causales y acciones items.

8) Multirregional y multi-tenant

Cortes: región/tenant/canal/proveedor, SLO independientes y presupuestos.
Zonas de confianza: datos PII/finanzas - sólo visibles en las áreas correspondientes, el resto son agregados.
Costo-aware: comparación de rutas por precio a la misma p95; recomendaciones de optimización.

9) Seguridad y privacidad

RBAC/ABAC: visibilidad y acciones sobre los roles; ReBAC para la propiedad del producto/tenant.
Firmas y recibos: para eventos financieros/críticos - hashes y recibos DSSE.
Higiene PII: tokenización, enmascaramiento, acceso sólo a través de jobes aprobados.
Auditoría: registros WORM para cambios en configuraciones/roles/límites, reproducibilidad.

10) Modelo de datos métricos (ejemplo)

`metric` `{name, unit, type: counter/gauge/hist, owner, sla_ref}`

`dim` `{region, tenant, product, provider, version, environment}`

`point` `{metric, value, ts, dims{}, trace_id, signature?}`

`event` `{type, severity, subject_id, payload_hash, receipt_hash, ts}`

`slo` `{name, target, window, burn_rate, owners[], runbook_url}`

`alert` `{slo_ref, condition, status, ack_by, acknowledged_at, runbook_step}`

11) API/webhooks de dashboard

'POST/ingest/metrics' - recepción de métricas (esquema, límites, autenticación).
'POST/ingest/events' - Eventos empresariales (versiones/firmas).
`GET /kpis? filters... '- agregados para widgets.
'GET/traces/{ trace _ id}' es una promoción profunda.
Вебхуки: `IncidentRaised`, `QuotaCapReached`, `PriceMismatch`, `WebhookDeliveryLag`, `SecuritySoDViolation`.

12) Calidad de los datos y pruebas

Contratos de datos: esquemas y validación en recepción, versionamiento ('expand → migrate → contract').
Anomalías: monitoreo de pases/saltos, umbrales «flatline »/» noise».
Sampling: para métricas de alta QPS - deslizante, manteniendo la representatividad.
Backfill: descargas inversas seguras marcadas con la versión.

13) Métricas del propio dashboard (métricas métricas)

Disponibilidad de UI/API ≥ 99. 9%.
Latency p95 consultas a la API ≤ 300 ms.
Completeness: la proporción de fuentes que enviaron datos a la ventana ≥ 99. 5%.
Freshness: trae actualizaciones incrementales ≤ 30 s.
Corrección: discrepancia con los informes de referencia ≤ 0. 1%.

14) Economía y FinOps en dashboard

Costo por 1k eventos con descomposición por proveedor/región.
Tarjetas térmicas Egress/Ingress, recomendaciones de almacenamiento en caché/routing.
Presupuestos/cap-alertas: 80/90/100%, autotrotling y priorización.

15) Disponibilidad y UX

Tema nocturno, firmas breves, iconos de estado.
Navegación por teclado y a11y: contraste, alt, aria-etiquetas.
Presets guardados: «SRE de turno», «finanzas», «socio».
Snapshots y Sharing: fijar el estado con filtros y referencia/exportación.

16) Riesgos y anti-patrones

Dash-sprawl: 20 dashboards diferentes sin un solo diccionario de métricas.
Vanity-métricas: gráficos hermosos sin conexión con SLO/acciones.
Incompatibilidad de números: informes ≠ facturación/auditoría.
Alertas ruidosas: cansancio y pases P1.
Ausencia de drill-down: es imposible llegar a la primaria y las causas.

17) Lista de verificación de implementación

• Definir roles y escenarios; acordar Norte Star y SLI/SLO.
• Crear un diccionario de métricas y unidades; formalizar los contratos de datos.
• Configurar ingest (metrics/events/traces), OLAP y auditoría WORM.
• Implementar módulos clave (salud, socios, checkout, FinOps, Seguridad).
• Incluir alertas con runas y escaladas; «botón rojo».
• Añadir acciones: rollback/pause/re-route/raise-limit.
• Construir heat-map por región/tenante; filtros y presets.
• Verifique el resultado de los dígitos con facturación/recibos.
• Juego-día (GameDay): desconexión del proveedor, avalancha de retiros, resincronización de precios.
• Revuelo semanal SLO y calidad post-mortem.

18) RACI

19) FAQ

¿Se pueden reemplazar todos los informes por un dashboard?
No. Dashboard - para la operatividad y la acción; informes/auditorías formales - artefactos separados.

¿Cuánto «tiempo real» se necesita?
Para los incidentes - segundos/minutos, para la economía - minutos/horas; lo importante es la coherencia, no la «noción en línea» absoluta.

¿Cómo lidiar con el ruido de las alertas?
Condiciones orientadas a SLO, agregación, deduplicación por 'trace _ id', priorización y runbooks automáticos.

¿Cómo puedo comprobar que las métricas son correctas?
Conciliaciones regulares con informes de referencia, feeds de prueba, muestras de control y registros WORM.

Resumen: El dashboard operativo no es un «tablero hermoso», sino una herramienta de control: SLI/SLO unificados, acciones desde la interfaz, seguimiento a la materia prima y estricta coherencia con facturación y auditoría. Construirlo en una arquitectura de eventos, dar contexto por roles, agregar runas y escalar, y obtendrá operaciones predecibles, soluciones rápidas y crecimiento sostenido.