Plantilla de Regresión de Rendimiento

Visión General

Las regresiones de rendimiento son invisibles hasta que son dolorosas. Un aumento del 20% en la latencia después de un release pasa desapercibido durante semanas, y de repente tu cliente más grande se va porque su integración de API expiró. Hacer benchmarking no es suficiente — necesitas una forma estructurada de comparar métricas antes/después, identificar causas raíz y decidir si hacer rollback o avanzar con el arreglo. Esta plantilla crea un proceso repetible para detectar, analizar y resolver regresiones de rendimiento.

Cuándo Usar

Usa este recurso cuando:

• Tu pipeline de releases carece de puertas automáticas de rendimiento
• Un despliegue reciente degradó los tiempos de respuesta o aumentó el consumo de recursos
• Estás estableciendo presupuestos de rendimiento y necesitas una forma de hacerlos cumplir

Solución

# Reporte de Regresión de Rendimiento: `<Release / Feature>`

## 1. Resumen de la Regresión

| Campo | Valor |
|-------|-------|
| Release | `versión / commit` |
| Fecha Detectada | `AAAA-MM-DD` |
| Detectado Por | `Benchmark de CI / alerta de APM / reporte de cliente` |
| Severidad | `Crítica (> 50%) / Alta (> 20%) / Media (> 10%) / Baja (< 10%)` |
| Estado | `Investigando / Causa raíz identificada / Arreglo desplegado / Resuelta` |
| Responsable | `@nombre` |

## 2. Comparación de Benchmarks

### 2.1. Latencia

| Métrica | Línea Base | Actual | Delta | Umbral | ¿Excedido? |
|---------|------------|--------|-------|--------|------------|
| P50 | `X ms` | `Y ms` | `+Z%` | `+10%` | Sí / No |
| P95 | `X ms` | `Y ms` | `+Z%` | `+15%` | Sí / No |
| P99 | `X ms` | `Y ms` | `+Z%` | `+20%` | Sí / No |

### 2.2. Throughput

| Métrica | Línea Base | Actual | Delta | Umbral | ¿Excedido? |
|---------|------------|--------|-------|--------|------------|
| RPS | `X` | `Y` | `+/- Z%` | `-10%` | Sí / No |

### 2.3. Utilización de Recursos

| Métrica | Línea Base | Actual | Delta | Umbral | ¿Excedido? |
|---------|------------|--------|-------|--------|------------|
| CPU | `X%` | `Y%` | `+Z%` | `+20%` | Sí / No |
| Memoria | `X%` | `Y%` | `+Z%` | `+20%` | Sí / No |
| Disco I/O | `X MB/s` | `Y MB/s` | `+Z%` | `+30%` | Sí / No |

## 3. Análisis de Causa Raíz

| Hipótesis | Evidencia | ¿Validada? | Responsable |
|-----------|-----------|------------|-------------|
| | | | |

### Pasos de Diagnóstico Realizados

1. Correlacionar la regresión con el tiempo de despliegue
2. Revisar cambios de código en el diff del release
3. Revisar planes de consulta de la base de datos para nuevas queries o cambios de schema
4. Profilear CPU y memoria (flame graphs, heap dumps)
5. Revisar latencia de servicios downstream
6. Verificar cambios de infraestructura (tipo de instancia, eventos de escalamiento)
7. Revisar tasas de acierto de caché y patrones de evicción
8. Verificar jobs en segundo plano o procesos batch que coincidan con pico de tráfico

## 4. Plan de Acción

| Acción | Responsable | Fecha Límite | Estado |
|--------|-------------|--------------|--------|
| | | | |

### Decisión: ¿Rollback o Fix Forward?

| Criterio | Rollback | Fix Forward |
|----------|----------|-------------|
| Severidad | Crítica o Alta | Media o Baja |
| Tiempo para Arreglar | > 4 horas estimadas | < 2 horas estimadas |
| Riesgo de Rollback | Bajo (rollback probado) | Alto (migración irreversible) |
| Impacto a Clientes | > 5% de usuarios afectados | < 5% de usuarios afectados |
| **Decisión** | [ ] | [ ] |

## 5. Verificación Después del Arreglo

