Error Budgets y gestión de SLO

1) Por qué SLO y presupuesto de errores

SLO (Service Level Objective) es el nivel de calidad objetivo percibido por el usuario; SLI - métrica a medir; Error Budget - Tolerancia de desviación por ventana (normalmente 30/90 días).
El presupuesto de errores transforma la confiabilidad de la «abstracción» en un recurso administrado: cuando el presupuesto se quema rápidamente - congelamos los fiches y chinim; cuando el presupuesto es saludable - puede acelerar las liberaciones.

2) Selección de SLI: qué considerar «bueno»

Criterio: «con éxito desde el punto de vista del usuario».

2. 1 SLI clásico

Disponibilidad: porcentaje de solicitudes válidas (excluyendo las canceladas por el cliente).
'success = http_status ∈ {2xx, 3xx, 404} y sin tiempo de espera' (404 puede considerarse un éxito para la API de lectura si es la semántica esperada).
Latency: la proporción de solicitudes es más rápida que el umbral (por ejemplo, p95 ≤ 300 ms).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness: «datos no mayores de X minutos» (caché, directorios, factores).
Calidad: la corrección del resultado (paso de validadores de negocios/invariantes de fondo).

2. 2 Límites y segmentos

SLI debe contarse por cortes importantes: 'route', 'tenant/brand', 'region/jurisdiction', 'payment _ provider'. Por lo tanto, no va a «desenfocar» la falla de un lápiz crítico en todo el sistema.

3) Fórmulas y presupuesto

3. 1 Request-based (preferiblemente para API)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 Time-based (para servicios de fondo/streaming)

SLO_uptime = good_minutes / total_minutes

3. 3 Ejemplos de objetivos

API generales: 99. 9% de disponibilidad en 30 días → presupuesto = 0. 1%.
Bolígrafos de pago críticos: 99. 95%; directorios/búsqueda: 99. 5%.
Latencia: p95 ≤ 300 ms por '/v1/payments ', p99 ≤ 800 ms.

4) Herramientas SLI

4. 1 Principios

Logs/tracks → métricas RED (Tasa/Errores/Duración) con buckets explícitos.
Asegúrese de colocar 'tenant', 'region', 'route _ class' (sin PII).
Cuenta dos métricas: «éxito» y «todo», y para latency, «rápido» y «todo».

4. 2 Ejemplo Prometheus (tasa de 5m)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) Alertas de burn rate (multi-window, multi-burn)

5. 1 Idea

Vamos a ver a qué velocidad se quema el presupuesto con respecto al objetivo. Si la velocidad es alta en una ventana corta y larga - señal.

5. 2 Perfiles de umbral (para SLO 99. 9%)

Paging: burn rate ≥ 14. 4 × (10% del presupuesto en 1 hora y 5% en 6 horas).
Ticket: burn rate ≥ 6 × (2% en 6 horas y 1% en 24 horas).

5. 3 Ejemplo de reglas (Prometheus, pseudo)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

Similar a 6h/24h para el ticket.

6) Oficina de Presupuesto: Procesos

6. 1 Gates de lanzamiento

Si el saldo del presupuesto es <25% y la tendencia es negativa es «código de congelación» en los fiches, prioridad SRE/sostenibilidad.
Los lanzamientos canarios deben tener un corte SLO separado ('deployment. environment="canary"`).

6. 2 Priorización de Becklog

Distribuya la capacidad del equipo en proporción a la velocidad de combustión y al impacto en los ingresos.
Justifique la deuda técnica con métricas: «el fix X reducirá la tasa burn en Y%».

6. 3 Post-incidente

Cada incidente es RCA y «fix que no se puede retrotraer» (actionable), el control «ha vuelto a SLO».

7) SLO como código

7. 1 Ejemplo de manifiesto SLO (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 Generación de reglas

Utilice generadores (slo-generator, pyrra, sloth) para crear automáticamente reglas, dashboards e informes.

8) Degradación y protección de SLO

Load shedder: dar respuestas rápidas sin dependencias «caras» en el pico.
Cache & stale: `stale-while-revalidate` для read.
Rate/Concurrency limits: protege los backends; rutas importantes - prioridad.
Circuito/Timeout: tiempos rápidos y ramas «fallback».
Flags de función: desactivar los fiches pesados con un solo botón.

9) Observabilidad para SLO

Dashboards: SLO actual vs target, presupuesto restante, tasa burn, contribución en rutas/proveedores.
Correlación: del «agujero» de SLO → al exemplar → trace específico → logs/perfiles.
Informes: semanalmente - tendencias, consumo del presupuesto, las principales causas de la degradación.

10) Antipattern

Un SLO «global» para todo el → enmascara los problemas. Segmentar.
«99. 99% para todo" sin tener en cuenta el coste y la realidad. Seleccione objetivos de la experiencia del usuario.
Alertas por CPU/heap en lugar de burn rate/SLO.
Ignora los redirecciones 4xx/largos que estropean a UX.
Ventana opaca (rolling vs calendario) - comparaciones de «manzanas con naranjas».

11) Especificidad de iGaming/finanzas

Formas de dinero (depósitos/retiros): SLO individuales por encima del nivel general (por ejemplo, 99. 95% de disponibilidad; p95 ≤ 250 ms).
Proveedores de PSP/KYC: SLO para cada proveedor + alertas sobre su contribución a burn; conmutación automática de rutas (smart routing).
Jurisdicciones/tenantes: SLO y presupuestos por 'region/jurisdiction/brand' para que el problema local no «inunde» la métrica global.
Juego responsable: SLO durante la aplicación de límites/autoexclusión (fórmulas compliance).
Auditoría/regulación: almacena informes de SLO e incidentes; transparencia para las auditorías internas.

12) Lista de comprobación prod

• SLIs (availability/latency/quality/freshness) y segmentos (route/tenant/region) definidos.
• Los objetivos (SLO) son realistas, coherentes con el negocio; hay ventanas rolling 30/90 días.
• Alertas por rate burn con múltiples ventanas (paginación/ticket).
• SLO como código (generador de reglas/dashboards); Informes de presupuesto.
• Las puertas de lanzamiento están atadas al saldo del presupuesto; cortes canarios.
• Mecanismos de degradación (shedder, cache stale, circuit, limites) implementados y probados.
• Correlación de métricas ↔ tracks (exemplars), runbooks claros.
• Vías financieras/jurisdiccionales - SLO/alertas individuales; PSP/KYC están desagregados.
• Retro regular sobre incidentes e inversión en fiabilidad basada en burn.

13) TL; DR

Identifique SLI por valor personalizado, establezca SLO realistas y administre a través de Error Budget y burn rate con múltiples ventanas. Incluye código SLO, gates de lanzamiento y degradación según el plan. Segmentar por rutas/tenantes/regiones; para formas de dinero, mantenga objetivos más rígidos y alertas separadas.