"Tu vuelo ha sido cancelado por motivos operativos": ¿¡Cómo!?

11 de enero de 2024

Tres días sumidos en el caos, pérdidas económicas millonarias y miles de pasajeros afectados por “motivos operativos”. Dicho de otra forma, por un bug en el software de los controladores aéreos de Reino Unido.

¿Cuál fue el fallo?

El fallo se produjo en el software FPRSA-R que se utiliza para gestionar los vuelos que entran y salen del espacio aéreo de Reino Unido. Esto provocó que NATS (National Air Traffic Services), la organización que se encarga de gestionar y controlar el tráfico aéreo en el espacio aéreo del Reino Unido, tuviera que reducir la capacidad del sistema de control de tráfico aéreo.

En consecuencia, provocó la cancelación de cientos de vuelos y retrasos de miles de otros.

¿Se podría haber evitado?

El informe preliminar del incidente dice claramente que el fallo pudo haberse evitado si NATS hubiera implementado un proceso de pruebas más riguroso.

El proceso de pruebas de NATS no detectó el fallo antes de su puesta en producción y había estado operando con el subsistema FPRSA-R de forma continua desde octubre de 2018 procesando más de 15 millones de planes de vuelo sin incidencias y no se había realizado ninguna actualización reciente que hubiera podido introducir el error.

¿Cuál fue el origen del error?

Para entender si el plan de pruebas de NATS era lo suficientemente riguroso o no, habría que analizarlo y ver si en las especificaciones se definía el proceso que generó el fallo y si ese caso estaba cubierto o no por las pruebas.

Pero hay que entender el origen del error para saber cómo podría haberse evitado:

El software de gestión de planificación de vuelos de NATS (FPRSA-R) es el encargado de registrar y autorizar todo vuelo que entra y sale del espacio aéreo de Reino Unido.
En un primer momento la prensa comunicó que el error se desencadenó a causa del vuelo BAW231, un vuelo de British Airways que cubría la ruta Londres-Nueva York. El vuelo despegó del aeropuerto de Heathrow a las 10:00 hora local del 29 de mayo de 2023 y pudo aterrizar en el aeropuerto de Nueva York sin incidentes. El plan de vuelo enviado al sistema de NATS contenía una línea vacía en el campo "hora de llegada".
Pero según indican los foros de aficionados y profesionales aeronáuticos en Reddit, el origen del error fue el vuelo FBU731 de French Bee desde Los Angeles USA a Orly en Francia. Su plan de vuelo enviado al sistema de NATS contenía un punto de la ruta (waypoint) duplicado.

⚠️ En cualquiera de los posibles casos mencionados, ya sea porque el origen de una línea vacía o de un punto de la ruta duplicado, ambos escenarios deberían haber sido probados entre otros muchos para comprobar la robustez y la respuesta del sistema en caso de no recibir la entrada esperada y evitar que el sistema FPRSA-R de NATS se bloqueara.

¿Qué pasa si hay un error en un sistema crítico?

Un sistema crítico ha de tener una o varias réplicas, que aseguren que, si una máquina/sistema deja de estar operativo, siempre haya otra/s de respaldo, con los mismos datos disponibles para seguir procesando la información pendiente. Las posibles redundancias y distribuciones de sistemas y datos pueden dar para otro post completo, pero lo importante en estos sistemas es que siempre exista un plan alternativo por si se produce un fallo en el sistema.

Hay contingencias a muchos niveles, pero las que podrían afectar a un sistema como el de NATS podrían ser por software, hardware, instalaciones (cortes de suministros, sabotajes o inclemencias meteorológicas) o incluso a nivel continental (guerras o bloqueos). El objetivo es que puedan seguir funcionando antes las adversidades o al menos minimizar la posible pérdida de información o seguir con la función que realiza.

El sistema encargado de procesar la lista de planes de vuelo pendientes para autorizar se encontró con este plan erróneo o mal formado, no pudo procesarlo y el sistema se bloqueó, levantando una excepción crítica y entrando en modo mantenimiento. Esto hacía que el sistema dejara de estar operativo y el plan de vuelo pendiente de autorizar.
El sistema de respaldo asume el rol de procesar el siguiente plan de vuelo pendiente (el que no había podido ser procesado) y hacía el mismo intento y también se bloqueaba hasta que todos los posibles ejecutores de la tarea se bloquearon por el mismo motivo.
Los técnicos en un primer momento intentaron reiniciar el sistema, pero no se podía volver a la normalidad. El tiempo corría y el plazo de cuatro horas para iniciar la introducción manual (y lenta) de planes de vuelo había empezado.

¿Posibles soluciones?

Los ingenieros de soporte, al no poder restaurar el servicio, solicitaron ayuda al fabricante del sistema. Con el conocimiento del sistema descubrieron el origen del error y las posibles soluciones:

