Observabilidad y control del estado

1) Objetivos y principios

Objetivo: comprender en tiempo real «qué está pasando» y «por qué» para prevenir incidentes y recuperarse rápidamente sin violar el SLO ni inflar el OPEX.
Principios: SLO-first, «señales de oro» (latency, traffic, errors, saturation), estándar único de telemetría (OpenTelemetry), detalles mínimamente suficientes, explicabilidad, observabilidad costaware.

2) Capas de observabilidad

1. Métricas: agregados para SLI/SLO, capacidad y tendencias (modelos RED/USE).
2. Tracks: cadenas causales de solicitudes, pagos y transacciones de juegos.
3. Registros/eventos: contexto detallado y auditoría de las acciones de los operadores/servicios.
4. Sintética (black-box): comprobaciones externas de API/rutas web, PSP/KYC pings hels.
5. RUM (usuario real): métricas de primera línea (TTFB, LCP, errores JS), cortes geo/device.
6. Telemetría de bajo nivel: eBPF/profiling CPU/IO/alloc, retardo percentil de red.

3) Conjunto de SLI y «señales de oro»

Latency: p50/p95/p99 por caminos críticos (inicio de sesión, depósito, tasa, retiro).
Errores: participación 5xx/timeout/decline (con normalización por proveedores/bancos).
Traffic/Throughput: RPS/TPS, sesiones activas, eventos/sec.
Saturation: descarga de CPU/RAM/IO, profundidad de colas, pool-usage, replication log.
SLI de negocios: depósitos exitosos/tasas de% por ventana, desviaciones de la conversión de KYC/PSP, cuota de chargeback.

4) Arquitectura de telemetría

Higo estandarizado: OpenTelemetry SDK/collector → normalización, muestreo, filtros de privacidad → almacenamiento (TSDB, rastreo, registros).
Correlación: trace-id/span-id en logs y métricas (exemplars); un único ID de correlación para los eventos de pago/juego.
Topología: servicio de mapa (service graph), proveedores externos dependientes con SLI en vivo.
Gestión de costos: niveles de retención, agregación, muestreo dinámico, clases de almacenamiento «caliente «/» frío ».

5) Métricas: diseño y cardinalidad

Reglas: número pequeño de etiquetas, prohibición de alta cardinalidad (userId, sessionId) en series de tiempo; tales detalles son sólo en pistas/registros.
RED/USE: Requests-Errors-Duration для API; Utilization-Saturation-Errors para infraestructura.
Exemplars: enlaza percentiles altos a ejemplos trace específicos.
Métricas de negocio: $/RPS, conversión de PSP por banco/GEO, tolerancia a fallas de los proveedores.

6) Senderismo: profundidad y sampling

Contexto: trace-contexto a través del frente → API → brokers → workers → DAB/PSP.
Sampling: básico 1-10%, con anomalías - mejora dinámica según reglas (tail-based).
Enfoque: flow de pago (init → auth → capture/settle), transacciones de juego (bet → settle), KYC (init → verify).
Anotaciones: código de respuesta PSP, categoría bank-BIN/issuer, región, riesgo-score.

7) Registros y auditorías

Registros estructurados: JSON, nivel por perfil (INFO en venta, DEBUG en depuración).
Filtros de privacidad: enmascaramiento PII, prohibición de documentos KYC en bruto en los logs.
Eventos de auditoría: quién/qué/dónde/cuándo/por qué, ID de ticket, valores pre/post para operaciones de alto riesgo (bonos, límites, routing PSP).
Inamovible: WORM/immutable, firma, retoque de políticas.

8) Control del estado (salud)

Liveness/Readiness/Startup: muestras correctas (no comprobar las dependencias externas en liveness).
Modo degradado: banderas explícitas de degradación del servicio para que las alertas y la página de estado sean coherentes.
Budget health: presupuesto de error burn-rate (ventana rápida/lenta), headroom por recursos y colas.

9) Alerta y alerta temprana

SLO-alertas: bajo el presupuesto de errores (4 horas y 1 hora ventanas) en lugar de «crudo» p95.
Anomalías: detectores STL/IQR/en línea para picos de 5xx, caídas de autorizaciones PSP en un GEO/banco específico.
Root-cause hints: asociamos las alertas con los últimos lanzamientos/fichflags/trabajos planificados.
Runbooks: cada alerta tiene links en el playbook, gráficos, «chequeos rápidos».

10) Dashboards (quién y qué ve)

