Qué hace un tipo de sistemas cuando se le cae todo el sistema

Nuestra dependencia de la tecnología es más fuerte que nunca, y eso tiene sus consecuencias: cuando los servicios dejan de funcionar -y todos ellos dejan de hacerlo tarde o temprano- llega el caos. El impacto que tiene que nos quedemos sin Gmail o sin WhatsApp es enorme, pero lo mismo ocurre -si es que el impacto no es mayor- cuando los que se caen son los servidores de Amazon o de Microsoft.

¿Cómo es posible que empresas de esta magnitud puedan tener fallos así? Evidentemente todas ellas cuentan con intrincadas infraestructuras en las que temas como la redundancia y la alta disponibilidad son recurrentes. Y aún así, siempre hay algo que acaba fallando. ¿Cómo tratan de evitar esas caídas esas empresas, y cómo actúan cuando estas se producen a pesar de todo?

Creednos: que se caiga WhatsApp no es el problema

Lo cierto es que los fallos son más comunes de lo que cualquiera de nosotros podría imaginar. En IEEE Spectrum llevan más de una década haciendo un seguimiento de todos esos fallos que se dan en todo tipo de sistemas informáticos, y tras ese tiempo publicaban el año pasado una extensa serie de reportajes en las que trataban de ofrecer conclusiones sobre todos esos fallos.

Una de esas conclusiones, por ejemplo, es la enorme cantidad de dinero que cuestan esos proyectos que fallan o que incluso no llegan a implantarse tras una enorme inversión.

El Departamento de Defensa de los Estados Unidos invirtió 1.000 millones de dólares y 12 años de desarrollo en un sistema de recursos humanos para su ejército (aquí el PDF), pero mucho más dantesco fue el gasto de 18.000 millones de dólares por parte del ejército de los EE.UU. en un Future Combat System (FCS) que trataba de modernizar sus sistemas y que acabó cancelándose al detectarse que el gasto iba a dispararse a más de 200.000 millones de dólares

Las conclusiones de IEEE Spectrum tras esa década eran claras: "los sistemas IT están volviéndose cada vez más complejos y grandes (en términos de datos capturados, almacenados y manipulados), lo que significa que no solo están volviéndose cada vez más difíciles y costosos de desarrollar, sino también más complicados de gestionar". La complejidad de esos sistemas también se debe a otra de las grandes condenas de la tecnología: su incesante evolución y mejora:

Durante la pasada década hemos visto grandes esfuerzos de modernización de las TIC en las industrias financiera, bancaria, aeronáutica y especialmente en el gobierno, generalmente orientada a sustituir sistemas TIC antiguos que se implantaron en los 80 y 90, si es que no lo hicieron antes. Muchos de estos esfuerzos buscaban sustituir múltiples sistemas TIC dispares con un único sistema, lo que tradicionalmente ha demostrado ser mucho más difícil tanto a nivel técnico como de gestión, además de mucho más caro de lo que se imaginaba.

Los fantásticos documentos infográficos que nos deja el análisis de IEEE Spectrum van más allá de los fallos de los que hablábamos al inicio de este reportaje: nosotros nos quejamos de que WhatsApp se nos cae o de que de repente no podemos acceder a nuestro correo en Gmail, pero esos problemas son casi anecdóticos cuando hablamos de infraestructuras de las que sí dependen nuestras vidas como las redes eléctricas, de transporte -un ligero problema en un aeropuerto puede tener consecuencias catastróficas- o todo aquello que afecta al sector sanitario.

No solo hay que protegerse de los ciberataques

El 27 de agosto de 2013 China dejó de tener acceso a internet durante cuatro horas. El problema no fue (solo) un error humano: fue uno de los ataques de denegación de servicio más importantes de toda la historia "digital" de ese país. Evidentemente uno de los apartados más importantes de la infraestructura tecnológica de toda empresa es esa protección frente a ciberataques.

Muchas son las medidas que los administradores de sistemas ponen para evitar este tipo de problemas, pero lo cierto es que los casos de robo de contraseñas y datos sensibles es cada vez más frecuente en todo tipo de servicios. La seguridad de cualquier sistema es tan fuerte como su eslabón más débil, dicen, y esa es una verdad absoluta en este segmento en el que cualquier debilidad puede ser detectada y explotada por parte de los ciberatacantes si tienen suficiente motivación y paciencia.

Incluso en esos casos, como veremos más adelante, no siempre se nos ofrece una explicación especialmente detallada de lo que ocurrió. La explicación de por qué un hacker o un cracker ha logrado acceso a ciertos sistemas a menudo proviene de otros expertos, no de las empresas que sufrieron esos ataques: reconocer errores y explicarlos no suele dar muy buena prensa al público en general y a los clientes en particular, pero es algo que los expertos de la comunidad de seguridad informática tratan de animar a hacer de forma abierta.

Los ejemplos son numerosos, y hay fantásticas recopilaciones de esos grandes robos de datos como el que realizaron en Information is Beautiful. Allí es posible obtener más datos sobre los 164 millones de contraseñas robadas a MySpace, los 145 millones de eBay o el mucho más impactante caso de Mossack Fonseca, y en todos ellos se comprueba cómo esas intrusiones se debieron a ataques que casi siempre aprovecharon despistes de quienes gestionaban esos sistemas.

En el caso de Mossack Fonseca el error fue usar una versión antigua de Drupal y un plugin no actualizado de WordPress en dos de sus sitios web: algo tan aparentemente trivial como una actualización de ambas plataformas hubiera evitado un escándalo que ha salpicado a miles de empresas y particulares. En realidad es tan solo un ejemplo -muy llamativo, eso sí- de una situación cada vez más frecuente. En el segmento de la seguridad informática hay ya un viejo dicho: hay dos tipos de empresas, las que han sido hackeadas y las que lo han sido pero todavía no lo no saben.

