Fallo óptico de OVH 2017: independencia de la redundancia

Resumen

El límite del evento es estrecho:este artículo cubre únicamente el fallo de la red óptica de Roubaix del 9 de noviembre de 2017. El corte eléctrico simultáneo de Estrasburgo fue un incidente independiente con un mecanismo y una cadena de control distintos.
El fallo visible fue amplio, pero no universal:los relatos contemporáneos describieron la pérdida de conectividad de Roubaix hacia seis de los puntos de presencia de red de OVH. Eso no prueba que todas las rutas, clientes o cargas de trabajo de OVH fallaran del mismo modo.
La diversidad nominal no proporcionó independencia operativa:OVH describió una conectividad óptica redundante; sin embargo, los enlaces de Roubaix quedaron indisponibles a la vez tras la pérdida de configuración y tuvieron que restaurarse a partir de una configuración guardada.
La causa raíz pública tiene dos capas:OVH atribuyó el evento inmediato a un defecto de software y a la pérdida de configuración del equipo óptico. La pérdida correlacionada también puso de manifiesto un dominio de fallo compartido de configuración o supervisión que la diversidad física de rutas no había eliminado.
La configuración guardada no es un sistema de recuperación independiente:una configuración guardada permitió la restauración, pero su existencia no mantuvo disponible el sistema óptico en funcionamiento. La disponibilidad de copias de seguridad, la autoridad de restauración y la recuperabilidad probada deben medirse por separado.
La responsabilidad sigue al control:OVH controlaba la arquitectura, el despliegue, la protección de la configuración, la supervisión, la restauración y la comunicación con los clientes. El fabricante del equipo controlaba la investigación del defecto del producto y la corrección del software. Los pares, las redes de tránsito y los clientes controlaban su propia diversidad externa, pero no el estado óptico interno de OVH.
La reparación anunciada separó correctamente dos problemas:OVH planificó una actualización de software con el fabricante del equipo y la división del sistema de multiplexación óptica en dos sistemas. La primera abordaba un defecto; la segunda pretendía limitar el radio de impacto de una recurrencia.
Una reparación no queda probada por un anuncio:un cierre creíble exige evidencia de topología y configuración, pruebas de inyección de fallos, mediciones independientes de alcanzabilidad y la prueba de que un único fallo de control ya no puede eliminar todas las rutas externas de Roubaix.

Congelar el evento de Roubaix antes de asignar responsabilidades

OVH sufrió dos fallos graves el mismo día. Un fallo eléctrico afectó a su centro de Estrasburgo, mientras que un fallo de la red óptica afectó a Roubaix. La declaración posterior de OVH describió explícitamente los incidentes como simultáneos pero no relacionados. Esa distinción es el punto de partida para la rendición de cuentas, no un detalle que deba colapsarse en una historia más amplia. [1]

Combinar los incidentes produciría una cadena causal inexacta. Estrasburgo implicó suministro eléctrico, equipos de transferencia, generadores y reinicio de servicios. Roubaix implicó transporte óptico, pérdida de configuración y conectividad hacia ubicaciones externas de red. Los sistemas responsables, los operadores, los proveedores, las señales de detección, las acciones de recuperación y las pruebas de prevención fueron distintos.

Por lo tanto, este artículo comienza en el fallo óptico de Roubaix y termina cuando se restauraron los enlaces pertinentes y la conectividad del centro de alojamiento, seguido de la reparación específica de Roubaix que anunció OVH. Excluye el evento eléctrico de Estrasburgo, un incidente de almacenamiento de julio de 2017, un incidente de red posterior de diciembre de 2017, el incendio de Estrasburgo de 2021 y un evento de enrutamiento distinto de 2021. Esos eventos pueden servir para una historia más amplia de OVH, pero no pueden utilizarse como evidencia de la causa ni de la reparación del fallo óptico de Roubaix.

La cronología pública tiene dos niveles útiles. La declaración formal de OVH indicó que el centro de Roubaix volvió a funcionar en menos de dos horas y media. Un proveedor de servicios afectado registró por separado una falta de alcanzabilidad visible para los clientes durante la misma mañana y describió la restauración después de recuperar la configuración óptica. [1][4]

Esos relatos describen la ventana de recuperación óptica en niveles distintos. No establecen que todos los servicios de los clientes se recuperaran en un único momento exacto. Un centro de alojamiento es una pila: los enlaces de transporte vuelven, las sesiones de enrutamiento se restablecen, las rutas convergen, los balanceadores de carga y las dependencias de aplicación se recuperan, las colas de correo se drenan, la supervisión se normaliza y los clientes reintentan. La evidencia pública no ofrece una tabla completa de restauración servicio por servicio.

