Metodología de telemetría y detección de caídas
En CaídoEstá combinamos dos fuentes complementarias e independientes de información: verificaciones sintéticas continuas ejecutadas desde una malla distribuida de servidores y reportes ciudadanos en tiempo real procesados mediante algoritmos estadísticos de detección de anomalías.
1. Red de sondas sintéticas regionales distribuidas
A diferencia de las plataformas tradicionales de monitorización que ejecutan pruebas únicamente desde centros de datos en Norteamérica o Europa occidental, CaídoEstá opera una red propia de nodos de sondeo estratégicamente desplegados dentro de los principales puntos de intercambio de tráfico de Iberoamérica:
2. Ciclo de vida y métricas de una sonda sintética
Cada 60 a 180 segundos, un microservicio de sondeo concurrente despacha solicitudes optimizadas hacia los puntos de acceso públicos y endpoints de salud de cada servicio monitorizado. El ciclo de vida de cada prueba desglosa:
- Resolución DNS (DNS Lookup): Medición del tiempo que tarda el resolvedor recursivo local en obtener el registro A o AAAA mediante protocolos UDP estándar o DoH (DNS sobre HTTPS).
- Establecimiento de Conexión TCP (TCP Handshake): Tiempo requerido para completar el saludo de 3 vías (SYN, SYN-ACK, ACK) con el balanceador de carga perimetral.
- Negociación TLS 1.3 (TLS Handshake): Validación del intercambio criptográfico de claves, vigencia del certificado SSL/TLS y negociación de protocolo ALPN (Application-Layer Protocol Negotiation para HTTP/2).
- Tiempo al Primer Byte (TTFB - Time to First Byte): Intervalo transcurrido entre el envío del encabezado HTTP GET/HEAD y la recepción del primer byte de datos del servidor de origen.
- Validación del Código de Estado HTTP: Verificación de respuestas 2xx (Éxito), 3xx (Redirección válida), y detección inmediata de anomalías 4xx (bloqueos perimetrales) o 5xx (500 Internal Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout).
3. Algoritmo estadístico Z-Score con ajuste diurno
El volumen de quejas ciudadanas experimenta una fuerte variación estacional y diurna: el tráfico en plataformas bancarias es naturalmente mucho más alto un viernes a las 14:00 horas que un domingo a las 04:00 de la madrugada. Un umbral estático fijo generaría cientos de falsas alarmas durante el día y pasaría por alto caídas críticas durante la noche.
Para resolver este problema, CaídoEstá divide cada día de la semana en 96 intervalos móviles de 15 minutos. El motor estadístico mantiene una ventana deslizante de 28 días (4 semanas) para calcular la media histórica ($\mu$) y la desviación estándar ($\sigma$) específica para cada intervalo y día de la semana:
Fórmula de anomalía estadística normalizada:
Z = (Reportes_Actuales_15m - Media_Historica_Intervalo) / Desviacion_Estandar_Intervalo
Los estados del semáforo se asignan según la severidad de la desviación combinada con los resultados de las sondas:
- 🟢 OPERATIVO: Puntuación $Z < 2.0$ y sondas respondiendo con HTTP 200 y latencia normal.
- 🟡 PROBLEMAS LEVES: Puntuación $2.0 \le Z < 3.5$ o incremento en latencia TTFB mayor al 150% del promedio de la sonda.
- 🔴 CAÍDA CONFIRMADA: Puntuación $Z \ge 3.5$ acompañada de fallas en sondas o $Z \ge 4.5$ con volumen masivo de reportes comunitarios concurrentes.
4. Desambiguación de enrutamiento por Sistema Autónomo (ASN / ISP)
Uno de los problemas más frecuentes en Iberoamérica ocurre cuando un servicio bancario o plataforma web está 100% operativo en sus servidores centrales, pero un operador de telecomunicaciones específico (por ejemplo, Telmex AS8151 en México, Claro AS10620 en Colombia, o Personal AS7303 en Argentina) sufre una rotura de fibra, saturación de peering o fallo en sus servidores DNS.
Cuando nuestro motor analiza los reportes comunitarios entrantes y detecta que el 70% o más de los reportes provienen de usuarios con direcciones IP pertenecientes a un mismo Sistema Autónomo (ASN) mientras nuestras sondas desde otros operadores devuelven respuestas HTTP normales, el sistema activa de manera autónoma el estado:
5. Privacidad y sanitización criptográfica de reportes
Para garantizar la inviolabilidad de la privacidad ciudadana y prevenir ataques de manipulación maliciosa de reputación (granjas de bots enviando reportes falsos), CaídoEstá implementa una rigurosa arquitectura de sanitización:
- Hashing con sal rotativa diaria (SHA-256): La dirección IP del usuario nunca se escribe en texto claro en la base de datos. Se procesa al vuelo mediante una función hash unidireccional combinada con una sal criptográfica que se destruye automáticamente a las 00:00 UTC de cada día.
- Limitación estricta de frecuencia (Rate Limiting): Un mismo hash anonimizado solo puede computar 1 reporte cada 30 minutos para un mismo servicio, neutralizando ataques de denegación de servicio (DoS) contra las métricas.
- Cero recopilación de PII: No solicitamos nombres, correos electrónicos, números de teléfono ni identificadores de hardware.
6. Neutralidad técnica y transparencia
CaídoEstá opera bajo los principios de neutralidad de red, independencia editorial y máxima transparencia técnica. Todos los datos de telemetría de red se generan a partir de protocolos estandarizados internacionalmente (RFC 7230, RFC 8446) sin discriminación ni manipulación comercial.