Editor Top
«La mayoría de las herramientas de recuperación ante desastres, incluso DRaaS, solo protegen fragmentos del patrimonio de TI», dijo Gogia. «Su alcance se ajusta estrictamente al presupuesto o a la facilidad de implementación, no para garantizar una recuperación integral. Los entornos con mucha nube empeoran las cosas cuando los equipos asumen que la resiliencia está incorporada, pero no han configurado rutas de conmutación por error, no se han replicado en todas las regiones ni se han validado cargas de trabajo posteriores a la conmutación por error. Las iniciativas de nube soberana pueden abordar el riesgo geopolítico, pero rara vez abordan el realismo operativo.
«El mayor defecto en las pruebas de recuperación ante desastres es la suposición de que infraestructura es igual a servicio», afirmó. “La mayoría de las empresas prueban [whether] los sistemas pueden arrancar, los datos se pueden restaurar y los paneles permanecen verdes. Pero eso no es recuperación. Es una lista de verificación estática. En un desastre real, los sistemas pueden entrar en línea [but] los usuarios aún no pueden acceder a ellos. Los bucles de autenticación, el tráfico desviado, la comunicación poco clara y el comportamiento de pánico se interponen en el camino. Lo que las pruebas pasan por alto es la entropía creada cuando 100.000 usuarios actúan sobre información parcial y los equipos internos luchan por procesos fragmentados”.
Los problemas con la mayoría de las estrategias empresariales de recuperación ante desastres empeoran aún más. Una táctica popular es aprovechar los hiperescaladores competidores con el argumento de que incluso si, por ejemplo, Google fracasa, ¿cuáles son las probabilidades de que Microsoft y AWS también fracasen al mismo tiempo?
