El método Steffen lleva años apareciendo como la solución matemática al embarque de pasajeros en los aviones: menos bloqueos en el pasillo, menos interferencias entre asientos y tiempos muy inferiores a los métodos tradicionales. El algoritmo funciona y los experimentos que lo respaldan son reales. Sin embargo, su escasa adopción ofrece una lección especialmente familiar para sysadmins, desarrolladores y equipos DevOps: optimizar un sistema ideal no equivale a optimizar el sistema que finalmente llega a producción.
Las claves del método Steffen en 20 segundos
- Steffen ordena los pasajeros para reducir dos bloqueos: pasillo y acceso a los asientos.
- Un experimento de 2011 consiguió embarcar 72 personas en 3 minutos y 36 segundos.
- WilMA necesitó 4 minutos y 13 segundos y el embarque por bloques, 6 minutos y 54 segundos.
- El problema aparece al introducir usuarios que no siguen exactamente el protocolo.
- Es un buen ejemplo de la distancia entre un algoritmo optimizado y un sistema de producción.
El caso resulta interesante precisamente porque no existe un error evidente en el algoritmo. Jason Steffen aplicó técnicas de optimización al embarque y consiguió resultados experimentales que justificaban estudiar su propuesta.
La dificultad aparece en otra capa: el sistema tiene usuarios.
Familias que quieren permanecer juntas, pasajeros prioritarios, personas con movilidad reducida, equipaje que tarda más de lo previsto en colocarse, viajeros que llegan tarde y usuarios que sencillamente no entienden el grupo que les corresponde.
Cualquiera que administre sistemas reconoce el patrón. El entorno controlado funciona. Producción introduce variables que nadie había incluido en el modelo.
Un problema de concurrencia con personas en lugar de procesos
Un avión de pasillo único puede analizarse como un pequeño problema de concurrencia.
Existe un recurso compartido y limitado, el pasillo, que todos los pasajeros necesitan utilizar. Cada uno avanza hasta una posición determinada, ocupa temporalmente ese recurso mientras guarda su equipaje y finalmente lo libera al sentarse.
Si varios pasajeros consecutivos necesitan detenerse en filas próximas, aparece una cola.
Es parecido a lo que sucede cuando demasiados procesos compiten simultáneamente por un recurso limitado.
Steffen intentó reducir esas interferencias mediante un orden específico. En su versión más conocida, embarcan primero las ventanillas de filas impares, después las ventanillas pares y posteriormente se repite el proceso con asientos centrales y de pasillo.
El detalle importante está en el espaciado.
No basta con ordenar ventanilla → centro → pasillo. Los pasajeros consecutivos también deben dirigirse a filas suficientemente separadas para que varias personas puedan guardar sus maletas simultáneamente sin bloquearse.
Desde la perspectiva de sistemas podría interpretarse como una forma de distribuir las operaciones sobre un recurso compartido para evitar una concentración innecesaria de peticiones.
Además reduce otra clase de bloqueo.
Si quien ocupa la ventanilla embarca antes que el pasajero del pasillo, este último no tendrá que levantarse posteriormente para permitirle acceder a su asiento.
El algoritmo intenta eliminar ambas interferencias.
Y en condiciones controladas funciona.
En 2011 se realizó un experimento con 72 participantes en una reproducción de un Boeing 757 con 12 filas de seis asientos.
Los resultados publicados fueron:
| Método | Tiempo |
|---|---|
| Steffen | 3 min 36 s |
| WilMA | 4 min 13 s |
| Aleatorio | 4 min 44 s |
| Trasera a delantera | 6 min 11 s |
| Bloques o zonas | 6 min 54 s |
El método Steffen redujo prácticamente a la mitad el tiempo obtenido por el embarque mediante bloques.
Visto únicamente desde la métrica, parecería que el problema estaba resuelto.
Pero producción tenía otros planes.
Cuando los usuarios entran en el algoritmo
El experimento tenía una característica que cualquier desarrollador detectaría inmediatamente: los participantes conocían el procedimiento y lo cumplían.
Ese supuesto cambia completamente el problema.
Una aerolínea no controla de la misma forma a cientos de personas que esperan frente a una puerta. Hay pasajeros que llegan tarde, familias que no quieren separarse, diferentes niveles de prioridad y personas que interpretan incorrectamente las instrucciones.
Además existe un coste para hacer cumplir el algoritmo.
La aerolínea tendría que ordenar previamente a los pasajeros y conseguir que mantuvieran una secuencia relativamente precisa antes de entrar al avión.
La optimización del pasillo podría trasladar entonces parte del tiempo perdido a la puerta de embarque.
Es un problema habitual en ingeniería: optimizar una métrica local puede empeorar el rendimiento global del sistema.
Reducir el tiempo dentro del avión sirve de poco si organizar la cola añade varios minutos antes de comenzar.
El artículo de partida recoge además que United Airlines comparó en operaciones reales WilMA con Steffen y obtuvo mejores resultados con WilMA.
WilMA es considerablemente más sencillo: primero embarcan quienes tienen ventanilla, después los asientos centrales y finalmente los pasajeros de pasillo.
No alcanza el nivel de optimización teórica de Steffen, pero requiere menos coordinación.
Para un sysadmin podría resumirse con una situación conocida: una configuración algo menos eficiente puede ser preferible cuando es más sencilla de operar, observar y recuperar cuando algo falla.
Simular el embarque como un sistema distribuido
El caso se vuelve todavía más interesante cuando se traslada a código.
El artículo original propone una simulación simplificada en Python donde el pasillo funciona como un autómata celular. Cada fila representa una posición y cada pasajero puede avanzar cuando la siguiente está libre.
Cuando alcanza su asiento necesita un tiempo aleatorio para guardar el equipaje.
El modelo introduce además dos tipos de interferencia:
Pasajero
│
▼
Entrada al pasillo
│
▼
¿Siguiente posición libre?
├── No → espera
│
└── Sí
│
▼
Avanza una fila
│
▼
¿Ha llegado?
├── No → continúa
│
└── Sí
│
▼
Guarda equipaje
│
▼
¿Hay interferencia de asiento?
├── Sí → espera adicional
└── No
│
▼
SentadoNo reproduce exactamente el modelo matemático de Steffen y no pretende hacerlo. Su utilidad está en permitir modificar condiciones y observar cómo responde cada estrategia.
Con 20 filas, seis asientos por fila y 200 simulaciones, el ejemplo incluido en el artículo obtiene un resultado llamativo.
Sin pasajeros incumpliendo el orden:
| Método | Tiempo medio |
|---|---|
| WilMA | 940,0 s |
| Aleatorio | 1.147,3 s |
| Steffen | 1.155,9 s |
| Trasera a delantera | 1.534,8 s |
La simulación no reproduce la victoria de Steffen obtenida en el experimento de 2011. WilMA termina primero.
Esto no demuestra que WilMA sea universalmente superior. Demuestra algo posiblemente más útil para un desarrollador: pequeños cambios en el modelo pueden cambiar el ganador.
El tiempo asignado al equipaje, la distancia entre pasajeros, las penalizaciones por interferencias y la forma exacta de ordenar cada grupo modifican el resultado.
Es el equivalente a cambiar latencias, tamaños de cola, distribución de peticiones o tiempos de respuesta en una simulación informática.
Añadir ruido cambia el comportamiento del sistema
La simulación introduce después algo parecido a un chaos test: usuarios que no cumplen el orden.
Con un 15 % de incumplimiento, WilMA continúa primero con 983,3 segundos de media. Steffen registra 1.144,1 segundos, el aleatorio 1.152,4 y trasera a delantera baja hasta 1.444,4.
Cuando el porcentaje alcanza el 35 %, trasera a delantera vuelve a mejorar hasta 1.310,7 segundos.
El resultado parece extraño: introducir desorden mejora uno de los algoritmos.
Tiene explicación.
El método trasera a delantera concentra pasajeros que se dirigen a zonas próximas del avión. Esto aumenta la probabilidad de que varias personas intenten utilizar simultáneamente el mismo tramo del pasillo.
El ruido rompe parcialmente esa concentración.
Es comparable a introducir jitter en sistemas distribuidos.
Cuando miles de clientes reintentan una petición exactamente al mismo tiempo después de una caída, pueden provocar un thundering herd y volver a saturar el servicio. Añadir una pequeña cantidad aleatoria al backoff distribuye los reintentos en el tiempo.
Lo que aparentemente introduce desorden puede aumentar la estabilidad.
La lección para sysadmins y desarrolladores está en producción
El método Steffen resulta útil como caso de estudio porque separa tres conceptos que con frecuencia se confunden: correcto, óptimo y operable.
Un algoritmo puede ser matemáticamente correcto.
Puede incluso demostrar mejores resultados bajo unas condiciones determinadas.
Y aun así puede no ser la mejor solución para producción.
Los equipos de sistemas se encuentran continuamente con situaciones parecidas. Una arquitectura de Kubernetes puede ser técnicamente impecable y excesivamente compleja para el equipo encargado de mantenerla. Un sistema de caché puede mejorar extraordinariamente un benchmark y complicar la consistencia de datos. Una política de seguridad puede ser perfecta sobre el papel y provocar que los usuarios terminen buscando mecanismos para saltársela.
También ocurre con machine learning.
Un modelo puede conseguir mejores métricas en un notebook y fracasar cuando recibe datos incompletos, distribuciones diferentes o entradas que nadie contempló durante el entrenamiento.
El error está en confundir el benchmark con el sistema.
Para evaluar una solución destinada a producción no basta con preguntar cuánto rinde cuando todo funciona. También interesa saber qué sucede cuando alguien incumple el supuesto principal sobre el que fue diseñada.
Ese enfoque cambia las pruebas.
En lugar de medir únicamente el escenario ideal, puede introducirse latencia, pérdida de paquetes, peticiones duplicadas, servicios lentos, usuarios fuera de secuencia, discos llenos o dependencias temporalmente indisponibles.
El método Steffen sobrevivió perfectamente a la pregunta matemática: cómo organizar pasajeros para minimizar interferencias.
La pregunta operativa era diferente: cómo conseguir que cientos de personas reales sigan ese orden sin que el coste de organizarlo elimine la mejora conseguida.
Ahí está la parte interesante para ingeniería de software y administración de sistemas. La mejor solución no siempre es la que obtiene el número más bajo en el benchmark, sino la que conserva suficiente rendimiento cuando aparecen las condiciones que el benchmark decidió ignorar.
Preguntas frecuentes
¿Qué puede aprender un desarrollador del método Steffen?
Que una optimización depende de los supuestos utilizados para diseñarla. Antes de trasladar un algoritmo a producción conviene comprobar qué ocurre cuando usuarios, datos o servicios dejan de respetarlos.
¿Por qué WilMA puede funcionar mejor que Steffen en situaciones reales?
WilMA sacrifica parte de la optimización del orden a cambio de una regla mucho más sencilla: ventanilla, centro y pasillo. Esa menor complejidad puede facilitar su aplicación con pasajeros reales.
¿Qué relación tiene el embarque de un avión con los sistemas distribuidos?
Ambos pueden tener múltiples actores compitiendo por recursos limitados. Colas, concurrencia, bloqueos, jitter, latencia y comportamiento impredecible pueden cambiar considerablemente el rendimiento global.
¿La simulación Python demuestra que WilMA es mejor?
No. La simulación del artículo es deliberadamente simplificada y sus resultados dependen de sus parámetros. Precisamente muestra que cambiar el modelo puede alterar qué algoritmo obtiene el mejor resultado.
Fuentes:
- Artículo y simulación de partida sobre el método Steffen y su aplicación práctica.
- Jason H. Steffen, Optimal boarding method for airline passengers, Journal of Air Transport Management, 2008.
- Jason H. Steffen y Jon Hotchkiss, Experimental test of airplane boarding methods, Journal of Air Transport Management, 2012; prepublicación arXiv:1108.5211.
