Tenemos dos centros de datos. Dos enlaces de comunicaciones. Backups. Alta disponibilidad. Aplicaciones distribuidas en diferentes ambientes. Algunos servicios están en la nube y otros permanecen on-premise. Incluso existen proveedores alternativos para determinadas funciones críticas y tienen su PCN.

Sobre el papel, todo parece redundante, hasta que ocurre una interrupción y descubrimos algo que nadie había visto en el diagrama: las alternativas dependían de un mismo factor. La infraestructura estaba duplicada. La dependencia no. Y en ese momento aparece una de las lecciones más importantes de resiliencia tecnológica: tener dos no siempre significa tener una alternativa.

La redundancia nos puede dar una falsa sensación de seguridad

Durante años hemos diseñado arquitecturas bajo una lógica bastante razonable: evitar puntos únicos de falla, si un servidor falla, tenemos otro, si cae un enlace, existe uno alternativo, si perdemos el centro de datos principal, activamos el secundario, si un componente deja de funcionar, otro debería asumir su función.

El problema es que las arquitecturas tecnológicas actuales son mucho más interdependientes.

• Podemos tener dos aplicaciones completamente separadas que utilizan la misma base de datos.
• Dos centros de datos conectados mediante operadores diferentes que, en algún punto, comparten infraestructura.
• Dos proveedores contratados independientemente que funcionan sobre el mismo proveedor cloud.
• Dos ambientes perfectamente disponibles que dependen del mismo servicio de identidad.

Todo parece redundante hasta que un punto único de falla resalta lo que ambos tienen en común.

Los puntos únicos de falla ya no siempre son visibles

Antes era relativamente sencillo imaginar un Single Point of Failure (Punto Único de Falla)

• Un servidor.

• Un switch.

• Un enlace.

• Una base de datos.

Hoy puede estar escondido varias capas más abajo. Puede ser el servicio que autentica a los usuarios, un DNS, una API, un certificado digital, un repositorio de código, una herramienta de despliegue, un servicio administrado en la nube, una plataforma SaaS, una fuente de datos, una cuenta privilegiada. Incluso una persona que es la única que sabe cómo recuperar determinado componente.

Y aquí aparece una paradoja interesante.

Podemos tener una arquitectura distribuida geográficamente y seguir dependiendo de un único punto lógico. Si ese punto falla, probablemente nuestros servidores continúen encendidos, pero el servicio puede dejar de funcionar.

“Tenemos varios proveedores” tampoco garantiza diversificación

Una organización puede mirar su inventario y encontrar decenas o cientos de proveedores tecnológicos. Eso puede parecer diversificación, pero cuando comenzamos a investigar qué existe detrás de esos proveedores, la fotografía puede cambiar.

Supongamos que tenemos dos proveedores para un servicio crítico.

Proveedor A y Proveedor B.; Contratos distintos, Equipos diferentes, SLA independientes.

Hasta aquí parece una buena estrategia, pero después descubrimos que ambos utilizan la misma infraestructura cloud.

– el mismo proveedor de telecomunicaciones.

– la misma plataforma de identidad.

– el mismo servicio de protección.

Formalmente tenemos dos proveedores, pero operacionalmente seguimos teniendo una sola dependencia. Por eso, contar proveedores no es suficiente, necesitamos entender qué comparten.

La nube cambió el mapa, no eliminó el riesgo

La adopción de servicios cloud ha mejorado significativamente capacidades como escalabilidad, disponibilidad y recuperación, pero también ha creado nuevas formas de concentración:

• Una aplicación puede estar distribuida entre múltiples zonas y regiones y, aun así, depender de servicios comunes.

• Una organización puede utilizar varias soluciones SaaS y descubrir que buena parte de ellas funciona sobre la misma infraestructura.

• Puede incluso adoptar una estrategia multi-cloud y continuar utilizando un único proveedor de identidad, seguridad o conectividad.

La pregunta entonces deja de ser ¿Cuántas nubes tenemos? Y pasa a ser ¿Qué dependencia podría afectar simultáneamente varias de ellas?

Esa pregunta suele producir respuestas mucho más interesantes.

El riesgo también está detrás de nuestros proveedores

Cuando analizamos resiliencia tecnológica solemos mirar nuestros sistemas y nuestros proveedores directos, pero la cadena continúa. Nuestro proveedor también tiene proveedores y esos proveedores pueden tener otros.

No necesitamos conocer cada empresa de toda la cadena tecnológica. Sería poco práctico. Lo que sí necesitamos conocer son aquellas dependencias cuya falla podría afectarnos materialmente, especialmente cuando varias soluciones críticas convergen sobre la misma infraestructura.

Imagine que cinco proveedores diferentes utilizados por el banco dependen de una misma plataforma tecnológica. El día que esa plataforma tenga una interrupción importante, probablemente descubriremos que nuestra diversificación era menor de lo que creíamos.

El factor de riesgo no estaba en el contrato. Estaba en la concentración que existía detrás de ellos.

Quizás necesitamos otro tipo de mapa

Los diagramas de arquitectura suelen mostrar cómo están conectados los componentes. Para la resiliencia necesitamos agregar otra dimensión; qué puede hacerlos fallar juntos.

Tomemos un servicio crítico, por ejemplo pagos digitales. Mapeamos canales, autenticación, procesamiento, bases de datos, APIs, telecomunicaciones, cloud, ciberseguridad, proveedores, personas. Después comenzamos a conectar dependencias.

