7. Elegir el perfil según la pregunta

Descripción

Ya tienes todas las piezas: las formas (constante, rampa, spike) y los executors (por VUs y por tasa de llegada). Esta lección las junta en una sola habilidad práctica —la más importante del módulo—: elegir el perfil correcto según la pregunta que quieres responder. Porque un perfil no es una decisión estética; es la consecuencia directa de tu pregunta. "¿Aguanta la carga esperada?" pide un perfil; "¿dónde se rompe?" pide otro; "¿sobrevive un pico?", otro; "¿se degrada en horas?", otro más. Elegir mal el perfil es como usar un termómetro para medir el peso: la herramienta funciona, pero no responde tu pregunta. Aquí construimos el mapa pregunta → tipo de prueba → perfil (forma + executor), cerrando el círculo con los cinco tipos que conociste en el módulo 1 (smoke, load, stress, spike, soak) y conectándolos con las formas y executors de este módulo.

Conexión con el módulo: esta es la lección de síntesis. La 4 te dio las formas, la 5 y la 6 los executors; aquí decides cuál usar y por qué. Reutiliza los cinco tipos de prueba del módulo 1 —que allí conociste conceptualmente— y ahora les pone la forma y el executor concretos que aprendiste. Es también el ensayo del mini-proyecto (lección 8), donde aplicarás una de estas decisiones. No añade herramientas nuevas: es puro criterio, el pegamento que vuelve útil todo lo anterior. Los thresholds (el criterio de pass/fail) siguen siendo del módulo 5; aquí solo elegimos la forma de la carga.

La analogía: el médico que elige la prueba

Un buen médico no pide "todos los análisis"; pide el análisis que responde su pregunta. Si sospecha anemia, pide un hemograma. Si quiere ver el corazón bajo esfuerzo, una prueba de esfuerzo. Si busca una fractura, una radiografía. Cada prueba está diseñada para una pregunta, y pedir la equivocada gasta tiempo y dinero sin acercarte al diagnóstico. La destreza no está en saber hacer las pruebas —eso lo hace la máquina—, sino en saber cuál pedir.

Elegir un perfil de carga es el mismo acto clínico. La máquina (k6, el generador) sabe aplicar cualquier forma; tu trabajo es traducir la pregunta del negocio a la prueba que la responde. "¿Sobreviviremos al Black Friday?" no es una prueba; es un síntoma vago. Como médico del sistema, lo descompones: "¿aguantamos la carga esperada de ese día?" (un load test), "¿dónde está nuestro límite por si el estimado se queda corto?" (un stress test), "¿sobrevivimos si el tráfico llega de golpe cuando abrimos a medianoche?" (un spike test). Cada una es una prueba distinta con un perfil distinto. La lección es aprender esa traducción.

El mapa: pregunta → tipo → perfil

Aquí está la tabla que resume todo el módulo. Léela como un diccionario de traducción: de la pregunta (izquierda) al perfil que la responde (derecha).

Cada fila es una pregunta legítima y distinta, y ninguna sustituye a otra. Un sistema puede pasar el smoke, aguantar la carga esperada (load), y aun así romperse con un pico súbito (spike) o filtrarse tras seis horas (soak). Por eso una prueba de carga seria no es una prueba: es una batería, cada una con su perfil.

Los cinco tipos, con su perfil concreto

Recorramos cada tipo poniéndole la forma y el executor que ya conoces.

Smoke — ¿funciona siquiera? El más humilde y el que va primero, siempre. Antes de invertir en pruebas grandes, confirmas que el sistema arranca y responde bajo una carga mínima. Forma: constante, 1-5 VUs, unos segundos. Executor: constant-vus. Si el smoke falla, no tiene sentido correr un stress test —hay algo roto de base—. Es el "¿respira el paciente?" antes de cualquier otra prueba.

Load — ¿aguanta lo que espero? La prueba central. Fijas la carga esperada (tu pico normal de tráfico) y verificas que el sistema cumple sus objetivos ahí. Forma: ramp-up → steady (a la carga esperada) → ramp-down; lees el p95 en la meseta. Executor: ramping-vus, o constant-arrival-rate si tu carga esperada está en RPS ("500 pedidos por segundo"). Es la prueba que responde "¿estamos listos para el tráfico que anticipamos?".

