Presentación del módulo: vigilar la rampa, no solo subirla

Por qué este módulo, ahora

El módulo 3 te dio la rampa completa: rolloutPlan() define las cuatro etapas —canary 1% → 10% → 50% → 100%— y los criterios explícitos para avanzar de una a la siguiente. Con eso resuelto, parece que ya está todo: tienes el interruptor (módulo 2) y tienes el plan de cuánta gente exponer en cada paso (módulo 3). Pero el módulo 3 dejó una pregunta abierta a propósito, y la dejó abierta con estas palabras exactas en su frontera: "vigilar los guardrails durante la rampa es M4". Diseñar la escalera y subir la escalera son dos problemas distintos. Este módulo resuelve el segundo: mientras subes, ¿qué miras, y cuándo dejas de subir?

La respuesta no es nueva del todo. La guía de métricas ya construyó guardrailCheck() y ya definió los cuatro guardrails de negocio de Mercado: checkoutLatencyP95Ms (techo 800ms), complaintRate, churnRate y grossMargin. Ese trabajo no se repite aquí — se reutiliza, sin cambios, y se pone a trabajar en vivo, etapa por etapa, mientras el rollout real avanza. La pieza nueva de este módulo es guardrailWatch(): la función que recorre la rampa del módulo 3 y decide, en cada etapa, si el guardrail se sostiene (continue) o si hay que detenerse ahí mismo (HALT) — antes de que la siguiente etapa exponga a más gente todavía a un problema que ya se sabe que existe.

Conexión con el módulo 3. La lección 8 de ese módulo terminó con la rampa diseñada y sus criterios de avance definidos, pero sin ejecutar todavía ningún dato real de guardrail contra esos criterios — el rollout, en ese punto, todavía no había arrancado. Este módulo toma esa misma rampa y la corre contra los números reales del lanzamiento de recommendations: la latencia que la guía de métricas ya había medido en 910ms, muy por encima del techo de 800ms.

Una analogía: el tablero del auto, no solo el velocímetro

Acelerar un auto en una carretera larga se siente, la mayor parte del tiempo, como un solo número: la velocidad. Pero ningún conductor con experiencia mira solo el velocímetro. El tablero tiene, al lado, la temperatura del motor y la presión del aceite — dos números que casi nunca cambian nada en un viaje normal, y que existen exactamente para el día en que sí cambian. Un motor que se recalienta no avisa primero con una falla total: avisa con la aguja de temperatura subiendo, minutos antes de que algo se funda de verdad. El conductor que solo mira el velocímetro —"voy rápido, vamos bien"— y nunca la temperatura, es el que termina varado en el hombro de la carretera, con el motor arruinado, preguntándose qué pasó.

El rollout de recommendations tiene el mismo par de agujas. El velocímetro es checkoutConversionRate, la métrica primaria que la guía de métricas confirmó que mejora, con fuerza, mientras el rollout avanza. La temperatura del motor es checkoutLatencyP95Ms — y en este caso concreto, ya sabemos que sube más de lo que debería. Este módulo es aprender a leer esa segunda aguja con la misma disciplina que la primera, y a frenar el auto —no apagarlo, frenar— antes de que la aguja llegue a la zona roja, aunque el velocímetro siga mostrando un número que se ve espectacular.

El mapa de las ocho lecciones de este módulo

Lección   Pregunta que contesta
────────  ──────────────────────────────────────────────────────────────
L1        (esta) ¿Dónde nos dejó el módulo 3, y qué falta vigilar?
L2        ¿Qué se mira mientras sube una rampa: señales y su velocidad?
L3        ¿Cómo se vigila un guardrail EN VIVO, etapa por etapa?
L4        ¿Cuándo se frena, con qué criterio, y qué pasa si no se frena?
L5        ¿Qué debería mostrar el dashboard de un lanzamiento en curso?
L6        ¿Cómo se diseña una alerta que de verdad sirve, y no una que solo suena?
L7        ¿Cuánta regresión te queda antes de tener que parar?
L8        Proyecto: vigila el rollout de recommendations y decide frenar

