SLA, SLO y presupuestos de error para APIs: convertir métricas en puertas de release

El dashboard muestra 99,2 % de disponibilidad este mes—todo en verde. El martes el p99 de checkout se duplica durante seis horas, suben los tickets de soporte y finanzas pregunta por qué publicaste un release de features esa misma mañana. La brecha no son métricas faltantes; es política faltante. Los SLA describen lo que debes al cliente, los SLO lo que prometes internamente, y los presupuestos de error traducen esas promesas en un allowance finito de minutos malos que puedes gastar en velocidad.

Los equipos de API que tratan los SLO como posters en lugar de puertas de release lo aprenden a las malas. k6 hace la política ejecutable: umbrales sobre http_req_duration, checks de negocio personalizados y rutas etiquetadas convierten objetivos abstractos en señales pass/fail que CI y staging pueden exigir. En esta guía verás qué SLIs siente el usuario, cómo mapearlos a umbrales k6 y cuándo un presupuesto de error en llamas debería congelar lanzamientos—no solo mandar un emoji a Slack.

Por qué los SLIs importan más que los gráficos de infraestructura

Los clientes no experimentan utilización de CPU. Experimentan checkout lento, pagos fallidos y timeouts en búsqueda. Elige SLIs que reflejen esos momentos:

• Colas de latencia en rutas críticas—checkout, auth, búsqueda—no promedios globales (p95 vs p99).
• Disponibilidad medida en la capa HTTP que tus clientes golpean, no solo readiness de pods.
• Señales de corrección donde duplicados o escrituras parciales tienen impacto financiero (IDs de pedido, claves de idempotencia).

Piensa en un presupuesto de error como un tanque mensual de combustible. Gástalo en experimentos planificados y trade-offs conocidos; cuando está vacío, dejas de sumar features y arreglas deuda de confiabilidad (regresión de línea base).

Cuando dashboards verdes siguen violando el SLO

Los checks sintéticos de uptime pueden pasar mientras journeys reales fallan bajo concurrencia. Combina SLIs de producción con pruebas de carga que ejerciten las mismas rutas a tasas realistas—si no, el presupuesto refleja huecos de monitoreo, no experiencia de usuario.

Implementación práctica en k6: umbrales SLI y burn de presupuesto

Define un SLO por journey crítico y codifícalo como umbrales k6 etiquetados por ruta. Las corridas en staging deben usar puertas más estrictas que los objetivos de producción para detectar regresiones antes de consumir presupuesto en vivo.

Script de ejemplo (ilustrativo—no listo para producción). URLs, tokens y números SLO ficticios; adapta a tu entorno.

Qué demuestra este ejemplo:

• SLIs por ruta: umbrales en http_req_duration{route:checkout} y {route:search} en lugar de una línea global.
• Puerta de disponibilidad: http_req_failed limitado al 0,5 % de la corrida—proxy del burn mensual de presupuesto en CI.
• SLI de negocio personalizado: métrica Rate que cuenta respuestas de pedido duplicado, con umbral propio.
• Etiquetado por build: la variable git_sha etiqueta cada request para comparar releases manzanas con manzanas.

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

const BASE = __ENV.API_BASE || 'https://staging.example.com';
const duplicateOrders = new Rate('duplicate_order_responses');

export const options = {
  scenarios: {
    checkout_sli: {
      executor: 'constant-arrival-rate',
      rate: 20,
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 15,
      maxVUs: 60,
      tags: { route: 'checkout', slo: 'checkout-latency' },
      exec: 'checkoutFlow',
    },
    search_sli: {
      executor: 'constant-arrival-rate',
      rate: 50,
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 10,
      maxVUs: 40,
      tags: { route: 'search', slo: 'search-latency' },
      exec: 'searchFlow',
    },
  },
  thresholds: {
    'http_req_duration{route:checkout}': ['p(95)<800', 'p(99)<1200'],
    'http_req_duration{route:search}': ['p(95)<400', 'p(99)<700'],
    http_req_failed: ['rate<0.005'],
    duplicate_order_responses: ['rate<0.001'],
  },
};