La misma disciplina se aplica al inicio del incidente. Un proveedor de servicios afectado describió accesibilidad desde algunas redes pero no desde otras durante la interrupción de la mañana, mientras que OVH describió el fallo óptico del lado del proveedor y la posterior restauración. Esas perspectivas no son necesariamente contradictorias. Una registra el efecto observado por un cliente externo; la otra registra un evento en el sistema óptico del proveedor. Observadores, relojes y rutas de red distintos pueden ver límites distintos. [4]

La rendición de cuentas exige preservar esas distinciones en lugar de forzar un único momento perfecto. Un registro de incidente sólido alinearía sondas externas, alarmas ópticas, transiciones de interfaz, registros del controlador, cambios de sesión de enrutamiento e informes de clientes con un reloj común. El material público no proporciona esa alineación completa, por lo que este artículo no la inventa.

Lo que expuso la red en funcionamiento

El centro de Roubaix dependía del transporte óptico que lo conectaba hacia seis de los puntos de presencia de red de OVH, según el relato del proveedor de servicios afectado. El registro público describe múltiples rutas ópticas y una amplia pérdida de conectividad externa, pero no proporciona una topología completa verificada de cada circuito, ruta de cliente o dependencia. [4]

Esos detalles importan porque muestran que el evento no se presentó como un corte rutinario de una sola fibra. OVH y los relatos contemporáneos describieron, en cambio, un fallo de software y configuración que afectó al sistema óptico, seguido de un trabajo de recuperación con el fabricante del equipo. Las fuentes disponibles no exponen la secuencia completa de diagnóstico ni el estado interno del plano de gestión. [1][4]

La descripción pública de la causa raíz identificó una pérdida de configuración en el equipo óptico. OVH recuperó la configuración guardada y restauró la conectividad afectada. La empresa atribuyó el evento inmediato a un defecto de software, mientras que la pérdida correlacionada de rutas puso de manifiesto una cuestión más amplia sobre las dependencias compartidas de configuración y supervisión. [1][4]

Se trata de un relato significativo, pero no de un informe forense completo. No revela la versión exacta del software, el cambio de estado inicial, el fallo del proceso, la secuencia de almacenamiento, la semántica de replicación, la elección en el plano de control, el comando humano, la cronología de alarmas ni el registro interno del incidente. No prueba si la configuración perdida fue la única causa inicial o una consecuencia visible de un fallo de control más profundo.

La afirmación defendible más sólida es más estrecha: el equipo óptico de OVH entró en un estado en el que los enlaces externos de Roubaix quedaron indisponibles; OVH atribuyó ese estado a un defecto de software y a la falta de configuración; la restauración de la configuración guardada devolvió la conectividad; y OVH propuso más tarde tanto una corrección de software como una separación arquitectónica.

La red en funcionamiento es la evidencia principal. Los registros de inventario pueden decir que existen fibras, rutas, tarjetas y copias de seguridad. Los documentos de diseño pueden decir que los enlaces son redundantes. Lo que importó durante el incidente fue que el sistema óptico dejó de proporcionar la conectividad externa necesaria para la alcanzabilidad de Roubaix. El estado operativo prevaleció sobre el diagrama nominal.

Esta es la cuestión central de la rendición de cuentas en infraestructura de red. La redundancia no debe contarse solo por componentes. Debe evaluarse por los dominios de fallo que pueden eliminar el servicio.

La diversidad física no es independencia del dominio de control

El modelo visual habitual del transporte resiliente son dos líneas entre dos ubicaciones. Si se corta una fibra, el tráfico usa la otra. Ese modelo es útil para un riesgo físico estrecho. Resulta incompleto cuando ambas rutas comparten software, autoridad de configuración, hardware de supervisión, temporización, alimentación, acceso de gestión, lógica de activación o un procedimiento común de recuperación.

Dos rutas ópticas geográficamente distintas pueden ocupar un único dominio de fallo operativo. Pueden terminar en tarjetas gobernadas por la misma base de datos. Pueden depender del mismo controlador o par de supervisión. Pueden recibir la misma imagen de software defectuosa. Pueden heredar una misma transacción de configuración. Pueden requerir una única red de gestión para el diagnóstico. Pueden quedar bloqueadas al entrar en un estado de seguridad común.

El relato de OVH es un ejemplo concreto de esa distinción. El proveedor describió una conectividad óptica redundante; sin embargo, los enlaces de Roubaix quedaron indisponibles a la vez cuando se perdió la configuración. Los controles destinados a preservar la conectividad no contuvieron el fallo compartido del estado de configuración que realmente ocurrió. [1][4]

