“A maioria das ferramentas de DR, mesmo o DRaaS, protege apenas fragmentos do patrimônio de TI”, disse Gogia. “Eles têm um escopo restrito para caber no orçamento ou na facilidade de implementação, não para garantir uma recuperação holística. Ambientes com uso intenso de nuvem pioram as coisas quando as equipes presumem que a resiliência está integrada, mas não configuraram caminhos de failover, replicados entre regiões ou cargas de trabalho validadas pós-failover. Iniciativas soberanas de nuvem podem abordar riscos geopolíticos, mas raramente abordam o realismo operacional.

“A maior falha nos testes de DR é a suposição de que infraestrutura é igual a serviço”, disse ele. “A maioria das empresas testa (se) os sistemas podem ser inicializados, os dados podem ser restaurados e os painéis permanecem verdes. Mas isso não é recuperação. É uma lista de verificação estática. Em um desastre real, os sistemas podem ficar on-line (mas) os usuários ainda não conseguem acessá-los. Loops de autenticação, tráfego incorreto, comunicação pouco clara e comportamento de pânico atrapalham. O que os testes deixam passar é a entropia criada quando 100.000 usuários agem com base em informações parciais e equipes internas se atrapalham em processos fragmentados.”

Os problemas com a maioria das estratégias de recuperação de desastres empresariais ficam ainda piores. Uma tática popular é aproveitar os hiperscaladores concorrentes com base no raciocínio de que, mesmo que, por exemplo, o Google falhe, quais são as chances de a Microsoft e a AWS também falharem ao mesmo tempo?