SLO/SLA y métricas

SLO/SLA y métricas

1) Términos y jerarquía

SLI (Service Level Indicator) es un indicador medible de «cómo nos ve el usuario»: proporción de solicitudes exitosas, p95 latencia, frescura de datos, proporción de batches procesados con éxito, etc.
SLO (Objective Service Level): valor de destino SLI en el intervalo de observación (28/30/90 días). Ejemplo: "99. El 9% de las solicitudes/pagos se completan ≤ 400 ms".
Error budget — 1 − SLO. Con SLO 99. 9% presupuesto de error = 0. 1% de tiempo/consultas.
SLA (Agreement) - Nivel de servicio legalmente significativo: incluye SLO, medición, excepciones, compensaciones/multas.

2) Principios de diseño

Síntomas> métricas internas. Los SLIs deben reflejar la experiencia real del usuario.
Pequeño número de SLI clave. En el servicio - 2-5 principales: éxito, latencia, ancho de banda/frescura, corrección.
Cobertura de vías críticas. Para cada escenario empresarial (checkout, login, webhook, ETL-download), su propio conjunto SLI/SLO.
Una estricta semántica de «éxito». No es el «código 200», sino que «el usuario ha recibido una respuesta a tiempo y el resultado es válido».
Separación de SLO externos e internos. Interior - más estricto; el SLA externo ≤ en 1-2 novenas abajo.

3) Catálogo SLI (referencia)

3. 1 API/servicios en línea

Éxito: 'SLI _ success = 1 − (5xx + timeout + business_error )/ all_requests'

Latencia: p95/p99 'http _ server _ duration _ seconds' en rutas/métodos/inquilinos

Ancho de banda: 'RPS '/límites/cuotas

Corrección: proporción de respuestas válidas (firmas, esquemas, invariantes)

3. 2 Webhooks/entregas asíncronas

Entrega: proporción de eventos confirmados en T segundos y ≤ N retraídos

Clientes: porcentaje de suscriptores sin retraso prolongado (per-tenant)

3. 3 Datos/ETL/DWH

Frescura (freshness): 'now − last_successful_ingest_ts'

Integridad: 'ingested _ rows/ expected_rows'

Corrección: porcentaje de registros que han superado los controles de calidad

Pipelines: proporción de jobs completados antes de la línea de salida

3. 4 SDK móvil/cliente

Éxito del cliente: proporción de sesiones sin errores fatales

Latencia round-trip: p95 desde la consulta hasta el renderizado

Hits de caché: porcentaje de los atendidos de la caché (como síntoma de rendimiento)

4) Fórmulas y ejemplos de objetivos

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99. 95% 'durante 30 días → error budget = 0. 05% de las consultas.

• `uptime = (obs_window − downtime) / obs_window`

• ' SLO _ latency = p95 (route = »/pay») ≤ 400 ms' en cortes de 7 días, excluyendo los calores de caché (1%)

• ' SLO _ freshness (dataset =» orders») ≤ 10 min' p99 en 24 horas.

5) Error budget y gestión de cambios

Presupuesto (B): 'B = 1 − SLO'.
Gasto presupuestario (burn): relación entre los errores reales y los válidos.

• Sobrecarga (burn> 1) → fieltro, enfoque en la fiabilidad.
• Con burn rate> X en la ventana corta - incidente y cap. medidas.
• Planificación: la proporción de sprint por fiabilidad se correlaciona con burn durante el período anterior.

6) Alerting: burn rate y reglas de múltiples ventanas

La idea: atrapar fugas rápidas y una deriva lenta.

• Crítico: «2% del presupuesto en 1 hora» (fuego rápido).
• Advertencia: «5% del presupuesto en 6 horas» (degradación deslizante).

• Ventana corta (minuto-hora) para incidentes rápidos.
• Ventana larga (6-24 horas) para las tendencias.
• Latencia: alerta de p99> umbral de ≥5 min, con supresión de flapping y comunicación con instancias de trazados.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) Multiarrendamiento (multi-tenant) y segmentación

SLI/SLO se consideran por inquilinos/planes/regiones, de lo contrario la mediana «amordazará» los fallos.
Número mínimo de eventos para significación estadística (guard-rails).
El SLA puede variar según las tarifas (por ejemplo, "Pro 99. 9%, Free 99. 5%»).

8) Relación con la observabilidad y trazabilidad

Métricas de SLI: de histogramas/contadores con exemplares → pasar a tracks «malos».
Los registros son la fuente de las razones: timeouts, códigos de error de negocio, límites.
Para los datos, un ligamento con lineage: «qué joba retrasó la métrica de frescura».

