Operaciones y Administración → Auditoría de métricas y SLA

Auditoría de métricas y SLAs

1) Por qué es necesario

Si las métricas son incorrectas - las soluciones serán incorrectas, los SLA serán violados «en el papel» o por el contrario ocultar los problemas. La auditoría de métricas y SLA garantiza la comparabilidad, credibilidad y seguridad legal de las promesas ante usuarios y socios.

• Proporcionar una única «fuente de verdad» (SSOT) y cálculos reproducibles.
• Reducir las discrepancias entre dashboards/informes/facturación.
• Hacer que el SLA sea factible y verificable (basado en la evidencia).
• Identificar las degradaciones en las mediciones es tan temprano como en los servicios.

2) Conceptos básicos y límites de responsabilidad

Métrica (métrica): magnitud a medir (RPS, p95, CR, GGR, tasa de éxito).
KPI/OKR: objetivos a los que están enlazadas las métricas.
SLO: calidad de servicio objetivo (por ejemplo, "p99 ≤ 400 ms 99. 9% del tiempo").
SLA: una promesa externa; legalmente significativo, basado en SLO.
OLA: un acuerdo interno entre equipos/vendedores, apoya a la SLA.
SSOT: sistema/almacenamiento cuyos datos se consideran de referencia para los informes.

3) Taxonomía de métricas (capas)

1. Infraestructura: CPU/Memory/IO/Net, pods/nodos, HPA/VPA.
2. Plataforma: colas/streams (lag, throughput), DB/caché (connects, hit), API (p95/p99, 5xx).
3. Flujos de negocios: depósitos/retiros, apuestas, lanzamiento de juegos, autorización, KYC.
4. Producto/marketing: conversiones, ARPPU/LTV, campañas.
5. Calidad de los procesos: MTTA/MTTR, Change Failure Rate, recubrimiento de listas de verificación.

Regla: cada métrica debe tener una capa, un propietario y una fórmula.

4) Fuentes de datos y «verdad»

Telemetría online: Prometheus/OTel, logs (ELK/ClickHouse), tracks.
Eventos y contabilidad: Kafka/Outbox, DWH/date-marts (BigQuery/ClickHouse).
Artefactos manuales: postmortems, tickets, registros de incidentes.
Registros externos: informes de proveedores (PSP/KYC/estudio), facturación.

Solución del conflicto: en las discrepancias «online vs DWH», existe un reglamento de prioridad (por ejemplo, para SLA, unidades de DWH con trazabilidad de origen).

5) Proceso de auditoría de métricas (contorno de control)

1. Inventario: catálogo de métricas/SLO/SLA (nombre, propietario, capa, fórmula, fuente, frecuencia de cálculo).
2. Verificación de fórmulas: conciliación de solicitudes SQL/prom con definición (pruebas de cálculo unitario).
3. Sampling y revisiones: muestreo de cadenas de eventos/registros y conciliación manual.
4. Correlación de contornos: comparación de dashboards en línea y informes DWH.
5. Control de cambios: ruge de fórmulas durante lanzamientos de esquemas/lógica.
6. Auditoría de SLA: comprobación de la corrección de conjuntos y excepciones (mantenimiento planificado, fuerza mayor).
7. Informe y mejoras: enumera las discrepancias y las ficciones detectadas con los Deadline.

6) Definiciones y fórmulas (muestras)

• `success = requests - (5xx + timeouts + circuit_open)`
• `success_rate = success / requests`

• en SSOT se fija una única definición de ventana (rolling 5m/1h) y agregación (HDR/TDigest).

• 'SLO _ availability _ month = (tiempo de ejecución - excepciones _ válidas )/tiempo _ total'

• `SLA_month = 99. El 90% del aptime en la ventana UTC, excluyendo las ventanas programadas (aviso T-48), los accidentes probados en los operadores de tránsito (documentos) "

7) Calidad de los datos: comprobaciones y alertas

• Полнота (completeness): `received_events / expected_events ≥ 0. 99`.
• Puntualidad (timeliness): valor de carga ≤ N minutos.
• Singularidad (uniqueness): sin tomar las llaves (idempotency-key).
• Consistencia (consistency): importes/moneda/signos.
• Linealidad (monotonicity): los contadores no «retroceden».

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) Auditoría SLA/OLA: metodología

1. Recoge el calendario de excepciones: ventanas programadas, degradaciones acordadas, actos de vendedores.
2. Cálculo del aptime: por zona horaria única, con apoyo de SSOT.
3. Conciliación con incidentes: tiempo en línea, entradas, post mortem.
4. Atribución: fallos propios, proveedor, tránsito, DDoS, funcionamiento reglamentario.
5. Perímetro SLA: experiencia de usuario (E2E) vs una API específica.
6. Informe: informe por mes/trimestre: hecho, desviaciones, indemnizaciones (si corresponde), medidas correctivas.

9) Verificación de la reproducibilidad de los cálculos

Versificación de fórmulas: repositorio Git con especificaciones SQL/PromQL/dock.
Pruebas unitarias de métricas: en datos sintéticos (casos edge: saltos, tomas, límites de fechas).
Línea de datos: desde el tablero de regreso a las tablas y eventos originales.
Snapshots: congela los datos por corte para que los cálculos de plumas sean comparables.

10) Muestras de control (sampling)

Diariamente: 10-20 eventos en los flujos clave (depósito/tasa/CUS) - la conciliación manual del trazado ↔ DWH.
Semanal: 1% de sample para comparar «online vs DWH» por agregados.
Mensual: conjunto de incidentes con efecto SLA - reconstrucción detallada.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Auditoría de dashboards y alertas

Diccionario único de métricas: glosario directamente en el dashboard.
Anotaciones de lanzamientos/eventos: para ver la causa de las desviaciones.
Comparación «antes/después de la liberación»: paneles de regresión automáticos.
Dobles/discrepancias: identificar «dos p99 diferentes» - editar fórmulas/ventanas.
Disponibilidad de paneles: derechos, reserva, control de enlaces/versiones.

12) Gestión de cambios en las métricas

Proceso RFC: cambio de fórmula/ventana/origen - a través de RFC con evaluación de impacto en SLA/informes.
Migración «expand → migrate → contract»: mantenemos temporalmente ambas versiones, comparamos, luego apagamos la antigua.
Comunicaciones: notificar con antelación al producto/negocio los cambios en los valores «según la nueva técnica».

13) Especificaciones de iGaming/fintech

Picos de demanda: las métricas deben soportar cargas explosivas (las agregaciones no se «vierten»).
Proveedores: SLA depende de los vendedores de OLA → almacenar sus informes, estados de incidentes y cuotas.
Coste: 'coste _ per _ 1k _ calls' y' coste de éxito 'son paneles obligatorios.
Antifraude/riesgo: sensibilidad a retrasos y «falsos positivos» de las métricas.

14) Auditorías Dashboards (conjunto mínimo)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence: SLO calculado, SLA real, excepciones, referencias a incidentes/actos.
Compare en línea vs DWH: p95/p99/Success Tasa, desviaciones y tendencias.
Vendor SLA: aptime/cupos/tiempos de espera/costo en el corte de proveedores.
Efecto Release: regresiones de métricas después de poner/encender un fich.

15) Lista de comprobación de cuentas (operativo)

• El catálogo de métricas/SLO/SLA con propietarios y fórmulas es relevante.
• El SSOT se define para cada informe/panel.
• Las pruebas de fórmula unit son verdes, los cálculos de paipelines están documentados.
• Las alertas de calidad de datos están activas (completeness/timeliness/duplicates).
• «Online vs DWH» discrepancia ≤ un umbral válido (por ejemplo, ≤2%).
• Las exenciones de SLA acordadas están documentadas y se adjuntan al informe.
• Se realizaron muestras de control y se formalizaron los actos.
• Todos los cambios de fórmula han pasado por RFC y migración.

16) Ejemplos (fragmentos)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) Anti-patrones

Dos fórmulas diferentes de «una» métrica en diferentes paneles.
Cambiar la métrica sin migración y aviso - «saltos» en OKR/SLA.
Informes en Excel local como «verdad» (no reproducible).
Mezcla de zonas horarias y calendarios en cálculos SLA.
Las excepciones de SLA no están documentadas.
No hay alertas para la calidad de las mediciones.

18) KPI de madurez de medición

Drift Rate Online↔DWH (objetivo ≤2%).
Metrics Health Uptime (tiempo sin degradación ingest/ETL).
Time-to-Fix Formula (tiempo de eliminación de errores en la fórmula).
SLA Dispute Rate (frecuencia de casos controvertidos con socios).
Coverage SLO/SLA (proporción de rutas críticas con SLO/SLA formalmente descritas).

19) Funciones y responsabilidades

Propietario de la métrica/servicio: fórmula, fuente, dashboard, alertas.
Observabilidad/SRE: SSOT/plataforma, pruebas de fórmula, alertas de calidad de datos.
Data/BI: DWH, reproducibilidad de informes, lineage.
Abogados/gerentes asociados: acuerdos de SLA y excepciones.
Gerente de incidentes: atribución y conjunto de incidentes con SLA.

20) Inicio rápido (30 días)

Semana 1: inventario de métricas/SLO/SLA y propietarios; asignar SSOT.
Semana 2: habilitar alertas de calidad de datos y el panel «Online vs DWH».
Semana 3: realizar muestreos de control, alinear la ventana p95/p99.
Semana 4: formalizar el proceso de RFC para fórmulas, preparar un informe mensual de SLA con aplicaciones.

21) FAQ

P: ¿Qué cuenta SSOT para SLA?
R: Almacenamiento con cálculos reproducibles (DWH) y línea completa; paneles en línea - para el control operativo, no para los actos legales.

P: ¿Cómo lidiar con «dos p99»?
R: Fijar la ventana/método de agregación en el directorio de métricas, migrar los paneles, agregar una alerta a la deriva.

P: ¿Cómo se tienen en cuenta los trabajos programados?
R: Mantener un calendario de excepciones y deducirlas automáticamente del SLA según las reglas del contrato; almacenar los artefactos de confirmación.