Análisis de cambios y rendimiento

1) Objetivo y valor

La analítica de turnos es un sistema de medición que hace previsible el control de 24 × 7 operaciones: confirma la cobertura de SLO, identifica cuellos de botella (ranuras nocturnas, dominios sobrecargados), evita el agotamiento y mejora la calidad de los hendovers. Para iGaming, esto afecta directamente la velocidad de los depósitos/redes, los plazos KYC/AML y la reputación.

2) Taxonomía métrica

2. 1 Cobertura y preparación

Tasa de cobertura:% de horas con composición completa (por rol/dominio/región).
Lectura On-Call: proporción de turnos con IC/CL y contactos válidos asignados.
Handover SLA - cumplir con la ventana de transmisión (10-15 min) y la lista de verificación.

2. 2 Velocidad de reacción y recuperación

MTTA/MTTR (por ranuras Day/Swing/Night, por dominios): mediana, p90.
Detection Lead es un trago entre la degradación SLI y la primera acción.
Post-Release Monitoring Time es la observación real del lanzamiento.

2. 3 Calidad de transferencia de cambio

Handover Defect Rate - Elementos de lista de comprobación en blanco.
Info Drift es la divergencia de hechos entre el var room, el ITSM y el status channel.
Action Carryover es la proporción de tareas que «migraron» sin propietario/ATA.

2. 4 Carga y fatiga

Pager Fatigue: alertas/persona/semana, paginas nocturnas, P1/persona/turno.
Escalation Density: porcentaje de incidentes que han llegado a L2/L3 (contra el runbook-fix L1).
Idle vs. Busy Ratio: tiempo de descarga productiva vs. espera.

2. 5 Eficiencia y automatización

Auto-Fix Rate - Incidentes resueltos por autocaravanas/bot.
Runbook Usage es el% de las alertas cerradas en scripts estándar.
Primera solución de contacto (FCR): cierre en nivel L1 sin escalar.
Mean Time Between Incidents (MTBI) - Resistencia de dominio/ranura.

2. 6 Justicia y sostenibilidad

Fair-Share Index - La uniformidad de las noches/fines de semana por persona.
Replacement SLA: sustituciones confirmadas ≥48 h antes del cambio.
Coaching Coverage - Compartir los turnos con la ranura shadow para onboarding.

2. 7 Paquete de negocios

SLO Impact Score - cuánto tiempo el cambio mantuvo a SLO en la zona verde.
Revenue at Risk (proxy) - estimación de la pérdida de ingresos por P1/P2 en el turno.
Partner Latency/Declines - La contribución de los socios PSP/KYC a los incidentes de turnos.

3) Modelo de datos

3. 1 Grano de eventos

shift_event: comienzo/fin, composición, funciones (IC/CL/L1/L2), región, dominios.
alert_event: señal, prioridad, propietario, cierre, runbook/autocaravana.
incident_event: P1-P4, timelines, IC/CL, status-publishing.
handover_check: marcas de lista de verificación + defectos/comentarios.
release_watch: ventanas de vigilancia, puertas de seguridad, retrocesos automáticos.
worklog: minutos productivos (diagnósticos, ficks, comm updates, post mortem).
fatigue_signal: frecuencia de paginas/noches, horas trabajadas.

3. 2 Régimen (simplificado)

Ключи: `timestamp`, `tenant`, `region`, `environment`, `domain`, `role`, `severity`.
Opciones de almacenamiento: lake de eventos (parquet/iceberg) + preconexiones en DWH/TSDB.
Política PII: sólo agregados y alias; e-mail/ID se enmascaran.

4) Recopilación de datos (ETL)

1. ChatOps/bot: comandos '/handover ', '/incident', '/runbook '→ registro WORM.
2. ITSM: estados de incidentes/tickets, conjunto con var rooms.
3. Metrics API: SLI/SLO (auth-success, bet→settle p99, error-rate), KRI (queue lag, PSP declines).
4. Programador de turnos: calendarios, sustituciones, roles, shadow.
5. CI/CD: lanzamientos, ventanas de vigilancia, giros automáticos.

ETL normaliza, añade 'shift _ slot' (Day/Swing/Night), calcula métricas derivadas (MTTA/MTTR, Fair-Share).

5) Dashboards

5. 1 Exec (revisión semanal/mensual)

CFR, MTTR, Auto-Fix Rate, SLO Impact, Revenue-at-Risk (proxy).
Mapa de sobrecarga de ranuras y dominios (térmico).

5. 2 Ops/SRE (horario/diario)

Panel de tiempo real: P1-P4 abiertos, burn-rate, colas/replicaciones, guardrails.
Tarjeta Hendover de estado de lista de verificación y defectos.
Panel fatigue: paginas/persona, noches/persona (últimas 4 semanas), advertencias.

5. 3 Team/Domain

MTTA/MTTR por dominio, FCR, Runbook Usage, proporción de escalaciones por L2/L3.
Fair-Share y Replacement SLA para un equipo específico.

6) Fórmulas y umbrales

Tasa de cobertura = relojes cubiertos/168. Objetivo ≥ 99%.
Handover SLA =% de los turnos donde se realiza la transferencia y se cierra la lista de verificación ≤ 15 min (objetivo ≥ 95%).
Pager Fatigue (ned.) : p95 alertas/persona ≤ objetivo; advertencia a> p90.
Fair-Share Index = 1 − (σ noches/ target_nochey). Objetivo ≥ 0. 8.
Auto-Fix Rate ≥ 40% para L1 por trimestre (el objetivo depende de la madurez).
Runbook Usage ≥ 70% para alertas repetitivas (10 señales principales).