export function checkoutFlow() {
  const idempotencyKey = `ord-${__VU}-${__ITER}-${Date.now()}`;
  const body = JSON.stringify({ sku: 'SKU-100', qty: 1 });
  const res = http.post(`${BASE}/v1/checkout`, body, {
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${__ENV.TOKEN}`,
      'Idempotency-Key': idempotencyKey,
    },
    tags: { route: 'checkout', git_sha: __ENV.GIT_SHA || 'local' },
  });
  check(res, { 'checkout 2xx': (r) => r.status >= 200 && r.status < 300 });
  duplicateOrders.add(res.headers['X-Duplicate-Order'] === 'true');
  sleep(0.2);
}

export function searchFlow() {
  const res = http.get(`${BASE}/v1/search?q=laptop&limit=20`, {
    headers: { Authorization: `Bearer ${__ENV.TOKEN}` },
    tags: { route: 'search', git_sha: __ENV.GIT_SHA || 'local' },
  });
  check(res, { 'search 2xx': (r) => r.status >= 200 && r.status < 300 });
  sleep(0.1);
}

Patrones que funcionan

• Puertas escalonadas: smoke en CI (tasa baja, errores estrictos) + cortes soak semanales a carga con forma de producción (pruebas de carga en CI/CD).
• Umbrales por ruta alineados a docs de SLO de producto—no un número copiado del PDF de SLA de marketing.
• Resets de presupuesto documentados: si ensanchas un umbral tras una corrida fallida, registra sign-off de stakeholders y la nueva fecha de línea base.

Antipatrones a evitar

• Presupuestos de vanidad que siempre pasan porque los umbrales se aflojaron en silencio tras builds rojos.
• Medir solo http_req_duration sin tasa de fallos—latencia y disponibilidad queman presupuesto juntas.
• Usar números SLO de producción directamente en pruebas de carga agresivas; las puertas de staging deben ser más estrictas.

Pro tip (comando de ejemplo):

k6 run slo-gates.js -e GIT_SHA=$(git rev-parse --short HEAD) --summary-export=slo-summary.json

Qué demuestra este comando: cada request lleva la etiqueta de build y el export JSON alimenta dashboards de release o calculadoras de burn fuera de k6.

Marco de decisión: cuándo publicar vs congelar

Publica si las pruebas de carga en staging pasan con la forma de tráfico actual y el presupuesto restante cubre el riesgo del lanzamiento.

Congela si el burn de error en producción o staging viola la política durante dos ventanas de medición consecutivas—la velocidad para hasta que los SLIs se recuperen.

Resetea líneas base solo con aprobación escrita, nueva fecha objetivo y resúmenes k6 archivados para comparación (ejemplos de umbrales k6).

Observabilidad, documentación y próximos pasos

La política SLO solo funciona cuando los equipos comparten las mismas definiciones:

• Publica definiciones de SLI (ruta, percentil, ventana) donde ingeniería y producto las encuentren.
• Conecta fallos de umbrales k6 al mismo canal que alertas de presupuesto en producción.
• Archiva JSON de summary-export por release con git_sha para auditoría.
• Revisa burn semanalmente en un ritual de 15 minutos—sin slide deck, solo números vs política.
• Combina puertas SLO con cómo leer reportes de pruebas de carga para que no especialistas interpreten fallos.

Cómo Performate simplifica pruebas de carga orientadas a SLO

Traducir hojas SLO en corridas k6 repetibles se rompe cuando cada equipo edita scripts distinto. Abajo un flujo concreto para SLIs de checkout y búsqueda—adapta rutas y números a tus docs de política.

Ejemplo: codificar SLOs de checkout y búsqueda sin drift de umbrales

1. Importa una colección Postman con login, POST checkout y GET búsqueda—los mismos journeys que nombra tu doc SLI. Problema resuelto: un artefacto coincide con el lenguaje de producto y el código de prueba.
2. Crea dos escenarios en el editor visual—checkout_sli a 20 req/s y search_sli a 50 req/s—con tags route:checkout y route:search. Problema resuelto: métricas por ruta sin copiar bloques de ejecutores a mano.
3. Define umbrales en la UI según puertas de staging: checkout p95 < 800 ms, búsqueda p95 < 400 ms, http_req_failed < 0,5 %. Problema resuelto: QA y SRE editan los mismos números que aprobó producto.
4. Corre y abre la vista de comparación tras cada release candidate; filtra por tag de ruta y revisa cola de latencia antes del merge. Problema resuelto: debates de release referencian un export, no hojas bifurcadas.
5. Exporta el script k6 con env vars para GIT_SHA e intégralo en smoke de CI (pruebas de carga en CI/CD). Problema resuelto: ajuste en escritorio y puertas de pipeline alineados.
6. Archiva historial de corridas junto a fechas de deployment para que postmortems de presupuesto mapeen a configs exactas de escenario.

Ese flujo coincide con el cta de este post: publica con más confianza en rendimiento cuando imports, umbrales e informes viven en un workspace de escritorio.

Cierre

Los presupuestos de error no son vocabulario abstracto de SRE—son política de release con un número adjunto. Mapea cada SLI orientado al cliente a un umbral k6 etiquetado, bloquea merges cuando el burn en staging viola puertas y congela features cuando el presupuesto en vivo se agota.

Corre esta semana la mezcla de staging contra tus SLIs de checkout y búsqueda antes de la próxima revisión de lanzamiento—y anota si el presupuesto restante cubre el riesgo que vas a publicar.

Try Performate free | Book a demo | k6 thresholds