- [ ] Re-ejecución de benchmark muestra métricas dentro del 5% de la línea base
- [ ] Dashboards de APM muestran tendencia estable por 24 horas
- [ ] No hay nuevas alertas disparadas post-despliegue
- [ ] Tests sintéticos orientados al cliente pasan
- [ ] Utilización de recursos regresó a la línea base
- [ ] Revisión post-arreglo documentada en tracker de incidentes

Explicación

La plantilla fuerza una decisión cuantificada en lugar de una corazonada. Muchos equipos o hacen rollback a todo pánico o nunca hacen rollback y dejan que el rendimiento se degrade. Las tablas de comparación hacen visible la regresión con números, y la matriz de decisión rollback/fix-forward elimina la ambigüedad. Los pasos de diagnóstico están ordenados por frecuencia: la mayoría de las regresiones son causadas por una mala consulta, una caché faltante, o una lentitud downstream — no por problemas exóticos de infraestructura.

Variantes

Contexto	Métricas Clave	Consideración Especial
Web / API	P50, P95, P99 latencia; RPS; tasa de error	Enfocarse en percentiles orientados al usuario
Backend móvil	Latencia de API, tamaño de payload, impacto en batería	Considerar costos de transferencia de datos
Base de datos	Latencia de consulta, uso de pool de conexiones, lag de replicación	Cambios de planes de consulta después de migraciones
Batch / ETL	Duración de jobs, throughput, costo de recurso por registro	Costo por ejecución de job, no solo velocidad
Microservicios	Latencia entre servicios, disparos de circuit breaker, tormentas de reintentos	La sobrecarga de red domina
Frontend	Time to Interactive, Largest Contentful Paint, tamaño de bundle	Scores de Lighthouse + datos de RUM

Mejores Prácticas

1. Ejecuta benchmarks en CI para cada release; bloquea despliegues si la regresión supera el umbral
2. Establece métricas de línea base a partir de un período estable, no de un objetivo arbitrario
3. Profilea en producción, no solo localmente; los benchmarks locales a menudo engañan
4. Correlaciona regresiones con el tiempo de despliegue, no solo con “alguna vez la semana pasada”
5. Documenta el arreglo en el runbook; el mismo patrón de regresión suele repetirse

Errores Comunes

1. Ignorar la latencia P99 y solo observar promedios; los promedios ocultan latencia de cola
2. Hacer benchmarking en aislamiento sin carga concurrente; las condiciones de carrera solo aparecen bajo tráfico
3. Culpar a la infraestructura antes de revisar cambios de código; la mayoría de las regresiones son código, no hardware
4. No establecer umbrales por adelantado; umbrales ad-hoc llevan a decisiones inconsistentes
5. No verificar después de un arreglo; el primer arreglo suele solo abordar parcialmente el problema

Preguntas Frecuentes

¿Cómo establezco líneas base de rendimiento?

Recopila métricas durante un período conocido por ser estable (por ejemplo, las últimas 2 semanas sin incidentes ni releases mayores). Usa el percentil 95 de los picos diarios como tu línea base, no el promedio. Actualiza las líneas base trimestralmente a medida que cambian los patrones de tráfico. Almacena los datos de línea base en tu herramienta de APM o una base de datos de rendimiento dedicada para que sea consultable durante las regresiones.

¿Debería la regresión de rendimiento bloquear un release?

Sí, para regresiones Críticas y Altas. Para Medias, usa una advertencia que requiera aprobación de ingeniería. Para Bajas, registra y programa el arreglo en el siguiente sprint. El umbral debe definirse antes del release, no debatirse durante el incidente. Si tu benchmark de CI es inestable, arregla el benchmark antes de usarlo como puerta.

¿Qué pasa si la regresión solo afecta a un pequeño subconjunto de usuarios?

Una regresión de subconjunto puede seguir siendo grave si afecta a clientes de alto valor o una característica crítica. Documenta el segmento afectado en el reporte. Si es un caso de uso de nicho, puedes avanzar con el arreglo. Si es un segmento de alto valor, considera un rollback dirigido o deshabilitar la feature flag. Nunca ignores una regresión solo porque es “solo el 1% de usuarios” sin entender quién es ese 1%.