É só virar a chave — Falsas Certezas da TI

“É só virar a chave.” A frase vem com gesto de mão, como se existisse um interruptor na parede. Eu entendo de onde vem: alguém vendeu um ambiente de recuperação de desastre, mostrou um diagrama bonito com duas nuvens e uma seta, e a sensação que ficou foi de interruptor.

Mas DR não é interruptor. É um procedimento com dezenas de passos, executado sob pressão, por pessoas que raramente treinaram.

O que “virar a chave” realmente envolve

Subir os servidores replicados. Confirmar que o banco de dados está consistente. Apontar o DNS. Reconfigurar VPN e acessos. Validar integrações com sistemas de terceiros. Avisar os usuários sobre o novo endereço. Descobrir que uma licença está presa ao hardware antigo. Cada um desses passos é um lugar onde a chave emperra, e nenhum deles aparece no diagrama.

O teste do gerador

O gerador tem transferência automática, e mesmo assim é testado com carga real, porque a transferência automática é o componente que mais falha. Com DR, a lógica é idêntica: quanto mais automatizado parece, mais importante é ativar de verdade e cronometrar. A ativação de teste é a única forma de descobrir se o RTO de 2 horas do contrato é um RTO de 2 horas ou de 2 dias.

Os dois números que importam

RTO: em quanto tempo a empresa voltou a operar. RPO: quanto dado se perdeu no caminho. Os dois aparecem em toda proposta de DR e quase nunca aparecem em um relatório de teste. Pergunte os medidos, não os prometidos. Depois compare com o que o negócio aguenta, sistema por sistema. É comum descobrir que o ERP tem RTO de 8 horas num negócio que para em 2.

DR e continuidade são irmãos, não gêmeos

A certeza anterior da série trata do plano de continuidade: pessoas e processo. Esta trata da tecnologia. Uma empresa pode ter DR perfeito e ninguém saber a quem ligar, ou ter um plano impecável e nenhum servidor para voltar. Os dois precisam de teste, e de preferência no mesmo simulado.

A evidência que você deveria exigir

Uma pergunta, três respostas: quando a chave foi virada pela última vez em teste, quanto tempo levou e quanto dado se perdeu. Se as três vierem com números, o DR existe. Se vier “está tudo replicado”, você tem uma cópia dos dados em outro lugar, o que é bom e é só o começo.

O que pedir na próxima reunião

Quatro evidências. Não é desconfiança: é o mesmo critério que você já aplica ao gerador de energia.

Registro da última ativação de teste do DR: data, sistemas ativados, tempo até operação (RTO medido) e perda de dados (RPO medido)

Comparação entre o RTO e RPO medidos e o que o negócio aguenta, sistema por sistema

Quem tem acesso e sabe executar a ativação, e se essa pessoa foi quem fez o último teste

O que o DR não cobre: sistemas, integrações, licenças e DNS que precisam de ação manual

Perguntas frequentes

O que são RTO e RPO?

RTO é o tempo que a empresa leva para voltar a operar depois de um desastre. RPO é a quantidade de dados que se perde, medida em tempo: um RPO de 4 horas significa que o que foi feito nas últimas 4 horas antes do incidente não volta. Os dois só têm valor quando medidos num teste, não quando prometidos num contrato.

Com que frequência o DR deve ser ativado em teste?

Ao menos uma vez por ano de forma completa, e sempre que houver mudança relevante no ambiente: novo sistema crítico, troca de servidor, migração. Ambientes que mudaram e não foram retestados têm um DR da versão anterior da empresa.

Replicação para a nuvem é DR?

Replicação é a parte dos dados. DR é dados mais sistemas funcionando, mais rede, mais DNS, mais acesso dos usuários, mais alguém que sabe acionar tudo isso. Replicação sem ativação testada resolve metade do problema e deixa a sensação de ter resolvido tudo.

É só virar a chave: o que essa certeza esconde e a evidência que você deveria exigir