Análisis operativo

1) Qué es el análisis operativo y por qué es necesario

La analítica operativa (Ops Analytics) es un ensamblaje de señales del sistema a partir de la observabilidad (métricas/logs/tracks), ITSM (incidentes/problemas/cambios), CI/CD (lanzamientos/confecciones), proveedores (PSP/KYC/CDC N/Cloud), FinOps (costos) y SLI empresarial (éxito de pago, registro), convertidos en escaparates y dashboards únicos para la toma de decisiones.

• reducir la MTTD/MTTR mediante la detección temprana y la atribución correcta de las causas;
• mantener bajo control el SLO y el presupuesto de errores;
• vincular los cambios → los impactos (comunicados/confecciones → SLI/SLO/quejas/costos);
• dar auto-servicio de análisis a los equipos y la gestión.

2) Fuentes y capa de datos canónicos

Telemetría: métricas (SLI/recursos), registros (sampling/revisión PII), tracks (trace_id/span_id, etiquetas de lanzamiento).
Módulos ITSM/Incident: SEV, timestamps T0/Detected/Ack/Declared/Mitigated/Recovered, RCA/CAPA.
CI/CD & Config: versiones, commits, canario/azul-verde, bandera-estate, confites objetivo.
Proveedores: estados/SLA, retrasos, códigos de error, pesos de ruta.
FinOps: costo por etiquetas/cuentas/tenantes, $/unidad (1k óperas.) .
DataOps: frescura del escaparate, errores DQ, lineage.

El principio clave es una sola correlación a través de identificadores: 'service', 'region', 'tenant', 'release _ id', 'change _ id', 'incident _ id', 'provider', 'trace _ id'.

3) Modelo único de datos (marco simplificado)

dim_service(service_id, owner, tier, slo_targets…)
dim_time(ts, date, hour, tz)
dim_region(region_id, country, cloud)
dim_provider(provider_id, type, sla)
fact_sli(ts, service_id, region_id, tenant, metric, value, target, window)
fact_incident(incident_id, service_id, sev, t0, t_detected, t_ack, t_declared, t_mitigated, t_recovered, root_cause, trigger_id, burn_minutes)
fact_change(change_id, type(code    config    infra), service_id, region_id, started_at, finished_at, canary_pct, outcome(ok    rollback), annotations)
fact_cost(ts, service_id, region_id, tenant, cost_total, cost_per_1k)
fact_provider(ts, provider_id, region_id, metric(latency    error    status), value)
fact_dq(ts, dataset, freshness_min, dq_errors)

4) SLI/SLO y métricas de negocio

Бизнес-SLI: `payment_success_ratio`, `signup_completion`, `deposit_latency`.
Тех-SLI: `availability`, `http_p95`, `error_rate`, `queue_depth`.
Capa SLO: objetivos + tasa burn (ventana corta/larga), anotaciones automáticas de infracciones.
Normalización: indicadores de 1k de operaciones/usuarios/tráfico exitosos.

5) Correlaciones y atribución de causas

Versiones/confecciones ↔ SLI/SLO: anotaciones en gráficos; Informes de causa y efecto (porcentaje de incidentes relacionados con cambios; Incidentes de cambio MTTR).
Proveedores ↔ negocio SLI: el peso de las rutas vs latency/error, la contribución de cada proveedor en los errores de SLO.
Capacidad/recursos ↔ latencia: sobrecalentamiento de las agrupaciones → crecimiento p95 → impacto en la conversión.

6) Anomalías y predicción

Anomalía-detecto: estacionalidad + umbrales percentiles + change-search fiches (antes/después del lanzamiento).
Predicción: patrones de carga semanales/estacionales, pronóstico de error de presupuesto de salida, predicción de costos ($/ed.) .
Gardrailes: alertas sólo para quórum de fuentes (synthetic + RUM + business SLI).

7) Vitrinas y dashboards (referencia)