Esto no significa que la diversidad física fuera inútil. Significa que abordaba un riesgo distinto. Las afirmaciones de resiliencia deberían nombrar la clase de riesgo que contienen:

el corte de una sola fibra;
el fallo de un conducto o de una ruta geográfica;
la pérdida de un amplificador óptico o de un nodo;
la pérdida de una tarjeta de línea o de un chasis;
el fallo de un controlador o de una tarjeta de supervisión;
una configuración corrupta o ausente;
un defecto de software común;
la pérdida de conectividad de gestión;
un error del operador propagado a sistemas redundantes;
un fallo de restauración en condiciones de incidente.

Un diseño puede superar los tres primeros y fallar en el sexto o séptimo. Llamar "redundante" al resultado sin nombrar la clase de fallo protegida oculta la pregunta más importante.

El RFC 3439 advierte, en términos arquitectónicos generales, de que la complejidad tiene costes reales y de que los sistemas suelen fallar en interacciones inesperadas. No fue escrito sobre el incidente de OVH y no prueba el diseño interno del proveedor. Ofrece una disciplina analítica útil: añadir componentes, copias y automatización puede crear estado compartido y modos de fallo adicionales salvo que su comportamiento esté acotado y sea observable. [14]

La guía de sistemas ciberresilientes del NIST trata la resiliencia, de manera similar, como una capacidad diseñada para anticipar, resistir, recuperarse y adaptarse. Es un marco posterior, no evidencia de lo que OVH desplegó en 2017. Aplicada con cuidado, sugiere que una red debe juzgarse no solo por las afirmaciones de prevención, sino por los límites de degradación, la autoridad de recuperación, la preservación de evidencia y la adaptación tras el fallo. [17]

La arquitectura de transporte óptico descrita por las recomendaciones de la UIT proporciona vocabulario para capas, relaciones de trayecto y protección. No puede reconstruir la topología privada de OVH a partir de hechos públicos. Su valor aquí es reforzar un punto general: el transporte óptico es una red gestionada con funciones de control, supervisión y recuperación, no simplemente cristal pasivo. [18]

La prueba de rendición de cuentas es, por tanto, la independencia, no la duplicación. Un operador debe poder identificar qué elementos son independientes, cuáles se comparten intencionadamente y qué ocurre cuando falla cada elemento compartido.

La configuración guardada no equivalía a disponibilidad operativa

El relato del incidente de OVH dice que se restauró la configuración guardada. Ese detalle ilustra un problema recurrente en la garantía de infraestructura: la existencia de copias de seguridad suele tratarse como equivalente a la recuperabilidad.

Una copia de seguridad puede existir y, aun así, no preservar el servicio. Puede estar almacenada dentro del mismo dominio de fallo. Sus réplicas pueden estar sujetas al mismo software defectuoso. Puede contener el mismo estado corrupto. El sistema puede no poder seleccionarla o cargarla automáticamente. El acceso de gestión puede estar indisponible. Los operadores pueden necesitar intervención física. Los procedimientos de restauración pueden ser lentos, ambiguos o no estar probados ante un fallo común.

La narrativa de Roubaix indica que los ingenieros recuperaron finalmente la configuración guardada. Fue una acción de recuperación exitosa. También muestra que el sistema en funcionamiento no mantuvo la disponibilidad simplemente porque existiera una configuración recuperable. [1][4]

Por tanto, los controles pertinentes son más precisos que "existía una copia de seguridad":

¿Qué objeto exacto se copió: una base de datos completa, una configuración generada, el estado del dispositivo o un registro de transacciones?
¿Qué proceso escribió cada copia y podía un único defecto de software corromperlas todas?
¿Eran las copias inmutables o estaban versionadas de forma independiente?
¿Se almacenaban en sistemas física y lógicamente separados?
¿Qué regla de coherencia determinaba si una copia era utilizable?
¿Podía seleccionarse una versión en buen estado sin el componente de gestión averiado?
¿Era la restauración automática, requería aprobación del operador o dependía de acceso local?
¿Cuánto tiempo había durado una restauración completa en la última prueba?
¿Recreaba la restauración el estado previsto o solo el último estado replicado?
¿Qué evidencia confirmaba que cada nodo óptico y cada enlace orientado al enrutador habían vuelto correctamente?

El material público responde solo a una parte de la lista. Muestra que la restauración de la configuración era posible. No muestra que la recuperación fuera independiente, estuviera preautorizada, se ejercitara con regularidad o se midiera frente a un objetivo de servicio.

