Recomendações para conceber uma estratégia de recuperação após desastre

  • Artigo

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

RE:09 Implemente planos estruturados, testados e documentados de continuidade empresarial e recuperação após desastre (BCDR) que se alinham com os objetivos de recuperação. Os planos têm de abranger todos os componentes e o sistema como um todo.

Este guia descreve recomendações para conceber uma estratégia de recuperação após desastre fiável para uma carga de trabalho. Para cumprir os objetivos de nível de serviço interno (SLOs) ou mesmo um contrato de nível de serviço (SLA) que tenha garantido aos seus clientes, tem de ter uma estratégia de recuperação após desastre robusta e fiável. São esperadas falhas e outros problemas importantes. Os seus preparativos para lidar com estes incidentes determinam quanto é que os seus clientes podem confiar na sua empresa para os entregar de forma fiável. Uma estratégia de recuperação após desastre é a espinha dorsal da preparação para incidentes importantes.

Definições

Termo Definição
Ativação pós-falha A mudança automática 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.
Reativação pós-falha A mudança automatizada e/ou manual do tráfego de carga de trabalho de produção de uma região de ativação pós-falha de volta para a região primária.

Principais estratégias de design

Este guia pressupõe que já realizou as seguintes tarefas como parte do seu planeamento de fiabilidade:

Uma estratégia fiável de recuperação após desastre (DR) baseia-se na base de uma arquitetura de carga de trabalho fiável. Resolva a fiabilidade em todas as fases da criação da carga de trabalho para garantir que as peças necessárias para a recuperação otimizada estão implementadas antes de começar a conceber a sua estratégia de DR. Esta base garante que os destinos de fiabilidade da carga de trabalho, como o objetivo de tempo de recuperação (RTO) e o objetivo de ponto de recuperação (RPO), são realistas e exequíveis.

Manter um plano de recuperação após desastre

A pedra angular de uma estratégia de DR fiável para uma carga de trabalho é o plano de DR. O seu plano deve ser um documento vivo que é revisto e atualizado rotineiramente à medida que o seu ambiente evolui. Apresente o plano às equipas adequadas (operações, liderança tecnológica e intervenientes empresariais) regularmente (a cada seis meses, por exemplo). Armazene-o num arquivo de dados altamente disponível e seguro, como OneDrive para Empresas.

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

  • Defina claramente o que constitui um desastre e, por conseguinte, requer a ativação do plano de DR.

    • Os 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 maliciosos graves, como ataques de ransomware ou ataques 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 os respetivos escalamentos de DR.

  • Crie o plano de DR na documentação do FMA. Certifique-se de que o seu plano de DR captura os modos de falha e as estratégias de mitigação para falhas que são definidas como desastres. Atualize o seu plano de DR e os seus documentos FMA em paralelo para que sejam precisos quando o ambiente muda ou quando os testes descobrem comportamentos inesperados.

    • Se desenvolver planos de DR para ambientes de não produção depende dos requisitos empresariais e dos impactos nos custos. Por exemplo, se oferecer ambientes de garantia de qualidade (QA) a determinados clientes para testes de pré-lançamento, poderá querer incluir esses ambientes no planeamento de DR.

  • Defina claramente funções e responsabilidades na equipa de carga de trabalho e compreenda quaisquer funções externas relacionadas na sua organização. As funções devem incluir:

    • O responsável por declarar um desastre.

    • O responsável por declarar o encerramento do incidente.

    • Funções de operações.

    • Funções de teste e validação.

    • Funções de comunicações internas e externas.

    • Funções potenciais de análise retrospectiva e de causa raiz (RCA).

  • Defina os caminhos de escalamento que a equipa de carga de trabalho tem de seguir para garantir que o estado de recuperação é comunicado aos intervenientes.

  • Capture procedimentos de recuperação ao nível do componente, recuperação ao nível do património de dados e processos de recuperação ao nível da carga de trabalho. Inclua uma ordem de operações prescrita para garantir que os componentes são recuperados da forma menos impactante. Por exemplo, recupere e verifique as bases de dados antes de recuperar a aplicação.

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

    • Defina as responsabilidades da sua equipa em relação às responsabilidades do seu fornecedor de alojamento na cloud. Por exemplo, a Microsoft é responsável por restaurar um PaaS (plataforma como serviço), mas é responsável por reidratar dados e aplicar a 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 de ser recolhidos.

    • Capture a causa principal 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, mitigue esse problema antes de recuperar os sistemas afetados no seu ambiente de ativação pós-falha.

  • Consoante a estrutura de redundância da carga de trabalho, poderá ter de fazer um trabalho de pós-ativação pós-falha significativo antes de disponibilizar novamente a carga de trabalho aos seus clientes. O trabalho pós-ativação pós-falha pode incluir atualizações de DNS, atualizações de cadeia de ligação de base de dados e alterações de encaminhamento de tráfego. Capture todo o trabalho pós-ativação pós-falha nos seus procedimentos de recuperação.

    Nota

    A sua estrutura de redundância pode permitir-lhe recuperar automaticamente de incidentes principais de forma total ou parcial, por isso certifique-se de que o seu plano inclui processos e procedimentos em torno destes cenários. Por exemplo, se tiver um design totalmente ativo-ativo que abrange zonas ou regiões de disponibilidade, poderá conseguir efetuar a ativação pós-falha de forma transparente automaticamente após uma zona de disponibilidade ou indisponibilidade regional e minimizar os passos no seu plano de DR que têm de ser executados. Da mesma forma, se tiver concebido a carga de trabalho com selos de implementação, poderá sofrer apenas uma indisponibilidade parcial se os selos forem implementados zonalmente. Neste caso, o seu plano de DR deve abranger como recuperar selos em zonas ou regiões não afetadas.

  • Se precisar de reimplementar a aplicação no ambiente de ativação pós-falha, utilize as ferramentas para automatizar o processo de implementação o máximo possível. Certifique-se de que os pipelines do DevOps foram predeployed e configurados nos ambientes de ativação pós-falha para que possa iniciar imediatamente as implementações da aplicação. Utilize implementações ponto a ponto automatizadas, com portas de aprovação manuais sempre que necessário, para garantir um processo de implementação consistente e eficiente. A duração total da implementação tem de estar alinhada com os destinos de recuperação.

    • Quando uma fase do processo de implementação requer intervenção manual, documente os passos manuais. Definir claramente funções e responsabilidades.

  • Automatize o máximo possível do procedimento. Nos seus scripts, utilize a programação declarativa porque permite a idempotência. Quando não puder utilizar a programação declarativa, tenha em atenção o desenvolvimento e a execução do código personalizado. Utilize lógica de repetição e lógica de disjuntor automático para evitar perder tempo em scripts que estão bloqueados numa tarefa quebrada. Uma vez que executa estes scripts apenas em situações de emergência, não quer que os scripts desenvolvidos incorretamente causem mais danos ou atrasem o processo de recuperação.

    Nota

    A automatização representa riscos. Os operadores preparados precisam de monitorizar cuidadosamente os processos automatizados e intervir se algum processo encontrar problemas. Para minimizar o risco de a automatização reagir a falsos positivos, seja minucioso nas suas explorações de DR. Teste todas as fases do plano. Simular a deteção para gerar alertas e, em seguida, percorrer todo o procedimento de recuperação.

    Lembre-se de que as suas explorações de DR devem validar ou informar as atualizações das métricas de destino de recuperação. Se considerar que a automatização é suscetível a falsos positivos, poderá ter de aumentar os limiares de ativação pós-falha.

  • Separe o plano de reativação pós-falha do plano de DR para evitar potenciais confusões com os procedimentos de DR. O plano de reativação pós-falha deve seguir todas as recomendações de desenvolvimento e manutenção do plano de DR e deve ser estruturado da mesma forma. Quaisquer passos manuais necessários para a ativação pós-falha devem ser espelhados no plano de reativação pós-falha. A reativação pós-falha pode ocorrer rapidamente após a ativação pós-falha ou pode demorar dias ou semanas. Considere a reativação pós-falha como separada da ativação pós-falha.

    • A necessidade de reativação pós-falha é situacional. Se estiver a encaminhar o tráfego entre regiões por motivos de desempenho, a reativação pós-falha da carga originalmente na região de ativação pós-falha é importante. Noutros casos, poderá ter concebido a carga de trabalho para funcionar totalmente, independentemente do ambiente de produção em que se encontra em qualquer altura.