1. Executive 28d: mezcla SEV, mediana MTTR/MTTD, SLO adherence, $/unit, razones superiores.
2. SRE Ops: SLI/SLO + burn-rate, Page Storm, Actionable %, Change Failure Rate.
3. Change Impact: lanzamientos/confecciones ↔ SLI/SLO/quejas, retrocesos y su efecto.
4. Proveedores: líneas de estado PSP/KYC/CDN, impacto en SLI de negocios, tiempos de respuesta.
5. FinOps: costo por 1k txn, registros/egress, anomalías de costos, recomendaciones (sampling, almacenamiento).
6. DataOps: escaparates frescos, errores DQ, pipelines SLA, éxito de backfill.

8) Calidad de los datos y gobierno

Contratos de eventos: esquemas claros para incidentes/lanzamientos/SLI (campos obligatorios, zonas horarias únicas).
Verificadores DQ: integridad, singularidad de las llaves, consistencia de la línea de tiempo (t0≤detected≤ack...).
Linj: desde el dashboard hasta la fuente (traceable).
PII/secretos: edición/enmascaramiento de políticas; WORM para la evidencia.
Frescura SLA: escaparates Ops ≤ 5 min de retraso.

9) Métricas de madurez de análisis operativo

Cobertura:% de servicios críticos en escaparates y bordes SLO (objetivo ≥ 95%).
Freshness: porcentaje de widgets con frescura ≤ 5 min (objetivo ≥ 95%).
Actionability:% de las transiciones de dashboard a acción (playbook/SOP/ticket) ≥ 90%.
Cobertura de detección: ≥ el 85% de los incidentes detecta la automatización.
Tasa de atribución: porcentaje de incidentes con causa confirmada y desencadenante ≥ 90%.
Change Impact Share: porcentaje de incidentes relacionados con el cambio (controlar la tendencia).
Calidad de datos: errores DQ/semana → ↓ QoQ.

10) Proceso: de datos a acciones

1. Recolección → limpieza → normalización del escaparate → (ETL/ELT, capa de características para ML).
2. Detección/pronóstico → escalamiento por matriz (IC/P1/P2/Comms).
3. Acción: playbook/SOP, puerta de lanzamiento, bandera de fichas, cambio de proveedor.
4. Evidence y AAR/RCA: línea de tiempo, gráficos, enlaces a lanzamientos/logs/tracks.
5. CAPA y soluciones de productos: priorización por minuto burn y $ -impacto.

11) Ejemplos de consultas (idea)

11. 1 Impacto de las versiones en SLO (24h)

sql
SELECT r. change_id,
COUNT(i. incident_id) AS incidents,
SUM(i. burn_minutes) AS burn_total_min,
AVG(CASE WHEN i.root_cause='code' THEN 1 ELSE 0 END) AS code_ratio
FROM fact_change r
LEFT JOIN fact_incident i
ON i.trigger_id = r. change_id
WHERE r. started_at >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY burn_total_min DESC;

11. 2 Proporción de problemas de los proveedores por región

sql
SELECT region_id, provider_id,
SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END) AS prov_inc,
COUNT() AS all_inc,
100. 0SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END)/COUNT() AS pct
FROM fact_incident
WHERE t0 >= DATE_TRUNC('month', NOW())
GROUP BY 1,2
ORDER BY pct DESC;

11. 3 Costo por 1k pagos exitosos

sql
SELECT date(ts) d,
SUM(cost_total)/NULLIF(SUM(success_payments)/1000. 0,0) AS cost_per_1k
FROM fact_cost c
JOIN biz_payments b USING (ts, service_id, region_id, tenant)
GROUP BY d ORDER BY d DESC;

12) Patrones de artefactos

12. 1 Esquema de evento de incidente (JSON, fragmento)

json
{
"incident_id": "2025-11-01-042",
"service": "payments-api",
"region": "eu",
"sev": "SEV-1",
"t0": "2025-11-01T12:04:00Z",
"detected": "2025-11-01T12:07:00Z",
"ack": "2025-11-01T12:09:00Z",
"declared": "2025-11-01T12:11:00Z",
"mitigated": "2025-11-01T12:24:00Z",
"recovered": "2025-11-01T12:48:00Z",
"root_cause": "provider",
"trigger_id": "chg-7842",
"burn_minutes": 18
}

