---
title: "Shift-left de rendimiento: quién posee el primer script k6 en un equipo de producto"
description: "Rendimiento shift-left con k6: DRIs, umbrales CI y quién posee el primer script—cultura SRE workbook con automatización k6."
publishDate: "2026-10-08"
draft: false
keyword: "shift left pruebas rendimiento"
intent: "TOFU"
cta: "Explora cómo Performate simplifica las pruebas de carga con k6, desde imports hasta resultados, para que tu equipo publique con más confianza en rendimiento."
tags: ["k6", "pruebas-de-carga", "rendimiento-api", "shift-left", "rendimiento"]
translationOf: shift-left-performance-k6-ownership
---

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](https://sre.google/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](/es/blog/revision-salud-escenarios-k6-trimestral).

## 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.

```javascript
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](/es/blog/postman-a-k6-paso-a-paso)); promover a [perfiles CI](/es/blog/pipeline-ci-smoke-carga-stress) 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](/es/blog/usuarios-virtuales-think-time-chequeos-ia)).

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

| Etapa | DRI squad | Plataforma | SRE |
|:---|:---|:---|:---|
| Servicio nuevo | Autor smoke local | Plantilla + secretos | Candidato SLO |
| Cerca del GA | Escenario ARR estable | Runner CI | Revisar umbral vs budget |
| API compartida | Extiende plantilla | Avisos breaking | Cola entre squads |
| Data regulada | Co-firma sintéticos | Política sin prod | Auditoría de corridas |

## 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](https://performate.app) | [Guides](/guides) | [Book a demo](/demo)