KPI de infraestructura y aptime

¿por

Los KPI de infraestructura convierten los «sentimientos» de estabilidad en objetivos medibles, gestionan el riesgo y el foco de trabajo. Las métricas adecuadas relacionan los SLI técnicos con los resultados empresariales (conversión, Time-to-Wallet, LTV) y permiten planificar el desarrollo, la carga y la cuota de innovación vs confiabilidad.

Conceptos básicos: SLI, SLO, SLA y presupuesto de errores

SLI (Service Level Indicator) es un indicador de calidad medible: porcentaje de solicitudes exitosas, p95 latencia, aptime por intervalo.
SLO (Service Level Objective) es el objetivo de SLI (por ejemplo, "éxito ≥ 99. 9% en 30 días").
SLA (Agreement) es una promesa externa con sanciones/préstamos. Siempre derivado de SLO, pero no igual a él.
Presupuesto de error = '1 − SLO'. Esta es la proporción máxima permitida de «fracaso» por ventana de medición. Se utiliza para tomar decisiones sobre lanzamientos de riesgo y experimentos.

• SLO disponibilidad 99. 95% en 30 días → presupuesto de error 0. 05% ≈ 21. 6 minutos de «fracaso» en el mes calendario.

Cuatro señales «doradas» y adicionales

1. Latencia (p50/p90/p95/p99, tail es más importante que la media).
2. Errores (5xx/timeout/error empresarial).
3. Tráfico/ancho de banda (RPS/QPS, MBps).
4. Saturación (CPU/RAM/IO/FD/conexiones/GC/cuotas).
Opcional: inicio frío, colas/becklog, tiempo de deploy, SLO-cumplimiento.

Modelo SLI para diferentes tipos de servicios

HTTP/API

Disponibilidad: '(2xx/3xx acertados − errores lógicos )/( todas las consultas)'

Latencia: 'p95' para consultas exitosas; objetivo a lo largo de rutas «calientes».
Calidad: proporción de consultas con 'audience/scope' correctas (sin errores authZ).

Colas/asinchron

Tiempo de procesamiento del mensaje: p95 end-to-end ≤ N segundos.
Backlog: mediana <X, cola p99 <Y.
Error de envío: ≤ Z ppm.

BD/caché

Latencia de las operaciones: p95 get/put/commit.
Saturación: uso de la piscina de conexión, caché de hit-ratio.
Errores: timeouts, deadlocks, eviction storms.

CDN/Static

Hit Ratio: ≥ de nivel objetivo; degradación → aumento de la carga de origin.
Disponibilidad POP: Diseño Anycast, las fallas son compensadas por los vecinos.

Pagos (SLI de negocios)

Tiempo-a-Wallet p95, éxito de depósito/retiro%, tasa de fallos PSP.

Cálculo de disponibilidad y «aptime»

Disponibilidad del servicio = 'consultas exitosas/todas las solicitudes' (preferiblemente, no «minutos de aptime»).
Alternativa para nodos de infraestructura: 'tiempo en estado' verde '/tiempo de ventana '.
Ventana del calendario: 28-31 días, ventana deslizante: últimos 30/90 días.
Horario de trabajo/ventanas críticas: para backoffice se puede considerar un aptime según el horario previsto (por ejemplo, 08: 00-22: 00 hora local).

• 'Disponibilidad (A) ≈ Av (B) × Av (C) × Av (A' B, C) '- es importante poner SLO en los límites.

Ejemplo de conjunto SLO (muestra)

API Gateway: disponibilidad ≥ 99. 95 %/30д; p95 latency ≤ 120 ms; error ≤ 0. 2%.
Checkout/Payments: el éxito del depósito ≥ 98. 5 %/30д; Time-to-Wallet p95 ≤ 90 с; PSP-timeouts ≤ 0. 3%.
Base de datos: pre95 lectura ≤ 10 ms; p95 write ≤ 25 ms; replica lag p95 ≤ 150 мс.
Caché: hit ratio ≥ 85%; eviction storms = 0/30д.
Pagos: p95 procesamiento ≤ 5 minas; phrod-fols-positivos ≤ 0. 3%.

Presupuesto de errores y gestión de cambios

Si el presupuesto de errores se agota en un 50% + antes de la mitad de la ventana - se introduce la «congelación» de fich/releases, el enfoque está en la estabilización.
Si el presupuesto se gasta lentamente, es posible acelerar los experimentos/canarios.
Asocie el consumo de presupuesto con lanzamientos/incidentes específicos a través de 'release _ id'.

Alerting: cómo no «llamar por la noche» en vano

Alertas solo por degradación de SLO y síntomas vitales, no por cada métrica.
Multi-window, multi-burn rate: ventana corta (5-15 min) + larga (1-6 h).
Ejemplo: «Burn rate 14 × en 5 min Y 6 × en 1 hora» → página on-call.
Reloj silencioso para señales no P1; enrutamiento por responsabilidad (ownership).

Dashboards y prácticas de visualización

Panel SLO: cumplimiento de servicios, presupuesto restante, mapas de dependencia.
Panel Latency: p50/p90/p95/p99, descomposición en rutas/tenantes/países/ASN.
Error-panel: códigos/razones, correlación con lanzamientos/fichas.
Capacity-panel: corte CPU/RAM/IO/network/FD/connects, tendencias y predicciones.
Panel de negocios: conversión, Time-to-Wallet, depósitos/retiros, protección de impacto (WAF/antibot).

Incidentes, MTTR y post mortem

• MTTD (detección), MTTA (aceptación), MTTR/MTTC (recuperación/contención),% de los incidentes sin RCA a tiempo.
• Playbucks: quién está escalando, cómo habilitar fichas/bloques, cómo retrotraer la liberación, la comunicación con el negocio.
• Postmortem (blameless): hechos, línea de tiempo, causas de origen (esas/procesos), acciones: inmediato/a largo plazo, pruebas de regresión, efecto en SLO.

Rendimiento, saturación y degradación

Headroom: stock de recursos de destino (por ejemplo, CPU <70% p95, RAM <75% p95).
Hot paths: perfilar rutas críticas; 'p99' es más importante que la media.
Degradation modes: caché-sólo, read-only, pulido drop de solicitudes sin importancia, «límite de apuestas «/cuota.

Fórmulas y ejemplos de cálculos

1) Disponibilidad a petición

availability = (total_requests - error_requests) / total_requests

donde 'error _ requests' = 5xx + timeouts + errores empresariales (configurable).

2) Presupuesto de errores (minutos)

error_budget_minutes = window_minutes (1 - SLO)

Ejemplo: 30 días (43.200 min), SLO 99. 95% → 21. 6 minutos

3) Burn rate

burn_rate = observed_error_ratio / (1 - SLO)

Si SLO 99. 9% (presupuesto 0. 1%) y el error 1% → burn_rate = 10 ×.

4) Disponibilidad compuesta

A_total ≈ A_gw × A_auth × A_db × A_psp

Las pequeñas caídas golpean multiplicativamente el total de A.

Directivas de medición y

Ventanas no programadas (incidentes): se contabilizan.
Ventanas de servicio programadas: sólo se tienen en cuenta si el SLA está así prescrito; para SLO a menudo no se restan (o se marcan por separado como 'planned _ downtime').
Sintética vs usuarios reales: es útil tener ambos canales (RUM + chequeos sintéticos).

Ejemplos de artefactos

KQL/PromQL (ideas)

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (SLI de negocios por pago)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Administración de dependencias y cascadas

Contratos de SLO entre equipos: gateway↔auth↔wallet↔PSP.
Políticas de degradación: cuando cae la dependencia, el servicio pasa al «modo simplificado».
Flags de función: desactivar funciones no críticas, «liberación gris» para reducir las colas latency.

Planificación de la capacidad y predicciones

Shchomes. pronóstico de RPS/MBps sobre tendencias y eventos (torneos, partidos, promociones).
Prueba de carga por «caminos de oro», pruebas individuales para PSP/pagos.
Stock en pico: factor objetivo 1. 3×–2. 0 × de la carga esperada.

Lista de comprobación de implementación de SLO/KPI

1. Identificar rutas de usuario críticas y negociar SLI «desde la perspectiva del cliente».
2. Seleccionar objetivos de SLO y ventana (30/90 días); contar el presupuesto de errores.
3. Integrar la recogida de métricas en las puertas de enlace/servicios, normalizar los códigos/causas.
4. Configurar alertas burn-rate (ventana corta + larga), enrutamiento y on-call.
5. Visualizar el cumplimiento de SLO, asociar con lanzamientos/fichflags.
6. Poner en marcha una política de «presupuesto contra cambio» y un proceso de congelación.
7. Retrospectivas y RCA por cada exceso, pruebas de regresión.
8. Revisa trimestralmente SLO sobre el uso real del presupuesto y los objetivos comerciales.

Errores típicos

Miden el «aptime por ping», ignorando los errores de las aplicaciones.
Los SLO se exponen «sobre el stock» (99. 999%), pero son inalcanzables y no resuelven nada.
Alertas en métricas de bajo nivel en lugar de síntomas personalizados.
No hay mapa de dependencias → no está claro dónde se quema.
No hay conexión entre SLO y los lanzamientos → no está claro quién se «comió» el presupuesto.
Ignorar las colas p99 → buenos medios pero malos usuarios VIP UX.

Características específicas para iGaming/Fintech

Picos programados: partidos/eventos/promociones - aumentar la capacidad de antemano, calentar el caché/CDN, incluir perfiles de límites especiales.
SLI Business: Time-to-Wallet, éxito de depósito/retiro, «velocidad de pago» p95; en la raíz de los dashboards.
PSP/partners: SLO/dashboards individuales por proveedor, cambio automático de ruta.
Antibot/antifraude: no debe dejar de lado el presupuesto de errores - separar los «bloques legítimos» de los «errores técnicos».
Regulación: almacenamiento de registros, reproducibilidad de cálculos SLO/SLA, informes de incidentes.

FAQ

¿Es necesario restar los trabajos programados del SLO?
Normalmente no: SLO refleja la experiencia que experimenta el usuario. Se pueden estipular excepciones para el SLA.

¿Por qué p95, no la media?
La media enmascara las colas; UX define las colas (p95/p99).

¿Es posible un SLO para todo el producto?
Necesita un árbol SLO: agregado por producto e hijo por rutas/componentes críticos.

Resultado

Un sólido sistema de infraestructura de KPI es SLI personalizados, SLO realistas, presupuesto de errores como palanca de control de cambios, alerta inteligente y disciplina de incidentes y RCA. Vincule los indicadores técnicos a las métricas del negocio, automatice la recopilación y la visualización, y la infraestructura se volverá predecible y el aptime estará controlado incluso en escenarios máximos.