Esta distinción debería influir en los informes a clientes y al consejo. "La configuración estaba respaldada" es una afirmación de inventario. "Una configuración en buen estado puede restaurarse por una vía de control independiente dentro de un tiempo probado, preservando la evidencia e impidiendo la reintroducción del estado defectuoso" es una afirmación de control operativo.

El transporte óptico formaba parte del servicio de alojamiento

La rendición de cuentas del alojamiento suele analizarse a nivel de servidor o de centro de datos. El fallo de Roubaix muestra por qué ese límite es demasiado estrecho. Un servidor puede seguir encendido y en buen estado mientras se vuelve inalcanzable porque el transporte óptico que conecta su centro con puntos externos de interconexión ha fallado.

El material público de peering de OVH y los registros actuales de PeeringDB y RIPE identifican el AS16276 y una huella de interconexión considerable. Esos registros son útiles para la identidad de red y la atribución del operador. Ayudan a un cliente o investigador a distinguir la red de OVH de la de otro proveedor e identificar ubicaciones donde puede producirse la interconexión. No prueban el estado operativo de un circuito de Roubaix en 2017, la ruta utilizada por un paquete concreto ni la independencia de dos servicios de cliente cualesquiera. [8][9][10][11]

Esta es una distinción de la capa de la realidad. Un registro o directorio puede registrar quién opera un sistema autónomo. Una página de peering puede describir una política. Un colector de rutas puede preservar observaciones BGP seleccionadas. Ninguno puede hacer que un sistema óptico averiado transporte tráfico.

A la inversa, el fallo óptico no borró la identidad de la red. El número de AS, las rutas y las relaciones externas siguieron siendo evidencia significativa para diagnosticar qué red se esperaba que originara y transportara tráfico. Los registros y la infraestructura en funcionamiento cumplen funciones de rendición de cuentas distintas: los registros identifican y preservan la autoridad; los sistemas en funcionamiento determinan si los paquetes se mueven.

Los clientes que compran alojamiento "redundante" o varios servicios a un mismo proveedor deben preguntarse si sus dependencias convergen dentro del proveedor. Dos máquinas virtuales en clústeres separados pueden compartir el transporte del mismo centro. Dos servicios en edificios distintos pueden compartir un sistema óptico metropolitano. Dos rutas anunciadas pueden converger en un único controlador o base de datos de configuración. Los nombres de producto y los recuentos de recursos no revelan estas dependencias.

El informe de Actility ofrece una visión externa instructiva. Indicó que algunos servicios quedaron inalcanzables mientras que una oferta SaaS alojada en otro centro de datos no se vio afectada. También describió alcanzabilidad desde algunas ubicaciones o redes, pero no desde otras. [4] Ese patrón es coherente con la diversidad de dependencias y rutas, aunque los datos públicos no bastan para cartografiar cada ruta o servicio.

La lección para el cliente no es simplemente "usar dos proveedores". El diseño multiproveedor puede reducir la concentración, pero crea su propia complejidad de DNS, enrutamiento, coherencia de datos, seguridad y operación. El requisito más firme es documentar los límites de dependencia y probar el fallo que importa.

El impacto debe permanecer ligado a la evidencia observable

OVH reconoció consecuencias directas para otros servicios y dijo que recibir el correo electrónico de los clientes fue especialmente difícil. La empresa se disculpó y afirmó que sus equipos permanecían movilizados. [1] La información contemporánea describió un impacto significativo para los clientes en todo el entorno de Roubaix. [5][6][7]

Las fuentes públicas no proporcionan un recuento completo de clientes afectados, una serie temporal de pérdida de paquetes, un análisis ruta por ruta, un inventario de servicios, el impacto en ingresos ni una tabla final de SLA. No establecen que todas las cargas de trabajo de Roubaix estuvieran inalcanzables durante todo el intervalo óptico. Tampoco establecen que un servicio estuviera sano simplemente porque una sonda pública tuviera éxito.

Redes distintas podían observar comportamientos distintos. Las políticas de enrutamiento, las respuestas DNS en caché, las sesiones existentes, las ubicaciones alternativas de servicio y la lógica de reintento de las aplicaciones pueden afectar al impacto visible. Algunos clientes pueden haber perdido todo el acceso. Otros pueden haber llegado a un servicio por una ruta restante o por un centro separado. El correo puede quedar en cola y llegar más tarde, haciendo que el fallo del transporte se manifieste como retraso y no como pérdida permanente.

La afirmación correcta sobre el impacto tiene tres capas:

Impacto de infraestructura declarado por el proveedor:el centro de Roubaix perdió los enlaces ópticos externos descritos en el relato de OVH.
Impacto de servicio observado externamente:clientes y al menos un proveedor alojado informaron de falta de alcanzabilidad parcial o amplia y de interrupciones concretas del servicio.
Impacto completo desconocido:el registro público no enumera todos los clientes, flujos, rutas, servicios ni consecuencias financieras afectados.

Preservar estas capas evita tanto la subestimación como la exageración. Decir que el impacto completo es desconocido no minimiza el evento. Perder los principales enlaces ópticos de un centro es intrínsecamente grave. Tampoco es necesario afirmar una caída universal cuando la evidencia no la respalda.

Un informe de impacto responsable publicaría la alcanzabilidad acotada en el tiempo desde redes independientes, el estado de las sesiones BGP, la disponibilidad de los enlaces, el tráfico agregado, el retraso del correo, el estado de los servicios principales, el volumen de tickets de clientes y las distribuciones de restauración. Describiría los límites del muestreo y los relojes. Separaría la recuperación del transporte de la recuperación de las aplicaciones.

Asignación del control: la responsabilidad distribuida no es responsabilidad ausente

La infraestructura de red cruza fronteras organizativas. Eso puede llevar a la conclusión vaga de que la responsabilidad era "compartida". Un método mejor asigna la responsabilidad según el control.

OVH

OVH controlaba la arquitectura de su red óptica de Roubaix, la relación entre las rutas físicas y los sistemas de control, el despliegue de software dentro de su ámbito, la protección de la configuración, la supervisión, la escalada de incidentes, la intervención local, la secuencia de restauración, la comunicación con los clientes y la decisión de cambiar el diseño.

Ese control crea obligaciones concretas. OVH necesitaba identificar los dominios de fallo comunes, desplegar el software de forma segura, preservar una configuración en buen estado, mantener una vía de diagnóstico independiente, probar la restauración, fijar las expectativas de los clientes y producir evidencia de que el diseño corregido contenía la recurrencia.

OVH no creó necesariamente el defecto de software del equipo. Eso no elimina su responsabilidad arquitectónica. Los operadores eligen cómo puede afectar a su servicio un defecto de un proveedor. Deciden si un defecto alcanza todas las rutas redundantes, si es posible la reversión y si un controlador averiado puede omitirse.

El fabricante del equipo

El fabricante del equipo controlaba la ingeniería del producto, el análisis de defectos, el software corregido, los diagnósticos del proveedor y la información disponible para OVH. El registro público dice que OVH estaba investigando con el fabricante y planeaba actualizar el software afectado. [1][4]

Sin un informe público del proveedor, este artículo no puede asignar el error exacto de software ni afirmar si el defecto era conocido previamente. El fabricante, no obstante, era dueño de la tarea del lado del producto de identificar por qué la configuración desapareció o quedó inutilizable y de demostrar que el código corregido impedía el fallo.

Pares y proveedores de tránsito

Los operadores de red externos controlaban sus propios enlaces, sesiones BGP, preferencias de ruta, supervisión y escalada. Podían observar la pérdida de alcanzabilidad de OVH y adaptarse donde existía interconexión alternativa. No podían restaurar la configuración óptica interna de OVH.

Las prácticas operativas de BGP, como las políticas explícitas de importación y exportación, son esenciales en los límites interdominio. Los RFC 7454 y 8212 ofrecen salvaguardas de enrutamiento posteriores o generales, no un diagnóstico de este evento óptico. Importan porque la restauración de la luz no prueba por sí sola un intercambio correcto de rutas. Después de que vuelvan las interfaces, una política de enrutamiento explícita ayuda a mantener acotada la recuperación de rutas. [15][16]

Clientes

Los clientes controlaban la selección del proveedor, la ubicación del servicio, la supervisión externa, el DNS y la conmutación por error de la aplicación, la replicación de datos y su propia comunicación de incidentes. Un cliente que comprara varios productos de OVH podía pedir evidencia de que esos productos no compartían el dominio de fallo óptico de Roubaix.

Los clientes no controlaban el estado interno del equipo óptico de OVH, su sistema de configuración ni su topología óptica. Sería incorrecto trasladar el fallo interno de transporte del proveedor a los clientes porque podrían haber comprado más redundancia. La resiliencia del cliente y la rendición de cuentas del proveedor son complementarias, no sustitutivas.

Reguladores, directorios y observadores

Los registros, los números de AS y los registros de peering respaldan la atribución y el análisis histórico. Las plataformas de medición pueden preservar observaciones de enrutamiento seleccionadas. Los organismos de normalización definen principios de diseño y operación útiles. Ninguno operaba el sistema de Roubaix ni podía restaurarlo.

Esta asignación evita dos errores. El primero es tratar un fallo del proveedor como una excusa completa para el fallo del proveedor de servicio. El segundo es asignar todas las consecuencias a OVH sin reconocer los controles de clientes e interconexiones fuera de su límite. La rendición de cuentas sigue a la capacidad de prevenir, detectar, contener, recuperar y demostrar.

La detección y el diagnóstico forman parte de la superficie de control

El registro público no revela la primera alarma interna, su marca de tiempo, gravedad, responsable ni calidad diagnóstica. Sabemos que los clientes vieron falta de alcanzabilidad y que OVH movilizó equipos. No sabemos si la supervisión identificó primero la pérdida del transporte óptico, el fallo de gestión, la pérdida de sesiones de enrutamiento, el colapso del tráfico o los síntomas de los clientes.

Esa evidencia ausente importa porque el diseño de la detección influye en la duración de la interrupción. Una alarma que dice "host inalcanzable" es menos útil que un registro correlacionado que muestre el estado del controlador óptico, la salud de la base de datos, el modo de la tarjeta, la alcanzabilidad de gestión, el estado de la interfaz del enrutador y la pérdida de rutas externas.

Los fallos de control común también pueden comprometer la supervisión. Si la tarjeta de supervisión, la red de gestión o el servicio de configuración comparten el mismo dominio de fallo, el sistema puede perder tanto el servicio como la telemetría explicativa. Los ingenieros se enfrentan entonces a un fallo a ciegas: síntomas amplios, acceso remoto incompleto y presión para reiniciar el equipo antes de preservar la evidencia volátil.

Una vía de diagnóstico independiente no debería significar solo una segunda interfaz en el mismo plano de control. Debería tener acceso gestionado y alimentado por separado, dependencias mínimas, un límite de seguridad conocido y la capacidad de capturar el estado cuando el sistema principal esté dañado.

El diseño también necesita autoridad operativa. ¿Quién puede restablecer la configuración? ¿Qué evidencia debe capturarse primero? ¿Qué versión en buen estado puede cargarse? ¿Cuándo se requiere intervención local? ¿Cómo se sopesa el riesgo de un reinicio frente a una interrupción continua? Un plan de recuperación que existe pero no puede autorizarse rápidamente no es un control eficaz.

La narrativa de Roubaix muestra que restaurar el sistema óptico requirió más que observar la existencia de una copia de seguridad. [4] Eso convierte el tiempo de recuperación en un parámetro arquitectónico. Si la restauración depende de reiniciar y secuenciar varios componentes, esas dependencias deberían aparecer en las pruebas de resiliencia y en los objetivos de servicio.

La reparación anunciada separó la corrección del defecto del control del radio de impacto

El plan de acción formal de OVH para Roubaix tenía dos partes. Planeaba investigar y corregir el defecto de software con el fabricante del equipo mediante una actualización. También aceleró un proyecto para distribuir el sistema de multiplexación óptica en dos sistemas separados con el fin de limitar el alcance del fallo. [1]

Esa separación es importante desde el punto de vista técnico. La corrección del software aborda un defecto conocido. La separación arquitectónica aborda la incertidumbre, incluida la posibilidad de otro defecto o de un fallo de control común distinto.

Un parche de software no puede demostrar que haya desaparecido toda una clase de fallo. Puede corregir una ruta a través del código dejando sin cambios las dependencias compartidas de configuración, supervisión o gestión. A la inversa, dividir los sistemas sin corregir un defecto conocido puede producir dos sistemas que fallen de forma independiente si el mismo software y estado se despliegan de forma idéntica.

Por tanto, un programa de reparación sólido debería probar ambas dimensiones.

Corrección del defecto

Vincular el aviso del proveedor o el registro del defecto a la versión de software afectada.
Identificar la condición exacta del fallo, los componentes afectados y el comportamiento corregido.
Preparar la imagen corregida en un sistema representativo.
Verificar la migración de configuración, la reversión y la preservación del estado.
Ejercitar la condición que previamente causó la pérdida de configuración.
Preservar registros que muestren que el fallo ya no se produce.

Separación de dominios de fallo

Documentar qué rutas ópticas terminan en cada sistema.
Separar el control, la supervisión, el almacenamiento de configuración y el acceso de gestión cuando sea necesario.
Impedir que una transacción de configuración desactive ambos sistemas.
Garantizar que un despliegue de software pueda probarse como canario y detenerse antes de llegar a todas las rutas.
Demostrar que la pérdida de un sistema deja suficiente capacidad externa y alcanzabilidad para el objetivo de servicio definido.
Probar el movimiento de tráfico y la convergencia de enrutamiento con la topología reducida.

Evidencia de recuperación

