Qué mirar mientras subes: señales, y qué tan rápido avisan

Descripción

Antes de construir cualquier mecanismo de vigilancia, hace falta contestar una pregunta más simple: ¿qué se mira? La lección 1 nombró el par de agujas del tablero —el velocímetro y la temperatura del motor—, pero un lanzamiento real tiene más de dos señales, y no todas avisan al mismo ritmo. Esta lección junta dos marcos: los golden signals de Google SRE —la lista de qué vigilar en cualquier sistema en producción— y los cuatro guardrails de negocio que la guía de métricas ya definió para Mercado. Y agrega una distinción que el resto del módulo va a usar todo el tiempo: qué señales avisan rápido (leading) y cuáles tardan en decir algo confiable (lagging).

Conexión con el módulo. Esta lección no construye todavía guardrailWatch() —eso es la lección 3—; construye el vocabulario y el criterio que esa función va a necesitar: cuándo un OK en una etapa temprana del rollout significa "confirmado sano" y cuándo significa, simplemente, "todavía no hay suficiente gente expuesta para saberlo".

Una analogía: el chequeo médico de rutina contra el que tarda en dar resultado

Cuando vas al médico, algunos resultados están disponibles al instante: te toman la presión y en un minuto ya sabes si está alta o baja. Otros exámenes —un análisis de sangre completo, una biopsia— tardan días, a veces semanas, en volver con un resultado confiable. Un médico que espera el análisis de sangre completo antes de decir absolutamente nada sobre tu presión arterial está desperdiciando una señal que ya estaba disponible desde el primer minuto. Pero un médico que declara "estás perfectamente sano" basado solo en la presión, sin esperar los resultados que sí tardan, está confundiendo "no tengo evidencia de un problema todavía" con "confirmé que no hay ningún problema".

El rollout de recommendations tiene exactamente los dos tipos de examen. checkoutLatencyP95Ms es la presión arterial: cada visita a la página de producto genera una medición, y con un puñado de usuarios ya hay suficiente para saber si algo anda mal. churnRate es el análisis de sangre completo: necesita días, y un volumen de usuarios mucho mayor, antes de que el número diga algo distinto del ruido normal.

Ejemplo trabajado: golden signals, guardrails de negocio, y leadingOrLagging()

Los cuatro golden signals

Google SRE define cuatro señales que, si solo puedes vigilar cuatro cosas de cualquier sistema en producción, son esas cuatro: latencia (cuánto tarda una request), tráfico (cuánta demanda recibe el sistema), errores (qué fracción de requests falla) y saturación (qué tan lleno está el sistema, medido en el recurso más restringido). Son señales de infraestructura — describen la salud técnica del sistema, sin decir todavía nada sobre si el negocio está mejor o peor.

Los cuatro guardrails de negocio de Mercado —checkoutLatencyP95Ms, complaintRate, churnRate, grossMargin— son un marco distinto, construido en la guía de métricas: describen el impacto en el negocio, no la salud técnica del sistema. Fíjate en que hay un punto de contacto exacto entre los dos marcos, y no es casualidad: checkoutLatencyP95Ms es, al mismo tiempo, el golden signal de latencia de Google SRE y uno de los cuatro guardrails de negocio de Mercado. El mismo número sirve para las dos preguntas —"¿el sistema está lento?" y "¿ese enlentecimiento le está costando algo al negocio?"—, porque en este caso las dos preguntas tienen la misma respuesta.

leadingOrLagging(): qué señal ya dice algo útil en canary

// leadingOrLagging: modelo pedagogico. Estima si una metrica ya tiene senial
// util en la etapa ACTUAL del rollout, segun cuantos eventos necesita
// acumular para ser confiable (minEvents) contra cuantos entrega la etapa
// (estimatedEventsAtStage). No reemplaza un calculo real de poder estadistico
// -- es una heuristica para razonar sobre "que tan rapido avisa cada senial".
function leadingOrLagging(metric, minEvents, estimatedEventsAtStage) {
  const hasSignal = estimatedEventsAtStage >= minEvents;
  const type = minEvents <= 200 ? 'leading' : 'lagging';
  return { metric, minEvents, estimatedEventsAtStage, hasSignal, type };
}

// Canary: 1% de 250,000 compradores = 125 personas (el mismo numero del
// proyecto del modulo 1). Cada comprador ve, en promedio, 3 paginas de
// producto -- y cada vista de pagina es una medicion de latencia.
const stageUsers = 125;
const requestsPerUser = 3;
const estimatedRequests = stageUsers * requestsPerUser;

const signals = [
  leadingOrLagging('checkoutLatencyP95Ms', 100, estimatedRequests),
  leadingOrLagging('complaintRate', 500, stageUsers),
  leadingOrLagging('churnRate', 5000, stageUsers),
  leadingOrLagging('grossMargin', 2000, stageUsers),
];

