Las 10 principales perturbaciones de 2022

Los peores cortes de red y de servicio de 2022 tuvieron consecuencias de gran alcance. Vuelos en tierra, reuniones virtuales interrumpidas y comunicaciones bloqueadas.

Los culpables de la caída de las principales infraestructuras y proveedores de servicios también fueron diversos, según un análisis de ThousandEyes, una empresa de ciberinteligencia propiedad de Cisco que rastrea el tráfico de Internet y la nube. Los errores relacionados con el mantenimiento se han citado más de una vez: La operadora canadiense Rogers Communications sufrió un corte masivo en todo el país que se atribuyó a una actualización de mantenimiento, y un error de script de mantenimiento causó problemas al fabricante de software Atlassian.

Los errores de configuración de BGP también aparecen en los principales informes de interrupciones. El Protocolo de Pasarela Fronteriza indica al tráfico de Internet qué ruta tomar, pero si la información de enrutamiento es incorrecta, el tráfico puede desviarse a la ruta incorrecta, como ocurrió con Twitter. (Más información sobre los cortes en EE.UU. y el resto del mundo en nuestro chequeo semanal de la salud de Internet.

He aquí las 10 principales perturbaciones del año, por orden cronológico.

British Airways pierde su sistema en línea: 25 de febrero

El 25 de febrero, los servicios en línea de British Airways estuvieron inaccesibles durante varias horas, lo que provocó cientos de cancelaciones de vuelos e interrumpió las operaciones de la aerolínea. No se pueden reservar vuelos ni facturar electrónicamente. Al parecer, la aerolínea se vio obligada a volver a los procesos en papel cuando sus sistemas en línea quedaron inaccesibles, y el impacto se dejó sentir en todo el mundo. "Nuestra monitorización muestra que la ruta de la red a los servicios en línea (y servidores) de la aerolínea es accesible, pero el servidor y las respuestas del sitio están temporizadas", dijo ThousandEyes en su análisis de interrupción, que culpó del fallo a un servidor de aplicaciones que no respondía. - En lugar de problemas de red - interrupción.

"La naturaleza del problema y la respuesta de la aerolínea al mismo sugieren que la causa raíz puede ser un repositorio back-end central del que dependen múltiples servicios front-end. Si este es el caso, este incidente puede ser la base para que British Airways reconstruya o deconstruya sus Catalysts al final para evitar puntos únicos de fallo y reducir la probabilidad de que se repita. Sin embargo, es igualmente probable que la secuencia de acontecimientos que condujo al apagón ocurra raramente y pueda controlarse en gran medida en el futuro. El tiempo lo dirá", afirmó Thousand Eyes.

Twitter secuestrado por BGP: 28 de marzo

El 28 de marzo, el proveedor ruso de Internet y comunicaciones por satélite JSC RTComm.RU anunció indebidamente uno de los prefijos de Twitter (104.244.42.0/24), lo que provocó el desvío del tráfico a Twitter de algunos usuarios y su fallo. Algunos usuarios no pueden utilizar Twitter. Una vez retirado el aviso BGP de RTComm, los usuarios afectados recuperaron el acceso al servicio de Twitter. ThousandEyes señala que la mala configuración de BGP puede utilizarse para bloquear tráfico de forma selectiva, pero no siempre es fácil saber si la situación es accidental o intencionada.

"Sabemos que el Incidente de Twitter del 28 de marzo fue causado porque RTComm se anunció como el origen del prefijo de Twitter y luego lo retiró. Aunque no sabemos qué llevó a este anuncio, es importante entender que las desconfiguraciones accidentales de BGP no son infrecuentes, y dado que el ISP retiró esta ruta, es probable que RTComm no tuviera intención de causar un corte de impacto global al servicio de Twitter. Dicho esto, los ISP de algunas regiones han utilizado la manipulación localizada de BGP para aplicar políticas de acceso locales basadas en el tráfico de bloque", afirma ThousandEyes en su análisis de la interrupción.

Una forma que tienen las organizaciones de hacer frente a las fugas y secuestros de rutas es vigilar la rápida detección y protección de BGP mediante mecanismos de seguridad como la Infraestructura de Clave Pública de Recursos (RPKI), un mecanismo de seguridad criptográfico utilizado para hacer cumplir la autorización de origen de rutas. RPKI es eficaz contra el secuestro y la fuga de BGP, pero su adopción no está muy extendida. "Mientras que su empresa puede haber implantado RPKI para protegerse de las amenazas de BGP, su operador de telecomunicaciones puede no haberlo hecho. Esto es algo a tener en cuenta a la hora de elegir un ISP", afirma ThousandEyes.

Atlassian exagera el impacto de la interrupción: 5 de abril

Atlassian informó de problemas con varias de sus principales herramientas de desarrollo en la mañana del 5 de abril, entre ellas Jira, Confluence y OpsGenie. Un error de script de mantenimiento provocó la interrupción de estos servicios durante varios días, pero solo afectó a unos 400 clientes de Atlassian.

Al analizar la interrupción, ThousandEyes hizo hincapié en la importancia de las páginas de estado de los proveedores a la hora de informar de los problemas: La página de estado de Atlassian tenía un "mar de indicadores naranjas y rojos" que indicaban una interrupción grave, y la empresa dijo que movilizaría a cientos de ingenieros para corregir el incidente, pero para la mayoría de los clientes no hay ningún problema.

Las páginas de estado suelen subestimar el alcance de una interrupción, pero también pueden exagerar su impacto, advierte ThousandEyes: "Es un equilibrio muy difícil: decir demasiado poco o demasiado tarde, y los clientes se sentirán incómodos con la capacidad de respuesta; decir demasiado, y ser demasiado transparente, corre el riesgo de preocupar innecesariamente a un gran número de clientes no afectados, así como a partes interesadas más amplias.

Un apagón en Rogers corta el servicio en todo Canadá: 8 de julio

Una actualización de mantenimiento errónea provocó un prolongado apagón nacional en la red del operador canadiense Rogers Communications. La interrupción afectó a los servicios telefónicos y de Internet de unos 12 millones de clientes y obstaculizó muchos servicios críticos en todo el país, incluidas las transacciones bancarias, los servicios gubernamentales y las capacidades de respuesta a emergencias.

Según ThousandEyes, Rogers retiró sus prefijos debido a problemas internos de enrutamiento, que dejaron a los proveedores de nivel 1 inalcanzables a través de Internet durante casi 24 horas. "Este incidente parece haber sido provocado por la retirada de un gran número de prefijos de Rogers, lo que hizo que su red fuera inalcanzable desde Internet. Sin embargo, el comportamiento observado en su red durante este tiempo sugiere que la retirada de rutas BGP externas puede haber sido causada por problemas de enrutamiento interno", dijo ThousandEyes en su análisis de la interrupción.

La interrupción de Rogers es un recordatorio importante de la necesidad de redundancia en los servicios críticos; ThousandEyes recomienda tener varios proveedores de red, contar con planes de copia de seguridad en caso de interrupción y asegurarse de tener una visibilidad proactiva. "Ningún proveedor es inmune a las interrupciones, por grandes que sean. Así que para servicios críticos como hospitales y bancos, planifique un proveedor de red de respaldo que pueda mitigar la duración y el alcance de la interrupción", escribió ThousandEyes.

Interrupción en la región este de EE.UU. de AWS: 8 de julio

Un apagón el 28 de julio interrumpió el servicio dentro de la Zona de Disponibilidad 1 (AZ1) de Amazon Web Services (AWS) en la región Este 2 de Estados Unidos. "El apagón afectó a la conectividad de la región y provocó la caída de las instancias EC2 de Amazon, lo que afectó a aplicaciones como Webex, Okta, Splunk y BambooHR, entre otras", informó ThousandEyes en su análisis del apagón. No todos los usuarios o servicios se han visto afectados por igual; por ejemplo, los componentes de Webex ubicados en centros de datos de Cisco siguen funcionando con normalidad. AWS informó de que la interrupción sólo duró unos 20 minutos, pero algunos de los servicios y aplicaciones de sus clientes tardaron hasta tres horas en restablecerse.

Es importante diseñar un cierto grado de redundancia física en las aplicaciones y servicios prestados en la nube, escribe ThousandEyes: "No hay aterrizaje suave con un corte del centro de datos: cuando se va la luz, es duro para los sistemas dependientes. Ya se trate de un apagón de la red o de sistemas relacionados ( En tiempos como estos, la resistencia arquitectónica y la redundancia de los servicios digitales son cruciales.

Google Search, Google Maps obsoletos: 9 de agosto

La breve interrupción afectó a Google Search y Google Maps, y los usuarios de todo el mundo no pudieron acceder a estos servicios de Google durante aproximadamente una hora. "Los intentos de acceder a estos servicios dan lugar a mensajes de error de los servidores de borde de Google, incluyendo HTTP 500 y 502 respuestas del servidor, que a menudo indican problemas internos del servidor o de la aplicación", informó ThousandEyes.

Según los informes, la causa es una actualización de software que salió mal. No sólo los usuarios finales no pudieron acceder a Google Search y Google Maps, sino que las aplicaciones que dependían de la funcionalidad del software de Google también dejaron de funcionar durante la interrupción.

Los profesionales de TI se interesan por las interrupciones por varias razones, señala ThousandEyes. "En primer lugar, pone de relieve el hecho de que incluso los servicios más estables, como Google Search, que rara vez experimentan problemas o escuchamos hablar de interrupciones, están sujetos a las mismas fuerzas que pueden perturbar cualquier sistema digital complejo. En segundo lugar, el acontecimiento reveló lo omnipresentes que están algunos sistemas de software, entrelazados a través de los muchos servicios digitales que consumimos cada día sin ser conscientes de estas dependencias de software.

La interrupción de Zoom altera las reuniones virtuales: 15 de septiembre

Durante la interrupción del 15 de septiembre, los usuarios no pudieron iniciar sesión ni unirse a las reuniones de Zoom durante aproximadamente una hora, lo que provocó errores de puerta de enlace incorrecta (502) para usuarios de todo el mundo. Los usuarios no pudieron iniciar sesión ni unirse a las reuniones y, en algunos casos, los usuarios que ya estaban en la reunión fueron expulsados de la misma.

La causa principal no se ha confirmado, "pero parece estar dentro de los sistemas backend de Zoom, en torno a su capacidad para resolver, enrutar o redistribuir el tráfico", dijo ThousandEyes en su análisis de la interrupción.

El agente Zscaler sufre una pérdida de paquetes 100%: 25 de octubre

El 25 de octubre, el tráfico a un subconjunto de puntos finales de proxy Zscaler experimentó una pérdida de paquetes 100%, afectando a los clientes que utilizan el servicio Zscaler Internet Access (ZIA) en su Zscaler Cloud Network 2. Según el análisis de interrupciones de ThousandEyes, la pérdida de paquetes más grave duró unos 30 minutos, aunque algunos problemas de accesibilidad y picos de pérdida de paquetes en determinadas ubicaciones de usuarios persistieron de forma intermitente durante las tres horas siguientes.

Zscaler se refiere al problema como un "problema de reenvío de tráfico" en su página de estado. Cuando la IP virtual del dispositivo proxy es inalcanzable, el tráfico no puede ser reenviado.

ThousandEyes explicó cómo la situación impidió a algunos clientes que utilizan el servicio de seguridad Zscaler acceder a herramientas empresariales críticas y aplicaciones SaaS: "Esto puede haber afectado a varias aplicaciones para clientes empresariales que utilizan el servicio Zscaler porque está en el borde del servicio de seguridad ( Es típico en las implementaciones de SSE) proxy no solo tráfico web, sino también otras herramientas empresariales críticas y servicios SaaS como Salesforce.com, ServiceNow y Microsoft Office 365. Por lo tanto, el proxy está en la ruta de datos del usuario, y cuando el proxy no es accesible, hay una necesidad de estas herramientas para acceder se ve afectada, y la remediación a menudo requiere la intervención manual para enrutar a los usuarios afectados a una puerta de enlace alternativa.

WhatsApp corta la mensajería: 25 de octubre

Una interrupción de dos horas el 25 de octubre dejó a los usuarios de WhatsApp sin poder enviar ni recibir mensajes en la plataforma. El software gratuito propiedad de MetaWiki es la app de mensajería más popular del mundo: 31% de la población mundial utiliza WhatsApp, según datos de 2022 de la plataforma de inteligencia digital Similarweb.

Según el análisis de interrupciones de ThousandEyes, la interrupción se debió a un fallo de la aplicación backend y no a un fallo de la red. Ocurrió en horas punta en India, donde la aplicación tiene cientos de millones de usuarios.

AWS EE.UU. Región Este golpea de nuevo: 5 de diciembre

Amazon Web Services (AWS) sufrió una segunda interrupción en su región de EE.UU. Este 2 a principios de diciembre. Según AWS, la interrupción duró aproximadamente 75 minutos y causó problemas de conectividad a Internet hacia y desde la región US East 2.

ThousandEyes observó una pérdida de paquetes entre dos ubicaciones globales y la región US-East-2 de AWS durante más de una hora. Este incidente afectó a los usuarios finales que se conectaron a los servicios de AWS a través de sus ISP. "Esta pérdida sólo se produce entre los usuarios finales conectados a través de sus ISP y no parece afectar a la conectividad entre instancias dentro o entre regiones", dijo ThousandEyes en su análisis de interrupción.

Ese mismo día, AWS publicó una entrada en su blog en la que afirmaba que el problema se había resuelto. "Las conexiones entre instancias dentro de una zona, entre zonas y las conexiones directas no se ven afectadas por este problema. El problema se ha resuelto y la conectividad se ha restablecido por completo".