Restaurar una configuración en buen estado sin depender del componente de control averiado.
Medir los tiempos de detección, decisión, restauración, retorno de enlaces y convergencia de rutas.
Preservar sumas de verificación y estado de topología antes y después.
Comparar el estado interno de los enlaces con sondas externas independientes.
Registrar errores residuales en lugar de declarar el restablecimiento total al primer ping exitoso.

La declaración pública de OVH documenta la intención de realizar la división. Las fuentes congeladas para este artículo no proporcionan una fecha de finalización, un diagrama de implementación, una prueba independiente ni un ejercicio posterior de recurrencia. La conclusión responsable es que la dirección anunciada abordó la distinción de control correcta, mientras que su eficacia sigue sin probarse en este registro.

Cómo comprobar la independencia de la redundancia

Un operador puede convertir el incidente en una auditoría repetible construyendo una matriz de dominios de fallo. Cada ruta relevante para el cliente se asigna frente a la ruta física, los nodos ópticos, las tarjetas de línea, los chasis, los sistemas de supervisión, los almacenes de configuración, la versión de software, la red de gestión, la alimentación, la temporización, el grupo de operadores y la autoridad de restauración.

La matriz debe responder una pregunta sencilla para cada par de rutas "redundantes": ¿qué componentes pueden seguir eliminando ambas?

Ese análisis suele revelar dependencias ocultas por los diagramas de topología. Fibras separadas pueden entrar en el mismo edificio. Chasis separados pueden usar un único controlador. Controladores separados pueden compartir un clúster de base de datos. Instancias de software separadas pueden recibir una configuración defectuosa de una canalización de automatización común. Centros de datos separados pueden depender de un único servicio de DNS, identidad o control de red.

La matriz es solo una hipótesis hasta que se prueba. Entre las pruebas útiles se incluyen:

retirar una fibra física y verificar la protección óptica automática;
retirar un chasis y verificar que la capacidad se mantiene dentro del objetivo declarado;
aislar un controlador y verificar que el otro sistema continúa sin una convergencia de estado insegura;
corromper o retener una réplica de configuración y verificar una selección segura;
denegar la ruta de gestión principal y realizar el diagnóstico por la ruta independiente;
desplegar una imagen de software deliberadamente rechazada en un canario y verificar la contención del despliegue;
restaurar una configuración en buen estado bajo presión de tiempo;
medir la convergencia de BGP y del plano de datos desde redes independientes;
verificar que el estado orientado al cliente refleja el servicio observado, no solo la salud del dispositivo;
conservar evidencia suficiente para que un revisor externo pueda reproducir la conclusión.

La condición de superación debe definirse antes de la prueba. "El tráfico se recuperó" es demasiado vago. Una condición útil indica la capacidad mínima, la pérdida máxima de alcanzabilidad, la pérdida de paquetes permitida, el tiempo de convergencia, las clases de servicio, los puntos de observación externos y los requisitos de conservación de evidencia.

Las pruebas también deben tener en cuenta el mantenimiento. Muchos fallos comunes se producen durante actualizaciones o cambios de configuración, cuando los sistemas redundantes están alineados intencionadamente. Un diseño que sobrevive a la pérdida aleatoria de una tarjeta puede fallar cuando un trabajo de automatización común empuja el mismo estado defectuoso a ambos lados.

La operación independiente no exige que todos los componentes sean diferentes. La heterogeneidad completa puede aumentar la complejidad y el error. Exige que las dependencias compartidas sean explícitas, acotadas y estén alineadas con una recuperación probada. El objetivo no es un teatro de diversidad. Es la evidencia de que un fallo plausible no puede derrotar silenciosamente todas las rutas anunciadas como redundantes.

Los controles contrafácticos aclaran las primeras oportunidades perdidas

El análisis contrafáctico no debe pretender que un control habría impedido con certeza el evento. Pregunta dónde habrían podido cambiar la secuencia los controles observables.

Si el defecto de software se hubiera detectado antes del despliegue

Un entorno de preproducción representativo, un despliegue canario o una prueba de defectos del proveedor podrían haber expuesto el estado de fallo antes de que llegara al sistema de producción. La evidencia pública no nos dice si el defecto requería una secuencia rara imposible de reproducir en preproducción. Por tanto, este contrafactual es posible, no probado.

Si los sistemas ópticos hubieran tenido un estado de control independiente

Si dos grupos de rutas hubieran tenido autoridades de configuración y sistemas de supervisión separados, la pérdida de una base de datos de configuración podría haber dejado operativo al otro grupo. La división de sistemas anunciada por OVH sugiere que la empresa vio valor en reducir el alcance del fallo común. La topología exacta anterior al incidente no es pública, por lo que la magnitud del contrafactual no puede calcularse.