console.log('=== leadingOrLagging: que tiene senial util en canary (1%, 125 compradores) ===\n');
signals.forEach((s) => {
  console.log(s.metric.padEnd(22) + 'minEvents=' + String(s.minEvents).padStart(5) + '  estimado=' +
    String(s.estimatedEventsAtStage).padStart(5) + '  hasSignal=' + s.hasSignal + '  tipo=' + s.type);
});

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== leadingOrLagging: que tiene senial util en canary (1%, 125 compradores) ===

checkoutLatencyP95Ms  minEvents=  100  estimado=  375  hasSignal=true  tipo=leading
complaintRate         minEvents=  500  estimado=  125  hasSignal=false  tipo=lagging
churnRate             minEvents= 5000  estimado=  125  hasSignal=false  tipo=lagging
grossMargin           minEvents= 2000  estimado=  125  hasSignal=false  tipo=lagging

Lee el resultado con cuidado, porque contesta exactamente la pregunta que abrió esta lección. De las cuatro señales, solo checkoutLatencyP95Ms tiene hasSignal: true en canary: con 125 compradores viendo, en promedio, 3 páginas cada uno, ya hay 375 mediciones de latencia — de sobra para confiar en el número. Las otras tres —complaintRate, churnRate, grossMargin— todavía no: 125 compradores es apenas una fracción de los miles de eventos que hacen falta para que una tasa de quejas, de churn, o un margen agregado digan algo distinto del ruido. Esto no significa que esas tres métricas estén rotas ni que haya que ignorarlas — significa que un OK en canary, para esas tres, es "no hay evidencia todavía", no "confirmado sano". Esa diferencia es exactamente el error común que la lección 1 ya nombró, y la razón por la que el resto de este módulo trata checkoutLatencyP95Ms con un peso distinto al de las otras tres durante las etapas tempranas.

Profundización: por qué esto no cambia qué guardrails se vigilan, solo cómo se leen

Vale la pena ser preciso sobre lo que esta lección no dice. No dice "solo vigila checkoutLatencyP95Ms en canary y olvida el resto" — los cuatro guardrails se siguen vigilando en cada etapa, exactamente como los definió la guía de métricas. Lo que cambia es la confianza que se le pone a cada resultado según la etapa: un checkoutLatencyP95Ms: OK en canary es una señal fuerte, con cientos de mediciones detrás; un churnRate: OK en la misma etapa es una señal débil, casi vacía de contenido, que se vuelve fuerte recién cuando el rollout avanza a 10% o más y acumula suficiente volumen. guardrailWatch(), en la lección 3, va a evaluar los cuatro guardrails en cada etapa sin excepción — esta lección solo te da el criterio para leer esos resultados con el peso correcto.

Errores comunes

Tratar "el guardrail no se rompió en canary" como la validación completa del lanzamiento. Qué pasa: el equipo revisa guardrailCheck() en la etapa de canary, ve los cuatro guardrails en OK, y declara "el lanzamiento está limpio" antes de subir a la siguiente etapa. Por qué pasa: OK se ve igual de sólido sin importar cuántos usuarios lo respaldan, y cuatro OK seguidos se sienten como una confirmación completa. Cómo detectarlo: si nadie puede decir cuántos eventos o usuarios respaldan cada OK, la confirmación es más débil de lo que parece. Cómo corregirlo: usa leadingOrLagging() como filtro mental antes de confiar en un resultado — un guardrail lagging en una etapa temprana necesita, todavía, más volumen antes de tratarse como confirmado.

Ignorar los golden signals de infraestructura porque "ya tenemos los guardrails de negocio". Qué pasa: el equipo vigila solo los cuatro guardrails de Mercado y nunca mira tráfico ni saturación del sistema —dos de los cuatro golden signals— asumiendo que están cubiertos porque la latencia (uno de los cuatro) sí se vigila. Por qué pasa: los guardrails de negocio se sienten más relevantes porque hablan directamente de dinero y usuarios, y es fácil olvidar que un problema de saturación (por ejemplo, el servidor de recomendaciones quedándose sin memoria) puede aparecer antes en esas señales técnicas que en la latencia que el usuario percibe. Cómo detectarlo: si el equipo de ingeniería no tiene, en algún lugar, un vistazo a CPU/memoria/tráfico del servicio de recomendaciones durante el rollout, hay un punto ciego de infraestructura sin cubrir. Cómo corregirlo: los guardrails de negocio de este módulo son el foco de guardrailWatch(), pero no reemplazan el monitoreo de infraestructura estándar (golden signals) que cualquier servicio en producción ya debería tener corriendo por debajo.

Confundir "leading" con "más importante" y "lagging" con "menos importante". Qué pasa: alguien concluye que, como checkoutLatencyP95Ms avisa rápido y churnRate tarda, la latencia importa más que el churn. Por qué pasa: la velocidad con la que una señal avisa se confunde fácilmente con su peso real en la decisión. Cómo detectarlo: si la conversación trata al churn como "un detalle secundario" solo porque tarda en aparecer. Cómo corregirlo: leading y lagging describen cuándo una señal empieza a ser confiable, no cuánto importa cuando por fin lo es — un guardrail de churn roto, una vez que tiene suficiente volumen detrás, suele ser tan grave o más que uno de latencia, como ya viste en la guía de métricas al comparar guardrails técnicos contra guardrails de negocio profundos.

