Un caso de descarte metodológico · Observed State Index
Resumen
Este no es un estudio sobre un evento del mundo. Es un estudio sobre cómo se descubrió que una fuente de datos, con el mejor código del sistema, medía algo que no servía para su propósito — y cómo se llegó a esa conclusión comparándola contra otra fuente en un evento real.
La lección no es técnica en el sentido de sintaxis. Es metodológica: una API bien documentada, con datos bien formados y un pipeline robusto, puede seguir siendo la fuente equivocada. Y esto solo se descubre cuando hay algo contra qué contrastarla.
El contexto
El sistema mide dos dominios como efectos directos: tráfico aéreo (ADS-B) y alcanzabilidad de red (IODA). Una tercera fuente, Cloudflare Radar, se integró para cubrir demanda de tráfico de internet — una señal distinta a la infraestructura que mide IODA.
De las tres, el pipeline de Cloudflare era el mejor construido. Tenía reintentos con backoff exponencial y jitter, clasificación de errores por código HTTP, un mecanismo de pausa adaptativa que se ajustaba solo según la respuesta de la API, métricas enviadas a CloudWatch, y un guardián que evitaba disparar el procesamiento si menos del 10% de los países respondía. Ninguno de los otros dos pipelines tenía nada de eso en ese momento.
Por diseño, capturaba series horarias normalizadas de tráfico HTTP por país, con un cálculo de "porcentaje de degradación" hecho dentro del propio proceso de ingesta, usando un umbral de 20% fijado en el código.
La prueba que lo delató
El 28 de febrero de 2026, un evento real —el cierre coordinado de espacio aéreo del Golfo y el apagón de conectividad en Irán— ya estaba documentado de forma independiente por dos fuentes: ADS-B mostraba el colapso de tráfico aéreo, e IODA mostraba la caída sostenida de ping-slash24 en Irán, con −96.7% de cambio y una duración de al menos cinco días.
Eso dio algo poco común: un caso con verdad de campo conocida. Si Cloudflare medía lo mismo que IODA, debía mostrar a Irán colapsado y sostenido durante los mismos días.
Se corrió el mismo periodo sobre los datos de Cloudflare, franja por franja:
| Corrida | Cloudflare (índice normalizado) | IODA (ping-slash24) |
|---|---|---|
| 28-feb, 01 | 0.627 | normal |
| 28-feb, 03 | 0.373 | −96.7% |
| 28-feb, 04 | 0.225 | −96.6% |
| 01-mar, 01 | 0.105 | −96.6% |
| 01-mar, 03 | 0.644 | −96.6% |
| 02-mar, 04 | 0.698 | −96.8% |
Cloudflare marcó la caída, y luego reportó una recuperación casi total en 24 horas. IODA, con datos independientes, decía que Irán seguía apagado cinco días después. Las dos fuentes no podían tener razón a la vez.
Por qué pasó
Se revisó cómo se construye el índice de Cloudflare, y apareció el mecanismo exacto del error.
El endpoint entrega una serie de 24 horas normalizada a su propio máximo dentro de esa ventana, no un volumen absoluto. El valor no dice cuánto tráfico hubo: dice qué proporción del pico de esas 24 horas representa cada punto.
Mientras la ventana de 24 horas mezclaba horas normales con horas de apagón, el contraste entre ambas exageraba la caída aparente — de ahí el 0.105 del 1 de marzo. Pero en cuanto la ventana completa de 24 horas quedó enteramente dentro del periodo de apagón, el sistema recalculó su propio máximo sobre valores ya deprimidos, y el índice volvió a acercarse a 1.0 — no porque el tráfico se hubiera recuperado, sino porque el punto de referencia había cambiado con él.
Un indicador construido así es estructuralmente incapaz de medir nivel sostenido. Solo puede detectar transiciones bruscas, y únicamente mientras la ventana de comparación las contenga.
Se encontró además que la URL usada incluía un filtro de tráfico (botClass=LIKELY_AUTOMATED) que restringía la medición a tráfico automatizado — bots, rastreadores, escáneres — en lugar de tráfico humano. La fuente no solo tenía un problema estructural de normalización: estaba midiendo la variable equivocada desde el origen de la consulta.
Por qué esto no se detecta revisando el código
El pipeline de Cloudflare no tenía errores de programación. Los reintentos funcionaban, el manejo de errores era correcto, los datos llegaban bien formados y se guardaban sin pérdida. Cualquier revisión de código lo habría aprobado.
El defecto era conceptual, no sintáctico, y solo se hizo visible al pedirle al sistema una afirmación verificable contra una fuente distinta que midiera lo mismo por otro camino. Sin ese cruce, el índice de Cloudflare habría seguido publicando un "Irán recuperado" incorrecto de forma indefinida, con un pipeline que en todo momento habría parecido estar funcionando.
La decisión tomada
Cloudflare Radar se retiró del índice principal. El pipeline de captura se mantiene activo, pero fuera de la fase de cálculo: sirve como registro histórico y como origen del código de referencia para futuros pipelines, no como fuente de medición.
Se identificó un endpoint distinto de la misma API —anotaciones de incidentes verificados manualmente por Cloudflare, con causa y alcance declarados— que sí aporta valor como capa de contexto: no como señal del índice, sino como confirmación de si un evento detectado ya está reportado por un tercero independiente.
Lo que este caso demuestra
Que la calidad de la ingeniería y la validez de la medición son evaluaciones distintas. Un pipeline puede tener el mejor manejo de errores del sistema y seguir capturando la métrica equivocada.
Que un evento real con verdad de campo conocida es la herramienta de validación más fuerte disponible. No fue una auditoría de código lo que encontró el defecto. Fue confrontar dos fuentes contra el mismo hecho verificable y notar que una contradecía a la otra.
Que descartar una fuente con evidencia es tan valioso como confirmar una que funciona. El sistema hoy mide dos dominios en lugar de tres, y esa reducción no es una limitación: es el resultado de aplicar el mismo estándar de verificación a las herramientas del propio sistema que a los fenómenos que el sistema busca medir.
Nota metodológica
Este documento no invalida el hallazgo del cierre de espacio aéreo del Golfo, publicado por separado. Los resultados de ADS-B e IODA para el 28 de febrero de 2026 no dependen de Cloudflare Radar en ningún punto de su cálculo; de hecho, fue precisamente ese hallazgo, ya validado por otras dos fuentes, el que sirvió de referencia para exponer el error en la tercera.
← Volver al índice