Defenderse de esos ciberataques es uno de los problemas serios a los que deben enfrentarse estos expertos, que establecen todo tipo de medidas para tratar de salvarse de los temibles ataques de denegación de servicio -si son lo suficientemente grandes, difícil evadirlos- o el aprovechamiento de vulnerabilidades que es muy difícil controlar con el detalle necesario. Sin embargo esa es solo una parte de la ecuación, y las empresas también deben afrontar riesgos como los que provocan los desastres naturales -Amazon lo sabe bien- y los omnipresentes errores y descuidos humanos.

Lo que sí han hecho muchas empresas con servicios en la nube es tratar de informar del estado de esos servicios para que los usuarios al menos puedan verificar que hay o no problemas en realidad. En algunos casos contamos con paneles de estado separados totalmente de esos servicios que nos informan de su estado -Amazon es un buen ejemplo, pero en Google también ofrecen esa información-, e incluso hay "metapaneles" como DownDetector o IsItDownRightNow que agrupan la información de un buen número de servicios, algo que se une a la información que algunas empresas ofrecen por ejemplo vía Twitter.

Secretismo: quien calla no otorga

Cuando iniciamos el proceso de elaboración de este reportaje nos enfrentamos a una realidad contundente: las empresas no hablan abiertamente de estos temas, y no lo hacen porque son altamente confidenciales. Todd Hoff, responsable de High Scalability -uno de los blogs de referencia en este ámbito- nos explicaba cómo "es un tema muy duro en el que lograr información: gran parte de ella es la 'salsa secreta' de esas empresas, y las implicaciones de seguridad son enormes".

Pongamos de ejemplo a Microsoft, una de las empresas tecnológicas más importantes del mundo, y una de las que tiene una infraestructura más compleja. Sus responsables no podían darnos datos concretos, y trataron de ofrecernos una perspectiva general que nos ofrece una visión de la complejidad de estos sistemas. Entre los datos clave:

Microsoft cuenta con más de 100 centros de datos en más de 40 países. Las localizaciones de esos centros de datos no son públicas para "garantizar una alta seguridad para los datos de nuestros clientes". En esos centros de datos se ofrecen más de 200 servicios en la nube que utilizan "más de 1.000 millones de clientes en 90 mercados [...] Los centros de datos de Microsoft se han implantado para ofrecer el 99,999% de disponibilidad para satisfacer las necesidades de servicio y SLA de nuestros clientes".

La empresa de Redmond gestiona esos servicios a través del Microsoft Operations Center (MOC), y cuenta con instalaciones para "levantar" todos sus servicios en California, Redmond y en la India "para proporcionar disponibilidad instantánea de la continuidad de los servicios georeplicaos en caso de desastres naturales o calamidades". Tenemos más datos en el sitio web informativo de Microsoft, pero la realidad es que los detalles clave son muy limitados. Son, como nos decía Hoff, la salsa secreta de su capacidad operativa en la nube.

Esa realidad presentada por Microsoft se extiende al resto de empresas, pero además suele ocurrir que cuando caen los sistemas de alguna empresa la información sobre esas caídas y sus soluciones es limitada. Esta es una queja constante de los expertos de IEEE Spectrum, que criticaban la ausencia de "post-mortems", los datos que permiten hacer "autopsias públicas" de lo ocurrido y analizar cuál fue el detonante del problema.

En GitHub, por ejemplo, tenemos una compilación de algunos de esos análisis internos de fallos que empresas tecnológicas sufrieron en los últimos años. Afortunadamente aquí sí encontramos esas autopsias que permiten conocer cuál fue el problema. Es curioso comprobar cómo a menudo esos fallos son simples errores de configuración que no se detectaron durante su implantación y que luego costó encontrar más de lo esperado.

Open Compute Project, un buen paso de un largo camino

Es cierto que algunas empresas comparten información cada vez más interesante y liberan tanto esos datos como proyectos que son claves para su infraestructura. Tanto la citada Microsoft como Google o Facebook comparten cada vez más y mejor, y precisamente el caso de Facebook es especialmente destacable porque la empresa de Mark Zuckerberg es la responsable del llamado Open Compute Project (OCP).

Esta iniciativa comparte diseños de productos de centros de datos y que trata de comunicar buenas prácticas y todo tipo de claves para que todo tipo de empresas puedan acceder a soluciones escalables, altamente eficientes y altamente disponibles. Facebook hace uso de centros de datos que son "certificables" por la OCP al 100%, y a ese esfuerzo se han unido Intel, Google, Apple, Microsoft, Rackspace, Ericsson, Cisco, Juniper Networks, Goldman Sachs, Fidelity, Lenovo y el Bank of America.

Eso no parece ser suficiente, claro. Hay críticas claras a un proyecto que según algunos expertos ha creado fragmentación en la industria -favoreciendo unos estándares frente a otros- y que ha hecho que los vendedores de hardware con esa "certificación OCP" tengan una capacidad limitada y dirigida sobre todo a grandes empresas con equipos de ingenieros propios.

También se ha criticado ese proceso de certificación, y parece que aún quedan muchos flecos por resolver como los que están dedicados a la integridad de los datos. El proyecto sigue avanzando, desde luego, y aunque hay ya beneficios patentes -la industria necesita estándares fiables, y OCP está tratando de proporcionarlos- es evidente que hay mucho camino por recorrer.