La lección 2 separa dos tipos de señal que suelen confundirse: las que ya avisan algo útil con pocos usuarios expuestos (checkoutLatencyP95Ms, medible en cada request) y las que necesitan mucho más volumen o tiempo para decir algo confiable (churnRate, complaintRate). La lección 3 construye la pieza central del módulo, guardrailWatch(), y la corre sobre el rollout real de recommendations: en canary, la latencia se sostiene; al subir a 10%, se rompe. La lección 4 se queda en ese resultado y pregunta qué significa, en la práctica, "frenar" — y qué le pasaría a la base de usuarios de Mercado si el equipo decidiera ignorar el HALT y seguir subiendo de todos modos. La lección 5 diseña el dashboard que hace visible, de un vistazo, el estado que guardrailWatch() calcula. La lección 6 entra en las alertas: la diferencia entre una que avisa un síntoma técnico suelto y una que liga ese síntoma a un impacto real de usuario. La lección 7 cierra el arco temático con el error budget: cuánta regresión de latencia te queda, en milisegundos concretos, antes de que el presupuesto se agote. La lección 8, el proyecto, reutiliza guardrailWatch() sin cambiarle una línea sobre el caso completo: canary a 10%, y la decisión de frenar antes de llegar a 50%.

La frontera: qué NO entra en este módulo

Este módulo vigila. No construye la rampa, no decide qué hacer después de frenar, y no calcula si el resultado primario es estadísticamente real:

• Cómo se diseña la rampa —las cuatro etapas, sus criterios de avance— es el módulo 3. Aquí la rampa ya existe; este módulo la corre contra datos de guardrail en vivo.
• Qué hacer después de un HALT —revertir, arreglar hacia adelante, el runbook, la severidad del incidente— es el módulo 5. Este módulo se detiene exactamente en el momento de la decisión de frenar; el proceso completo de responder al problema empieza en la puerta siguiente.
• El postmortem de lo que pasó es el módulo 6. Aquí se observa y se decide frenar; documentar la causa raíz y los factores contribuyentes es un trabajo posterior.
• Si el lift en checkoutConversionRate es estadísticamente significativo ya lo contestó la guía de métricas (p=0.0114, significativo). Este módulo no recalcula esa estadística — la da por sabida, y se concentra en los guardrails que se vigilan mientras el número primario sube.

Errores comunes

Creer que "vigilar" significa mirar el dashboard cuando algo ya salió mal. Qué pasa: el equipo diseña la rampa, prende el rollout, y solo abre el dashboard de guardrails cuando alguien más —un usuario, un ticket de soporte— reporta que algo anda lento. Por qué pasa: entre construir la rampa (módulo 3) y vigilarla en vivo hay una disciplina distinta, y es fácil asumir que "ya está todo automatizado" sin haber decidido quién mira qué, y cuándo. Cómo detectarlo: si nadie puede decir, para la etapa actual del rollout, cuál es el valor más reciente de checkoutLatencyP95Ms, la vigilancia existe en el papel, no en la práctica. Cómo corregirlo: como construye este módulo, vigilar es una función que corre en cada etapa, no una revisión ocasional — guardrailWatch() de la lección 3 es, literalmente, esa disciplina convertida en código.

Pensar que un solo guardrail roto invalida todo el lanzamiento. Qué pasa: alguien ve HALT en la etapa de 10% y concluye que hay que cancelar recommendations por completo, sin distinguir entre "frenar la rampa aquí" y "revertir todo lo que ya se lanzó". Por qué pasa: la palabra HALT suena definitiva, y es más simple reaccionar en blanco y negro que sostener la distinción entre pausar y cancelar. Cómo detectarlo: la conversación salta de "el guardrail se rompió" a "hay que revertir ya" sin pasar por "¿en qué etapa estamos, y qué tan grave es seguir ahí mientras se diagnostica?". Cómo corregirlo: este módulo trata HALT como "detente antes de exponer a más gente" — no como "revierte lo que ya está expuesto". La decisión de revertir, con todo su proceso, es del módulo 5.

Confundir "el guardrail no se rompió todavía" con "el guardrail está confirmado sano". Qué pasa: en la etapa de canary, con muy pocos usuarios expuestos, todos los guardrails salen OK, y el equipo lo lee como una confirmación fuerte de que todo va bien. Por qué pasa: OK se ve igual de definitivo sin importar cuántos usuarios respaldan ese número, y es fácil no notar la diferencia entre "no hay señal de problema" y "hay señal confirmada de que no hay problema". Cómo detectarlo: si nadie puede decir cuántos usuarios o eventos respaldan un OK en una etapa temprana, ese OK podría ser, simplemente, que todavía no hay suficiente volumen para que el guardrail se mueva. Cómo corregirlo: la lección 2 de este módulo construye exactamente esta distinción — qué guardrails ya tienen señal útil en canary, y cuáles todavía no.

Ejercicios

Ejercicio 1 — Ubica la pregunta. Para cada pregunta, di si la contesta el módulo 3 (ya visto), este módulo 4, o un módulo posterior (5 o 6):

