Métricas de Resiliencia y SLO en Codex — Medir Confiabilidad Antes del Fallo

Official References: Best Practices · Review · Worktrees · Automations

Por qué medir es un control de resiliencia

La confiabilidad deriva gradualmente antes de romperse de forma visible. Las métricas son el sistema de alerta temprana para esa deriva.

Set central de métricas

Diseño de SLO por severidad

• SEV-1: ventana estricta de contención + activación de rollback
• SEV-2: ventana de estabilización para degradación mayor
• SEV-3: ventana de cierre para release correctivo planificado

Los SLO deben ser numéricos y con owner asignado.

Protocolo de medición

Registra estos timestamps en cada incidente:

• inicio de incidente
• primera detección
• primera decisión de mitigación
• confirmación de estado estable
• cierre

Cadenas incompletas de timestamps reducen credibilidad analítica.

Revisión operativa semanal

1. revisar breaches de umbral
2. inspeccionar outliers de cola
3. mapear misses a buckets de control
4. asignar owner + fecha para regresiones de mayor impacto

Modelo de escalación por umbral

Define límites green/yellow/red por métrica. Si se toca red, exige:

• registro inmediato de escalación
• owner de confiabilidad nombrado
• re-check forzado en el siguiente ciclo

Reglas de calidad de dashboard

• mostrar tendencia y bandas percentiles
• separar clases de severidad
• incluir denominador y tamaño de muestra
• enlazar cada pico a notas de incidente

Bucle trimestral de calibración

Cada trimestre:

• elevar SLO solo tras logro sostenido
• retirar métricas no accionables
• agregar una métrica para nueva clase de fallo

El objetivo es calidad de decisión, no tamaño de dashboard.

Anti-patrones avanzados

Promediar el riesgo de cola

Los promedios ocultan eventos que causan incidentes.

SLO sin owner responsable

Un SLO sin owner deriva en teatro de estado.

Cierre con evidencia obsoleta

Pruebas antiguas no justifican confianza del estado actual.

Checklist rápido

Antes de revisión mensual de resiliencia:

• definiciones de métricas vigentes
• SLO por severidad publicados y con owner
• breaches red/yellow asignados explícitamente
• tendencia de cierre de follow-up revisada

Codex acelera ejecución. Las métricas protegen integridad de confiabilidad.

Diccionario de métricas (campos obligatorios)

Define cada métrica con esquema único:

### Metric Definition
- Name:
- Purpose:
- Formula:
- Data source:
- Collection cadence:
- Owner:
- Red threshold:
- Yellow threshold:
- Expected action on breach:

Definiciones ambiguas generan discusiones interminables en incidentes.

Política SLO tipo error budget

Define por severidad:

• número de breaches permitidos por trimestre
• umbral de escalación obligatoria
• regla de freeze al agotar presupuesto

Ejemplo

• SEV-1: cero tolerancia a incumplir ventana de contención
• SEV-2: más de 2 breaches trimestrales obliga revisión de controles
• SEV-3: seguimiento por tendencia

Preguntas de revisión semanal

1. ¿Qué métrica se movió más vs baseline?
2. ¿La variación es señal o ruido (muestra)?
3. ¿Quién es el owner de acción esta semana?
4. ¿En qué bucket de control cae la acción?
5. ¿Qué cambio esperamos ver para la próxima revisión?

Tabla de mapeo de escalación

Formato de resumen ejecutivo mensual

### Monthly Resilience Summary
- Top improving metric:
- Top regressing metric:
- Repeated breach classes:
- Controls added this month:
- Controls retired this month:
- Ownership risks:
- Next-month focus:

Mantén el resumen corto y accionable.

Checks de calidad de datos

Antes de confiar en el dashboard:

• ratio de timestamps faltantes
• incident IDs duplicados
• etiquetas de severidad inconsistentes
• latencia de refresco de fuentes

Métrica precisa sobre datos rotos sigue siendo engañosa.

Reglas anti-gaming

• no evaluar equipos por ranking de una sola métrica
• exigir enlaces de evidencia para mejoras grandes
• revisar percentiles de cola antes de celebrar promedios
• premiar tendencia sostenida, no picos de una semana

Estas reglas preservan integridad de métricas bajo presión organizacional.

Regla operativa del board de métricas

El board mensual solo produce tres salidas:

1. keep — la métrica sigue guiando acción
2. change — requiere ajuste de definición/umbral
3. remove — no aporta valor de decisión

Así se evita crecimiento de dashboard sin valor.

Seguimiento de riesgo de cola

Además del promedio, rastrea:

• p90 / p95 / p99 para MTTD y MTTR
• edad del follow-up más antiguo abierto
• intervalo de recurrencia del breach más severo

La cola muestra el riesgo real de incidente.

Playbook de breach SLO

Cuando ocurre breach:

• abrir registro el mismo día
• asignar owner y verifier
• definir control correctivo candidato
• fijar checkpoint de revisión en 7 días

Cierra solo con evidencia de efecto del control.

Criterios para retirar métricas

Retira una métrica cuando se cumpla todo:

• 2 trimestres sin acciones derivadas
• solapamiento alto con otra métrica
• stakeholders no explican uso práctico

Retira con nota explícita, no borrado silencioso.

Contrato métrica→acción

Cada métrica debe tener ruta de acción predefinida.

Sin contrato de acción, la métrica es decorativa.

Rúbrica de negociación SLO

Si hay desacuerdo en objetivos SLO, decide con:

1. severidad de impacto al cliente
2. baseline real de capacidad del sistema
3. reversibilidad de fallos en ese dominio
4. costo operativo de endurecer objetivo

Define SLO por economía de riesgo, no por optimismo.

Checks de confiabilidad del propio sistema métrico

Ejecuta semanalmente:

• ratio de completitud de timestamps
• consistencia de etiquetas de severidad
• tasa de incidentes duplicados
• retraso de refresco de fuentes

Equipos resilientes miden servicio y también calidad de medición.

Plantilla narrativa ejecutiva

Cada mes conecta métrica con acción:

• qué empeoró
• qué control se añadió
• qué mejoró tras el control
• qué sigue en riesgo alto
• quién es owner de la siguiente corrección

Esta cadena guía inversión correcta en confiabilidad.

Política de rotación de ownership de métricas

Rota owner secundario cada trimestre y mantiene un owner primario estable.

• primario: continuidad
• secundario rotativo: mirada fresca y detección de puntos ciegos

Esto evita estancamiento del sistema métrico.

Forecast de resiliencia

Añade sección mensual de forecast:

• banda esperada de MTTD/MTTR
• riesgo top de breach por severidad
• nivel de confianza del forecast
• controles planificados que afectan forecast

Así las métricas pasan de reporte a planificación.

Reconciliación alerta↔métrica

Revisión semanal:

1. alertas disparadas sin incidente asociado
2. incidentes sin alerta correspondiente
3. breaches no reflejados en dashboard

Estas brechas indican deriva del modelo de monitoreo.