Costo de las pruebas de carga: time-to-green, infra y tooling (sin sorpresas)

Finanzas aprobó «solo corre k6 en un laptop»—y luego el primer soak serio necesitó tres días-ingeniero para parametrizar datos, un cluster staging dedicado y upgrades de retención APM que nadie presupuestó. Los costos ocultos dominan planes ingenuos de pruebas de carga, y la factura llega tras una ventana de lanzamiento fallida, no antes.

Correr k6 localmente no es el costo completo. En esta guía verás dónde caen realmente time-to-green, infra de generadores y gasto en observabilidad, cómo codificar smoke gates conscientes del costo en k6, y qué reglas de decisión mantienen programas de perf financiados sin facturas sorpresa.

Por qué «k6 gratis» igual cuesta dinero real

k6 open source no tiene licencia; el programa alrededor sí. Presupuesta estas categorías antes de prometer fechas a producto:

• Tiempo de ingeniería (time-to-green): imports, tuning de escenarios, higiene de datos y debates de umbrales suelen superar horas de runner (errores comunes).
• Entorno objetivo: staging prod-like, tenants perf dedicados o stacks burst en cloud facturados por hora—no la CPU de tu laptop.
• Infra de generadores: k6 cloud, runners CI o agentes bare-metal con egress suficiente para evitar cuellos en el generador (k6 cloud vs self-hosted).
• Observabilidad: retención APM, ingest de logs y almacenamiento de trazas suben en soaks (correlation IDs).
• Costo de oportunidad: cada semana en scripts bifurcados es una semana sin arreglar cola de checkout (contrato vs rendimiento).

Piensa en pruebas de carga como experimento de laboratorio: el termómetro es barato; la sala controlada, sensores y horas del científico no.

Cuando el plan asumió una tarde

Los equipos subestiman costo al confundir smoke (minutos, baja RPS, staging compartido) con prueba de capacidad (horas, datos prod-like, infra dedicada). Sin etiquetar qué pregunta responde cada corrida, finanzas oye «probamos carga semanal» e ingeniería compra un cluster que nadie aprobó.

Implementación práctica con k6: smoke gates que respetan presupuesto

Codifica corridas smoke baratas y frecuentes separadas de jobs soak/capacidad caros. El script siguiente usa duración corta, tasa de llegada baja y umbrales de fallo estrictos—ideal para CI—mientras variables env documentan cuándo promover el mismo flujo a un entorno perf pagado.

Ejemplo de script (ilustrativo—no listo para producción). El fragmento usa URLs, tokens y números SLO ficticios. Adapta base URL, auth, payloads y umbrales a tu entorno.

Qué demuestra este ejemplo:

• Modelo de costo por tiers: modo SMOKE limita duración y RPS; modo CAPACITY (flag env) extiende la corrida—mismo script, factura distinta.
• Aborto temprano ante fallo: umbrales de error ajustados dejan de quemar minutos de runner cuando staging ya está rojo.
• Tags tier:smoke vs tier:capacity: finanzas y plataforma ven qué tipo de job consumió infra.
• Targets vía env: un script para smoke CI en staging compartido y corridas trimestrales de capacidad en perf dedicado—sin repos duplicados.

import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = __ENV.API_BASE || 'https://staging.example.com';
const TOKEN = __ENV.TOKEN || 'staging-token-replace-me';
const TIER = (__ENV.RUN_TIER || 'smoke').toLowerCase();

const tierConfig = {
  smoke: {
    rate: 3,
    duration: '2m',
    preAllocatedVUs: 3,
    maxVUs: 10,
    tag: 'smoke',
    p95: 900,
    p99: 1400,
  },
  capacity: {
    rate: 40,
    duration: '20m',
    preAllocatedVUs: 30,
    maxVUs: 120,
    tag: 'capacity',
    p95: 700,
    p99: 1100,
  },
};

const cfg = tierConfig[TIER] || tierConfig.smoke;

export const options = {
  scenarios: {
    checkout_tiered: {
      executor: 'constant-arrival-rate',
      rate: cfg.rate,
      timeUnit: '1s',
      duration: cfg.duration,
      preAllocatedVUs: cfg.preAllocatedVUs,
      maxVUs: cfg.maxVUs,
      tags: { route: 'checkout', tier: cfg.tag },
      exec: 'checkout',
    },
  },
  thresholds: {
    [`http_req_duration{route:checkout,tier:${cfg.tag}}`]: [
      `p(95)<${cfg.p95}`,
      `p(99)<${cfg.p99}`,
    ],
    http_req_failed: ['rate<0.01'],
  },
};

