Visão geral
Esta série fornece um exemplo ilustrativo de como uma organização pode projetar uma estratégia de recuperação de desastres (DR) para uma plataforma de dados corporativos do Azure.
- Esta série de artigos complementa as orientações fornecidas pela Estrutura de Adoção de Nuvem da Microsoft, pela Well-Architected Framework do Azure e pelo Gerenciamento de Continuidade de Negócios
O Azure fornece uma ampla gama de opções de resiliência que podem fornecer continuidade de serviço em caso de desastre. Mas níveis de serviço mais altos podem introduzir complexidade e um prêmio de custo. A compensação de custo versus resiliência versus complexidade é o principal fator de tomada de decisão para a maioria dos clientes em relação à DR.
Embora falhas pontuais ocasionais aconteçam no serviço do Azure, deve-se observar que os Data Centers da Microsoft e os Serviços do Azure têm várias camadas de redundância internas. Qualquer falha é normalmente limitada no escopo e normalmente é recuperada em questão de horas. Historicamente, é muito mais provável que um serviço importante, como o gerenciamento de identidades, enfrente um problema de serviço do que uma região inteira do Azure ficando offline.
Também deve ser reconhecido que os ataques cibernéticos, particularmente o ransomware, agora representam uma ameaça tangível para qualquer ecossistema de dados moderno e podem resultar em uma interrupção da plataforma de dados. Embora isso esteja fora do escopo desta série, os clientes são aconselhados a implementar controles contra esses ataques como parte do design de segurança e resiliência de qualquer plataforma de dados.
- As orientações da Microsoft sobre proteção contra ransomware estão disponíveis nos Fundamentos da nuvem do Azure
Escopo
O escopo desta série de artigos inclui:
- A recuperação de serviço de uma plataforma de dados do Azure de um desastre físico para uma persona ilustrativa do cliente. Este cliente ilustrativo é:
- uma organização de médio e grande porte com uma função de suporte operacional definida, seguindo uma metodologia de gerenciamento de serviços baseada em ITIL
- não nativa da nuvem, com sua empresa principal, serviços compartilhados como gerenciamento de acesso e autenticação e gerenciamento de incidentes utilizados no local
- na jornada de migração na nuvem para o Azure, habilitada pela automação
- A plataforma de dados do Azure implementou os seguintes designs na locação do Azure do cliente
- Zona de Destino Enterprise – Fornece a base da plataforma, incluindo rede, monitoramento, segurança etc.
- Plataforma Azure Analytics - Fornece os componentes de dados que dão suporte às várias soluções e produtos de dados fornecidos pelo serviço
- Esse processo será executado por um recurso técnico do Azure em vez de uma PME especializada do Azure. Como tal, o(s) recurso(s) deve(m) ter o seguinte nível de conhecimentos/habilidades
- Fundamentos do Azure – Conhecimento prático do Azure, seus principais serviços e componentes de dados
- Conhecimento prático de Azure DevOps. Capaz de navegar pelo controle do código-fonte e executar implantações de pipeline
- Esse processo descreve o processo de Failover, da região primária para a secundária
Fora do escopo
Os seguintes itens são considerados fora do escopo desta série de artigos:
- O processo de fallback, da região secundária de volta para a região primária
- Quaisquer aplicativos, componentes ou sistemas que não sejam do Azure – isso inclui, entre outros, locais, outros fornecedores de nuvem, serviços Web de terceiros, etc.
- Recuperação de quaisquer serviços upstream, como redes locais, gateways, serviços compartilhados corporativos, etc., que são pré-requisitos para esse processo
- Recuperação de quaisquer serviços downstream, como sistemas operacionais locais, sistemas de relatórios de terceiros, modelagem de dados ou aplicativos de ciência de dados, etc., que dependam desse processo para recuperar seus próprios serviços
- Cenários de perda de dados, incluindo recuperação de ransomware ou incidentes de segurança de dados semelhantes
- Estratégias de backup de dados e planos de restauração de dados
- Estabelecendo a causa raiz de um evento de DR
- Para incidentes de serviço/componente do Azure, a Microsoft publica uma "Análise de Causa Raiz" na página da Web Status – Histórico
Principais suposições
As principais suposições para este exemplo de DR trabalhado são:
- A organização segue uma metodologia de gerenciamento de serviços baseada em ITIL para suporte operacional da plataforma de dados do Azure
- A organização tem um processo de recuperação de desastres existente como parte de sua estrutura de restauração de serviços para ativos de TI
- A "Infraestrutura como Código" (IaC) foi usada para implantar a plataforma de dados do Azure habilitada por um serviço de automação, como o Azure DevOps ou similar
- Cada solução hospedada pela plataforma de dados do Azure concluiu uma Avaliação de Impacto nos Negócios ou similar, fornecendo requisitos de serviço claros para RPO, RTO e MTO
Próximas etapas
Agora que você aprendeu sobre o cenário em um alto nível, você pode seguir em frente para aprender sobre a arquitetura projetada para o caso de uso.