Stress — ¿dónde me rompo? Aquí buscas el límite: subes la carga más allá de lo esperado hasta que el sistema cede —el p95 se dispara de forma no lineal o empiezan los errores—. Forma: rampa creciente y sostenida, empujando hacia arriba. Executor: ramping-vus (o ramping-arrival-rate si piensas en RPS). Te da el punto de quiebre y, con él, cuánto margen tienes sobre tu carga normal. La rampa por etapas que ejecutaste es un stress test en miniatura: al subir 4 → 12 → 24, viste el p95 acelerarse (22 → 77 → 175 ms), la firma de acercarse al límite.

Spike — ¿sobrevivo a un golpe? Ya lo conoces a fondo de la lección 4. Un baseline bajo, un salto abrupto a un pico, y una vuelta al baseline. Executor: ramping-vus con stages muy cortos en la subida. Se lee distinto: el daño del golpe vive en el max/p99 (lo viste: max de 2016 ms en el spike ejecutado), y la recuperación en el p95 de vuelta al baseline (15 ms, como el inicio). Responde "¿sobrevivimos a que el tráfico llegue de golpe y nos recuperamos?".

Soak — ¿me degrado con el tiempo? El más lento y el que más fugas atrapa. Una carga constante pero larga —horas—, para ver si algo se degrada con el tiempo: memoria que no se libera, conexiones que se agotan, un disco que se llena. Forma: meseta plana. Executor: constant-vus. La variable clave no es la altura de la carga (es moderada) sino la duración. Responde "¿aguanta un día entero, o se filtra a las seis horas?". Es el único tipo donde el tiempo es la prueba.

El perfil no se elige por gusto: es la traducción de tu pregunta. Estado mínimo → smoke (constante corto). Carga esperada → load (ramp a lo esperado, leer la meseta). Límite → stress (rampa hasta ceder). Pico súbito → spike (salto abrupto, mirar max y recuperación). Degradación temporal → soak (constante largo). Elegir mal el perfil responde una pregunta que no hiciste.

Cómo se combinan en una sola prueba

En la práctica, estos tipos no siempre viven en pruebas separadas: a menudo se encadenan en un solo perfil, aprovechando las fases. Un patrón común es smoke → load → stress en una sola corrida creciente:

// CONTENIDO (no ejecutado aquí). Un perfil que encadena smoke, load y stress.
export const options = {
  stages: [
    { duration: '30s', target: 5 },   // smoke: confirma que funciona
    { duration: '1m',  target: 50 },  // ramp-up a la carga esperada
    { duration: '3m',  target: 50 },  // load: steady a lo esperado (aquí lees el p95)
    { duration: '2m',  target: 200 }, // stress: empuja más allá para buscar el límite
    { duration: '1m',  target: 0 },   // ramp-down: recuperación
  ],
};

Lee el perfil como una historia: arranca suave (smoke), sube a la carga esperada y la sostiene (load, la meseta donde lees el número oficial), luego empuja mucho más arriba para encontrar el límite (stress), y baja (recuperación). Una sola corrida responde tres preguntas. Lo que no se suele mezclar es el soak (necesita su propia duración larga) ni el spike (su abruptez se diluye si va después de una rampa). El criterio: encadena lo que comparte forma creciente; separa lo que necesita una forma o duración propia.

Errores comunes

Correr un stress o un load sin haber pasado el smoke. Qué pasa: alguien lanza directo una prueba grande, esta falla, y pierde una hora depurando cuando el problema era trivial (un endpoint mal escrito, un puerto equivocado). Por qué pasa: se salta el paso humilde por prisa. Cómo detectarlo: si tu primera prueba del día es grande y algo falla, no sabes si es la carga o un bug de base. Cómo corregirlo: siempre un smoke primero —pocos VUs, confirma que responde 200— antes de cualquier prueba seria; es barato y te ahorra depurar lo que no es.

Probar solo la carga esperada y declararse listo. Qué pasa: se corre un load test a la carga anticipada, cumple el SLO, y se da el sistema por listo —hasta que el estimado se queda corto o llega un pico y todo se cae—. Por qué pasa: el load test responde "¿aguanto lo que espero?", y es fácil olvidar que lo esperado puede fallar. Cómo detectarlo: si nunca corriste un stress (¿cuánto margen tengo?) ni un spike (¿sobrevivo un golpe?), tu "listo" solo cubre el escenario optimista. Cómo corregirlo: complementa el load con un stress (para conocer tu límite y tu margen) y, si el tráfico puede llegar de golpe, un spike.

