Shift-left de rendimiento: quién posee el primer script k6 en un equipo de producto

Los emails de plataforma dicen «shift-left de rendimiento», pero el servicio de checkout nuevo sale sin un solo archivo k6 en el repo. Hay colecciones Postman; CI corre unit tests; y el primer incidente en producción se convierte en debate sobre quién debió probar en carga—plataforma, SRE o el squad dueño del feature.

Shift-left solo funciona cuando la propiedad está nombrada antes de escalar, no repartida tras un outage. Esta guía define quién posee el primer script k6 en un equipo de producto, qué debe cubrir, cómo gradúa a CI y qué rituales evitan que se pudra cuando rota el DRI.

Por qué importa más el owner del primer script que un guild de perf

Los guilds ayudan con plantillas y formación—no reemplazan un responsable directo (DRI) en el squad que cambia la API cada sprint (cultura SRE workbook).

• Squads de feature saben qué endpoints movieron y qué flujos de auth rompieron.
• Plataforma aporta secretos, capacidad de runners y plantillas—not every scenario.
• SRE define matemática de SLO y revisa quema de error budget.
• QA valida que reportes mapeen criterios de aceptación.

El primer script es pequeño a propósito: readiness + un camino dorado de negocio, no simulación del sistema entero.

Cuando falla «plataforma posee perf»

Scripts huérfanos, umbrales con URLs viejas y secretos CI expirados. La solución no es más reuniones—es un smoke con tag owner:checkout y un nombre en SERVICE.md.

Combina ownership con health checks trimestrales.

k6 práctico: smoke del squad con camino de promoción

El DRI publica smoke en sprint uno y promueve el mismo archivo a CI tras dos verdes en escritorio.

Script de ejemplo (ilustrativo).

Qué demuestra:

• Radio bajo: per-vu-iterations con 3 VUs.
• Tags de owner: owner:checkout vía env en reportes.
• Readiness + negocio: /ready luego /api/orders.
• Umbral solo en errores al inicio—latencia cuando exista baseline.

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

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

export const options = {
  scenarios: {
    squad_smoke: {
      executor: 'per-vu-iterations',
      vus: 3,
      iterations: 5,
      tags: { owner: SQUAD, suite: 'smoke' },
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const ready = http.get(`${BASE}/ready`, { tags: { route: 'ready', owner: SQUAD } });
  check(ready, { ready: (r) => r.status === 200 });

  const orders = http.get(`${BASE}/api/orders`, {
    headers: { Authorization: `Bearer ${__ENV.TOKEN}` },
    tags: { route: 'orders', owner: SQUAD },
  });
  check(orders, { orders_ok: (r) => r.status >= 200 && r.status < 500 });
  sleep(0.5);
}

Patrones: import Postman existente (Postman a k6); promover a perfiles CI tras dos verdes; añadir p(95) cuando producto acuerde número.

Anti-patrones: esperar hire de perf dedicado; plataforma escribe sin revisión del squad; 500 VUs el día uno (sanity VUs).

Marco de decisión: quién hace qué según madurez

Observabilidad y siguientes pasos

• DRI y backup en SERVICE.md.
• Enlace al workspace k6 en README del servicio.
• Smoke en CI en dos sprints.
• Archivar primer export verde con git SHA.
• Revisión trimestral de smoke + steady.

Cómo Performate habilita ownership shift-left en el squad

Ejemplo: squad checkout publica smoke semana uno

1. Importa la carpeta Postman del squad el día uno—sin esperar glue code de plataforma. Problema resuelto: el DRI arranca desde requests que ya cura.
2. Crea squad_smoke en el editor visual con tag owner checkout. Problema resuelto: tags coinciden con el modelo k6 de arriba sin typos de YAML.
3. Corre localmente contra staging; corrige secretos de entorno en perfiles Performate. Problema resuelto: bucle más rápido que editar .env a mano por desarrollador.
4. Añade umbral http_req_failed; luego añade p(95) cuando exista número de SLO. Problema resuelto: gates progresivos sin archivos nuevos.
5. Exporta k6 al repo del servicio; plataforma cablea CI usando el mismo archivo. Problema resuelto: un artefacto de escritorio a pipeline.
6. Entrega export PDF a runbooks de on-call con tags de ruta para incidentes. Problema resuelto: evidencia de perf vive donde responders ya miran.

Cierre

Shift-left = owner nombrado + script smoke. Nombra al DRI, publica readiness + un camino dorado este sprint y promueve a CI con evidencia.

Añade el DRI a SERVICE.md hoy y corre el smoke antes de la próxima planning.

Try Performate free | Guides | Book a demo