Testando DR sem impacto

Um plano de recuperação de desastre que nunca foi testado é apenas uma hipótese. A experiência do mundo real mostra que os planos de DR frequentemente revelam lacunas — alterações não controladas na configuração, automação ausente, runbooks desatualizados ou tempos de inicialização maiores que o esperado — que só aparecem em condições de teste. Os testes regulares de DR são a única forma de ter confiança de que seu plano funcionará quando você mais precisar dele.

Test Failover é um recurso integrado do Azure Recuperação de Site que permite simular um failover para a região secundária sem interromper a produção. Durante um Test Failover, o ASR cria cópias das VMs replicadas em uma rede virtual isolada na região secundária. As VMs de produção continuam funcionando normalmente na região primária, portanto não há risco para os usuários ativos.

A VNet de teste isolada não deve ter conectividade com os sistemas de produção. Isso impede que as VMs de teste gravem acidentalmente no banco de dados de produção, enviem e-mails para clientes reais ou acionem transações de pagamento. Crie uma VNet de failover de teste dedicada, sem emparelhamento com VNets de produção e sem acesso à Internet, e use-a exclusivamente para exercícios de DR.

Um teste de DR deve validar um conjunto específico de critérios:

• Tempo de inicialização — todas as VMs iniciam dentro da janela de tempo esperada?
• Inicialização da aplicação — a aplicação é inicializada corretamente quando conectada ao banco de dados recuperado?
• Integridade dos dados — os dados no ponto de recuperação estão consistentes e completos?
• RTO real — meça o tempo total decorrido desde o acionamento do failover até a aplicação começar a atender às solicitações
• Execução do runbook — todos os scripts de automação foram concluídos com sucesso?

Durante o teste, inicie um cronômetro no momento em que você acionar o Test Failover. Pare o cronômetro quando a aplicação for confirmada como íntegra (a investigação de integridade do balanceador de carga retornar 200 OK). Esse é o seu RTO real. Compare-o com o RTO de destino. Se o valor real exceder o destino, identifique os gargalos — inicialização lenta das VMs, inicialização demorada do banco de dados ou atraso na propagação do DNS — e resolva-os.

Após a conclusão do Test Failover, conecte-se ao banco de dados recuperado e verifique os dados. Confira se as transações confirmadas antes do limite da replicação estão presentes e se as transações parcialmente confirmadas foram tratadas corretamente (revertidas ou concluídas). Para bancos de dados com restauração pontual (PITR), teste a restauração para um timestamp específico e verifique o estado esperado dos dados.

Quando o teste for concluído, você deverá limpar os recursos do Test Failover — as VMs de teste, seus discos e as interfaces de rede na região secundária. O Azure Recuperação de Site fornece a ação 'Limpar Test Failover' no portal, que remove todos os recursos de teste automaticamente. Esquecer de fazer a limpeza desperdiça dinheiro e deixa a região secundária cheia de recursos obsoletos.

Após cada teste de DR, escreva um relatório de teste que inclua: a data e o escopo do teste, o RTO e o RPO reais alcançados, uma lista de verificação dos itens de validação com o status de aprovação ou reprovação, quaisquer lacunas ou falhas observadas e as ações corretivas planejadas. Esse relatório é valioso para auditorias de conformidade (ISO 27001, SOC 2, HIPAA) e para acompanhar a evolução da maturidade de DR ao longo do tempo.

As práticas recomendadas do setor e as estruturas de conformidade normalmente exigem testes de DR no mínimo anualmente, mas muitas organizações testam trimestralmente ou até mensalmente as cargas de trabalho de Nível 1. Testes mais frequentes detectam alterações não controladas na configuração mais cedo e aumentam a confiança e a familiaridade da equipe. Automatize o máximo possível da configuração e da verificação dos testes para reduzir o esforço necessário à realização frequente deles.

O Azure Chaos Studio é um serviço gerenciado de engenharia do caos que permite injetar falhas controladas nos recursos do Azure para testar a resiliência das aplicações. É possível desligar VMs, fazer uma zona falhar, limitar a CPU ou injetar latência de rede para observar o comportamento da aplicação. Diferentemente de um exercício padrão de DR, a engenharia do caos testa se a aplicação se degrada de maneira controlada em condições de falha parcial.

Os testes de DR são mais valiosos quando fazem parte de um ciclo de melhoria contínua: Planejar → Executar → Medir → Corrigir → Repetir. Após cada teste, resolva as lacunas encontradas, atualize os runbooks e a documentação e teste novamente. Com o tempo, a diferença entre as metas de RTO/RPO declaradas e os valores reais alcançados deve diminuir, até que você passe consistentemente em todos os testes dentro da tolerância.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentos (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que o failover de teste permite simular um evento de DR sem interromper a produção, criando cópias das VMs em uma VNet isolada; durante o teste, é necessário medir o RTO real e verificar a integridade dos dados; e você deve limpar os recursos de teste e documentar os resultados após cada exercício. A seguir, exploraremos a recuperação de desastre especificamente para serviços PaaS, como o Banco de Dados SQL do Azure.