Tarjetas de control (X-MR, p-charts) para MTTA/MTTR y Tasa de defecto; alertas al ir más allá de los límites de control.

7) Métodos analíticos

Anomalías: STL/ESD/CUSUM por alertas y MTTA/MTTR, etiquetar outlaers y causas (lanzamiento, proveedor).
Predicción de carga: Prophet/ARIMA por alertas y P1/P2 a la ranura → planificación FTE.
Atribución de resultado: modelo uplift de cambios en los procesos (por ejemplo, una nueva plantilla hendover) → MTTR.
Experimentos de control: A/B en procesos internos (versión check-list, nuevo runbook).
Análisis de cohorte: rendimiento de principiantes (shadow→solo) vs. experimentados.

8) Integración

Incidente-bot: postea métricas de cambio, recuerda a un hendover sin abrir, empieza retro.
Release-portal: conecta las ventanas de lanzamiento con picos de carga; auto-pause con SLOs rojos.
Metrics API: listos para SLO-view + exemplars (trace_id) para RCA.
HR/PTO: factores de contracción (shrinkage) → planificación y análisis de fair-share.

9) Políticas y RACI

Ops Analytics Owner (SRE/Platform): modelo de datos, dashboards, métricas de precisión.
Service Owners: interpretación de señales de dominio, planes de mejora.
Duty Manager: análisis semanal de KPI/KRI, balance de ranuras.
Compliance/Sec: cumplimiento de PII/SoD en telemetría e informes.
Training Lead: los planes de onboarding a partir de las conclusiones de la analítica.

10) Patrones de artefactos

10. 1 Catálogo de métricas (YAML)

yaml apiVersion: ops.analytics/v1 kind: MetricCatalog items:
- id: coverage_rate owner: "SRE"
formula: "covered_hours / 168"
slice: ["region","slot","domain"]
target: ">=0.99"
- id: mtta_p50 owner: "Ops"
formula: "median(ack_ts - alert_ts)"
slice: ["slot","severity","domain"]
target: "<=5m (P1)"
- id: handover_defect_rate owner: "Ops"
formula: "defects / handovers"
target: "<=5%"
- id: pager_fatigue_p95 owner: "SRE"
formula: "p95(alerts_per_person_week)"
target: "<=team_threshold"

10. 2 Ejemplo de consulta (agregado SQL)

sql
SELECT slot, domain,
percentile_cont(0.5) WITHIN GROUP (ORDER BY ack_s-emit_s) AS mtta_p50,
percentile_cont(0.9) WITHIN GROUP (ORDER BY ack_s-emit_s) AS mtta_p90,
AVG(auto_fix)::float AS autofix_rate
FROM alerts_fact
WHERE ts BETWEEN:from AND:to AND severity IN ('P1','P2')
GROUP BY slot, domain;

10. 3 Hendover check-list (señales de calidad)

Resumen de SLO/SLI adjunto

Incidentes abiertos tienen propietarios/ATA

Trabajos programados/lanzamientos enlazados

Riesgos de proveedores registrados

Borradores comm listos

Los contactos on-call están actualizados

Watchlist actualizado

11) Gestión de riesgos y mejoras

KRI: crecimiento de DLQ/queue-lag en la ranura nocturna, caída de FCR <objetivo, aumento de Info Drift.
Plan de mejoras: Plan Ops semanal con propietarios/ATA en el top 3 fallas.
Post mortem de la disciplina de los turnos: retro por defectos de hendover y flapping alert.
Procesador A/B: comprobación del impacto de las nuevas regulaciones en MTTR/Auto-Fix.

12) KPI/OKR ejemplos (trimestre)

KR1: MTTR P1 (mediana) ↓ de 22 min a 15 min.
KR2: Handover SLA ≥ 95% en tres ranuras.
KR3: Auto-Fix Rate ≥ 45% para las 10 reglas de señalización superiores.
KR4: Pager Fatigue p95 ↓ en un 20% (después de optimizar la alerta).
KR5: Fair-Share Index ≥ 0. 85 en todos los equipos.

13) Hoja de ruta para la implementación (6-10 semanas)

Ned. 1-2: diagramas de eventos, ETL del bot/ITSM/Metrics API, primer catálogo de métricas, dashboards básicos.
Ned. 3-4: tarjetas de control y umbrales, panel fatigue, calidad handover, enlace con lanzamientos.
Ned. 5-6: predicción de carga (ranuras/dominios), fair-share y analítica de replacement.
Ned. 7-8: consejos de auto (que runbooks automatizar), informes de ROI de auto-fix, plantillas retro.
Ned. 9-10: experimentos en procesos (listas de comprobación A/B), KPI en paneles Exec, instrucción de comandos.

14) Antipattern

Contar «éxito de cambio» sólo por el número de tickets cerrados (sin contexto MTTR/SLO).
Ignorar los defectos de hendover («y así se entiende»).
Métricas sin normalización por volumen de tráfico/picos estacionales.
Personificación y «calificaciones de personas» sin tener en cuenta la complejidad/condiciones de entrada.
La ausencia de fair-share → el agotamiento y el aumento de los errores.
Correlación cero con lanzamientos/experimentos → conclusiones falsas.
Datos sin auditoría WORM y sin directiva PII.

Resultado

La analítica de turnos y rendimiento es un sistema de medición de producción en la parte superior de ChatOps, ITSM y telemetría: nítida taxonomía KPI/KRI, modelos de datos correctos, dashboards para diferentes roles, métodos estadísticos y relación con el efecto SLO/negocio. Este enfoque nivela las cargas, acelera la respuesta, reduce el agotamiento y mejora previsiblemente la calidad de las operaciones de la plataforma iGaming.