Recomendações para estruturar uma estratégia de recuperação após desastre
Aplica-se a esta Power Platform recomendação de lista de verificação de fiabilidade bem arquitetada:
| RE:07 | Implemente planos de continuidade de negócio e recuperação após desastre (BCDR) estruturados, testados e documentados 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 estruturar uma estratégia fiável de recuperação após desastre para uma carga de trabalho. Para cumprir os objetivos de nível de serviço (SLOs) internos ou até mesmo um contrato de nível de serviço (SLA) que tenha garantido aos seus clientes, tem de possuir 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 o quanto os seus clientes podem confiar na sua empresa para entregas de forma fiável. Uma estratégia de recuperação após desastre é a espinha dorsal da preparação para incidentes graves.
Definições
| Termo | Definição |
|---|---|
| Ativaçã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 não disponível para uma região não afetada. |
| Reativação pós-falha | A deslocação automatizada e/ou manual do tráfego de carga de trabalho de produção de uma região de ativação pós-falha para a região primária. |
Principais estratégias de design
Este guia assume que já executou as seguintes tarefas como parte do seu planeamento de fiabilidade:
Identificar fluxos críticos e não críticos.
Executar a análise do modo de falha (FMA) para os seus fluxos.
Identificar os alvos de fiabilidade.
Estruturar uma estratégia de teste robusta.
Uma arquitetura de carga de trabalho fiável é a base para uma estratégia fiável de recuperação após desastre (DR). Considere a fiabilidade em cada fase de criação da sua carga de trabalho para garantir que tem os componentes necessários para uma recuperação eficiente antes de começar a planear a sua estratégia de DR. Esta base garante que as metas de fiabilidade da sua carga de trabalho, como objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO), são práticas e atingíveis.
Manter um plano de recuperação após desastre
A chave para uma estratégia de DR fiável para uma carga de trabalho é o plano de DR. O seu plano deve ser um documento dinâmico que é regularmente revisto e atualizado à medida que o ambiente muda. Partilhe o plano com as equipas relevantes (operações, liderança tecnológica e intervenientes no negócio) regularmente (por exemplo, a cada seis meses). Mantenha-o num arquivo de dados seguro e de elevada disponibilidade como o OneDrive.
Siga estas recomendações para desenvolver o seu plano de DR:
Defina claramente o que constitui um desastre e requer a ativação do plano de DR.
Os desastres são problemas de grande escala. Podem ser indisponibilidades regionais, indisponibilidades de serviços como o Microsoft Entra ID ou o DNS do Azure ou ataques maliciosos graves, como ataques de ransomware ou DDoS.
Inclua exemplos de modos de falha que não são considerados desastres, como a indisponibilidade ou falha de um único recurso, no seu plano de DR para que os operadores não invoquem incorretamente os seus escalamentos de DR.
Cria o plano de DR na sua documentação da FMA. Certifique-se de que o seu plano de DR capta os modos de falha e as estratégias de mitigação das indisponibilidades definidas como desastres. Se forem necessárias atualizações, atualize o plano de DR e os documentos da FMA ao mesmo tempo para que sejam precisos quando o ambiente mudar ou quando os testes revelarem comportamentos inesperados.
Defina claramente as funções e responsabilidades dentro da equipa de carga de trabalho e compreenda quaisquer funções externas relacionadas dentro da sua organização. Se o desastre for causado pela indisponibilidade de um serviço externo, como o Microsoft Entra ID, certifique-se de que tem uma função definida que é responsável pela comunicação com a entidade externa e que pode partilhar atualizações com a equipa de carga de trabalho. As funções devem incluir:
- A parte responsável pela declaração de um desastre
- A parte responsável pela declaração de fecho do incidente
- Funções de operações
- Funções de testes e validação
- Funções de comunicação interna e externa
- Funções principais de análise retrospetiva 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.
Inclua a ordem prescrita na qual os componentes da carga de trabalho devem ser recuperados para causar o menor impacto. Por exemplo, recupere bases de dados e reinicie fluxos de cloud antes de recuperar a aplicação.
Detalhe o procedimento de recuperação de cada componente como um guia passo a passo. Inclua capturas de ecrã, se possível, e pré-requisitos para executar o procedimento. Por exemplo, liste os scripts ou credenciais necessários que precisam de ser reunidos.
Defina as responsabilidades da sua equipa versus as responsabilidades do seu fornecedor de alojamento na cloud. 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 execute a mitigação antes de iniciar a recuperação. Por exemplo, se a causa do incidente for um problema de segurança, mitigue este problema antes de recuperar os sistemas afetados no seu ambiente de ativação pós-falha.
Se precisar de reimplementar a sua aplicação no ambiente de ativação pós-falha, utilize ferramentas para automatizar o processo de implementação o máximo possível. Certifique-se de que os Pipelines do Azure foram previamente implementados e corretamente configurados nos ambientes de ativação pós-falha para poder começar imediatamente as implementações. Utilize implementações automatizadas ponto a ponto, com portas de aprovação manuais quando necessário, para garantir um processo de implementação consistente e eficiente. Quando uma fase do processo de implementação necessitar de intervenção manual, documente os passos manuais. Defina claramente as funções e responsabilidades.
Automatize o máximo possível do procedimento. Utilize a lógica de repetição para evitar perder tempo com scripts que estão presos numa tarefa interrompida. Como executa estes scripts apenas em emergências, não pretende que scripts desenvolvidos incorretamente causem mais danos ou atrasem o seu processo de recuperação.
Nota
A automatização apresenta riscos. Os operadores formados precisam de monitorizar os processos automatizados cuidadosamente e intervir se algum processo encontrar problemas. Para minimizar o risco de a automatização reagir a falsos positivos, seja rigoroso nas suas simulações de DR. Teste todas as fases do plano. Simule a deteção para gerar alertas e, em seguida, mova todo o procedimento de recuperação.
Realizar testes de recuperação após desastre
Uma prática de teste de DR é essencial para um bom plano de DR. Muitos setores têm estruturas de conformidade que exigem testes de DR regulares. Independentemente do seu setor, os testes de DR frequentes são cruciais para o seu sucesso.
Siga estas recomendações para testes de DR com êxito:
Execute pelo menos um teste de DR de produção por ano. Os testes de funcionamento a seco ou os testes que não sejam de produção ajudam a garantir que as partes envolvidas estão familiarizadas com as suas funções e responsabilidades. Estes testes também ajudam os operadores a ganhar familiaridade seguindo os processos de recuperação. Mas apenas os testes de produção realmente testam a validade do plano de DR e as métricas RTO e RPO. Utilize os seus testes de produção para cronometrar processos de recuperação de componentes e fluxos para garantir que os alvos de RTO e RPO que foram definidos para a sua carga de trabalho são alcançáveis. Para as funções que estão fora do seu controlo, como indisponibilidades do Microsoft Entra ID, certifique-se de que os alvos de RTO e RPO para os fluxos que envolvem estas funções representam possíveis atrasos fora do seu controlo.
Utilize testes de execução a seco para educar novos operadores sobre os processos e procedimentos de DR. Os operadores seniores devem dedicar algum tempo a permitir que os novos operadores desempenhem a sua função e devem estar atentos a oportunidades de melhoramento. Se um novo operador estiver hesitante ou confuso em relação a um passo de um procedimento, reveja esse procedimento para garantir que está claramente escrito.
Considerações
A execução de testes 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 suas implementações iniciais.
Dê à a sua equipa o máximo de tempo de manutenção possível durante os testes. Ao planear o tempo de manutenção, utilize as métricas de recuperação capturadas durante o teste como alocações do tempo mínimo necessário .
À medida que as suas práticas de teste de DR amadurecem, aprende quais procedimentos podem ser executados em paralelo e quais devem ser executados em sequência. No início das suas práticas de teste, suponha que cada procedimento deve ser executado em sequência e que precisa de tempo extra em cada passo para lidar com problemas imprevistos.
Capacidades de ativação pós-falha
Microsoft Os aplicativos de negócios fornecem recursos de continuidade de negócios e recuperação de desastres (BCDR) para todos os ambientes de produção em aplicativos de Dynamics 365 e Power Platform software como serviço (SAAS). Saiba como garante que Microsoft seus dados de produção sejam resilientes durante interrupções regionais.
Lista de verificação de fiabilidade
Consulte o conjunto completo de recomendações.