Si la restauración de la configuración hubiera tenido una vía independiente

Una configuración en buen estado e inmutable y un mecanismo de restauración fuera de banda podrían haber reducido el tiempo de diagnóstico y recuperación. El relato del incidente dice que la configuración guardada se restauró finalmente. No muestra si existía una vía de restauración independiente, cómo se probó ni cuánto de la recuperación dependió del entorno de control afectado.

Si los clientes hubieran tenido rutas de alojamiento independientes

Un cliente que usara otro centro de datos u otro proveedor podría haber evitado parte del impacto en el servicio. Actility informó de que una oferta SaaS en otro centro de datos no se vio afectada. [4] Esa observación respalda la diversificación de dependencias, pero no prueba que todos los diseños multisitio habrían tenido éxito.

Si la evidencia de alcanzabilidad externa se hubiera integrado

Sondas independientes y observaciones de enrutamiento podrían haber ayudado a distinguir la recuperación local del dispositivo de la alcanzabilidad de los clientes. No habrían restaurado los enlaces ópticos. Su valor habría sido un diagnóstico más rápido, una comunicación acotada y una prueba más sólida del cierre.

La primera oportunidad perdida no puede nombrarse de forma concluyente a partir de la evidencia pública. Pudo ser la garantía del software, la arquitectura, la protección del estado de configuración, la supervisión, el diseño de la recuperación o una combinación. Un registro privado del incidente debería identificar el control más temprano que tuviera autoridad y pudiera haber actuado razonablemente.

Evidencia que cambiaría la conclusión

La conclusión es deliberadamente falsable. Debería cambiar si aparece evidencia más sólida.

Los registros de dispositivos y controladores podrían mostrar que la pérdida de configuración fue una consecuencia y no una causa. Un informe del proveedor podría identificar una condición específica de hardware o software. Los registros de topología podrían mostrar que las rutas ópticas eran más independientes de lo que implica el relato público, o que otro componente compartido las eliminó. Los historiales de configuración podrían mostrar que un cambio humano, un trabajo de automatización o una transición de estado desencadenó el evento.

Los datos de clientes y de medición podrían revisar el límite del impacto. Un análisis completo de alcanzabilidad podría mostrar un aislamiento casi universal de Roubaix o una conectividad sustancial restante. Los datos del colector BGP podrían establecer qué sesiones y rutas externas cambiaron, pero aún necesitarían mediciones del plano de datos para respaldar conclusiones de reenvío.

La evidencia de reparación podría reforzar o debilitar la conclusión de rendición de cuentas. Una división de sistemas completada, probada de forma independiente ante fallos de controlador y configuración, mostraría que OVH convirtió la lección en contención. Una prueba posterior que mostrara que ambos sistemas seguían compartiendo un dominio de fallo demostraría que la duplicación no había proporcionado independencia.

El artículo no necesita esos registros para afirmar que se produjo un fallo de red grave. Los necesita para que la afirmación de reparación sea completa.

Conclusión

La caída de Roubaix de OVH no fue una lección de que la redundancia sea inútil. Fue una lección de que la redundancia debe describirse en función de los fallos que puede contener.

El proveedor tenía conectividad óptica redundante y configuración guardada. Esos controles abordaban riesgos reales. No impidieron que un fallo común de control óptico eliminara la conectividad de Roubaix, y la restauración siguió dependiendo de recuperar la configuración.

El plan de acción posterior de OVH reconoció las dos capas del problema: corregir el defecto de software y dividir el sistema de multiplexación óptica para que un fallo tenga un alcance menor. Esa fue la separación conceptual correcta. La evidencia pública de este conjunto de fuentes no prueba la finalización ni la resistencia a la recurrencia.

Para los operadores de alojamiento y de red, el estándar de rendición de cuentas es concreto. Nombrar las clases de fallo protegidas. Cartografiar los dominios de control compartidos. Preservar un diagnóstico independiente y una recuperación en buen estado. Probar la pérdida de un sistema mientras el otro transporta tráfico. Medir la alcanzabilidad desde fuera del proveedor. Publicar evidencia suficiente para distinguir la duplicación de componentes de la independencia operativa.

Los registros de identidad de red y los inventarios de topología pueden mostrar quién opera la infraestructura y qué se supone que existe. Solo la evidencia de código en ejecución, la alcanzabilidad observada y la restauración probada muestran si la infraestructura sigue funcionando.

El fallo de la red óptica de OVH en 2017 convirtió la independencia de la redundancia en una prueba de rendición de cuentas