Fallo masivo de Microsoft: la vulnerabilidad tecnológica global quedó expuesta

Samuel Arbesman, escritor y científico en residencia en Lux Capital, afirmó que los recientes fallos tecnológicos, como el apagón masivo de Microsoft el 19 de julio de 2024, revelan la fragilidad de nuestra infraestructura tecnológica. “Descubrimos la fragilidad de nuestra infraestructura tecnológica solo cuando ya es demasiado tarde”, señala Arbesman en su columna de opinión.

Estos fallos no son eventos aislados. En los últimos años, hemos presenciado apagones de Internet, debacles en sistemas de aviación y ahora un fallo que ha afectado a los sistemas de Microsoft, paralizando vuelos y alterando el funcionamiento de diversos sectores, incluidos proveedores de atención médica, bancos y medios de comunicación.

“¿Por qué somos tan malos evitando estos fallos?” pregunta Arbesman. La respuesta, según él, radica en la complejidad inherente de los sistemas tecnológicos modernos, que son “demasiado complicados para que alguien los entienda completamente”. argumenta en su columna publicada en el portal The Atlantic.

Los sistemas tecnológicos actuales no son programas de computadora construidos por una sola persona; son el resultado del trabajo de múltiples individuos a lo largo de muchos años. Están compuestos de innumerables componentes, cada uno con posibles interacciones que podrían no ser comprendidas por completo. “Muchos de nuestros sistemas involucran una gran cantidad de computadoras, cualquiera de las cuales podría fallar y derribar a todas las demás”, explica Arbesman.

Cómo reducir la frecuencia de fallos tecnológicos

Para reducir la frecuencia de estos fallos, Arbesman sugiere que necesitamos conocer mejor nuestros sistemas tecnológicos. Una de las maneras de hacer esto, irónicamente, es provocando fallos en ellos. “Al igual que los biólogos irradian bacterias para causar mutaciones que nos muestran cómo funcionan las bacterias”, cita, podemos introducir errores en las tecnologías para entender cómo tienden a fallar.

Este trabajo a menudo recae en los ingenieros de aseguramiento de calidad del software, cuya labor consiste en probar sistemas con una variedad de entradas. Una técnica utilizada por estos ingenieros es conocida como “fuzzing”, que implica alimentar a un programa de software con una enorme cantidad de entradas generadas aleatoriamente para ver cómo responde el programa. La idea es que si el programa no falla, entonces es más probable que sobreviva en el mundo real e impredecible. “El primer Apple Macintosh fue fortalecido mediante un enfoque similar”, señala Arbesman.

Otra técnica más reciente se llama “ingeniería del caos”, que se centra en inyectar fallos a nivel de sistema. “Incluso cuando todos los servicios individuales en un sistema distribuido funcionan correctamente, las interacciones entre esos servicios pueden causar resultados impredecibles”, según Arbesman. Un buen ejemplo lo proporciona Netflix, que en 2012, lanzó públicamente una suite de software llamada Chaos Monkey, que derribó aleatoriamente diferentes subsistemas para probar cómo respondía su infraestructura general.

Sin embargo, estas técnicas no son perfectas. A medida que los sistemas tecnológicos se vuelven más complejos, se hace imposible probar cada entrada o condición. “El azar puede ayudarnos a encontrar errores adicionales, pero solo estaremos muestreando un pequeño subconjunto de situaciones potenciales”, advierte Arbesman. Además, estos métodos no incluyen los tipos de fallos que distorsionan los sistemas sin romperlos por completo, lo cual es difícil de detectar.

Qué pasa con los sistemas modernos de tecnología

Arbesman enfatiza la necesidad de una humildad epistemológica al enfrentarnos a la complejidad de los sistemas modernos. Debemos reconocer que hay límites a lo que podemos saber acerca de cómo y cuándo fallarán nuestras tecnologías. También, sugiere que es crucial moderar nuestra inclinación a culpar a una persona o grupo específico por los fallos sistémicos. “Los sistemas modernos en muchos casos son simplemente demasiado grandes para permitirnos señalar a un solo actor cuando algo sale mal”.

Un ejemplo presentado por Casey Rosenthal y Nora Jones en su libro Chaos Engineering ilustra esta idea. Una gran minorista en línea intentó evitar errores durante la temporada navideña deteniendo temporalmente los cambios en su código de software, lo que también pausó los reinicios frecuentes del sistema. Esta precaución resultó contraproducente cuando un error menor en una biblioteca externa que la minorista utilizaba comenzó a causar problemas de memoria, lo que desencadenó apagones.

En resumen, sostener que la culpa de estos fallos es de un solo ingeniero es menos probable que el hecho de que la complejidad inevitable del software moderno sea la verdadera culpable. Por lo tanto, Arbesman aboga por enfrentar esta complejidad utilizando técnicas como la ingeniería del caos en lugar de tratar de eliminarla por completo. “A medida que nuestro mundo se vuelve más interconectado por sistemas masivos, necesitamos ser nosotros mismos los que los rompemos una y otra vez”, subraya.