Un archivo para destruir el mundo: Qué pasó con la falla de sistemas global que afectó los vuelos

En el mundo de la tecnología y los sistemas, hay dos máximas que son inalterables: la primera dice que tu sistema es tan fuerte como tu punto de conexión más débil y la segunda, que si hay que elegir entre bonito y andando, siempre se impondrá la segunda.

Más de un lector lo debe saber pero por las dudas: quien escribe trabajó en sistemas durante muchos años y tuvo que aprender de la forma difícil que estas cosas pasan, pasan más seguido de lo que uno quisiera reconocer y que en realidad el asunto tiene que ver con la escala. Voy a tratar de explicarlo de forma simple, pero sin dejar afuera ninguna arista.

Para poner las cosas en contexto, debemos arrancar con un poco de historia: en el principio de nuestra dependencia de los sistemas, las computadoras funcionaban en solitario: cada una tenía un sistema operativo, un disco y el software que se operaba se instalaba y ejecutaba en esa pc. La falla de una computadora afectaba únicamente a esa máquina. Pero un día, llegó la red local.

Aparecen las redes

A partir de la LAN (Local Area Network), las computadoras seguían ejecutando software individual, pero compartían recursos -periféricos y  sobre todo, servidores- y se comunicaban entre ellas a través de conexiones físicas establecidas por cables y switches. La falla de una pc podía afectar a otras -dependiendo de dónde estuviera la falla- y un problema de los recursos compartidos afectaba la disponibilidad de ese recurso, pero no impactaba en la capacidad de las pcs de seguir ejecutando tareas. Los servidores, computadoras de mayor capacidad que permiten almacenar archivos o bases de datos de acceso múltiple para que la información que procesaba cada terminal pudiera ser compartida en tiempo real con el resto de los usuarios, ganaban importancia. Y un día llegaron las WAN.

Las Wide Area Networks empezaron a interconectar LANs sin la limitante de la conexión física: a partir de diferentes protocolos de transmisión, se empezaron a utilizar tecnologías que permitían intercambiar paquetes de datos a través de conmutadores y enrutadores que dependen de compañías que se encargaban de proveer ese servicio, como las telefónicas. Es decir que una empresa que fabrica y vende zapatos no tenía que hacer un cableado entre la fábrica, las oficinas y los puntos de venta: usaba la infraestructura de la compañía de teléfonos -pagando una tarifa- y los paquetes de datos viajaban por ella hasta los puntos de entrada de cada una de las redes locales.

Cada PC seguía ejecutando instancias individuales de software, pero la prevalencia de los servidores dentro de la lista de recursos compartidos creció enormemente: esto impedía que, en la empresa del ejemplo, el stock de zapatos fuera distinto para cada operador, o que la fábrica tuviera una idea más inmediata de qué iba a necesitar para seguir produciendo. Con internet, la computación dejó de ser una cuestión de sentarse en un escritorio y empezó a ser móvil: las notebooks y diversos equipos de computación portátil dependían cada vez más de la información compartida. Pero algunas cosas seguían dependiendo de las terminales: las empresas de software necesitaban vender licencias, y eso se hacía con cada instalación del sistema.

Y un día, llegó el SaaS

El Software as a Service llegó para resolver una de las cuestiones más importantes de la industria moderna: a la larga, la dependencia de los sistemas para cada empresa era tan grande que una buena parte de su presupuesto se iba en hardware, software y en el personal capacitado para operarlo, implementarlo y mantenerlo. Entonces, ya con internet completamente ubicua, las empresas de software empezaron a tomar el rol de lo que en algún momento hicieron las telefónicas: no gastes plata en recursos propios, personal y licencias. Te agrego al costo de la licencia toda la infraestructura para operar el software, el personal que lo mantendrá andando y las actualizaciones. Lo único que necesitás es una conexión a internet. Nació la bendita y bienamada nube, o Cloud Computing.