Ejercicios

Ejercicio 1 — Cambia el tamaño de la etapa. Si leadingOrLagging() se corriera en la etapa de 10% en vez de canary (1,250 compradores en vez de 125, con el mismo requestsPerUser: 3), ¿cuáles de los cuatro guardrails pasarían a tener hasSignal: true?

Ver solución

Con stageUsers: 1250, estimatedRequests sube a 3750 (de sobra para checkoutLatencyP95Ms, que ya tenía señal desde canary). Para las otras tres, se compara 1250 contra su minEvents: complaintRate (minEvents: 500) pasaría a hasSignal: true — 1250 >= 500. churnRate (minEvents: 5000) seguiría en false — 1250 < 5000, todavía falta volumen. grossMargin (minEvents: 2000) también seguiría en false — 1250 < 2000, muy cerca pero no alcanza. Este ejercicio muestra que "cuándo una señal se vuelve confiable" no es fijo — depende de en qué etapa del rollout estás, y por eso el mismo guardrail puede ser lagging en canary y ya tener señal útil en una etapa más adelantada.

Ejercicio 2 — Ubica un guardrail nuevo. El equipo de soporte de Mercado quiere agregar avgSupportResponseTimeHours como guardrail (el mismo candidato del ejercicio 2 de la lección 6 del módulo 4 de la guía de métricas). Si asumes que hacen falta al menos 300 tickets de soporte para que este número sea confiable, y que en canary (125 compradores) llegan, en promedio, 0.05 tickets por comprador, ¿este guardrail sería leading o lagging en canary?

Ver solución

lagging. Con minEvents: 300 (mayor que el umbral de 200 que usa leadingOrLagging() para clasificar), el tipo ya sale lagging sin necesitar calcular el estimado. Y confirmando con el estimado: 125 compradores * 0.05 tickets/comprador = 6.25 tickets esperados en canary — muy por debajo de los 300 que hacen falta. Este guardrail necesitaría muchísimas más etapas, o una base de usuarios bastante mayor, antes de que su número dijera algo confiable.

Ejercicio 3 — Explica la analogía a alguien nuevo en el equipo. En 2-3 frases, sin usar la palabra "leading" ni "lagging", explica a un compañero nuevo por qué el equipo de Mercado no debería relajarse solo porque churnRate está en OK durante la etapa de canary.

Ver solución

Un mensaje razonable: "En canary solo tenemos 125 compradores expuestos, y el churn es una métrica que se mueve lento — hacen falta miles de personas y, muchas veces, varios días, antes de que un cambio real en el churn se note en el número. Que salga OK ahora mismo no significa que confirmamos que recommendations no está dañando la retención; significa que, con tan pocos datos, todavía no podríamos ver el problema aunque existiera. Vamos a poder confiar en ese número recién cuando el rollout lleve más gente expuesta por más tiempo."

Resumen y siguiente paso

En esta lección conectaste dos marcos —los cuatro golden signals de infraestructura (latencia, tráfico, errores, saturación) y los cuatro guardrails de negocio de Mercado— y viste que checkoutLatencyP95Ms es, literalmente, el punto donde ambos coinciden. Con leadingOrLagging() ejecutado sobre canary, confirmaste que solo la latencia tiene señal útil con apenas 125 compradores expuestos; los otros tres guardrails necesitan más volumen antes de que un OK signifique algo confiable, no solo "todavía no hay evidencia de problema".

Antes de avanzar deberías poder: nombrar los cuatro golden signals y explicar por qué son de infraestructura, no de negocio; explicar la diferencia entre una señal leading y una lagging sin confundirla con importancia; y anticipar, para cualquier guardrail nuevo, si va a tener señal útil en una etapa temprana del rollout o no.

La lección 3 usa exactamente este criterio para construir guardrailWatch(): la función que recorre la rampa completa del módulo 3, corre guardrailCheck() en cada etapa, y decide continue o HALT — y vas a ver, con los datos reales de recommendations, que la señal que primero rompe el guardrail es, justamente, la que esta lección identificó como la más rápida en avisar.

Recursos

• Google SRE Book, Capítulo 6, "Monitoring Distributed Systems" — sre.google/sre-book/monitoring-distributed-systems. La sección "The Four Golden Signals" define latencia, tráfico, errores y saturación como las cuatro señales mínimas de cualquier sistema en producción, la base de esta lección. En inglés.
• Google SRE Book, Capítulo 4, "Service Level Objectives" — sre.google/sre-book/service-level-objectives. El capítulo sobre cómo elegir qué medir y con qué umbral, útil para razonar sobre cuánto volumen hace falta antes de confiar en un SLI. En inglés.
• Ronny Kohavi, "Guardrail Metrics for A/B Tests" — linkedin.com/pulse/guardrail-metrics-ab-tests-ronny-kohavi. El artículo que distingue guardrails de negocio (los de esta guía) de guardrails de confianza en el experimento, ya visto en la guía de métricas y relevante otra vez al pensar en qué tan rápido cada tipo de guardrail acumula señal. En inglés.