Extraer ese plan de vuelo de la lista.
Desarrollar una actualización que corrigiera el error en el sistema.

La solución sería sacar ese plan y avisar al operador para autorizarlo (o no) de manera manual, mientras el resto de las autorizaciones continuaba.

¿Qué lecciones se pueden aprender?

El fallo del control del tráfico aéreo de NATS es un recordatorio de la importancia de la calidad del software.

Las empresas que utilizan software crítico deben asegurar que el software desarrollado se prueba de manera exhaustiva contemplando tanto casos de entrada de datos válidos para funcionar, pero también es importante probar como va a responder ante casos inválidos o inesperados.

Sería costoso en tiempo y en esfuerzo validar los posibles escenarios de un sistema que se validará. Pero existen muchas aproximaciones para hacerlo. Una de las pruebas de cálculo matemáticos es agrupar escenarios similares, así se probar con muestras de valores que representan a todo su grupo casuístico.

Un ejemplo para entenderlo fácilmente sería probar una funcionalidad que recibe como entrada un parámetro, un número que debe estar entre 0 y 100 para realizar ciertos cálculos matemáticos.

Una primera aproximación en este escenario sería agrupar los escenarios en distintos grupos como, por ejemplo:

Los valores positivos válidos (0≥x≥100) y seleccionar algunas muestras [3, 17, 80]
Los valores positivos inválidos (100<x) y probar con algunas muestras [150, 500, 9999]
Los valores negativos inválidos (x<0) y sus muestras [-10, -33, -5555]
Los valores frontera, que son los escenarios que están en el límite de los válidos y los inválidos, y deberíamos dividirlos entre los que se esperan que sean válidos e inválidos:
- VF-Válidos: [0, 1, 99, 100]
- VF-Inválidos: [-1, 101]
Valores incorrectos, que serían los casos de introducción de valores de otro tipo al esperado como, por ejemplo: [a, Z, @, ™, “105 OR 1=1”, etc. ]

Así, hemos pasado de tener infinitos posibles casos a unas 20 muestras posibles para una cobertura de escenarios muy alta. Y si además se hace con pruebas automáticas que seleccionan la muestra de cada grupo de manera dinámica incluso se disparan el número de casos probados con el mínimo esfuerzo.

Otra aproximación utilizada es evaluar cuáles son los mayores riesgos del software y cuáles son los escenarios más críticos con la funcionalidad que se debe cubrir. En esos casos se identifican y priorizan para tener cubiertos los más importantes y poder probar dentro del espacio y los recursos que se hayan asignado a la fase de validación.

✅ En el mundo de las pruebas de software cuanto más tarde se encuentre el error mayor será el coste de reparación.

Por ello se invierte mucho esfuerzo que la calidad de los productos entregados tenga fases de validación en la que se asegure que la funcionalidad a entregar sea la que se ha especificado y se haya confirmado que cumple con las expectativas funcionales y no funcionales (accesibilidad, cantidad de usuarios soportada, tiempos de carga o respuesta, robustez, resiliencia, etc.).

¿Cómo lo hacemos en Telefónica Tech?

En nuestra área tenemos proyectos muy diversos con el nexo común de usar los datos que tenemos disponibles como operador. Tenemos proyectos que van desde ayudar a que nuestros clientes no sean víctimas de fraudes al pagar en comercios con SmartDigits. Hasta otros proyectos en los que ayudamos a las entidades públicas a la toma de decisiones basada en datos.

Con los datos de movilidad de SmartSteps podemos entender cómo se mueve la población para que su experiencia en movilidad sea la mejor posible ayudando a planificar o mejorar los servicios acordes a la demanda real. Siempre con la seguridad de que los datos son anonimizados y agregados para respetar la privacidad de todos los usuarios.

Para validar todos estos proyectos a nivel funcional usamos una estrategia común de trabajo y compartimos las mismas herramientas para que podamos reutilizar los conocimientos adquiridos y que la forma de trabajo sea parecida independientemente del proyecto. Esto nos permite centrar nuestro esfuerzo en conocer a fondo la funcionalidad y validarla de la mejor manera posible.

◾ Si estás interesado en saber sobre este mundo, te recomiendo que investigues sobre BDD (Behaviour Driven Development) que es una metodología de desarrollo guiado por comportamiento, para nosotros es una parte fundamental de nuestro proceso de validación funcional.

Tras leer todo esto creo que ahora podrás entender este chiste:

Un tester entra a un bar nuevo y pide una cerveza, pide ⌀ cervezas, pide 99999999 cervezas, pide una lagartija, pide -1 cerveza y pide una asgdhfk.

El primer cliente real entra al mismo bar y pregunta dónde está el baño. El bar explota.