Compartilhar via

Estratégias de arquitetura 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 desastre) 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 de nível de serviço) internos 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 importantes são esperados. Seus preparativos para lidar com esses incidentes determinam o 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

Prazo Definição
Failover O deslocamento automatizado 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 O deslocamento automatizado e/ou manual do tráfego de produção de uma região alternativa de volta para a região primária.

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

Uma estratégia de recuperação de desastre confiável (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 tarefas 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 DR. Essa base garante que os destinos de confiabilidade da carga de trabalho, como o RTO (objetivo de tempo de recuperação) e o 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 vivo que é revisado e atualizado rotineiramente à 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 altamente disponível e seguro, como o 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 a ativação do plano de DR.

    • Desastres são problemas em larga escala. Podem ser interrupções regionais, interrupções de serviços como a ID do Microsoft Entra ou o 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. Esses modos de falha podem ser resolvidos solucionando problemas em vigor, reimplantando os recursos com falha ou utilizando um Plano de Backup

  • 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 seu plano de recuperação de desastre e seus documentos 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 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 retrospectiva e de causa raiz).

  • Defina os caminhos de escalonamento que a equipe de carga de trabalho deve seguir para garantir que o status de recuperação seja comunicado aos stakeholders.

  • Capture procedimentos de recuperação no nível do componente, recuperação em nível de patrimônio de dados e processos de recuperação abordando 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 verifique 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 um 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 de pós-failover significativo 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. Registre todas as atividades 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 principais 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ê tiver projetado 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é-implantados 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 aos seus objetivos de recuperação.

    • Quando um estágio do processo de implantação requer intervenção manual, documente as etapas manuais. Defina 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 programação declarativa, esteja atento ao desenvolvimento e à execução do código personalizado. Use lógica de repetição e lógica de 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 diminuam 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 simulações 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 os exercícios de recuperação de desastre devem validar ou informar atualizações para as metas de recuperação. Se você achar que sua automação é suscetível a falsos positivos, talvez seja necessário aumentar seus limites de tolerância a falhas.

  • 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 retomada 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 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, direcionar novamente a carga para a região original após o failover é importante. 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 exercícios 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 um número especificado de exercícios de recuperação de desastre para serem executados regularmente. Independentemente da sua indústria, os exercícios regulares de recuperação de desastres são essenciais para o seu sucesso.

Siga estas recomendações para simulações bem-sucedidas de recuperação de desastres:

  • Realize pelo menos um treinamento de DR de produção por ano. As simulações de mesa ou treinamentos que não envolvem produção ajudam a garantir que as partes envolvidas estejam familiarizadas com suas funções e responsabilidades. Esses exercícios também ajudam os operadores a criar familiaridade ("memória muscular") seguindo processos de recuperação. No entanto, somente as simulações de produção de fato testam a validade do plano de recuperação de desastre e das métricas de RTO e RPO. Use os exercícios de produção para cronometrar os processos de recuperação de componentes e fluxos, garantindo que as metas de RTO e RPO definidas para sua carga de trabalho sejam alcançáveis. Para funções que estão fora do seu controle, como a propagação de DNS, certifique-se de que as metas de RTO e RPO para os fluxos que envolvem essas funções levem em conta possíveis atrasos além do seu controle.

  • Use exercícios de mesa não apenas para criar familiaridade para operadores experientes, mas também para educar novos operadores sobre processos e procedimentos de recuperação de desastres. Os operadores seniores devem levar tempo para permitir que novos operadores executem sua função e devem observar as oportunidades de melhoria. Se um novo operador estiver hesitante ou confuso por uma etapa em um procedimento, examine esse procedimento para garantir que ele esteja claramente escrito.

Considerações

  • Executar exercícios 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 tempo mínimo necessário de alocações.

  • À medida que as práticas de recuperação de desastres amadurecem, você aprende quais procedimentos podem ser executados em paralelo e quais devem ser executados em sequência. No início de suas simulações, suponha que todos os procedimentos devem ser executados em sequência e que você precisa de tempo extra em cada etapa para lidar com problemas imprevistos.

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

O backup é uma parte importante do processo de recuperação geral. Geralmente, é apenas uma parte do seu ambiente que precisa de recuperação. Os planos de recuperação de desastre geralmente são de aplicativo ou até mesmo de toda a região. A exclusão acidental ou mal-intencionada de dados, corrupção de arquivos, malware e ataques de ransomware direcionados pode 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 recuperação de desastre eficaz, pois um plano de recuperação de desastre depende de um plano de backup sólido para ser eficaz. Assim como seu plano de recuperação de desastre, 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 as 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 determinados tipos de objetos é uma reimplantação de algum tipo de nível de repositório altamente disponível. (Azure DevOps, GitHub ou outros)

  • Os serviços de dados têm requisitos diferentes dos objetos relacionados ao aplicativo.

  • Considere uma estratégia de armazenamento de várias regiões para que os dados de backup criem capacidade de recuperação entre regiões.

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

Facilitação do Azure

Muitos produtos do Azure têm funcionalidades de failover internas. Familiarize-se com esses recursos e inclua-os em procedimentos de recuperação. Consulte a série de plataformas de dados do Azure para DR para obter diretrizes sobre como preparar uma plataforma de dados corporativa 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 funcionalidades de backup internas. Familiarize-se com esses recursos e inclua-os em 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 à VM e alguns serviços de dados. Consulte os seguintes artigos para produtos comuns:

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade