Quase todo plano de recuperação de desastre que analisamos tem backup funcionando. E quase todo teste de recuperação que conduzimos falha na primeira tentativa — não por falta de dado, mas por uma dependência que ninguém tinha mapeado. O certificado que só existia no servidor que morreu. O serviço de autenticação que precisava subir antes de tudo e ninguém sabia. O runbook guardado no sistema que estava fora. Backup é o pré-requisito; o plano é outro trabalho.

O inventário de dependências é o passo que ninguém faz

Pergunte a qualquer equipe o que a aplicação principal precisa para funcionar, e a resposta inicial vai citar o servidor de aplicação e o banco de dados. A lista real é bem mais longa, e cada item ausente é uma parada durante a recuperação:

• Resolução de nomes. Quem controla o DNS? Qual é o TTL dos registros? Se você não consegue alterar o DNS rapidamente, não consegue redirecionar tráfego.
• Certificados. Onde está a chave privada? Se ela só existe no servidor perdido, você vai emitir certificado novo sob pressão, com o domínio possivelmente inacessível para a validação.
• Autenticação. Provedor de identidade próprio ou de terceiro? Se for próprio, ele precisa subir antes de tudo — e é frequentemente esquecido na ordem.
• Segredos. Se estão em um cofre, o cofre está no plano? Como você o inicializa no site novo?
• Serviços externos. Gateway de pagamento, envio de e-mail, integração fiscal, API de parceiro. Muitos exigem liberação de endereço de origem — e o endereço vai mudar.
• Licenças que se validam contra hardware ou endereço.
• Registro de imagens ou repositório de artefatos, sem o qual você não consegue implantar.
• O próprio runbook, que não pode estar apenas no sistema que caiu.

Esse levantamento leva algumas horas e é, sozinho, a atividade de maior retorno de todo o processo. Ele encontra dependência crítica que ninguém sabia que existia.

Classifique por criticidade, não trate tudo igual

Proteger tudo com o mesmo rigor é caro e, paradoxalmente, deixa o essencial menos protegido — porque o esforço se dilui. A classificação em camadas resolve:

A conversa que define isso não é técnica: é com quem responde pelo negócio. Pergunte quanto custa uma hora de indisponibilidade de cada serviço, e a classificação se resolve quase sozinha. Sem esse número, toda discussão sobre investimento em recuperação fica abstrata e termina em "o mais barato possível".

Um alerta de escopo: a camada 1 deve ser pequena. Se metade dos serviços é crítica, a classificação não foi feita — foi evitada.

A ordem de recuperação importa mais do que parece

Serviços têm dependências entre si, e subir na ordem errada gera falhas que parecem problemas novos. A sequência que costuma funcionar:

1. Rede e resolução de nomes, sem o que nada se encontra.
2. Cofre de segredos e autenticação, dos quais todo o resto depende para iniciar.
3. Bancos de dados e armazenamento, verificando a consistência antes de liberar acesso.
4. Serviços de mensageria e fila, antes dos consumidores.
5. Aplicações, na ordem das dependências entre elas.
6. Trabalhos agendados, deliberadamente por último — e aqui um cuidado específico: tarefas que não rodaram durante a indisponibilidade podem tentar rodar todas de uma vez ao voltar, gerando cobrança duplicada ou avalanche de e-mail. Decida antes o que deve ser suprimido.
7. Redirecionamento do tráfego, só depois de validar a pilha completa.

Quem decide, e com base em quê

O tempo perdido no início de um incidente grave raramente é técnico — é de decisão. Sem critério definido, a primeira hora é consumida discutindo se já é hora de ativar o plano.

Combine antes, por escrito:

• Quem tem autoridade para declarar o desastre e acionar a recuperação, com um substituto nomeado.
• O critério objetivo que dispara a decisão. Algo como "indisponibilidade total acima de trinta minutos sem causa identificada". Critério objetivo evita a paralisia de esperar mais um pouco.
• Quem comunica clientes e equipe, e por qual canal. E aqui um detalhe: o canal de comunicação não pode depender da infraestrutura que caiu. Página de status hospedada na mesma infraestrutura é inútil exatamente quando é necessária.
• Quem decide voltar ao ambiente original, que é uma decisão distinta e normalmente mais delicada que a de sair.

O teste é o que separa plano de esperança

Plano não testado é um documento com hipóteses. Existem três níveis de teste, com custos bem diferentes, e todos têm valor:

• Mesa. A equipe reunida percorre o plano verbalmente diante de um cenário. Custa duas horas e encontra uma quantidade surpreendente de furos — dependência ausente, contato desatualizado, passo ambíguo. É o melhor primeiro teste.
• Restauração parcial. Restaurar de fato os serviços da camada 1 em ambiente isolado e verificar que funcionam. Custa um dia e prova que o backup é restaurável.
• Exercício completo. Simular a perda do ambiente principal e operar no secundário por um período. Custa caro, exige preparação e é o único que valida o plano de ponta a ponta, incluindo o retorno.

Uma cadência realista: mesa a cada trimestre, restauração parcial a cada semestre, exercício completo uma vez por ano ou depois de mudança arquitetural relevante.

O que os testes sempre encontram

A lista abaixo é notavelmente repetitiva entre clientes muito diferentes. Se você quiser ganhar tempo, verifique estes itens antes do primeiro teste:

• TTL de DNS longo, impedindo redirecionamento rápido.
• Certificado ou chave privada que existe em um lugar só.
• Endereço de origem cadastrado em serviço externo que não vale para o site secundário.
• Documentação do plano armazenada apenas no ambiente que cai.
• Credencial de acesso ao backup guardada dentro do ambiente perdido.
• Dependência de máquina de alguém — script que só roda no computador de um integrante da equipe.
• Ordem de subida que ninguém tinha escrito, descoberta por tentativa e erro.
• Contato desatualizado de fornecedor crítico.
• Backup restaurável, mas lento demais para o RTO prometido. Descobrir que a restauração leva doze horas quando a meta era duas é um achado comum e valioso.

Documente para quem vai executar sob pressão

O plano será usado por alguém cansado, à noite, possivelmente sem quem o escreveu. Isso impõe um formato:

• Passos concretos, com comandos exatos, não descrições de intenção.
• Ponto de verificação em cada etapa: como saber que funcionou antes de seguir.
• Fora do ambiente protegido: cópia impressa, em outro provedor, em repositório separado. Mais de um lugar.
• Versão com data e responsável, revisada depois de cada mudança relevante e depois de cada teste.

Depois do teste, a correção dos achados é a parte que costuma ser esquecida — e é a que faz o exercício valer. Teste que encontra oito problemas e corrige zero foi uma manhã perdida.

Erros comuns

• Ter backup e chamar isso de plano de recuperação.
• Nunca mapear as dependências além de aplicação e banco.
• Classificar quase tudo como crítico.
• Definir RTO e RPO sem conversar com quem responde pelo negócio.
• Nenhum critério objetivo para declarar o desastre.
• Página de status na mesma infraestrutura que cai.
• Runbook guardado só no ambiente protegido.
• Tarefas agendadas subindo todas de uma vez após a volta.
• Nunca ter medido o tempo real de restauração.
• Testar e não corrigir o que o teste encontrou.

Onde a Solvefy/Cloud entra

Conduzimos esse processo do início: levantamos o inventário de dependências, classificamos os serviços junto com quem responde pelo negócio, definimos RTO e RPO por camada, escrevemos o runbook no formato de quem vai executar sob pressão e facilitamos os testes — começando pelo exercício de mesa, que é rápido e revela muito. Depois, acompanhamos a correção dos achados, que é onde o valor se realiza. Também revisamos planos existentes, e o primeiro teste costuma ser esclarecedor.

Quer saber se o seu plano de recuperação sobrevive a um teste? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.