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

Aplica-se a esta recomendação da lista de verificação de confiabilidade bem arquitetada: Power Platform

Este guia descreve recomendações para projetar uma estratégia de recuperação de desastre confiável para uma carga de trabalho. Para atender aos objetivos de nível de serviço (SLOs) internos ou mesmo um contrato de nível de serviço (SLA) que você garantiu para os clientes, você deve ter uma estratégia para recuperação de desastre robusta e confiável. Falhas e outros problemas importantes são esperados. Os preparativos para lidar com esses incidentes determinam o quanto os clientes podem confiar na empresa com segurança. Uma estratégia para recuperação de desastre é a espinha dorsal da preparação para grandes incidentes.

Definições

Estratégias-chave de design

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

• Identifique fluxos críticos e não críticos.

• Realize a análise do modo de falha (FMA) para os fluxos.

• Identifique metas de confiabilidade.

• Projete uma estratégia de teste robusta.

Uma arquitetura da carga de trabalho confiável é a base para uma estratégia de recuperação de desastre (DR) confiável. Leve em consideração a confiabilidade em todos os estágios da criação da carga de trabalho para garantir que você tenha os componentes necessários para uma recuperação eficiente antes de começar a planejar a estratégia de DR. Essa base garante que as metas de confiabilidade da carga de trabalho, como objetivo do tempo de recuperação (RTO) e objetivo do ponto de recuperação (RPO), sejam práticas e viáveis.

Manter um plano para recuperação de desastre

A chave para uma estratégia de DR confiável para uma carga de trabalho é o plano de DR. O plano deve ser um documento vivo revisado e atualizado regularmente à medida que o ambiente muda. Compartilhe o plano com as equipes relevantes (operações, liderança em tecnologia e stakeholders de negócio) regularmente (por exemplo, a cada seis meses). Mantenha-o em um armazenamento de dados altamente disponível e seguro, como o OneDrive.

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

• Defina claramente o que constitui um desastre e exige a ativação do plano de DR.

  Os desastres são problemas de grande escala. Eles 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 DDoS.

  Inclua exemplos dos modos de falha não considerados desastres, como a indisponibilidade ou a falha de um único recurso, no plano de DR, de maneira que os operadores não invoquem por engano os escalonamentos de DR.

• Compile o plano de DR na documentação do FMA. Verifique se o plano de DR captura os modos de falha e as estratégias de mitigação para interrupções definidas como desastres. Se atualizações forem necessárias, atualize o plano de DR e os documentos de FMA ao mesmo tempo para que sejam precisos quando o ambiente mudar ou quando o teste descobrir comportamentos inesperados.

• Defina claramente funções e responsabilidades dentro da equipe da carga de trabalho e compreenda eventuais funções externas relacionadas dentro da organização. Se o desastre for causado pela interrupção de um serviço externo, como a ID do Microsoft Entra, verifique se você tem uma função definida responsável pela comunicação com a parte externa e consegue compartilhar atualizações com a equipe da carga de trabalho. Entre as funções devem estar:

  • A entidade responsável pela declaração de um desastre
  • A entidade responsável pela declaração de um fechamento de incidente
  • Funções de operações
  • Funções de teste e validação
  • Funções de comunicações interna e externa
  • Funções principais da análise de causa raiz (RCA) e retrospectiva

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

• Inclua a ordem prescrita na qual os componentes da carga de trabalho devem ser recuperados para causar o menor impacto. Por exemplo, recupere bancos de dados e reinicie fluxos de nuvem antes de recuperar o aplicativo.

  • Detalhar o procedimento de recuperação de cada componente como um guia passo a passo. Inclua capturas de tela, se possível, e pré-requisitos para executar o procedimento. Por exemplo, liste as credenciais ou os scripts necessários que precisam ser coletados.

  • Defina as responsabilidades da equipe em comparação com as responsabilidades do provedor de hospedagem na nuvem. Por exemplo, 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.

  • Capture a causa raiz do incidente e realize 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 no ambiente de failover.

• Se você precisar reimplantar o aplicativo no ambiente de failover, use as ferramentas para automatizar o processo de implantação o máximo possível. Verifique se o Azure Pipelines está pré-implantado e configurado corretamente nos ambientes de failover para que você possa começar imediatamente as implantações. 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. Quando um estágio do processo de implantação exigir intervenção manual, documente as etapas manuais. Defina claramente funções e responsabilidades.

• Automatize o procedimento o máximo possível. Use a lógica de repetição para evitar perder tempo com scripts que estejam presos em uma tarefa interrompida. Como só executa esses scripts em emergências, você não deseja que scripts desenvolvidos incorretamente causem mais danos ou retardem o processo de recuperação.

Realizar análises da recuperação de desastre

Uma prática de teste de DR é essencial para um bom plano de DR. Muitos setores têm estruturas de conformidade que exigem exercícios de DR regulares. Independentemente do setor, os exercícios de DR frequentes são cruciais para o êxito.

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

• Realize pelo menos uma análise de DR da produção por ano. Análises a seco ou de não produção ajudam a garantir que as partes envolvidas estejam familiarizadas com as funções e as responsabilidades. Essas análises também ajudam operadores a construir familiaridade seguindo processos de recuperação. Porém, apenas análises de produção verdadeiramente testam a validade do plano de DR e das métricas de RTO e RPO. Use as análises de produção para cronometrar processos de recuperação de componentes e fluxos para garantir que as metas de RTO e RPO definidas para a carga de trabalho sejam viáveis. Para funções que estejam fora do controle, como interrupções de ID do Microsoft Entra, verifique se as metas de RTO e RPO para os fluxos que envolvem essas funções levam em conta possíveis atrasos além do controle.

• Use análises feitas a seco para instruir novos operadores sobre processos e procedimentos de DR. Os operadores seniores devem dedicar tempo a permitir que os novos operadores desempenhem o papel e devem estar atentos às oportunidades de melhoria. Se um novo operador estiver hesitante ou confuso por uma etapa de um procedimento, revise esse procedimento para garantir que ele esteja escrito claramente.

Considerações

A realização de análises de DR na produção pode causar falhas catastróficas inesperadas. Teste os procedimentos de recuperação em ambientes de não produção durante as implantações iniciais.

Dê à equipe o máximo de tempo de manutenção possível durante as análises. 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 as práticas de análise de DR evoluem, você aprende quais procedimentos pode executar em paralelo e quais deve executar em sequência. No início das práticas de análise, vamos supor que cada procedimento deva ser executado em sequência e que você precisa de tempo extra em cada etapa para resolver problemas imprevistos.

Capacidades de failover

Microsoft Os aplicativos comerciais fornecem recursos de continuidade de negócios e recuperação de desastres (BCDR) para todos os ambientes de produção no Dynamics 365 e aplicativos de software como serviço (SAAS). Power Platform Saiba como Microsoft garante que seus dados de produção sejam resilientes durante interrupções regionais.

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.