Seguimiento de aptime

1) Por qué monitorear el aptime

Aptime es una fracción del tiempo que el servicio está disponible para el usuario. Esta es la «primera línea» de la observabilidad: notar instantáneamente inaccesibilidad, degradación a través de la red, fallo DNS/TLS, problemas de enrutamiento o CDN. Para sistemas altamente cargados y regulados (fintech, iGaming), el aptime afecta directamente a los ingresos, la ejecución de SLA y los riesgos penalizados.

2) Términos y fórmulas

SLI de disponibilidad: 'SLI = (validaciones exitosas/todas las validaciones) × 100%'.
SLO: disponibilidad objetivo por ventana (generalmente 28-30 días), por ejemplo 99. 9%.
SLA: obligación externa; siempre ≤ SLO interno.
MTBF/MTTR: tiempo medio entre fallos/tiempo medio de recuperación.

99. 0% → ~ 432 minutos de inaccesibilidad

99. 9% → ~ 43 minas

99. 99% → ~4. 3 minas

99. 999% → ~ 26 segundos

3) ¿Qué controles se necesitan (caja negra)

Se ejecutan desde puntos externos (diferentes regiones/proveedores) para ver el servicio «a través de los ojos del cliente».

1. ICMP (ping): red básica/disponibilidad del nodo. Rápido, pero no refleja el éxito empresarial.
2. TCP connect - ¿Escucha el puerto? Útil para corredores/DAB/SMTP.
3. HTTP/HTTPS: código de estado, encabezados, tamaño, redirecciones, tiempo hasta el primer byte.
4. TLS/certificados - caducidad, cadena, algoritmos, SNI, protocolos.
5. DNS - A/AAAA/CNAME, NS-salud, distribución, DNSSEC.
6. gRPC - estado de llamada, deadline, metadatos.
7. WebSocket/SSE - apretar la mano, mantener la conexión, mensaje-eco.
8. Proxy/enrutamiento/CDN - diferentes PoP, caché de muestra hash, geo-variantes.
9. Scripts sintéticos transaccionales (clics/formularios): «inicio de sesión → búsqueda → depósito (sandbox)».
10. Heartbeat/cron-monitoring - el servicio está obligado a «pulsar» (hook una vez cada N minutos); No hay alarma.

• Coloque los temporizadores más cerca del UX real (por ejemplo, TTFB ≤ 300 ms, total ≤ 2 s).
• Compruebe el assert de contenido (palabra clave/campo JSON) para que «200 OK» no se considere un éxito con el error.
• Duplique las comprobaciones a través de proveedores y redes independientes (multi-hop, diferentes ASN).

4) Caja blanca y servicio de salud

Muestras Liveness/Readiness para orquestador (¿procesos en vivo? ¿están listos para recibir tráfico?).
Salud de las dependencias: DB, caché, corredor de eventos, APIs externas (pagos/KYC/AML).
Banderas de fichas/degradación: cuando hay problemas, desactivamos suavemente los caminos no críticos.

Las muestras blancas no reemplazan las comprobaciones externas: el servicio puede ser «saludable en el interior», pero no está disponible para el usuario debido al DNS/TLS/route.

5) Geografía y multirregionales

Ejecute la sintética desde las regiones clave del tráfico y cerca de los proveedores de dependencias críticas.
Quórum: registramos un incidente si hay un fallo en ≥ N regiones (por ejemplo, 2 de 3) para cortar anomalías locales.
Umbral por cohorte: SLI/SLO separados para segmentos importantes (países, VIP, operadores de telecomunicaciones).

6) Política de alertas (mínimo ruido)

Multi-región + multi-prueba: el buscapersonas sólo cuando falla de forma consistente (por ejemplo, HTTP y TLS al mismo tiempo, ≥ 2 regiones).
Debauns: N fallas consecutivas o una ventana de 2-3 minutos antes de la pagina.

• L1: on-call (servicios de producción).
• L2: red/plataforma/seguridad dependiendo de la firma del fallo.
• Auto-cierre: después de las verificaciones de éxito M estables.
• Horas/concesiones silenciosas: para servicios internos no críticos, sólo tickets, sin buscapersonas.

7) Status-page y comunicación