Probablemente aparecerán algunos nodos con muchas dependencias:

• Un proveedor.

• Una plataforma.

• Un servicio de identidad.

• Una base de datos.

• Una API.

• Una persona.

Esos nodos merecen especial atención, no porque estén fallando hoy, sino porque si algún día fallan, demasiadas cosas pueden fallar al mismo tiempo.

Tener alta disponibilidad tampoco significa poder recuperarse de todo

Hay otra confusión frecuente. Una plataforma puede tener una disponibilidad extraordinaria y aun así no estar preparada para determinados escenarios.

La alta disponibilidad funciona muy bien frente a ciertas fallas técnicas, pero pensemos en algo diferente.

• Una configuración incorrecta se replica automáticamente.

• Datos corruptos se propagan entre ambientes.

• Credenciales privilegiadas son comprometidas.

• Un ransomware afecta producción y comienza a alcanzar repositorios conectados.

• Un despliegue defectuoso llega simultáneamente a varios nodos.

En esos casos, la capacidad de replicar rápidamente puede convertirse incluso en parte del problema, por eso, resiliencia tecnológica no consiste solamente en mantener disponible la infraestructura. También significa poder aislar, contener, reconstruir, validar y recuperar.

“Está arriba” ya no es suficiente

Imagine el momento posterior a un ciberincidente. El equipo tecnológico informa «Infraestructura disponible». Pero todavía faltan algunas preguntas.

¿Podemos confiar en los datos?

¿Las credenciales son seguras?

¿Estamos seguros de que el atacante ya no mantiene persistencia?

¿La configuración recuperada es confiable?

¿Los backups utilizados están limpios?

¿Podemos comenzar nuevamente a procesar transacciones?

Aquí aparece una distinción fundamental: disponibilidad no es lo mismo que confianza. Un sistema puede estar técnicamente disponible y continuar siendo operacionalmente inutilizable. La organización no necesita solamente recuperar tecnología, necesita recuperar tecnología confiable.

Los simulacros también deberían cambiar

Si nuestras pruebas siempre comienzan diciendo:

“El centro de datos principal quedó indisponible. Active el alterno.”

probablemente estamos probando una parte limitada del problema, podríamos probar algo diferente:

• El centro de datos está disponible, pero falla el servicio de identidad.

• El proveedor principal funciona, pero una dependencia compartida con el proveedor alternativo está caída.

• El backup existe, pero no podemos asegurar su integridad.

• La infraestructura está disponible, pero las credenciales privilegiadas han sido comprometidas.

• La configuración defectuosa ya se replicó al ambiente alterno.

• Dos proveedores críticos dejan de responder simultáneamente porque ambos dependen de la misma plataforma.

Estos escenarios son incómodos, precisamente por eso son útiles. Nos obligan a comprobar si tenemos alternativas realmente independientes o simplemente versiones diferentes de la misma dependencia.

Los indicadores también deberían contar otra historia

Seguiremos necesitando disponibilidad, incidentes, RTO y RPO.

Pero podríamos incorporar otras preguntas al tablero:

• ¿Cuántos servicios críticos tienen puntos únicos de falla?

• ¿Cuántos dependen del mismo proveedor tecnológico?

• ¿Cuántas aplicaciones críticas utilizan una única plataforma de identidad?

• ¿Cuántas alternativas comparten infraestructura?

• ¿Cuándo fue la última recuperación completa desde un entorno confiable?

• ¿Cuántos backups críticos han sido realmente restaurados y validados?

• ¿Qué servicios no tienen una alternativa viable?

• ¿Cuánto tiempo podemos operar de forma degradada?

Estas preguntas cambian la conversación, ya no estamos preguntando solamente “¿Está funcionando?”

Estamos preguntando: “¿Qué ocurriría si mañana deja de funcionar?”

Una pregunta que vale la pena llevar al Comité de Continuidad

En la próxima reunión con Tecnología, Riesgos o Continuidad podríamos colocar el mapa de servicios críticos sobre la mesa y hacer una sola pregunta:

¿Qué componente, proveedor o dependencia podría afectar simultáneamente varias de nuestras alternativas de recuperación?

Tal vez la respuesta sea evidente. Tal vez nadie la tenga. Ambas situaciones son útiles. Porque muchas veces el mayor riesgo tecnológico no está en aquello que aparece permanentemente en rojo. Está en un componente silencioso que lleva años funcionando correctamente y del cual, sin darnos cuenta, depende prácticamente todo.

Reflexión final

Dos centros de datos son mejores que uno, dos enlaces pueden ser mejores que uno. Tener backups es indispensable, la nube puede proporcionar capacidades extraordinarias de disponibilidad y recuperación.

La redundancia sigue siendo necesaria, pero no debemos confundirla con resiliencia.

Podemos tener dos centros de datos, tres nubes, múltiples proveedores y cientos de controles tecnológicos y continuar dependiendo de un único servicio que nadie consideró crítico.

Por eso, quizás la próxima revisión de arquitectura debería comenzar con una pregunta diferente.

Decir “¿Qué tenemos duplicado?” Sino preguntar “¿Qué puede hacer que nuestras alternativas fallen juntas?” Ahí suele aparecer el verdadero mapa de resiliencia tecnológica.

Porque la redundancia nos da alternativas. La resiliencia exige comprobar que esas alternativas realmente sean independientes cuando más las necesitemos.