export function checkout() {
  const body = JSON.stringify({ sku: `SKU-${__VU}`, qty: 1 });
  const res = http.post(`${BASE}/checkout`, body, {
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${TOKEN}`,
    },
    tags: { route: 'checkout', tier: cfg.tag },
  });
  check(res, { 'checkout 2xx': (r) => r.status >= 200 && r.status < 300 });
  sleep(TIER === 'capacity' ? 0.2 : 0.5);
}

Patrones que funcionan

• Etiqueta corridas en calendarios: smoke diario en staging compartido; capacidad trimestral en perf dedicado—owners y presupuestos distintos.
• Rastrea horas de ingeniería de mantenimiento de scripts aparte de minutos de runner—suele ser la partida mayor.
• Dimensiona generadores antes de culpar a la API (planificación de capacidad).
• Automatiza smoke en CI; programa tiers caros con gates de aprobación (CI/CD).

Anti-patrones a evitar

• Correr soaks de 20 minutos en cada PR—quema runners, staging e ingest APM sin insight proporcional.
• Usar producción como objetivo de carga «gratis»—el costo de incidente supera ahorros en cloud.
• Comprar seats k6 cloud antes de arreglar deriva de scripts y realismo de datos—pagas por reproducir errores más rápido.
• Ignorar alertas de overage de observabilidad en la primera prueba a escala completa.

Pro tip (comando de ejemplo): la línea siguiente muestra cómo correr el tier smoke barato en CI—promueve a capacity solo cuando env y presupuesto lo permitan.

RUN_TIER=smoke API_BASE=https://staging.example.com k6 run checkout-tiered.js --quiet

Qué demuestra este comando: smoke de dos minutos a tres RPS valida regresiones sin reservar clusters perf dedicados—el tier capacity queda como job programado y financiado.

Marco de decisión: smoke vs capacidad vs soak

Usa tiers smoke si necesitas señal de regresión frecuente sin infra perf dedicada—la mayoría subfinancia corridas de capacidad pero puede pagar smoke CI.

Usa tiers capacity si liderazgo o SLAs exigen prueba de headroom—reserva env, generadores y retención observabilidad juntos.

Usa tiers soak si sospechas fugas de memoria o deriva en colas—y finanzas acepta facturas largas de runner y APM (playbook soak).

Observabilidad, documentación y próximos pasos

El control de costo falla cuando las facturas sorprenden a equipos de plataforma. Antes de escalar tráfico:

• Documenta qué valores de RUN_TIER mapean a qué infra (staging compartido vs perf dedicado).
• Estima horas mensuales de ingeniería en mantenimiento de scripts—no solo gasto en runners cloud.
• Define políticas de retención APM/log antes del primer soak de 20 minutos; los picos son predecibles.
• Archiva notas de costo por corrida (tag tier, duración, env, tipo de generador) junto a resúmenes k6.
• Revisa errores comunes que inflan costo de re-ejecución (env equivocado, corridas únicas).

Cómo Performate reduce el costo de time-to-green

Las horas de ingeniería dominan cuando cada ajuste de escenario exige editar k6 a mano y reimportar Postman. Abajo un ejemplo concreto de flujo para corridas checkout por tiers con presupuesto acotado.

Ejemplo: smoke diario, capacidad trimestral—mismo workspace

1. Importa checkout una vez desde Postman u OpenAPI. Problema resuelto: deja de pagar horas duplicando HTTP entre repos smoke y capacity.
2. Crea escenario smoke: 3 req/s por dos minutos con tags tier:smoke y p95/p99 ajustados. Problema resuelto: corridas aptas para CI que terminan antes del almuerzo—no antes de revisión de presupuesto.
3. Duplica a escenario capacity a 40 req/s por veinte minutos en staging prod-like—mismo request, distintos ajustes de panel. Problema resuelto: promueve parámetros, no reescribe scripts.
4. Exporta k6 con notas env para RUN_TIER=smoke en GitHub Actions y capacity programada aparte. Problema resuelto: un artefacto, dos perfiles de costo—finanzas ve gasto intencional.
5. Compara tendencias smoke entre releases en vista de reporte; escala a capacity solo cuando las colas de smoke derivan. Problema resuelto: corridas caras cuando los datos lo justifican, no cada sprint por hábito.
6. Comparte exportaciones con plataforma mostrando tags tier y duración—adjunta a pedidos de infra en lugar de «necesitamos un cluster» verbal. Problema resuelto: env perf financiado ligado a jobs k6 etiquetados.

Ese flujo mapea al cta: menos tiempo reinventando scripts, más confianza por dólar gastado.

Conclusión

El costo de pruebas de carga es sobre todo gente, fidelidad de entorno y observabilidad—no el binario k6. Segmenta tus corridas, etiqueta smoke vs capacity con honestidad y financia prueba de capacidad como partida programada—no tarde sorpresa en producción.

Corre smoke en CI esta semana con tope de dos minutos—luego estima qué costaría un job trimestral de capacidad en env, generadores y retención APM antes de prometer fechas a producto.

Try Performate free | Reservar demo | Escenarios k6