#Opinión: La cascada sobre el incidente de AWS
La madurez en la nube no se mide por cuántos servicios usamos, sino por cuán robustamente hemos planificado su inevitable fallo.
El reciente incidente de Amazon Web Services (AWS), ocurrido este 20 de octubre, que causó un apagón de servicios, entre ellos con caídas en videojuegos, redes sociales, servicios de banca y aerolíneas, no fue un simple fallo técnico, sino la materialización de un riesgo sistémico en la era del Hyperscale*.
Y para quienes lideran las organizaciones la pregunta relevante sobre el incidente no debe ser qué servicio específico falló, sino cómo puedo estar preparado ante un incidente similar en el futuro considerando que la mayoría de las soluciones para prevenir un incidente así están fuera de tu ámbito de influencia.
La gravedad del incidente no radicó en la falla original, sino en el «efecto cascada»: un efecto dominó que evidencia las profundas interdependencias arquitectónicas, no solo dentro de la infraestructura de AWS, sino en los complejos ecosistemas creados a su alrededor, y que pueden además generar escenarios donde lo que contractualmente son dos proveedores diferentes e inconexos, terminan al final representando un cúmulo de riesgo para tu empresa.
Análisis realizados a partir del informe sobre el incidente sugieren que el fallo inicial se agravó porque un problema en los sistemas de gestión afectó la capacidad de iniciar y solucionar otros servicios.
Esto se debió a dos condiciones principales: una de diseño, donde servicios esenciales dependían demasiado entre sí, haciendo que el sistema para arreglar el problema dependiera del sistema ya dañado; y otra de procedimiento, ya que no se pudo contener el incidente, sugiriendo una falla en los protocolos de contención que deberían limitar el impacto de un problema regional.
La ineficiencia de la resiliencia
Para los proveedores de nube, el reto es su propia arquitectura fundamental y concepción. En regiones maduras y con mayor densidad de servicios, empiezan a convivir innovaciones con servicios apalancados en un legado arquitectónico.
Es plausible que las interdependencias creadas hace años sean ahora prohibitivamente complejas de desacoplar. Insisto, esto es algo que puede estar presente en cualquier proveedor en la nube.
La clave del negocio Cloud es la eficiencia, y la resiliencia ante fallos es un concepto que encaja con dificultad allí. Este incidente nos hace recordar que es algo inevitable de abordar.
Desde una perspectiva estratégica, los proveedores de nube deben reinvertir en lo que podría llamarse «resiliencia ineficiente», es decir, arquitecturas para servicios críticos que estén tácitamente aisladas, incluso si esto implica duplicación de infraestructura, mayor latencia o menor eficiencia de costes.
La promesa de «Aislamiento de Fallos”, “Zonas de Disponibilidad” o sus equivalentes en otros proveedores es irrelevante si se permite la existencia de un punto único de fallo.
Crédito: Pixabay.
Confundir acceso con simplicidad
El incidente también nos pone a pensar sobre cómo la industria TI consume la nube. Existe una sensible diferencia entre la simplificación del acceso a la tecnología y la complejidad inherente de la misma.
Se combinan dos situaciones: adoptamos servicios PaaS y SaaS sin un análisis profundo de riesgos de sus modos de fallo subyacentes, asumiendo que la «alta disponibilidad» gestionada por el proveedor es una garantía absoluta; y sobre esta base, construimos nuestras propias arquitecturas complejas, como los microservicios.
Tenemos entonces una complejidad compuesta donde la fragilidad de nuestras propias arquitecturas de microservicios amplifica cualquier fallo parcial en la infraestructura cloud que usamos o la de los proveedores de servicios que también se apoyen en estas.
Haciendo una analogía, es como adquirir un kit DIY para ensamblar un osciloscopio digital, una tarea que antes requería un grupo de especialistas e infraestructura. Poder ensamblar el kit no nos convierte en expertos en electrónica ni diestros en su utilización, pero al hacerlo estamos adquiriendo inconscientemente sus complejidades.
El balance de riesgo/beneficio gestionado en las limitaciones
La dependencia de un Hyperscale es un hecho del mercado y plantear prescindir de ellos es algo difícil y poco rentable. Tampoco la solución es una multi-cloud que a menudo sólo multiplicará la complejidad.
El cambio debe ser en el enfoque de la gestión del riesgo interno a partir de esta realidad. La prevención total es utópica por ello tenemos que interiorizar que cuando tercerizamos la infraestructura, esa es una tarea que también delegamos al menos parcialmente. El enfoque debe moverse de la prevención a la resiliencia y la continuidad. Aquí algunos pasos:
– Reconocer la vulnerabilidad: El primer paso es abandonar la complacencia. El RTO (Recovery Time Objective) y RPO (Recovery Point Objective) de la organización deben ser re-evaluados urgentemente. ¿Son suficientes para asumir los riesgos de esta dependencia? Si la respuesta es no, debemos iniciar el proceso de «retomar el control», sea internalizando servicios críticos o rediseñando nuestra estrategia de resiliencia para una mayor autonomía. Pero seguramente nos encontremos con que el costo y los beneficios dejados en el camino nos inviten a evaluar otras alternativas.
– Rediseñar para el fallo parcial: El objetivo no es sobrevivir a un apocalipsis (o sí, depende de los líderes poner el límite) sino a un eventual fallo del proveedor. Esto implica implementar patrones como servicios degradados, interrupciones de circuitos o arquitecturas celulares, donde partes de la operación pueden fallar sin detener todo el negocio, estrategia que también cuesta encajar con la búsqueda de la integración total del negocio.
– Revitalizar el BCP: Este es un punto neurálgico. Durante años, muchas organizaciones han permitido que sus BCP se atrofien, bajo la asunción de “la tercerización incluye el BCP”, cuando en realidad dicha tercerización exige revaluar el plan y adaptarlo a este escenario, lo que además exige un conocimiento profundo de los terceros involucrados y sus relaciones. No es necesariamente una simplificación sino un cambio de enfoque.
Este incidente nos vuelve a recordar que el riesgo cero no existe y que el BCP requiere un enfoque más estratégico y dinámico que en el pasado. ¿Qué procesos manuales se activan? ¿Cómo opera el negocio en modo degradado? ¿Cómo se gestiona la comunicación con el cliente cuando las propias herramientas de comunicación dependen de la nube caída? Son todas preguntas viejas, cuyas respuestas deben pasar por el tamiz de este nuevo escenario.
Este incidente no revela la infiabilidad de la nube, sino la necesidad de una adopción responsable, evitando la fe ciega en la abstracción o ignorando el riesgo sistémico que subyace a su complejidad.
*Hyperscale (Hiperescala): Término que define la arquitectura y escala de operación de los mayores proveedores cloud (AWS, Azure, GCP), diseñada para escalar horizontalmente a millones de servidores y gestionar una demanda masiva y global.
*El autor es MBA Unimet y Licenciado en Computación UNE. Exsocio PwC Argentina y Venezuela, líder de las prácticas de Risk Assurance, Cybersecurity and Forensics Services.
Lea más contenido interesante y actual:
#Dato: Producción de carbón en Venezuela se ha recuperado en más de un 156%
Banca casi duplicó sus ingresos por cartera de créditos hasta 55,7% del flujo total en 12 meses
Somos uno de los principales portales de noticias en Venezuela para temas bancarios, económicos, financieros y de negocios, con más de 20 años en el mercado. Hemos sido y seguiremos siendo pioneros en la creación de contenidos, análisis inéditos e informes especiales. Nos hemos convertido en una fuente de referencia en el país y avanzamos paso a paso en América Latina.
