Mecanismos de control de salud

1) Por qué

Los cheques de salud son la primera barrera contra fallas en cascada: sacan correctamente los nodos de la rotación, previenen la tormenta de retraídas, simplifican la degradación y aceleran la recuperación, manteniendo el SLO y reduciendo el MTTR.

2) Tipos básicos de inspecciones

Liveness es un proceso «vivo» (sin deadlock/fugas/pánico). Error → restaurar la instancia.
Readiness: el servicio es capaz de servir tráfico a los SLO de destino (grupos elevados, caché calentado, recursos dependientes normalmente). El error → ser excluido del equilibrio, pero no reestablecido.
Startup - el servicio está listo para ir a liveness/readiness (bootstrap largo, migración, warmup). Protege contra los restarts prematuros.
Deep-health (específico para dominios): invariantes de negocios (la tasa pasa end-to-end, el depósito está autorizado con el PSP activo). Se utilizan para señales de degradación, pero no para el restablecimiento inmediato.
External/Synthetic: pings activos en el exterior (ruta de acceso API, script frontal, endpoint PSP/KYC): miden la disponibilidad del usuario.

3) Diseño de muestras: reglas generales

1. Liveness barato: no vamos a las dependencias externas; verificamos el bucle de eventos, heap/FD, watchdog.
2. Lectura por SLO: comprueba los recursos locales necesarios para el mantenimiento (grupos de DB, caché cálido, límites). Dependencias externas: a través de «can-serve» sin bloquear? señales.
3. Latency-budget: cada muestra tiene su SLA (por ejemplo, ≤100 -200 ms); cuando se excede es «degraded», pero no 5xx por liveness.
4. Backoff & Jitter: intervalos de muestreo de 5-15 segundos, tiempo de espera de 1-2 segundos, con un retraso exponencial en los errores para evitar tormentas sincrónicas.
5. Histéresis: N respuestas acertadas/erróneas para cambiar el estado (por ejemplo, 'successThreshold = 2', 'failureThreshold = 3').
6. Versioning: los endpoints '/healthz ', '/readyz', '/startupz 'son estables; deep-checks bajo '/health/... 'con cheques con nombre.
7. Sin secreto y PII: las respuestas son sólo estados y códigos cortos.
8. Explainability: JSON con una lista de sub-comprobaciones: '{«status»: «degraded» «, checks»: [{«name»: «db» «, ok»: true «, latencyMs': 18}, {» name «:» psp. eu","ok":false,"reason":"timeout"}]}`.

4) Ejemplos deep-checks por capas

4. 1 DB/caché/almacenamiento

DB: transacción corta 'SELECT 1' en una réplica de lectura y verificación de grupos; latency/replication-lag umbrales.
Caché: 'GET '/' SET' de la clave de prueba + hit-ratio guard (bajo hit → warning).
Almacenamiento de objetos: HEAD de un objeto existente (sin descarga).

4. 2 colas/streaming

Broker: ping-topic publish + consume dentro de la partition local; los umbrales consumer-lag.
DLQ: no hay una oleada de mensajes en dead-letter más allá de la ventana.

4. 3 Proveedores externos (PSP/KYC/AML)

PSP: lightweight auth-probe (no monetario), verificación de contrato/certificado/cuotas; si no hay muestras seguras - utilice métricas proxy (éxito de las autorizaciones de 5 a 10 minutos por banco/GEO).
KYC/AML: health-API y cola SLA; cuando se degradan, cambian a un flujo/proveedor alternativo.

4. 4 API/frente

Sintética: ruta transaccional (inicio de sesión → depósito-iniciación → apuesta «en la arena») en EU/LATAM/APAC.
Señal RUM: proporción de errores JS/HTTP y LCP/TTFB - desencadenantes «fuera».

5) Integración con la plataforma

5. 1 Kubernetes / Cloud

'startupProbe' protege bootstrap (migraciones/cache-warmup).
'livenessProbe' es minimalista; 'readinessProbe' tiene en cuenta grupos/caché/colas locales.
Параметры: `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `failureThreshold`, `successThreshold`.
PodDisruptionBudget y maxUnavailable con readiness en mente.
HPA/KEDA: escalar por cola/SLI; readiness afecta a la ruta.

5. 2 Balanceadores/gateways/mesh

Health-routing en nivel L7 (HTTP 200/429/503 semánticos).
Detección de salida (envoy/mesh): salida de la agrupación a través de percentiles de error-rate/latency.
Circuit-breaker: límites de solicitudes/conexiones de dependencia simultáneas, integración con señales de salud.

5. 3 Auto Skaling y Degradación

Readiness = FALSE → el tráfico se dispara, pero el pod está vivo (puede calentarse).
Deep-degrade (PSP down) → flags de función para el modo graceful (por ejemplo, ocultar temporalmente los métodos de pago, habilitar waiting-room).

6) Políticas de tiempo de espera y retiro

Tiempo de espera <presupuesto SLO: 'timeout = min (⅓ p99, 1-2s)' para dependencias sincrónicas.
Idempotencia: obligatoria para los retraídos; usamos idempotency-keys.
Backoff + jitter exponencial: previene los efectos de eje síncrono.
Presupuestos de retiro: caps per-request/tenant, protección contra "retry-storms'.

7) Señales de estado y alerting

Verde/Amarillo/Rojo: estados resumidos en el dashboard de servicio.
Burn-rate-alert por SLO: rápido (1 h) y lento (6-24 h).
Correlation-hints: notas sobre lanzamientos/banderas de seguridad/trabajos programados.
Auto-acciones: con el «rojo» deep-check - habilitar el fallback del proveedor, aumentar el sampling de las pistas.

8) Estrategias inteligentes para iGaming

Payment-aware readiness: la disponibilidad del servicio de apuestas tiene en cuenta el estado del router PSP y los límites bancarios/GEO.
Odds/Lines publishing: readiness in pablisher depende de los registros de resumen por origen de línea y el tiempo de distribución en caché/edge.
Tournament spikes: una política temporal de outlier-detection y waiting-room más agresiva.

9) Antipatternas

Liveness, que va a la DB/PSP → restarts masivos en un problema externo.
Un endpoint de salud «universal» sin separación startup/readiness/liveness.
Tiempos de espera duros sin backoff/jitter → retrocesos de tormenta.
No hay histéresis → flapping de enrutamiento.
Un cheque profundo que desencadena restarts (su objetivo es diagnosticar y enrutar, no reiniciar).
5xx oculto en endpoints de salud (estado real enmascarado).

10) Plantillas de interfaz

/startupz → `200 OK {"uptimeSec": ..., "version":"..."}`

Validaciones: scripts init, migraciones completadas, claves y confecciones cargadas.

/healthz (liveness) → `200 OK {"heapOk": true,"fdOk":true,"eventLoop":"ok"}`

Verificaciones: ciclo de eventos, recursos del proceso, sin pánico/banderas oom.

/readyz (readiness) →

`200 OK/503 {"canServe": true,"db":{"ok":true,"latencyMs":12},"cache":{"ok":true},"queue":{"ok":true,"lag":0},"localQuota":{"ok":true}}`

/health/payments (deep) →

`200/206/503 {"psp. eu": {"ok":false,"reason":"timeout"}, "psp. alt":{"ok":true}, "routerMode":"failover"}`

11) Métricas de calidad del circuito de salud (KPI/KRI)

Tiempo de salida del pod de 'NotReady' en 'Ready' (warmup-SLO).
Frecuencia de «flapping» readiness per servicio.
% de pod restaurado erróneamente (root-cause es una dependencia externa).
MTTR de incidentes donde los mecanismos de salud han jugado un papel (antes/después).
Proporción de failover/feature-degrade automáticos sin participación on-call.
Precisión sintética vs RUM (falsos positivos/pases).

12) Hoja de ruta para la implementación (4-8 semanas)

Ned. 1-2: inventario de rutas críticas; separar startup/liveness/readiness; introduzca las respuestas JSON con las comprobaciones y la histéresis.
Ned. 3-4: añadir deep-checks: DB/caché/broker; sintético para inicio de sesión/depósito/apuesta en 2-3 GEO; habilitar outlier-detection en la puerta de enlace/mesh.
Ned. 5–6: payment-aware readiness и PSP-fallback; waiting-room para el frente; Auto-Scaling por lag/colas; alertas por burn-rate.
Ned. 7-8: días chaos (desactivación de PSP/réplicas de BD), verificación de backoff/jitter; fintuning time-out, PDB; informe de KPI y ajuste.

13) Artefactos

Health Spec (por servicio): lista de comprobaciones, presupuestos de tiempo, histéresis, acciones en estado rojo.
Runbooks: "Readiness = FALSE: ¿qué hacemos? ", "PSP-fallback: pasos y criterios de retorno".
Política de enrutamiento: reglas de detección de outlier, circuit-breakers, umbrales percentiles.
Synthetic Playbook: guiones y geografías, sintéticos SLO, horarios.
Release Gate: Bloques de liberación con el control profundo rojo de las dependencias clave.

Resultado

Un circuito de cheques de salud bien diseñado es un sistema de señales en capas: liveness liveness para la viabilidad del proceso, readiness para la capacidad de servir tráfico, startup para inicio seguro y deep-checks específicos de dominio para degradación y enrutamiento administrados. En combinación con autoscaling, outlier-routing, sintética y alerting SLO, reduce el riesgo de fallas en cascada, reduce el MTTR y estabiliza las rutas críticas de negocio de la plataforma iGaming.