• (a) "¿En qué porcentaje debería empezar el rollout de recommendations, y a qué porcentaje sube después?"
• (b) "A 10% de rollout, la latencia rompió su techo. ¿Seguimos a 50% o nos detenemos aquí?"
• (c) "Ya decidimos frenar en 10%. ¿Revertimos el 10% que ya está expuesto, o lo dejamos mientras arreglamos la causa?"

Ver solución

• (a) Módulo 3 — rolloutPlan() diseñó exactamente esas etapas y sus criterios de avance.
• (b) Este módulo 4 — guardrailWatch() de la lección 3 contesta exactamente esta pregunta, corriendo el guardrail contra cada etapa.
• (c) Módulo 5 — decidir entre revertir y arreglar hacia adelante, con su runbook, es el territorio de rollback e incident response.

Ejercicio 2 — La analogía, en tus palabras. Usando la analogía del tablero del auto, explica en dos frases por qué un conductor que solo mira el velocímetro puede terminar con el motor arruinado, incluso yendo "bien" según ese único número.

Ver solución

El velocímetro solo dice qué tan rápido vas, no si algo en el sistema se está degradando mientras vas rápido — la temperatura del motor puede subir de forma silenciosa, sin que la velocidad lo refleje en absoluto. Para cuando el motor falla, ya es demasiado tarde para haber hecho algo con solo esa aguja: el momento útil para actuar era antes, cuando la temperatura empezaba a subir pero el motor todavía funcionaba. Es exactamente el mismo problema que un equipo que solo mira checkoutConversionRate mientras checkoutLatencyP95Ms se degrada por debajo, sin que el número primario lo muestre.

Ejercicio 3 — Predicción. Sin haber leído todavía la lección 3, ¿qué crees que debería pasar si, al llegar a la etapa de 50%, el guardrail de latencia ya se hubiera roto en la etapa anterior (10%)? ¿Debería guardrailWatch() seguir evaluando la etapa de 50% con datos reales, o hacer otra cosa?

Ver solución

Si el guardrail ya se rompió en una etapa anterior, no debería haber datos reales de la etapa de 50% para evaluar — porque el equipo, siguiendo la disciplina de este módulo, nunca debió haber avanzado el rollout hasta ahí. guardrailWatch() va a marcar esa etapa como "no alcanzada", en vez de fingir que evaluó algo que en la práctica nunca ocurrió. Es la misma lógica que ves en la analogía: si la temperatura ya subió demasiado en el kilómetro 10, no sigues acelerando hasta el kilómetro 50 para "ver qué pasa".

Resumen y siguiente paso

En esta lección ubicaste este módulo en el arco completo de la guía: el módulo 3 diseñó la rampa (canary 1% → 10% → 50% → 100%); este módulo 4 la vigila, etapa por etapa, con los mismos guardrails de negocio que ya definió la guía de métricas —latencia, quejas, churn, márgenes—. Viste la analogía del tablero del auto —el velocímetro contra la temperatura del motor— y el mapa de las ocho lecciones que siguen, con su frontera clara respecto al módulo 5 (qué hacer después de frenar) y al módulo 6 (el postmortem).

Antes de avanzar deberías poder: explicar por qué diseñar la rampa y vigilarla son dos problemas distintos; distinguir "frenar la rampa" de "revertir lo ya expuesto"; y anticipar por qué un guardrail OK en una etapa con pocos usuarios no es, todavía, una confirmación fuerte.

La lección 2 empieza por el principio: antes de vigilar nada, hay que saber qué señales existen y qué tan rápido cada una empieza a decir algo útil — la diferencia entre una señal que avisa en minutos y una que tarda semanas en acumular suficiente evidencia.

Recursos

• Google SRE Book, Capítulo 6, "Monitoring Distributed Systems" — sre.google/sre-book/monitoring-distributed-systems. El capítulo que formaliza los cuatro golden signals —latencia, tráfico, errores, saturación— que este módulo aplica, en versión de negocio, al rollout de recommendations. En inglés.
• LaunchDarkly, "Introducing Guardrail Metrics: best-practice metrics for every release" — launchdarkly.com/blog/introducing-guardrail-metrics. Cómo una plataforma de feature flags real automatiza exactamente la vigilancia que este módulo construye a mano: guardrails ligados a cada release, revisados en cada etapa. En inglés.
• Google SRE Book, Capítulo 3, "Embracing Risk" — sre.google/sre-book/embracing-risk. El capítulo sobre error budgets, la idea central de la lección 7 de este módulo: cuánta regresión te puedes permitir antes de que el presupuesto se agote. En inglés.