9) Contratos y SLA

• Definiciones SLI/Método de medición/ventana.
• Excepciones (trabajos programados, fuerza mayor).
• Procedimiento de incidentes y comunicaciones (status page, RFO/RCA).
• Compensación (créditos de servicio) y orden de solicitud.
• Jurisdicción, período de validez, condiciones de revisión.

• Nunca prometa un SLO público más estricto de lo que permite la arquitectura y las prácticas operativas.
• Separe los SLO internos y los SLA externos.

10) Costo y prioridad

El precio de las novenas no sube linealmente. «99. 9% → 99. 99%" = otra clase de arquitectura (N + 1, multitisona, activo-activo).
Pon SLO en las acciones personalizadas más valiosas.
Controle el costo de la telemetría: downsampling, cupos, réplica y almacenamiento por clase.

11) Procedimientos y presentación de informes

Informes semanales: ejecución de SLO por servicios/inquilinos, gasto presupuestario, razones principales, planes de mejora.
RCA postincidentes: Asociamos con las piezas del presupuesto; fijamos objetivos para abordar las causas subyacentes.
Fichfrisis: criterios de inclusión/retirada.

12) Plantillas (para inicio rápido)

12. 1 Tarjeta SLO (ejemplo)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 Tabla «Madurez de SLO»

13) Ejemplos de reglas (fragmentos)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO para datos y ML (características)

Datos SLO de extremo a extremo: frescura p99, plenitud p99, tiempo de «sobreesfuerzo» después de la falla.
Contratos de datos: esquemas previstos, volúmenes, líneas de datos; violación → incidente de datos.
ML: SLO sobre la latencia del infierno, SLA sobre la disponibilidad del fitsor, monitoreo de la deriva (la calidad del modelo es un tema separado, fuera del SLA).

15) Integración con seguridad y privacidad

Registros SLI sin PII/secretos; tokenización/enmascaramiento.
Auditar los cambios de SLO/SLA y las publicaciones de informes en revistas inmutables.
Para las vías regulatorias (pagos/PII) - SLO separados, más estrictos.

16) Hojas de cheques

Antes de iniciar el servicio/fichas

• SLI «éxito/latencia/ancho de banda/frescura».
• Dados SLO y ventanas; presupuesto de errores calculado.
• alertas de burn-rate personalizadas (corto + largo).
• Dashboards RED + exemplars → la pista; ruinabooks de incidentes.
• Cortes multiarrendamiento y umbrales de significación.
• Procedimiento de fiecfrisis y presentación de informes.

• Informe semanal sobre SLO/burn, planes de hardening.
• Revalorización de SLO cuando cambia la arquitectura/carga.
• Ocasionales «incidentes-ejercicios» y actualización de rúnicas.
• Control del costo de telemetría y de la cantidad de SLI.

17) Runbook’и

Runbook: crecimiento rápido p99/pay

1. Alerta p99> umbral → abrir el dashboard → ir por exemplar a la pista.
2. Encontrar un CLIENTE/SERVIDOR-span estrecho, comparar regiones/versiones.
3. Habilitar la degradación (caché/límite/folback), notificar al comando de dependencia.
4. Después de la estabilización - RCA, tareas de optimización, actualización de las mediciones SLO.

Runbook: gasto presupuestario> 50% en una semana

1. Congelar los fichajes, elevar la prioridad de la fiabilidad.
2. Clustering de errores: por rutas/inquilinos/dependencias.
3. Poner en marcha las correcciones → confirmar la recuperación de la tendencia.
4. Retrospectiva y ajuste de alertas/umbrales.

18) FAQ

P: ¿Cuánto SLO necesita?
R: Mínimo en escenarios críticos del usuario: éxito + latencia. Todo lo demás es necesario.

P: ¿Qué es mejor: disponibilidad en el tiempo o a petición?
R: A petición, una métrica más personalizada. Conveniente para componentes de red/infra en el tiempo.

P: ¿Por qué p95, no la media?
R: El medio oculta la cola; el usuario siente p95/p99.

P: ¿Cómo no «torcer las tuercas» demasiado?
R: Comience con metas realistas (datos históricos), luego endurezca a medida que madure.

• «Observabilidad: registros, métricas, trazados»
• «Trazados distribuidos»
• «Auditoría y registros inmutables»
• "Garantías de entrega de webhooks'
• «Encriptación In Transit/At Nat»
• «Origen de los datos (Lineage)»