Recomendações para criar uma estratégia de recuperação de desastre
Aplica-se a esta recomendação de lista de verificação de confiabilidade do Azure Well-Architected Framework:
| RE:09 | Implemente planos de BCDR (continuidade de negócios e recuperação de desastres) estruturados, testados e documentados que se alinham com as metas de recuperação. Os planos devem abranger todos os componentes e o sistema como um todo. |
|---|
Este guia descreve as recomendações para criar uma estratégia de recuperação de desastre confiável para uma carga de trabalho. Para atender aos SLOs (objetivos internos de nível de serviço) ou até mesmo a um SLA (contrato de nível de serviço) garantido para seus clientes, você deve ter uma estratégia de recuperação de desastre robusta e confiável. Falhas e outros problemas principais são esperados. Seus preparativos para lidar com esses incidentes determinam quanto seus clientes podem confiar em sua empresa para entregar de forma confiável para eles. Uma estratégia de recuperação de desastre é a espinha dorsal da preparação para incidentes importantes.
Definições
| Termo | Definição |
|---|---|
| Failover | A mudança automatizada e/ou manual do tráfego de carga de trabalho de produção de uma região indisponível para uma região geográfica não afetada. |
| Failback | A mudança automatizada e/ou manual do tráfego de carga de trabalho de produção de uma região de failover de volta para a região primária. |
Principais estratégias de design
Este guia pressupõe que você já realizou as seguintes tarefas como parte do planejamento de confiabilidade:
Identificar fluxos críticos e não críticos.
Execute a FMA (análise de modo de falha) para seus fluxos.
Identificar destinos de confiabilidade.
Projetar para confiabilidade por meio de redundância, dimensionamento, autopreservação e autorrecuperação.
Crie uma estratégia de teste robusta.
Uma estratégia confiável de recuperação de desastre (DR) baseia-se na base de uma arquitetura de carga de trabalho confiável. Resolva a confiabilidade em cada estágio da criação de sua carga de trabalho para garantir que as partes necessárias para a recuperação otimizada estejam em vigor antes de começar a projetar sua estratégia de recuperação de desastre. Essa base garante que as metas de confiabilidade da carga de trabalho, como RTO (objetivo de tempo de recuperação) e RPO (objetivo de ponto de recuperação), sejam realistas e alcançáveis.
Manter um plano de recuperação de desastre
A base de uma estratégia de DR confiável para uma carga de trabalho é o plano de recuperação de desastre. Seu plano deve ser um documento em vida que é rotineiramente revisado e atualizado à medida que seu ambiente evolui. Apresente o plano às equipes apropriadas (operações, liderança tecnológica e stakeholders de negócios) regularmente (a cada seis meses, por exemplo). Armazene-o em um armazenamento de dados seguro altamente disponível, como OneDrive for Business.
Siga estas recomendações para desenvolver seu plano de recuperação de desastre:
Defina claramente o que constitui um desastre e, portanto, requer ativação do plano de recuperação de desastre.
Desastres são problemas de grande escala. Podem ser interrupções regionais, interrupções de serviços como Microsoft Entra ID ou DNS do Azure ou ataques mal-intencionados graves, como ataques de ransomware ou ataques de DDoS.
Identifique os modos de falha que não são considerados desastres, como a falha de um único recurso, para que os operadores não invoquem erroneamente seus escalonamentos de DR.
Crie o plano de recuperação de desastre na documentação do FMA. Verifique se o plano de recuperação de desastre captura os modos de falha e as estratégias de mitigação para interrupções definidas como desastres. Atualize o plano de recuperação de desastre e os documentos do FMA em paralelo para que eles sejam precisos quando o ambiente for alterado ou quando o teste descobrir comportamentos inesperados.
- Se você desenvolve planos de recuperação de desastre para ambientes de não produção depende de seus requisitos de negócios e impactos de custo. Por exemplo, se você oferecer ambientes de garantia de qualidade (QA) a determinados clientes para testes de pré-lançamento, talvez você queira incluir esses ambientes em seu planejamento de recuperação de desastre.
Defina claramente funções e responsabilidades dentro da equipe de carga de trabalho e entenda todas as funções externas relacionadas em sua organização. As funções devem incluir:
A parte responsável por declarar um desastre.
A parte responsável por declarar o encerramento do incidente.
Funções de operações.
Funções de teste e validação.
Funções de comunicação internas e externas.
Funções principais de RCA (análise de causa raiz e retrospectiva).
Defina os caminhos de escalonamento que a equipe de carga de trabalho deve seguir para garantir que a status de recuperação seja comunicada aos stakeholders.
Capture procedimentos de recuperação no nível do componente, recuperação em nível de propriedade de dados e processos de recuperação em toda a carga de trabalho. Inclua uma ordem de operações prescrita para garantir que os componentes sejam recuperados da maneira menos impactante. Por exemplo, recupere e marcar bancos de dados antes de recuperar o aplicativo.
Detalhe cada procedimento de recuperação no nível do componente como um guia passo a passo. Inclua capturas de tela, se possível.
Defina as responsabilidades da sua equipe em relação às responsabilidades do provedor de hospedagem na nuvem. Por exemplo, a Microsoft é responsável por restaurar uma PaaS (plataforma como serviço), mas você é responsável por reidratar dados e aplicar sua configuração ao serviço.
Inclua os pré-requisitos para executar o procedimento. Por exemplo, liste os scripts ou credenciais necessários que precisam ser coletados.
Capture a causa raiz do incidente e execute a mitigação antes de iniciar a recuperação. Por exemplo, se a causa do incidente for um problema de segurança, reduza esse problema antes de recuperar os sistemas afetados em seu ambiente de failover.
Dependendo do design de redundância para sua carga de trabalho, talvez seja necessário fazer um trabalho significativo pós-failover antes de disponibilizar a carga de trabalho para seus clientes novamente. O trabalho pós-failover pode incluir atualizações de DNS, atualizações de cadeia de conexão de banco de dados e alterações de roteamento de tráfego. Capture todo o trabalho pós-failover em seus procedimentos de recuperação.
Observação
Seu design de redundância pode permitir que você se recupere automaticamente de incidentes importantes de forma total ou parcial, portanto, certifique-se de que seu plano inclua processos e procedimentos em torno desses cenários. Por exemplo, se você tiver um design totalmente ativo-ativo que abrange zonas ou regiões de disponibilidade, poderá fazer failover de forma transparente automaticamente após uma zona de disponibilidade ou interrupção regional e minimizar as etapas em seu plano de recuperação de desastre que precisam ser executadas. Da mesma forma, se você projetou sua carga de trabalho usando selos de implantação, poderá sofrer apenas uma interrupção parcial se os selos forem implantados zonalmente. Nesse caso, seu plano de recuperação de desastre deve abordar como recuperar selos em zonas ou regiões não afetadas.
Se você precisar reimplantar seu aplicativo no ambiente de failover, use ferramentas para automatizar o processo de implantação o máximo possível. Verifique se os pipelines do DevOps foram pré-reimplantados e configurados nos ambientes de failover para que você possa iniciar imediatamente as implantações do aplicativo. Use implantações automatizadas de ponta a ponta, com portões de aprovação manuais, quando necessário, para garantir um processo de implantação consistente e eficiente. A duração completa da implantação precisa se alinhar com seus destinos de recuperação.
- Quando um estágio do processo de implantação requer intervenção manual, documente as etapas manuais. Definir claramente funções e responsabilidades.
Automatize o máximo possível do procedimento. Em seus scripts, use programação declarativa porque permite idempotência. Quando você não puder usar a programação declarativa, esteja atento ao desenvolvimento e à execução do código personalizado. Use a lógica de repetição e a lógica do disjuntor para evitar perda de tempo em scripts que estão presos em uma tarefa interrompida. Como você executa esses scripts apenas em emergências, não deseja que scripts desenvolvidos incorretamente causem mais danos ou abrandem o processo de recuperação.
Observação
A automação representa riscos. Os operadores treinados precisam monitorar os processos automatizados com cuidado e intervir se algum processo encontrar problemas. Para minimizar o risco de que a automação reaja a falsos positivos, seja detalhado em suas análises de recuperação de desastre. Teste todas as fases do plano. Simule a detecção para gerar alertas e, em seguida, passe por todo o procedimento de recuperação.
Lembre-se de que as análises de recuperação de desastre devem validar ou informar atualizações para suas métricas de destino de recuperação. Se você achar que sua automação está suscetível a falsos positivos, talvez seja necessário aumentar os limites de failover.
Separe o plano de failback do plano de recuperação de desastre para evitar possíveis confusão com os procedimentos de recuperação de desastre. O plano de failback deve seguir todas as recomendações de desenvolvimento e manutenção do plano de RECUPERAÇÃO e deve ser estruturado da mesma maneira. Todas as etapas manuais necessárias para failover devem ser espelhadas no plano de failback. O failback pode ocorrer rapidamente após o failover ou pode levar dias ou semanas. Considere o failback como separado do failover.
- A necessidade de fazer failback é situacional. Se você estiver roteando o tráfego entre regiões por motivos de desempenho, é importante fazer failback da carga originalmente na região de failover. Em outros casos, você pode ter projetado sua carga de trabalho para funcionar totalmente, independentemente de qual ambiente de produção ele está localizado a qualquer momento.
Realizar análises de recuperação de desastre
Uma prática de teste de DR é tão importante quanto um plano de DR bem desenvolvido. Muitos setores têm estruturas de conformidade que exigem que um número especificado de análises de DR seja executado regularmente. Independentemente do seu setor, as análises regulares de DR são primordiais para o seu sucesso.
Siga estas recomendações para análises de DR bem-sucedidas:
Execute pelo menos uma análise de DR de produção por ano. As simulações de mesa (execução seca) ou simulações de não produção ajudam a garantir que as partes envolvidas estejam familiarizadas com suas funções e responsabilidades. Essas simulações também ajudam os operadores a criar familiaridade ("memória muscular") seguindo os processos de recuperação. Mas apenas as análises de produção realmente testam a validade do plano de DR e das métricas de RTO e RPO. Use as análises de produção para cronometrar os processos de recuperação de componentes e fluxos para garantir que as metas de RTO e RPO definidas para sua carga de trabalho sejam alcançáveis. Para funções que estão fora de seu controle, como a propagação de DNS, verifique se o RTO e o RPO são direcionados para os fluxos que envolvem essas funções para possíveis atrasos além do controle.
Use análises de tabela não apenas para criar familiaridade para operadores experientes, mas também para instruir novos operadores sobre processos e procedimentos de DR. Os operadores seniores devem levar tempo para permitir que novos operadores executem sua função e devem watch para oportunidades de melhoria. Se um novo operador estiver hesitante ou confuso com uma etapa em um procedimento, examine esse procedimento para garantir que ele seja escrito claramente.
Considerações
Executar análises de recuperação de desastre na produção pode causar falhas catastróficas inesperadas. Certifique-se de testar procedimentos de recuperação em ambientes de não produção durante suas implantações iniciais.
Dê à sua equipe o máximo de tempo de manutenção possível durante os exercícios. Ao planejar o tempo de manutenção, use as métricas de recuperação que você captura durante o teste como loteamentos necessários de tempo mínimo .
À medida que suas práticas de análise de DR amadurecem, você aprende quais procedimentos podem ser executados em paralelo e quais devem ser executados em sequência. No início de suas práticas de análise, suponha que cada procedimento deve ser executado em sequência e que você precisa de tempo extra em cada etapa para lidar com problemas inesperados.
Facilitação do Azure
Muitos produtos do Azure têm recursos de failover internos. Familiarize-se com esses recursos e inclua-os em procedimentos de recuperação.
Para sistemas IaaS (infraestrutura como serviço), use o Azure Site Recovery para automatizar o failover e a recuperação. Consulte os seguintes artigos para obter produtos de PaaS comuns:
Exemplo
Confira a série dr para a plataforma de dados do Azure para obter diretrizes sobre como preparar um acervo de dados corporativos para DR.
Links relacionados
Lista de verificação de confiabilidade
Consulte o conjunto completo de recomendações.