Usar un soak corto o un spike gradual. Qué pasa: alguien corre un "soak" de diez minutos (demasiado corto para ver una fuga lenta) o un "spike" que en realidad sube en un minuto (demasiado gradual para ser un golpe). Por qué pasa: se copia el nombre del tipo sin respetar su variable clave. Cómo detectarlo: un soak sin horas no es un soak; un spike sin abruptez es una rampa. Cómo corregirlo: respeta lo que define cada tipo —el soak es duración (horas), el spike es abruptez (salto casi instantáneo)—; si no puedes darle eso, no estás corriendo ese tipo.

Ejercicios

Ejercicio 1 — Traduce la pregunta al tipo. Para cada pregunta, di qué tipo de prueba la responde y con qué forma. (a) "¿Nuestra API cumple p95 < 400 ms con los 200 usuarios que esperamos en hora pico?" (b) "¿A partir de cuántos usuarios se cae?" (c) "¿Sobrevive a que 1000 personas entren de golpe al abrir la venta de entradas?" (d) "¿Aguanta funcionando toda la noche sin degradarse?"

Ejercicio 2 — Critica el perfil. Un compañero quiere responder "¿dónde se rompe Reservo?" y escribe: { vus: 30, duration: '5m' }. ¿Responde su pregunta? Si no, ¿qué perfil debería usar?

stages: [
  { duration: '1m', target: 30 },   // arranca en lo conocido
  { duration: '3m', target: 150 },  // empuja hacia arriba
  { duration: '2m', target: 300 },  // sigue subiendo hasta que ceda
  { duration: '1m', target: 0 },
]

Ejercicio 3 — Diseña la batería. Tu jefe dice: "Necesito estar seguro de que Reservo aguanta el lanzamiento". Diseña una batería de pruebas (no una sola) que cubra las preguntas relevantes, nombrando cada tipo y qué responde. Supón que esperas 200 usuarios concurrentes de pico y que el tráfico puede llegar de golpe al abrir.

Resumen y siguiente paso

En esta lección aprendiste la habilidad que vuelve útil todo el módulo: elegir el perfil según la pregunta. Un perfil no es una decisión estética, es la traducción de lo que quieres saber. Construiste el mapa completo: smoke (constante corto → ¿funciona?), load (ramp a la carga esperada, leer la meseta → ¿aguanto lo previsto?), stress (rampa hasta ceder → ¿dónde está mi límite?), spike (salto abrupto y recuperación → ¿sobrevivo un golpe?) y soak (constante largo → ¿me degrado con las horas?). Cada uno con su forma y su executor de las lecciones anteriores.

Viste que ninguna prueba sustituye a otra —un sistema puede pasar el load y romperse en el spike o filtrarse en el soak— y que en la práctica algunos tipos se encadenan en un solo perfil creciente (smoke → load → stress), mientras que el soak y el spike piden su propia corrida por su duración o su abruptez. La lección clínica: como un médico, no corres "todas las pruebas"; corres la que responde tu pregunta, y empiezas siempre por el smoke.

Antes de avanzar deberías poder: traducir una pregunta de negocio al tipo de prueba y al perfil que la responde; explicar por qué se empieza siempre por el smoke; criticar un perfil que no responde su pregunta; y diseñar una batería de pruebas para un objetivo amplio como "aguantar un lanzamiento".

Lo que sigue es ponerlo todo en práctica con tus manos. En la lección 8, el mini-proyecto: escribes un perfil de carga por etapas —el script k6 con stages ramp-up/steady/ramp-down (contenido) y su equivalente ejecutable en Python—, lo corres contra Reservo, reportas el p95 por etapa y reflexionas sobre lo que la forma reveló. Es la síntesis de las ocho lecciones.

Recursos

• k6 — Tipos de prueba de carga (test types) — la guía oficial que define smoke, load, stress, spike y soak y su perfil; la referencia central de esta lección.
• k6 — Soak testing — el detalle del soak: por qué la duración es su variable clave y qué fugas atrapa.
• k6 — Smoke testing — por qué el smoke va primero y cómo se configura (pocos VUs, poco tiempo).
• Google SRE Book — Addressing Cascading Failures — por qué conocer el límite (stress) y el comportamiento ante picos (spike) importa para evitar fallos en cascada en producción.