REL13-BP03 Testar a implementação da recuperação de desastres para validá-la
Teste regularmente o failover para o local de recuperação para verificar se a operação está correta e se o RTO e o RPO são cumpridos.
Práticas comuns que devem ser evitadas:
-
Nunca praticar failovers na produção.
Benefícios de implementar esta prática recomendada: testar regularmente seu plano de recuperação de desastres garantirá que ele funcione quando necessário e que sua equipe saiba como executar a estratégia.
Nível de risco exposto se esta prática recomendada não for estabelecida: Alto
Orientação para implementação
Um padrão que deve ser evitado é o desenvolvimento de caminhos de recuperação que raramente são executados. Por exemplo, você pode ter um datastore secundário utilizado para consultas somente leitura. Quando você grava em um datastore e o datastore primário falha, pode ser necessário fazer o failover para o repositório de dados secundário. Se você não testar esse failover com frequência, poderá descobrir que suas suposições sobre as capacidades do datastore secundário são incorretas. A capacidade do secundário, que talvez tenha sido suficiente quando testado pela última vez, pode não conseguir mais tolerar a carga nesse cenário. Nossa experiência mostrou que a única recuperação de erro que funciona é o caminho testado com frequência. É por isso que é melhor ter um pequeno número de caminhos de recuperação. Você pode estabelecer padrões de recuperação e testá-los regularmente. Se você tiver um caminho de recuperação complexo ou crítico, ainda precisará praticar regularmente essa falha na produção para se convencer de que o caminho de recuperação funciona. No exemplo que acabamos de discutir, você deve realizar o failover para o standby regularmente, não importa a necessidade.
Etapas de implementação
Projete suas workloads para recuperação. Teste regularmente seus caminhos de recuperação. A computação orientada para a recuperação identifica as características em sistemas que aprimoram a recuperação: isolamento e redundância, capacidade de reverter alterações em todo o sistema, capacidade de monitorar e determinar a integridade, capacidade de realizar diagnósticos, recuperação automatizada, design modular e capacidade de reinicialização. Pratique o caminho da recuperação para verificar se é possível realizá-la no tempo especificado para o estado determinado. Use seus runbooks durante essa recuperação para documentar problemas e encontrar soluções para eles antes do próximo teste.
Para workloads baseadas no Amazon EC2, use o AWS Elastic Disaster Recovery para implementar e lançar instâncias de simulação para sua estratégia de DR. A AWS Elastic Disaster Recovery fornece a capacidade de realizar exercícios com eficiência, o que ajuda você a se preparar para um evento de failover. Também é possível iniciar frequentemente as instâncias usando o Elastic Disaster Recovery para fins de teste e simulação sem redirecionar o tráfego.
Recursos
Documentos relacionados:
-
Parceiro da APN: parceiros que podem ajudar com a recuperação de desastres
-
Blog de arquitetura da AWS: série de recuperação de desastres
-
AWS Marketplace: produtos que podem ser usados para recuperação de desastres
-
Recuperação de desastres de workloads na AWS: recuperação na nuvem (whitepaper da AWS)
-
AWS Elastic Disaster Recovery: como se preparar para o failover
-
O projeto de computação orientado por recuperação de Berkeley/Stanford
Vídeos relacionados:
Exemplos relacionados:
