Todos los circuitos están ocupados ahora: el colapso de la red de larga distancia de AT&T en 1990 por Dennis Burke Noviembre de 1995 Universidad Estatal Politécnica de California A las 2:25 pm del lunes 15 de enero, los gerentes de red del Centro de operaciones de red de AT&T en Bedminster, Nueva Jersey, comenzaron a notar un número alarmante de señales de advertencia rojas provenientes de varias partes de su red nacional. En cuestión de segundos, la matriz de video gigante de 72 pantallas que representaba gráficamente la red se entrecruzó con una maraña de líneas rojas a medida que un malfuncionamiento se propagaba rápidamente de un centro de conmutación computado a otro. Los primeros procedimientos estándares de mitigación que intentaron los gerentes no lograron que la red recuperara la velocidad y durante nueve horas, mientras los ingenieros se apresuraban a estabilizar la red, casi el 50% de las llamadas realizadas a través de AT&T no se pudieron realizar. Incluso a las 11:30 pm, cuando las cargas de la red eran lo suficientemente bajos como para permitir que el sistema se estabilizara, tan sólo AT&T perdió más de 60 millones de dólares en llamadas no conectadas. Aún se desconoce la cantidad de negocios perdidos por los sistemas de reservaciones de aerolíneas, hoteles, agencias de alquiler de autos y otras empresas que dependían de la red telefónica. No se suponía que esto sucediera. AT&T se había ganado una reputación y una enorme campaña publicitaria basada en su fiabilidad y seguridad. ¿Qué había salido mal? En un buen dia Normalmente, la red de larga distancia de AT&T era un modelo de confiabilidad y solidez. En un día cualquiera, el servicio de larga distancia de AT&T, que en ese momento transportaba más del 70% del tráfico de larga distancia del país, enruta más de 115 millones de llamadas telefónicas. La columna vertebral de esta red masiva estaba conformada por un sistema de 114 conmutadores electrónicos operados por computadora (4ESS) repartidos por todos los Estados Unidos. Estos conmutadores, cada uno capaz de manejar hasta 700.000 llamadas por hora, estaban conectados a través de una red en cascada conocida como Sistema de Canal Común de Señales Nro. 7. Cuando la red recibe una llamada telefónica desde una central local, un conmutador analiza una lista de 14 rutas posibles diferentes para completar la llamada. Al mismo tiempo, pasa el número de teléfono a una red de señalización paralela que verifica las rutas alternativas para determinar si el conmutador del otro extremo podría conectar la llamada a su compañía local. Si el conmutador de destino estaba ocupado, el conmutador original enviaba a la persona que realizaba la llamada un tono audible de ocupado y liberaba la línea. Si el conmutador se encontraba disponible, una computadora de red de señales realizaba una reserva en el conmutador de destino y ordenaba al conmutador de destino que pasara la llamada, después de que los conmutadores verificaran si la conexión era buena. Todo el proceso tomaba solo de cuatro a seis segundos. Qué salió mal Tomó sólo un poco más de tiempo para ralentizar toda la red. Trabajando hacia atrás a través de los datos, un equipo de 100 técnicos telefónicos buscaron frenéticamente intentando identificar el problema, que comenzó en la ciudad de Nueva York. El conmutador de Nueva York había realizado una autoprueba de rutina que indicó que se estaba acercando a sus límites de carga. Como indicaba el procedimiento estándar, el conmutador realizó un reinicio de mantenimiento de cuatro segundos y envió un mensaje a través de la red de señalización de que no recibiría más llamadas hasta nuevo aviso. Después del reinicio, el conmutador neoyorkino comenzó a distribuir las señales que habían recibido durante el tiempo que estuvo fuera de línea. En todo el país, otro interruptor recibió un mensaje de que una llamada de Nueva York estaba en camino y comenzó a actualizar sus registros para mostrar que el conmutador de Nueva York estaba en línea nuevamente. Entonces llegó un segundo mensaje del conmutador de Nueva York, diez milisegundos después del primero. Debido a que el primer mensaje aún no se había manejado, el segundo mensaje debería haberse guardado para más tarde. Un defecto de software provocó que el segundo mensaje se escribiera sobre información de comunicaciones crucial. El software en el conmutador de recepción detectó la sobrescritura e inmediatamente activó un enlace de respaldo mientras se reiniciaba, pero otro par de mensajes sincronizados con precisión desencadenaron la misma respuesta en el procesador de respaldo, lo que provocó que también se apagara. Cuando el segundo conmutador se recuperó, comenzó a enrutar sus llamadas atrasadas y propagó el ciclo de mensajes de tiempo reducido y apagados en toda la red. El problema se repitió de forma iterativa en los 114 conmutadores de la red, bloqueando más de 50 millones de llamadas en las nueve horas que llevó estabilizar el sistema. El problema de raíz La causa del problema había llegado meses antes. A principios de diciembre, los técnicos habían actualizado el software para acelerar el procesamiento de ciertos tipos de mensajes. Aunque el código actualizado se había probado rigurosamente, se agregó inadvertidamente un error de una línea al software de recuperación de cada uno de los 114 conmutadores de la red. El defecto era un programa en C que presentaba una instrucción break ubicada dentro de una cláusula if, que estaba anidada dentro de una cláusula switch. En pseudocódigo, el programa decía lo siguiente: 1 while (el búfer de recepción del anillo no está vacío y el tampón lateral no está vacío) DO 2 Inicialice el puntero al primer mensaje en el búfer lateral o búfer de recepción de anillo 3 obtener una copia del búfer 4 cambiar (mensaje) 5 caso (mensaje_recibido) 6 si (el conmutador de envío está fuera de servicio) SÍ 7 si (el búfer de escritura en anillo está vacío) DO 8 enviar "en servicio" al mapa de estado 9 por demás 10 interrumpir TERMINAR SI 11 procesar el mensaje entrante, configurar punteros para parámetros opcionales 12 Interrumpir FINALIZAR Conmutador 13 hacer parámetro opcional funcionar Cuando el conmutador de destino recibió el segundo de los dos mensajes cronometrados mientras aún estaba ocupado con el primero (búfer no vacío, línea 7), el programa debería haber salido de la cláusula if (línea 7), procesado el mensaje entrante, y configure los punteros a la base de datos (línea 11). En cambio, debido a la declaración de interrupción en la cláusula else (línea 10), el programa abandonó la declaración de caso por completo y comenzó a realizar un trabajo de parámetro opcional que sobrescribió los datos (línea 13). El software de corrección de errores detectó la sobrescritura y apagó el interruptor mientras se reiniciaba. Debido a que todos los conmutadores contenían el mismo software, los restablecimientos cayeron en cascada por la red, incapacitando al sistema. Lección aprendida Desafortunadamente, no es difícil que un simple error de software permanezca sin ser detectado, para luego derribar incluso los sistemas más confiables. La actualización de software cargada en los 4ESS ya había pasado por capas de pruebas y había pasado desapercibida durante la ajetreada temporada navideña. AT&T era fanático de su confiabilidad. Toda la red se diseñó de manera que ningún conmutador pudiera hacer caer el sistema. El software contenía funciones de autorreparación que aislaban los interruptores defectuosos. La red utilizó un sistema de "democracia paranoica", donde los interruptores y otros módulos se monitoreaban constantemente entre sí para determinar si estaban "cuerdos" o "locos". Lamentablemente, el incidente de enero de 1990 mostró la posibilidad de que todos los módulos se volvieran "locos" a la vez, cómo los errores en el software de autorreparación pueden derribar sistemas saludables y la dificultad de detectar defectos oscuros dependientes de la carga y el tiempo en software. Sin embargo, aún queda mucho por aprender de este incidente. Claramente, el uso de programas C y compiladores contribuyó al colapso. Un lenguaje de programación más estructurado con compiladores más estrictos habría hecho mucho más evidente este defecto en particular. La práctica rutinaria de permitir que los interruptores de larga distancia se apaguen y reinicien por sí mismos también contribuyó. Un sistema de hardware y software más tolerante a fallas que pudiera manejar problemas menores sin apagarse podría haber reducido en gran medida los efectos del defecto. La lección final es positiva; Vale la pena señalar que con la cuidadosa atención de AT&T a la capacidad de supervivencia del hardware y las pruebas exhaustivas, este es uno de los pocos problemas que ha tenido un impacto tan grave en su red de larga distancia. Si bien la falla de la declaración de ruptura podría haberse evitado con técnicas de ingeniería de software más completas, el sistema implementado ya ha disuadido muchos más problemas. La caída del sistema de larga distancia de AT&T se destaca no solo como un ejemplo de ingeniería de software, sino por su rareza.