Realizar exercícios de recuperação após desastre

Uma prática de teste de DR é tão importante como um plano de DR bem desenvolvido. Muitas indústrias têm arquiteturas de conformidade que requerem um número especificado de explorações de DR para serem realizadas regularmente. Independentemente da sua indústria, os exercícios regulares de DR são fundamentais para o seu sucesso.

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

  • Efetue pelo menos uma exploração de DR de produção por ano. Os exercícios de tabela (execução a seco) ou os exercícios de não produção ajudam a garantir que as partes envolvidas estão familiarizadas com as suas funções e responsabilidades. Estes exercícios também ajudam os operadores a criar familiaridade ("memória muscular") ao seguir processos de recuperação. Mas apenas os exercícios de produção testam verdadeiramente a validade do plano de DR e as métricas RTO e RPO. Utilize os seus exercícios de produção para processar processos de recuperação temporal para componentes e fluxos para garantir que os destinos RTO e RPO que foram definidos para a carga de trabalho são alcançáveis. Para funções que estão fora do seu controlo, como a propagação de DNS, certifique-se de que os destinos RTO e RPO para os fluxos que envolvem essas funções são responsáveis por possíveis atrasos fora do seu controlo.

  • Utilize exercícios de tabela não só para criar familiaridade para operadores experientes, mas também para educar novos operadores sobre processos e procedimentos de DR. Os operadores seniores devem demorar algum tempo a permitir que os novos operadores executem a sua função e devem watch para oportunidades de melhoramento. Se um novo operador estiver hesitante ou confuso com um passo num procedimento, reveja esse procedimento para garantir que está claramente escrito.

Considerações

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

  • Dê à sua equipa o máximo de tempo de manutenção possível durante os exercícios. Ao planear o tempo de manutenção, utilize as métricas de recuperação que capturar durante os testes como lotes de tempo mínimo necessários .

  • À medida que as suas práticas de pormenorização de DR amadurecem, irá aprender quais os procedimentos que pode executar em paralelo e que têm de ser executados em sequência. No início das suas práticas de exploração, suponha que todos os procedimentos têm de ser executados em sequência e que precisa de tempo extra em cada passo para lidar com problemas inesperados.

Facilitação do Azure

Muitos produtos do Azure têm capacidades de ativação pós-falha incorporadas. Familiarize-se com estas capacidades e inclua-as nos procedimentos de recuperação.

Para sistemas IaaS (infraestrutura como serviço), utilize o Azure Site Recovery para automatizar a ativação pós-falha e a recuperação. Veja os seguintes artigos para produtos PaaS comuns:

Exemplo

Veja a série dr for Azure data platform (DR para plataformas de dados do Azure ) para obter orientações sobre a preparação de um património de dados empresarial para DR.

Lista de verificação de fiabilidade

Veja o conjunto completo de recomendações.

Lista de verificação de fiabilidade