La variabilidad de las medidas y cómo no volverse loco con ella

Un equipo pone un umbral de trescientos milisegundos sobre una medida cuyo ruido de fondo es de ochenta. La comprobación falla en peticiones de cambios que no tocan nada relacionado. La primera vez se investiga, la segunda se relanza el trabajo, y la tercera alguien la desactiva “temporalmente”. No es un fallo de disciplina: es la consecuencia matemática inevitable de poner una puerta determinista sobre una variable aleatoria, y se puede calcular de antemano.

De dónde viene el ruido

Ordenadas por cuánto aportan en un entorno de integración continua típico:

La contención del procesador en la máquina. La causa dominante y la más fácil de subestimar. Un ejecutor compartido ejecuta trabajos de otros al mismo tiempo, y la velocidad efectiva de tu medida depende de qué estén haciendo ellos. Puede introducir variaciones del treinta por ciento entre ejecuciones del mismo commit.

La gestión de frecuencia del procesador. Las máquinas modernas suben y bajan la frecuencia según la carga y la temperatura. La primera medida tras un rato de reposo es más rápida que la quinta seguida.

El recolector de basura. Sus pausas caen en momentos distintos en cada ejecución. Una pausa que cae dentro de una tarea larga la alarga; en otra ejecución cae entre dos y no se nota.

El estado de las cachés. Del sistema de ficheros, del código compilado del navegador, del DNS. La primera ejecución es sistemáticamente distinta.

El contenido, si no está fijado. Terceros que cambian, anuncios distintos, pruebas A/B activas, datos de una API que devuelve más elementos hoy. Si tu medición toca la red externa, esta causa domina a todas las demás.

Y el ruido no se reparte por igual entre métricas, cosa que casi nadie tiene en cuenta al poner umbrales:

El tiempo de bloqueo total merece una explicación aparte porque es la métrica que más falsos positivos genera y la que más se usa como puerta. Su definición suma el exceso de cada tarea por encima de cincuenta milisegundos. Eso hace que sea muy sensible a la partición de las tareas: una tarea de 105 milisegundos aporta 55; si esa misma tarea se parte en dos de 52 y 53, aporta 5. Un cambio minúsculo en cuándo cede el hilo puede mover la métrica en un factor de diez sin que el usuario note absolutamente nada. Es una métrica excelente para diagnosticar y pésima para poner una puerta.

Y el desplazamiento acumulado en laboratorio es bimodal: si el salto ocurre, la métrica es grande; si por un milisegundo de diferencia el recurso llega antes, es cero. La media de esa distribución no representa a ninguna ejecución real.

Cuánto cuesta reducir el ruido

La aritmética es desalentadora y conviene conocerla antes de prometer precisión a nadie.

El error típico de la mediana de N muestras es aproximadamente proporcional a uno partido por la raíz de N. Es decir:

Para reducir la incertidumbre a la mitad
hacen falta cuatro veces mas pasadas.

  3 pasadas  -> incertidumbre relativa 1,00
  5 pasadas  -> 0,77
 12 pasadas  -> 0,50
 48 pasadas  -> 0,25

Con un ejemplo concreto. Si el tiempo de bloqueo tiene una desviación típica de 60 milisegundos, la mediana de cinco pasadas tiene un error típico de unos 34 milisegundos, y su intervalo de confianza del noventa y cinco por ciento es de unos ±67. Es decir, con cinco pasadas no puedes distinguir de forma fiable una regresión menor de unos setenta milisegundos. Detectar veinte requeriría del orden de sesenta pasadas, que a treinta segundos cada una son media hora de máquina por petición de cambios. Nadie va a pagar eso.

La conclusión no es rendirse: es reconocer que hay un suelo de detección, calcularlo, y poner los umbrales por encima de él. Un umbral por debajo del suelo de detección no detecta regresiones, produce ruido.

Medir tu suelo es trivial y hay que hacerlo antes de configurar nada:

# Diez ejecuciones del MISMO commit, sin cambiar una linea.
for i in $(seq 1 10); do
  npx lhci collect --numberOfRuns=5
  npx lhci assert --preset=lighthouse:no-pwa || true
done

Toma la mediana de cada una de las diez ejecuciones y mira el rango. Ese rango es tu ruido, y cualquier umbral tiene que estar cómodamente fuera de él.

La aritmética de los falsos positivos

Este cálculo es el que hay que enseñar a quien proponga añadir “unas cuantas comprobaciones más por si acaso”.

Si una comprobación falla por azar con probabilidad α, y tienes m comprobaciones independientes, la probabilidad de que al menos una falle sin motivo en una ejecución cualquiera es:

P(al menos un falso positivo) = 1 - (1 - alfa)^m

Los números:

Lee la fila de diez comprobaciones con umbrales razonablemente holgados: cuatro de cada diez peticiones de cambios fallan sin motivo. Con veinte comprobaciones, casi dos de cada tres. Ningún equipo aguanta eso, y la reacción no es afinar los umbrales sino desactivar el mecanismo entero, porque desde fuera parece que el mecanismo no funciona.

De ahí salen tres reglas de diseño.

Menos comprobaciones. Cada puerta adicional multiplica el riesgo. Cinco bien elegidas valen más que veinte exhaustivas. Que sea posible comprobar algo no es motivo para comprobarlo.

Umbrales por encima del suelo de detección. Un umbral que deja la tasa de falsos positivos por debajo del uno por ciento por comprobación, con cinco comprobaciones, da un cinco por ciento de ejecuciones con falsa alarma. Aceptable.

Un objetivo explícito de tasa de falsos positivos. Escríbelo: como mucho una falsa alarma cada veinte ejecuciones, en total. Con ese objetivo, los umbrales se derivan; sin él, se ponen a ojo y sale la fila de arriba.

Las tres técnicas que funcionan

Uno: entrelazar las dos versiones en la misma máquina. Es la técnica con mejor relación entre esfuerzo y resultado y la que menos gente usa. En lugar de comparar tu medida de hoy con una guardada de ayer, compila las dos versiones y mídelas alternando en la misma sesión: base, cambio, base, cambio. Como las dos sufren la misma deriva de la máquina, la deriva se cancela en la diferencia.

#!/usr/bin/env bash
set -euo pipefail

git worktree add /tmp/base origin/main
(cd /tmp/base && npm ci && npm run build && npm run preview -- --port 4001 &)
(npm run build && npm run preview -- --port 4002 &)
sleep 8

for i in $(seq 1 6); do
  npx lighthouse http://localhost:4001/ --quiet --output=json \
    --output-path="res/base-$i.json" --only-categories=performance
  npx lighthouse http://localhost:4002/ --quiet --output=json \
    --output-path="res/cambio-$i.json" --only-categories=performance
done

El efecto es grande: elimina de golpe la fuente de varianza dominante, que es la diferencia entre máquinas y entre momentos. Cuesta el doble de tiempo de ejecución y compensa con creces.

Dos: intervalo de confianza por remuestreo. En vez de comparar dos medianas y declarar una regresión si la diferencia pasa de X, calcula un intervalo para la diferencia. Si el intervalo contiene el cero, no has detectado nada. El remuestreo no exige suponer ninguna distribución, que es justo lo que quieres con datos tan asimétricos:

// Intervalo de confianza del 95 % para la diferencia de medianas.
function mediana(xs) {
  const s = [...xs].sort((a, b) => a - b);
  const m = s.length >> 1;
  return s.length % 2 ? s[m] : (s[m - 1] + s[m]) / 2;
}

function remuestrear(xs) {
  const out = new Array(xs.length);
  for (let i = 0; i < xs.length; i++) {
    out[i] = xs[(Math.random() * xs.length) | 0];
  }
  return out;
}

export function intervaloDeDiferencia(base, cambio, repeticiones = 5000) {
  const difs = new Array(repeticiones);
  for (let i = 0; i < repeticiones; i++) {
    difs[i] = mediana(remuestrear(cambio)) - mediana(remuestrear(base));
  }
  difs.sort((a, b) => a - b);
  const inf = difs[Math.floor(repeticiones * 0.025)];
  const sup = difs[Math.floor(repeticiones * 0.975)];
  return {
    diferencia: Math.round(mediana(cambio) - mediana(base)),
    inferior: Math.round(inf),
    superior: Math.round(sup),
    significativo: inf > 0 || sup < 0,
  };
}

const base   = [280, 310, 295, 340, 288, 302];
const cambio = [350, 372, 358, 401, 366, 355];
console.log(intervaloDeDiferencia(base, cambio));
// { diferencia: 66, inferior: 43, superior: 91, significativo: true }

Ese resultado se puede informar tal cual y es honesto: la regresión está entre 43 y 91 milisegundos con un noventa y cinco por ciento de confianza. Compara eso con “TBT: 366, umbral 300, fallo”.

Tres: exigir confirmación consecutiva. Para las alertas de tendencia sobre la rama principal, no alertes por un valor: alerta cuando K ejecuciones seguidas estén por encima. Con K igual a tres y una tasa de falso positivo del cinco por ciento por ejecución, la probabilidad de tres seguidas por azar es de uno entre ocho mil. Se pierde algo de rapidez en la detección y se gana una alerta que la gente cree.