Páginas de estado público (cliente) y privado (interno).
Incidentes automáticos de sintéticos + anotaciones manuales.
Plantillas de mensajes: descubierto - identificado - impacto - solución - ETA - decidido - post-mordem.
Ventanas programadas: anunciar con antelación, excepciones a tener en cuenta por separado de SLO.

8) Contabilidad de dependencias externas

Para cada proveedor (pagos, KYC, boletines, CDN, nubes), sus comprobaciones son de varias regiones.
Rutas Falleras: cambio automático a un proveedor alternativo a través de una señal sintética.
SLO individuales a nivel de proveedor y e2e-SLO integral.
Negociar un SLA con los proveedores (status-webhooks, prioridad de soporte).

9) Dashboards y widgets clave

Mapa del mundo con estado de comprobación (por tipo: HTTP, DNS, TLS).
Timeline de incidentes con anotaciones de lanzamientos/banderas.
P50/P95/P99 TTFB/TTL/latencia por región.
Disponibilidad por cohorte (país/proveedor/dispositivo).
MTTR/MTBF, tendencias de «minutos de inactividad» y «burn-down» del presupuesto de disponibilidad para el mes.
Las principales causas de fallas (TLS-expiry, DNS-solving, 5xx, timeouts).

10) Proceso de incidente (escenario fugaz)

1. Activa multi-región/multi-tipo alert.
2. El encargado de guardia confirma, incluye la congelación de lanzamientos, alerta a los propietarios.
3. Diagnóstico rápido: estado DNS/TLS/CDN, versiones recientes, gráfico de errores.
4. Bypass: cambio de ruta, contenido folback/proveedor, activar el modo de degradación.
5. Recuperación: comprobar que el tráfico sintético/real es verde.
6. Comunicación en la página de estado; cierre del incidente.
7. RCA y acciones items: correcciones, pruebas, alertas, playbucks.

11) Informes sobre SLA/SLO

Informes mensuales: aptime por servicio/región, minutos de inactividad, MTTR, razones.
Comparación con SLA: préstamos/compensaciones, si corresponde.
Rugidos trimestrales: actualización de umbrales, distribución de sintéticos, lista de dependencias.

12) Plantillas de comprobación (ejemplo)

• Método: 'GET/healthz/public' (sin secretos).
• Tiempo de espera: 2 s, retry: 1.
• Éxito: '2xx', cabecera 'X-App-Version' presente, campo JSON '' status ':' ok '.

• Plazo> 14 días, cadena válida, protocolos 'TLS 1. 2 + ', SNI correcto.

• Tiempo de respuesta ≤ 100 ms, registros A/AAAA corresponden al plan, sin SERVFAIL/REFUSED.

• Webhook '/beat/{ service} 'una vez cada 5 minutos; ausencia de 2 señales consecutivas - alerta L2 (tareas de fondo/ETL).

13) Lista de verificación de implementación

• Auditorías externas multi-regionales (HTTP/TCP/DNS/TLS/escenarios profundos).
• Muestras blancas readiness/liveness para el orquestador.
• Separación de caminos críticos/no críticos, banderas de la degradación.
• Quórum y desbauns en alertas, escalada y cierre automático.
• Páginas de estado públicas e internas, plantillas de mensajes.
• Verificaciones individuales y SLO para proveedores externos + failover automático.
• Dashboards: mapa, línea de tiempo, percentili, minutos de inactividad, MTTR/MTBF.
• Informes periódicos sobre SLA/SLO y RCA post-incidente.

14) Errores frecuentes

Sólo ping/puerto sin NTTR/contenido - «verde» en la inaccesibilidad real.
Un punto de monitoreo es falsamente positivo/negativo.
Falta de control TLS/DNS: tiempo de inactividad repentino debido a la demora/misconfig.
Ruido superfluo: alertas por fallos individuales de una región/tipo de inspección.
No hay relación con los cambios: no hay anotaciones de lanzamientos y banderas en los dashboards.
Dependencias no contabilizadas - el proveedor de pago ha caído, y el estado general es «verde».

15) Resultado

El seguimiento del aptime no es solo «picar la URL». Se trata de un sistema de inspecciones sintéticas de regiones reales, alertas razonables sin ruido, comunicación transparente a través de páginas de status, contabilidad de dependencias externas e informes rigurosos. El monitoreo de aptime correctamente construido reduce el MTTR, protege el SLA y mantiene la previsibilidad de la experiencia del usuario.