Playbook de soak testing: memory leaks, deriva de conexiones y cuándo detener la corrida

Las pruebas cortas no ven memory leaks ni deriva de pools que requieren horas. El soak mantiene carga moderada para observar pendiente — no RPS pico (guía soak Grafana). La pregunta no es "¿sobrevivimos cinco minutos?" sino "¿la latencia o tasa de error crecen mientras el tráfico permanece plano?"

Este playbook cubre cuándo hacer soak, cómo dotar de personal las decisiones de abort, un escenario k6 a ~70% del pico RPS, y correlación con gráficos heap APM. Combínalo con muestra soak de health trimestral — soak completo antes de ventanas de uptime más largas.

Cuándo hacer soak (y cuándo omitir)

Los soak tests cuestan tiempo y ocupación de staging. Correlos cuando degradación lenta causa incidentes reales:

• Antes de eventos de varios días — conferencias, ventanas de nómina, picos de compras navideñas.
• Tras upgrades JVM/Node/runtime — cambios de GC exponen leaks que baselines antiguos omitían.
• Cuando incidentes muestran creep lento de métricas — p95 sube horas sin deploy ni cambio de tráfico.
• Tras cambios de pool de conexiones o config ORM — desajustes de idle timeout aparecen como agotamiento gradual.

Omite soak completo cuando careces de vigilancia APM con personal, staging es compartido sin reserva, o no pasaste baseline de carga steady de 10 minutos — arregla regresiones obvias primero (stress vs carga).

Criterios de abort antes de empezar

Designa un owner de abort con autoridad para detener la corrida sin war room. Tripwires de ejemplo:

• Pendiente de p95 sube >20% en 2 horas con RPS k6 plano.
• Tasa de error supera 1% durante 10 minutos consecutivos.
• Crecimiento lineal de heap o conexiones activas en APM sin meseta.
• DLQ o profundidad de cola sube en caminos async vinculados (pruebas de colas).

Documenta tripwires en el ticket — on-call a la hora cuatro no debería debatir si detener.

Escenario soak k6

Ejemplo ilustrativo — no es una prueba lista para producción. Soak en producción puede correr 2–4 horas; el ejemplo usa 30m para iteración amigable en lab — extiende duración antes de eventos reales una vez que funcione monitoreo de pendiente.

Qué demuestra este ejemplo:

• constant-arrival-rate a RPS moderado — ~70% del pico documentado, no carga hero.
• Tags suite:soak filtran métricas de smoke CI corto en el mismo servicio.
• Think time más largo reduce churn artificial si la ruta es read-heavy.
• Umbrales en percentiles de duración — observa tendencias en el tiempo, no solo resumen final (exporta a Prometheus/Grafana para pendiente).

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

const BASE = __ENV.API_BASE || 'https://staging.example.com';

export const options = {
  scenarios: {
    soak: {
      executor: 'constant-arrival-rate',
      rate: Number(__ENV.SOAK_RPS || 15),
      timeUnit: '1s',
      duration: __ENV.SOAK_DURATION || '30m',
      preAllocatedVUs: 10,
      maxVUs: 50,
      tags: { suite: 'soak' },
    },
  },
  thresholds: {
    'http_req_duration{suite:soak}': ['p(95)<800'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get(`${BASE}/work`, { tags: { route: 'work', suite: 'soak' } });
  check(res, { ok: (r) => r.status < 500 });
  sleep(Number(__ENV.THINK_SEC || 1));
}

Patrones que funcionan

• Exporta métricas k6 a Prometheus/Grafana — grafica p95 por minuto, no solo resumen final.
• Correlaciona heap, GC, conteo activo de pool con timeline k6 — captura para tickets de leak.
• RPS moderado — soak encuentra deriva; stress encuentra punto de quiebre — objetivos distintos.
• Mismas reglas de datos sintéticos que pruebas más cortas (datos GDPR).

Anti-patrones a evitar

• Soak al 100% del pico RPS — confunde fallo de capacidad con deriva.
• Corrida nocturna sin personal en staging compartido — nadie aborta; compañeros culpan tu prueba por sus fallos.
• Número final único de p95 en slide ejecutivo — oculta historia de pendiente.
• Ignorar efectos secundarios async — HTTP plano mientras profundidad de cola sube.

Pro tip (comando de ejemplo): empuja métricas a Grafana para gráficos de pendiente.

k6 run soak.js -o experimental-prometheus-rw --tag suite=soak

Qué demuestra este comando: cuando remote write Prometheus está configurado, p95 en el tiempo se vuelve visible — soak solo-resumen omite el creep que este playbook apunta. Adapta flag de output a tu stack de observabilidad.

Marco de decisión: señales durante soak

Detén pronto cuando la pendiente es obvia — otras dos horas rara vez cambian prioridad del ticket.

Observabilidad y checklist pre-corrida

• RPS moderado (~70% del pico) documentado con fuente.
• On-call u owner de abort vigilando APM + k6 en vivo — no "revisar por la mañana".
• Procedimiento post-run de GC/log/thread dump enlazado en runbook.
• Reserva staging comunicada — evita colisión con jobs carga CI.
• Datos sintéticos únicamente; caminos write idempotentes si reruns se solapan.
• Archiva enlace dashboard Grafana + resumen JSON k6 en el mismo ticket.

Cómo Performate simplifica soak testing

Abajo hay un ejemplo de flujo concreto para extender escenario steady a soak — adapta ruta y duración a tu calendario de eventos.

Ejemplo: clon steady → soak nocturno

1. Clona escenario steady de última corrida load verde — mismos requests y tags. Problema resuelto: soak prueba camino real de usuario, no URL one-off sintética.
2. Baja rate a ~70% pico; extiende duración en UI — 30m lab, 2h+ pre-evento. Problema resuelto: sin editar bloques executor a mano solo por cambio de duración.
3. Corre de noche en staging con owner de abort nombrado en canal Slack. Problema resuelto: export escritorio + métricas en vivo sin construir glue Grafana primero.
4. Exporta gráficos de tendencia del reporte integrado para revisión de pendiente. Problema resuelto: adjunto ticket leak listo aunque export Prometheus no esté cableado.
5. Abre ticket leak si pendiente mala — enlaza export + captura APM con timestamp. Problema resuelto: equipo dev recibe evidencia acotada en tiempo, no "perf se sintió peor".
6. Archiva para comparación muestra soak de health trimestral. Problema resuelto: deriva trimestre a trimestre visible en mismo linaje de workspace.

Ese flujo mapea directamente al cta de este post: escenarios soak ejecutables y exports de tendencia compartibles sin código de integración.

Cierre

Soak responde ¿degrada con el tiempo? — programa uno antes de tu ventana de uptime más larga, dota tripwires de abort con personal y grafica pendiente — no solo percentiles finales.

Clona tu escenario de carga más estable, baja RPS al setenta por ciento del pico, corre treinta minutos con alguien vigilando APM y detén pronto si la línea sube.

Try Performate free | Book a demo | Soak k6