Partilhar via

Recomendações para projetar uma estratégia de recuperação de desastres

Aplica-se a esta recomendação da lista de verificação de Fiabilidade do Azure Well-Architected Framework:

RE:09 Implemente planos estruturados, testados e documentados de continuidade de negócios e recuperação de desastres (BCDR) que se alinhem com as metas de recuperação. Os planos devem abranger todos os componentes e o sistema como um todo.

Este guia descreve recomendações para projetar uma estratégia confiável de recuperação de desastres para uma carga de trabalho. Para atender aos SLOs (Service Level Objetives, objetivos internos de nível de serviço) ou até mesmo a um contrato de nível de serviço (SLA) que você garantiu para seus clientes, você deve ter uma estratégia de recuperação de desastres robusta e confiável. Esperam-se falhas e outros problemas importantes. Seus preparativos para lidar com esses incidentes determinam o quanto seus clientes podem confiar em sua empresa para fornecer de forma confiável para eles. Uma estratégia de recuperação de desastres é a espinha dorsal da preparação para incidentes graves.

Definições

Período Definição
Comutação por Falha A transferência automatizada e/ou manual do tráfego da carga de trabalho de produção de uma região indisponível para uma região geográfica não afetada.
Retorno após falha O redirecionamento automatizado e/ou manual do tráfego de carga de trabalho de produção de uma região de contingência de volta para a região principal.

Principais estratégias de design

Este guia pressupõe que você já tenha executado as seguintes tarefas como parte do seu planejamento de confiabilidade:

Uma estratégia confiável de recuperação de desastres (DR) baseia-se na base de uma arquitetura de carga de trabalho confiável. Aborde a confiabilidade em cada estágio da criação de sua carga de trabalho para garantir que as peças necessárias para a recuperação otimizada estejam no lugar antes de começar a projetar sua estratégia de DR. Essa base garante que as metas de confiabilidade da sua carga de trabalho, como RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e RPO (Recovery Point Objetive, objetivo de ponto de recuperação), sejam realistas e alcançáveis.

Manter um plano de recuperação de desastres

A pedra angular de uma estratégia de DR confiável para uma carga de trabalho é o plano de DR. Seu plano deve ser um documento dinâmico que é revisado e atualizado rotineiramente à medida que seu ambiente evolui. Apresente o plano às equipes apropriadas (operações, liderança tecnológica e partes interessadas do negócio) regularmente (a cada seis meses, por exemplo). Armazene-o em um armazenamento de dados altamente disponível e seguro, como o OneDrive for Business.