Exec: aptime/SLO, burn-rate, depósitos/apuestas exitosas, estado de los proveedores, pronóstico de capacidad y $/RPS.
SRE/plataforma: RED/USE por servicios, colas/lag, pool-usage, replication log, CDN/WAF, perfiles eBPF.
Payments/Risk: éxito de las autorizaciones PSP/bancos/GEO, soft/hard declines, tiempo KYC, chargeback early-signals.
Support/CS: panel de estado de incidentes, SLA de respuesta, macros de preguntas frecuentes.

11) Gestión del coste de la observabilidad (FinOps-Observabilidad)

Retiro: 7-14 días para pistas «crudas», unidades más largas; selectivo - servicios calientes.
Sampling/agregación: muestreo dinámico de anomalías, descarga de series antiguas.
Políticas de ingestión: cortar el ruido (pings de salud, registros redundantes), cuotas de métricas de alta cardinalidad.
KPI de valor: $/GB ingest, $/trace, $/SLI dashboard; los rugidos periódicos de los mejores devoradores.

12) Privacidad y cumplimiento

PII/finanzas: enmascaramiento, tokenización, minimización de datos en telemetría.
Geolocalización: almacenamiento y procesamiento por jurisdicción; exportación de registros: sólo a través de flujos de trabajo aprobados con cifrado y TTL.
Auditoría de acceso a telemetría: RBAC/ABAC, SoD para descargas, registro de consultas.

13) Integración con gestión de incidentes y lanzamientos

Status Page: un feed automático de los apdates de la tarjeta de incidente.
Puerta de lanzamiento: análisis canario por SLI, auto-parada de lanzamiento en burn-rate> umbral.
Post-mortem: línea de tiempo de rutas/registros, SLI reales y ventanas de infracción.

14) Práctica de aplicación (8-12 semanas)

Ned. 1-2: inventario de rutas críticas y SLI; selección de pilas (OTel, TSDB, registros, pistas); Mapa de dependencias.
Ned. 3-4: implementación de OTel en 3-5 servicios clave (inicio de sesión/depósito/apuesta), RED/USO básico, contexto trace en los registros.
Ned. 5-6: SLO y burn-rate-alertas; sintético por PSP/KYC; los primeros runbooks; RUM en web/mobile.
Ned. 7-8: sampling dinámico, exemplars, servicio-map; dashboards Exec/SRE/Payments.
Ned. 9-10: eBPF/perfilando cuellos de botella calientes; filtros de privacidad; cuotas/retenciones.
Ned. 11-12: gateway de lanzamiento y auto-rollback por SLI; integración con la página de estado; enseñanzas de tabletop.

15) Patrones de artefactos

Tarjeta de servicio SLO: SLI, objetivos, ventanas, presupuesto de errores, alertas, propietarios.
Alert Spec: métrica/condición, umbrales, dedup/silens, destinatarios, runbook.
Dashboard Spec: audiencia, preguntas, 6-8 widgets, fuente de datos, frecuencia de actualización.
Política de telemetría: qué campos son válidos/prohibidos, retoque, enmascaramiento, exportación.
Paquete de revisión de costo: top series/logs, oferta de sampling/TTL, ahorros esperados.

16) Función de observación KPI

MTTA/MTTR (mejora después de la introducción de alertas SLO).
% de los incidentes detectados por sintética/SLI antes de las quejas de los usuarios.
Porcentaje de lanzamientos que han pasado la puerta por SLI sin intervención manual.
Reducción de $/RPS por telemetría mientras se mantiene la diagnóstica.
Cobertura de trazado de vías críticas (> 90%).
Exactitud de la correlación «apdate status ↔ SLI reales».

17) Antipatternas

«Todo es lógico» → explosión de valor y ruido.
Alertas por métricas «crudas» en lugar de SLO/burn-rate → pager-fatigue.
Métricas de alta cardinalidad (userId) → tormentas TSDB.
Los tracks sin contexto de negocio (PSP/banco/GEO) → no hay información privilegiada.
No hay relación de observación con lanzamientos/incidentes → la telemetría vive por separado.

La observabilidad y el control de estado no son un conjunto de herramientas, sino un sistema administrado: SLI/SLO correctos → telemetría estandarizada y correlación → alerting y runbooks de SLO → integración con lanzamientos y comunicación de status → explotación y privacidad de costa-aware. Este circuito da señales tempranas, RCA rápido y sostenibilidad empresarial incluso en picos de tráfico extremos.