12. 2 Directorio de métricas (YAML, fragmento)

yaml metric: biz. payment_success_ratio owner: team-payments type: sli target: 99. 5 windows: ["5m","1h","6h","28d"]
tags: [tier0, region:eu]
pii: false

12. 3 Tarjeta de informe del Ejecutivo (secciones)

1) SEV mix and MTTR/MTTD trends
2) SLO adherence and burn-out risks
3) Change Impact (CFR)
4) Providers: Degradation and switchover
5) FinOps: $/unit, log anomalies/egress
6) CAPAs: Status and Deadlines

13) Herramientas y patrones arquitectónicos

Data Lake + DWH: capa «cruda» para telemetría, escaparates para soluciones.
Procesamiento Stream: SLI/burn-rate near-real-time, fiches en línea para anomalías.
Feature Store: reutilización de fich (canario, estacionalidad, señales de proveedor).
Semantic Layer/Metric Store: definiciones de métricas unificadas (SLO, MTTR...).
Control de acceso: RBAC/ABAC, seguridad de nivel de fila para tenantes/regiones.
Catalog/Lineage: búsqueda, descripciones, dependencias, propietarios.

14) Hojas de cheques

14. 1 Lanzamiento de análisis operativo

• Se han aprobado diccionarios SLI/SLO, SEV, razones, tipos de cambio.
• Diagramas de eventos y temporizadores únicos.
• Conectores de telemetría, ITSM, CI/CD, proveedores, facturación.
• Vitrinas: SLI/SLO, Incidents, Changes, Providers, FinOps.
• Los dashboards están disponibles en Executive/SRE/Change/Providers.
• Se han configurado alertas de quórum y suppression en las ventanas de servicio.

14. 2 Revisión semanal de Ops

• Tendencias SEV, MTTR/MTTD, errores de SLO, burn-minutes.
• Change Impact y CFR, estado de retroceso.
• Incidentes providenciales y tiempos de reacción.
• FinOps: $/ed., anomalías de los registros/egresos.
• Estado de CAPA, atrasos, prioridades.

15) Anti-patrones

«Pared de gráficos» sin pasar a la acción.
Diferentes definiciones de métricas en los comandos (sin capa semántica).
La ausencia de anotaciones de lanzamientos/ventanas es una atribución débil de las causas.
Orientación a la media en lugar de p95/p99.
No hay normalización en el volumen - los grandes servicios «parecen ser peores».
PII en logos/vitrinas, violación de retenciones.
Datos «estancados» (> 5-10 min para widgets de tiempo real).

16) Hoja de ruta para la implementación (4-8 semanas)

1. Ned. 1: arreglos para el diccionario de métricas, esquemas de eventos, correlación de id; conectividad SLI/SLO e ITSM.
2. Ned. 2: escaparates de Incidents/Changes/Providers, anotaciones de lanzamientos; Executive & SRE dashboards.
3. Ned. 3: FinOps-capa ($/ed.) , ligamento con SLI; anomalía-bebé con quórum.
4. Ned. 4: self-service (semantic layer/metric store), catálogo y lineage.
5. Ned. 5-6: pronóstico de carga/costo, informes a proveedores, escaparate de CAPA.
6. Ned. 7-8: cobertura ≥95% Tier-0/1, frescura SLA ≤5 min, revisiones regulares Ops.

17) Resultado

La analítica operativa es una máquina de toma de decisiones: definiciones de métricas únicas, escaparates frescos, atribución correcta de causas y transiciones directas a playbooks y SOP. En un sistema de este tipo, el equipo detecta y explica rápidamente las desviaciones, evalúa con precisión el impacto de las versiones y los proveedores, administra los costos y reduce el riesgo sistémicamente, y los usuarios obtienen un servicio estable.