A partir de ahí, la (nueva) revolución: las empresas tercerizaron sus recursos de sistemas y sólo se encargaron de mantener un mínimo de personal para resolver cuestiones simples de conectividad y demás: ya no hacía falta un ejército de administradores, sino alguno que tuviera la suficiente capacitación como para ser el punto de contacto por si algo fallaba. El resto era propiedad y cuestión de quién te vende y distribuye el servicio. Por eso hoy nadie compra el Microsoft Office en una caja -oh, la nostalgia- y ya ni siquiera lo descarga de internet: con el usuario validado, el paquete de Office está disponible online -y con un conveniente modo offline que en algún momento deberá retomar la conexión-, así como los correos, las herramientas de conferencia, el software de administración, logística, inventario, ERP, y demás.

De hecho, en estos años volvieron las “terminales tontas”: hace muchos años, en algunas LANs había computadoras que sólo operaban conectadas a un servidor local. Ahora, equipos como las Chromebooks ya no tienen un sistema operativo per se, sino que funcionan a través de la conexión a internet con un pseudo OS. Casi no tienen disco rígido porque el grueso de lo que se guarda se hace en la nube y sólo son -simplificando- teclado y pantalla.

¿Qué pasó?

Toda esta introducción para decir: el problema de la independencia es la dependencia. 

De acuerdo con los primeros reportes, una falla de código en un paquete de actualización de Crowdstrike Falcon – sistema de protección de software malicioso en la nube- provocó que un archivo llamado C-00000291*.sys generara un error fatal en los sistemas operativos que recibieron dicho update.

Bien, identificado el asunto, y sabiendo qué hay que hacer para remediarlo, todo está arreglado, no? Bueno, sí pero no: usando una alegoría que me gusta, ya sabemos qué hizo que explotara un silo con dos toneladas de granos de arroz. Ahora hay que juntar los granos. Y el problema está en que es muy fácil distribuir una actualización, pero no es nada simple revertir el proceso. Principalmente, porque el sistema afectado no responde y aquél que se mandó la macana no está ni cerca de la computadora rota.

No te va a contestar, Armando

Cuando la terminal afectada no responde a un comando remoto, no queda otra que acceder a ella localmente. Y si eso era un problema antes, con departamentos de IT que guardaban cierta relación con el tamaño de la empresa a la que pertenecían, sólo cabe preguntarse qué tan difícil es ahora, después de que las empresas de software nos vendieran que la nube evitaría esta necesidad.

Hoy será un día en el que muchos usuarios deberán recibir instrucciones para llegar a partes de sus sistemas operativos que nunca habían navegado. Y, como cualquiera que entra a un bazar con los ojos vendados, las chances de romper otra cosa son, como mínimo, importantes. Por eso, la caída inicial de Azure fue solucionada en horas -en demasiadas horas, si me preguntan-, pero las consecuencias de este fallo van a durar bastante. Sobre todo, por el efecto de arrastre.

Todo lo que no se pudo procesar, eventualmente deberá agregarse a lo que ya se está procesando dentro de lo que sería normal. En el caso que nos afecta, los vuelos que no pudieron despacharse –Viva Aerobus canceló vuelos internacionales– deberán reprogramarse, afectando aviones y tripulaciones. Como nadie tiene aviones y pilotos sentados esperando por las dudas -más allá de las guardias, claro-, llevará un tiempo ir encontrando huecos para poner a andar esos vuelos cancelados.

Los días que vienen serán complejos, y quedarán demostradas nuevamente las dos máximas: en un mundo completamente interconectado, una falla distribuida rompe indefectiblemente todo aquello que dependa de lo que falló. Y ahora, viendo cómo las compañías despachan vuelos con tickets de embarque escritos de puño y letra, no queda otra que olvidarse de lo bonito para concentrarse en que quede andando.

 

from Aviacionline https://ift.tt/59o4jbP
via IFTTT