Siga estas recomendações para desenvolver seu plano de DR:

  • Definir claramente o que constitui uma catástrofe e, por conseguinte, requer a ativação do plano de DR.

    • As catástrofes são questões de grande envergadura. Podem ser interrupções regionais, interrupções de serviços como o Microsoft Entra ID ou o DNS do Azure, ou ataques maliciosos graves, como ataques de ransomware ou ataques DDoS.

    • Identifique 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. Esses modos de falha podem ser resolvidos solucionando o problema em vigor, reimplantando os recursos com falha ou utilizando um plano de backup

  • Crie o plano de DR com base na documentação do FMA. Certifique-se de que seu plano de DR capture os modos de falha e as estratégias de mitigação para interrupções definidas como desastres. Atualize seu plano de DR e seus documentos FMA em paralelo para que sejam precisos quando o ambiente mudar ou quando os testes revelarem comportamentos inesperados.

    • O desenvolvimento de planos de DR para ambientes que não sejam de produção depende dos requisitos de negócios e dos impactos nos custos. Por exemplo, se você oferecer ambientes de garantia de qualidade (QA) a determinados clientes para testes de pré-lançamento, convém incluir esses ambientes em seu planejamento de DR.

  • Defina claramente funções e responsabilidades dentro da equipe de carga de trabalho e compreenda quaisquer funções externas relacionadas dentro da 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 interna e externa.

    • Papéis de liderança em análise retrospetiva e de causa raiz (RCA).

  • Defina os caminhos de escalonamento que a equipe de carga de trabalho deve seguir para garantir que o status de recuperação seja comunicado às partes interessadas.

  • Capture procedimentos de recuperação ao nível do componente, recuperação ao nível da infraestrutura de dados e processos de recuperação de toda a carga de trabalho. Inclua uma ordem prescrita de operações para garantir que os componentes sejam recuperados da maneira menos impactante. Por exemplo, recupere e verifique bancos de dados antes de recuperar o aplicativo.

    • Detalhe cada procedimento de recuperação ao nível do componente como um guia passo a passo. Inclua capturas de tela, se possível.

    • Defina as responsabilidades da sua equipa versus as responsabilidades do seu fornecedor de alojamento na nuvem. Por exemplo, a Microsoft é responsável por restaurar um PaaS (plataforma como serviço), mas você é responsável por reidratar os dados e aplicar sua configuração ao serviço.

    • Inclua pré-requisitos para executar o procedimento. Por exemplo, indique 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, atenue esse problema antes de recuperar os sistemas afetados em seu ambiente de failover.

  • Dependendo do desenho de redundância para a sua carga de trabalho, pode ser necessário realizar atividades significativas após o failover antes de disponibilizar a carga de trabalho novamente aos seus clientes. 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. Registe todo o trabalho pós-failover nos seus procedimentos de recuperação.

    Observação

    Seu design de redundância pode permitir que você se recupere automaticamente de incidentes graves total ou parcialmente, portanto, certifique-se de que seu plano inclua processos e procedimentos em torno desses cenários. Por exemplo, se tiveres um design totalmente ativo-ativo que abranja zonas ou regiões de disponibilidade, poderás processar a transferência de forma transparente e automática após uma falha numa zona de disponibilidade ou interrupção regional, minimizando as etapas do teu plano de recuperação de desastres que precisem ser executadas. Da mesma forma, se o/a utilizador projetou a sua carga de trabalho usando carimbos de implantação, poderá sofrer apenas uma interrupção parcial se os carimbos forem implantados zonalmente. Neste caso, o seu plano de DR deve cobrir 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 de DevOps foram pré-implantados e configurados nos ambientes de failover para que você possa começar imediatamente as implantações do aplicativo. Use implantações automatizadas de ponta a ponta, com portas de aprovação manuais quando necessário, para garantir um processo de implantação consistente e eficiente. A duração total da implantação precisa estar alinhada com suas metas de recuperação.

    • Quando uma etapa do processo de implantação exigir intervenção manual, documente as etapas manuais. Defina claramente papéis 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 programação declarativa, esteja atento ao desenvolver e executar seu código personalizado. Use a lógica de repetição e a lógica de disjuntor para evitar perder tempo com scripts que estão presos em uma tarefa quebrada. Como você executa esses scripts apenas em emergências, não deseja que scripts desenvolvidos incorretamente causem mais danos ou atrasem seu processo de recuperação.

    Observação

    A automatização apresenta riscos. Operadores treinados precisam monitorar os processos automatizados cuidadosamente e intervir se algum processo encontrar problemas. Para minimizar o risco de que a automação reaja a falsos positivos, seja minucioso em seus exercícios de DR. Teste todas as fases do plano. Simule a deteção para gerar alertas e, em seguida, percorra todo o procedimento de recuperação.

    Lembre-se de que suas simulações de recuperação de desastres devem validar ou informar atualizações para suas métricas alvo de recuperação. Se achares que a tua automação é suscetível a falsos positivos, poderás precisar de aumentar os teus limites de failover.

  • Separe o plano de failback do plano de recuperação de desastres para evitar possíveis confusões com os procedimentos de recuperação de desastres. O plano de reversão deve seguir todas as recomendações de desenvolvimento e manutenção do plano de Recuperação de Desastres e deve ser estruturado da mesma forma. 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 demorar dias ou semanas. Considere o failback como separado do failover.

    • A necessidade de recuperação é situacional. Se você estiver roteando o tráfego entre regiões por motivos de desempenho, é importante fazer o failback da carga originalmente na região de failover. Em outros casos, você pode ter projetado sua carga de trabalho para funcionar totalmente, independentemente do ambiente de produção em que ela está localizada a qualquer momento.

Realizar exercícios de recuperação de desastres

Uma prática de teste de DR é tão importante quanto um plano de DR bem desenvolvido. Muitos setores têm quadros de conformidade que exigem um número especificado de exercícios de Recuperação de Desastres (DR) para serem realizados regularmente. Independentemente do seu setor, os exercícios regulares de DR são fundamentais para o seu sucesso.

Siga estas recomendações para exercícios de DR bem-sucedidos:

  • Execute pelo menos uma broca DR de produção por ano. Exercícios de mesa (ensaios) ou exercícios não produtivos ajudam a garantir que as partes envolvidas estejam familiarizadas com as suas funções e responsabilidades. Estes exercícios também ajudam os operadores a construir familiaridade ("memória muscular") seguindo os processos de recuperação. Mas apenas os exercícios de produção realmente testam a validade do plano de DR e as métricas de RTO e RPO. Use os seus testes de produção para cronometrar os processos de recuperação de componentes e fluxos, garantindo que os objetivos de RTO e RPO definidos para as suas workloads sejam alcançáveis. Para funções que estão fora do seu controle, como propagação de DNS, certifique-se de que os destinos RTO e RPO para os fluxos que envolvem essas funções contabilizem possíveis atrasos além do seu controle.

  • Use brocas de mesa não apenas para criar familiaridade para operadores experientes, mas também para educar novos operadores sobre processos e procedimentos de DR. Os operadores seniores devem dedicar algum tempo a permitir que os novos operadores desempenhem o seu papel e devem estar atentos às oportunidades de melhoria. Se um novo operador estiver hesitante ou confuso com uma etapa de um procedimento, reveja esse procedimento para garantir que está claramente escrito.

Considerações

  • A execução de exercícios de DR na produção pode causar falhas catastróficas inesperadas. Certifique-se de testar os procedimentos de recuperação em ambientes que não sejam de produção durante as implantações iniciais.

  • Dê à sua equipa o máximo de tempo de manutenção possível durante os treinos. Ao planejar o tempo de manutenção, use as métricas de recuperação capturadas durante o teste como alocações de tempo mínimo necessárias .

  • À medida que suas práticas de drill DR amadurecem, você aprende quais procedimentos podem ser executados em paralelo e quais devem ser executados em sequência. No início das vossas sessões de treino, suponham que cada procedimento deve ser executado em sequência e que precisam de tempo extra em cada etapa para lidar com problemas imprevistos.

Definir e manter planos de backup para recursos dentro de fluxos críticos

O backup é uma parte importante do seu processo geral de recuperação. Muitas vezes, é apenas uma parte do seu ambiente que precisa de recuperação. Os planos de DR são geralmente para uma aplicação ou até para abranger toda uma região. A exclusão acidental ou maliciosa de dados, corrupção de arquivos, malware e ataques de ransomware direcionados podem afetar a disponibilidade de sua carga de trabalho. Ter planos de backup sólidos para cada parte do seu ambiente é tão importante quanto ter um plano de DR eficaz, pois um plano de DR depende de um plano de backup sólido para ser eficaz. Assim como seu plano de DR, os planos de backup também precisam ser acordados pelos níveis apropriados de gerenciamento, revisitados regularmente para possíveis atualizações e documentados em um armazenamento de dados altamente disponível e seguro.

  • Determine soluções de backup apropriadas para os diferentes serviços do Azure que fazem parte dos caminhos críticos em sua carga de trabalho.

  • Defina os períodos de retenção necessários para cada serviço diferente.

  • Entenda que uma ferramenta pode não funcionar para tudo. As ferramentas de Backup do Azure podem abranger muitos tipos de recursos, mas não todos.

  • Às vezes, a melhor opção para restaurar certos tipos de objetos é uma redistribuição de algum nível de repositório altamente disponível. (Azure DevOps, GitHub ou outros)

  • Os serviços de dados terão requisitos diferentes dos objetos relacionados ao aplicativo.

  • Certifique-se de considerar uma estratégia de armazenamento em várias regiões para seus dados de backup para criar capacidade de recuperação entre regiões.

  • Execute restaurações de teste regulares e agendadas de dados de backup para garantir que os serviços estejam funcionando conforme o esperado.

Gestão do Azure

Muitos produtos do Azure têm recursos internos de failover. Familiarize-se com esses recursos e inclua-os nos procedimentos de recuperação. Consulte a série de plataformas de dados DR para Azure para obter orientações sobre como preparar um conjunto de dados corporativos para DR.

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 produtos PaaS comuns:

Muitos produtos do Azure têm recursos de backup internos. Familiarize-se com esses recursos e inclua-os nos procedimentos de recuperação.

Para sistemas IaaS (infraestrutura como serviço), use o Backup do Azure para facilitar o backup de VMs e serviços relacionados a VMs e alguns serviços de dados. Consulte os seguintes artigos para produtos comuns:

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de fiabilidade